Are you, in fact, a pregnant lady who lives in the apartment next door to Superdeath's parents? - Commodore

Create an account  

 
Reversing to Orion - project 1oom

(January 14th, 2019, 10:53)eMeM Wrote:
(January 12th, 2019, 10:31)Tapani Wrote: Personally I find the idea of forcing every 1oom player to compile their own PBX file to enable even basic fixes very un-user friendly. I'm strongly leaning toward changing 1oom default to include all fixes + kyrub improvements enabled, but also provide an easy way to downgrade to original (v1.3) behaviour. (This default behaviour change is already present in my own internal development version, but I have not dared to push them until I hear more what you, the users, think).

That would make sense. I found it hard to push myself to test 1oom version because original MOO is too easy for experienced player.

Do you have some sort of plans for your fork of 1oom? I think 1oom_aaron's original plans to add multiplayer were great but overambitious.

My own random ideas:
  • In next research window - show top tier techs in slightly different color.
  • In new spaceship window - show obsolete weapons in slightly different color e.g. nuclear bombs when we have fusion bombs available.
  • Change random events so all of them can happen to human and AI players.
  • Give AI ability to attack and capture Orion.
  • Make revolt on a human player system non-random but from spying. I've lost few games in Kyrub's version to this without meeting any other race!
  • I wonder how would it look like if human player wasn't protected with 1 guaranteed colonizable system in 3 parsecs and no other races in 7 parsecs. There is a danger current AI would struggle from early attack.

There are some very good ideas there!

Usually when I do things like this with 1oom (done it before ... ), I try not to loudly declare all kind of things I am going to do - I rather just do them first. Walk the walk before I talk the talk. But in the case 1oom I feel I am new to the MOO "community" (did not even know one existed until a few days ago!), so I do not know what people in general think. And I am happy to discuss things.

So, sorry if this post is going to be a bit long. Since I do have many thoughts :-)

About AI
In case of 1oom, my hopes were to make a better AI - one that does not cheat, but plays by same rules as the human. This does not come without some follow-up decisions about the game. For instance what you write about the starting conditions. The galaxy generator will guarantee players 1 ( = human player ) and player 2 ( = an AI ) a habitable world within 3 parsecs (however, due to a bug in the distance code, sometimes this turns out to be within 4 pc instead). I think the original intent was to guarantee a world to all players, but the original algorithm is too inefficient to scale the starting conditions to all players (it took my core i7 more than 2h to generate a galaxy with 5 players having these starts!). If the computers are not cheating, they should be given the same starts as the human. In my ai-development version, I have optimized the galaxy generator so the common start conditions apply to all players - and is still very fast. Actually I think this might have been the original intent, but the original programmer was not very good at algorithms.

The human player also has advantages in scout vs scout fights. The current AI always flees, a feature greatly abused by experienced players.
My new AI so far does not flee, and instead all early scout fights end up in 50 turn marathon - with the AI winning every time. (The game has hard coded that the AI always wins a timed out fight with the human). This does not make the game anymore fun. I'll probably change this to defending player winning, and / or in the case of unarmed ships, both fleets ending up in orbit and exploring the world without a fight. Or smth.

The new AI should make attempts to take Orion when strong enough, and not avoid Orion (in fact would not even know which system is Orion until it has run into the Guardian). This is a minor point, there are many greater challenges before this.

About Multiplayer
My predecessor had a vision about a multiplayer MOO. Adorable, but I think the game is too unbalanced to be viable in multiplayer. Klackons and Psilons rule, and the initial techs researchable are decisive. This is an endeavour I will not pursue any time soon, but will try not to break what little is there.

About Random Events
My take on these are that mostly these are a nuisance, and I usually play with them turned off. But if I make an AI that does not cheat, then the same rules about events should apply to humans and AI alike.

Also I thought revolts were random... but I have never played with Kyrub's patch. Found out about it long after I discovered 1oom (which was late November).


About Research Window
I like you idea to somehow highlight the top rung techs, so it is easier to know which ones open next category. Maybe also if it is a tech nobody else has (as far as you know).
Another thought I have played around with is whether it should be possible to change tech being researched at any time (with a loss of all research in that area).

About Ship Designer
The idea to highlight the latest in each "category" is interesting. As addition I would probably guarantee that the latest in each category is available - had a game where could not make a bomber since my best bomb (Anti-matter or smth) was too low tech level to be chosen.

Planet View
Long time ago, I tried to make my own MOO reimplementation. While I never finished, some of the features I added there was the option to change what is being built in most categories. To be able to flip between shield and missilie bases, terraforming and pop, factories and reserve etc.
Something I already added to 1oom is the ability to do finer adjustments to the slider. By default clicking on the arrows the slider moves +-4%, but in the latest 1oom (my fork) ctrl clicking allows changes of +-1%.
 

Game Balance
Missile bases and planetary shields seems a bit overpowered / underpriced. Worried that making an AI that plays as good as possible, might have to use this strategy too - which would be pretty sad.
Also some early techs are a must - maybe guarantee that one of the early production boost techs is researchable (robotics control III, IV, and terraforming +20,+30 and +40).
Same way guarantee one missile, one bomb, one planetary shield, one hand weapon, one armor better than titanium, one engine faster than retros etc.
The optimized galaxy generator also guarantees that the habitable world each player gets is not ultra-poor.

Looks
Esthetics seems a little more important to me than my predecessor. The uiextra race selection screen looks like sh*t, and so does some other things (the huge year display in the galaxy map, the funny research bonus LED, the new meny with sound volume and stuff ... ).  Let's see when I have time.

Actually I changed the research bonus LED to be indicated by the research level instead. Bright red means bonus exceeded, and normal means max bonus.

Also my predecessor had a strong opinion of NOT making scaler etc for 1oom to be "prettier". I strongly disagree, but have refrained from pushing any changes that might cause controversy, in case he might return. But one day I have to assume he is dead, and go my own way without his guidance.


These are many thoughts, and there are even more but I think this is enough about where I might be going. I am very happy to hear about ideas and opinions - and please stop me doing stupid things before I do them :-)
Reply

(January 14th, 2019, 12:33)Tapani Wrote: About AI
In case of 1oom, my hopes were to make a better AI - one that does not cheat, but plays by same rules as the human. This does not come without some follow-up decisions about the game. For instance what you write about the starting conditions. The galaxy generator will guarantee players 1 ( = human player ) and player 2 ( = an AI ) a habitable world within 3 parsecs (however, due to a bug in the distance code, sometimes this turns out to be within 4 pc instead). I think the original intent was to guarantee a world to all players, but the original algorithm is too inefficient to scale the starting conditions to all players (it took my core i7 more than 2h to generate a galaxy with 5 players having these starts!). If the computers are not cheating, they should be given the same starts as the human. In my ai-development version, I have optimized the galaxy generator so the common start conditions apply to all players - and is still very fast. Actually I think this might have been the original intent, but the original programmer was not very good at algorithms.

Wouldn't it be possible to streamline the algorithm? Basically, upfront generate a habitat world within 3 parsecs of every player's home world, and then randomly generate all the rest?
Reply

(January 14th, 2019, 15:42)Bionic Commando Wrote:
(January 14th, 2019, 12:33)Tapani Wrote: About AI
In case of 1oom, my hopes were to make a better AI - one that does not cheat, but plays by same rules as the human. This does not come without some follow-up decisions about the game. For instance what you write about the starting conditions. The galaxy generator will guarantee players 1 ( = human player ) and player 2 ( = an AI ) a habitable world within 3 parsecs (however, due to a bug in the distance code, sometimes this turns out to be within 4 pc instead). I think the original intent was to guarantee a world to all players, but the original algorithm is too inefficient to scale the starting conditions to all players (it took my core i7 more than 2h to generate a galaxy with 5 players having these starts!). If the computers are not cheating, they should be given the same starts as the human. In my ai-development version, I have optimized the galaxy generator so the common start conditions apply to all players - and is still very fast. Actually I think this might have been the original intent, but the original programmer was not very good at algorithms.

Wouldn't it be possible to streamline the algorithm? Basically, upfront generate a habitat world within 3 parsecs of every player's home world, and then randomly generate all the rest?

Yes, and I did. But not in the way you suggested, since the galaxy generator code is surprisingly long and I did not want to change more than necessary, but instead keep as much as possible as original. It was enough to make a cleverer home selection algorithm.

FYI:

The original homeworld selection code is like:
1. Create a galaxy
2. Pick (all) homeworlds at random
3. Check that homeworlds (for N first players) have a habitable world within 3 pc, and that no other homeworlds are within 8 pc
4. If any of the conditions in 3 fail, go to 2
5. If they have failed 200 times or more, go to 1

The stupid parts are: for each random selection, all checks are done. Even if the first homeworld fail the distance check, all are still checked. And if a colonizable world is found within 3 pc, it still continues calculating the distances to all stars.

The new code is smarter:
1. Create a galaxy
2. Generate a table of suitable stars that have a colonizable world within 3 pc
3. Select homeworlds randomly from the table
4. Check if any selected homeworlds are within 7 pc from each other
5. Replace the homeworld with most 'conflicts' (other homeworlds within 7pc) with a new star from the colonizable stars table. Go to 4
6. When all suitable stars (not all combinations) have been candidates, go to 1 (actually it retries with step 3 a few times, since step 1+2 is MUCH slower than steps 3--5 together).

This is much much faster, and six homeworlds can be selected well under 1ms on a core i7.

For the pedants: there is a slight change on the homeworld distance constraint. It is too improbable to be able to place six homeworlds on a small map without any pair being within 8 pc (probability maybe less than 0.00001). So on small maps the distance limit is lowered to 7 pc (for large galaxies it is 8 pc, and 9 pc for huge).

This new algorithm has not been pushed yet, and I am not sure if it should be default or not.
Reply

(January 14th, 2019, 12:33)Tapani Wrote: About AI
The human player also has advantages in scout vs scout fights. The current AI always flees, a feature greatly abused by experienced players.
My new AI so far does not flee, and instead all early scout fights end up in 50 turn marathon - with the AI winning every time. (The game has hard coded that the AI always wins a timed out fight with the human).  This does not make the game anymore fun. I'll probably change this to defending player winning, and / or in the case of unarmed ships, both fleets ending up in orbit and exploring the world without a fight. Or smth.

Developing good AI with same rules (no bonuses) is as hard as making a multiplayer version or even harder. Regarding scouts battle my proposition is: simple, easy & average difficulty = AI runs away. Hard & impossible difficulty = human player runs away. Question is what should happen when you have AI vs AI scouts battle. Defending player wins or both stay is also good.

AI vs AI battle algorithm is source of many problems. Sometimes you can see a fleet attacking enemy star system. They win a battle but missile bases aren't destroyed. Then if they somehow manage to capture new system, attacking fleet doesn't defend it so they will lose to other race few turns later. In AI vs AI Klackons and Meklars have much more chances to capture a new system than other races. Other races need to have a huge tech advantage to win a battle meaning most of the time only Psilons can do it.

Quote:The new AI should make attempts to take Orion when strong enough, and not avoid Orion (in fact would not even know which system is Orion until it has run into the Guardian). This is a minor point, there are many greater challenges before this.

Agree. It's important to keep AI away from dumping their fleets against much stronger enemies like Guardian.

Quote:About Multiplayer
My predecessor had a vision about a multiplayer MOO. Adorable, but I think the game is too unbalanced to be viable in multiplayer. Klackons and Psilons rule, and the initial techs researchable are decisive. This is an endeavour I will not pursue any time soon, but will try not to break what little is there.

Main problem here is 1oom needs original lbx files from old non-free DOS game. That's why making a multiplayer version is pointless because there aren't many players left who have MOO. It's different from other game which was re-released for free that you've made a famous patch.

Quote:About Random Events
My take on these are that mostly these are a nuisance, and I usually play with them turned off. But if I make an AI that does not cheat, then the same rules about events should apply to humans and AI alike.

Quote:About Research Window
As addition I would probably guarantee that the latest in each category is available - had a game where could not make a bomber since my best bomb (Anti-matter or smth) was too low tech level to be chosen.
Quote:Game Balance
Missile bases and planetary shields seems a bit overpowered / underpriced. Worried that making an AI that plays as good as possible, might have to use this strategy too - which would be pretty sad.
Also some early techs are a must - maybe guarantee that one of the early production boost techs is researchable (robotics control III, IV, and terraforming +20,+30 and +40).
Same way guarantee one missile, one bomb, one planetary shield, one hand weapon, one armor better than titanium, one engine faster than retros etc.
The optimized galaxy generator also guarantees that the habitable world each player gets is not ultra-poor.

For me random factor of MOO research tree is what makes games more interesting and more memorable. One of the main reasons why I still play this game after 25 years. It gives us great replayability factor. That's one of the main differences between MOO and other 4X games like Civ or MOO2. I wouldn't mess with it. Let say I don't have Improved Robotics or Eco tech. This forces me to trade, spy or attack race that does have it. Sometimes I don't have bombs but one of my opponents doesn't have planetary shields or there are opponent star systems in nebulas. If I need quick expansion to gain votes I'm forced to attack them first.

I know it's a bug but I like games with RNG forcing me to start without second colony or with ultra-poor system or very tiny. Another part of replayability factor. I never played OSG save games but lot of those save games are based on unlucky beginnings.

I don't think lack of bombs in research tree should be an issue for human player because:
  • "Weapons beyond max defense: Mauler Device, Death Ray, Anti-Matter Bomb, Omega-V Bomb, Neutronium Bomb, Plasma Torps." (quote from Jon Sullivan's FAQ). Death Ray is guaranteed in all games but sometimes Orion might be outside of our limited range.
  • Bio terminator (eco-friendly AIs will not use it)
  • Ion/Neutron stream projector
  • Combat transporters
  • Destroy missile bases with spies
Problem is AI is not good in using any of these options. Even when they have bombs they barely use it in ship designs.

Quote:Planet View
Long time ago, I tried to make my own MOO reimplementation. While I never finished, some of the features I added there was the option to change what is being built in most categories. To be able to flip between shield and missilie bases, terraforming and pop, factories and reserve etc.
Something I already added to 1oom is the ability to do finer adjustments to the slider. By default clicking on the arrows the slider moves +-4%, but in the latest 1oom (my fork) ctrl clicking allows changes of +-1%.

Good change. I would propose to set it to default.

Quote:Looks
Esthetics seems a little more important to me than my predecessor. The uiextra race selection screen looks like sh*t, and so does some other things (the huge year display in the galaxy map, the funny research bonus LED, the new meny with sound volume and stuff ... ).  Let's see when I have time.

Actually I changed the research bonus LED to be indicated by the research level instead. Bright red means bonus exceeded, and normal means max bonus.

Also my predecessor had a strong opinion of NOT making scaler etc for 1oom to be "prettier". I strongly disagree, but have refrained from pushing any changes that might cause controversy, in case he might return. But one day I have to assume he is dead, and go my own way without his guidance.

I think Remnants of the Precursors Java project will be more suited to get a better UI. I'm not sure it's worth your time to develop new UI unless it's just minor changes.

If he already stated on project website that he's dead it means there is no reason to wait.

Other minor ideas:
  • Clicking right mouse button on a Build new colony screen cancels building. Sometimes I misclick it and it annoys me. I would prefer to have a button to cancel and right click building a colony. I'm not sure if others agree as in MOO UI right click always means cancel.
  • Same with choose the type of tech to steal screen. Right button cancels spying at all. Sometimes I misclick on this screen and I'm annoyed because I don't get a tech. I think it's a bug. It shouldn't be possible to cancel spying. There are different ways to stop spying.
Reply

(January 15th, 2019, 03:47)Tapani Wrote:
(January 14th, 2019, 15:42)Bionic Commando Wrote:
(January 14th, 2019, 12:33)Tapani Wrote: About AI
In case of 1oom, my hopes were to make a better AI - one that does not cheat, but plays by same rules as the human. This does not come without some follow-up decisions about the game. For instance what you write about the starting conditions. The galaxy generator will guarantee players 1 ( = human player ) and player 2 ( = an AI ) a habitable world within 3 parsecs (however, due to a bug in the distance code, sometimes this turns out to be within 4 pc instead). I think the original intent was to guarantee a world to all players, but the original algorithm is too inefficient to scale the starting conditions to all players (it took my core i7 more than 2h to generate a galaxy with 5 players having these starts!). If the computers are not cheating, they should be given the same starts as the human. In my ai-development version, I have optimized the galaxy generator so the common start conditions apply to all players - and is still very fast. Actually I think this might have been the original intent, but the original programmer was not very good at algorithms.

Wouldn't it be possible to streamline the algorithm? Basically, upfront generate a habitat world within 3 parsecs of every player's home world, and then randomly generate all the rest?

Yes, and I did. But not in the way you suggested, since the galaxy generator code is surprisingly long and I did not want to change more than necessary, but instead keep as much as possible as original. It was enough to make a cleverer home selection algorithm.

The new code is smarter:
1. Create a galaxy
2. Generate a table of suitable stars that have a colonizable world within 3 pc
3. Select homeworlds randomly from the table
4. Check if any selected homeworlds are within 7 pc from each other
5. Replace the homeworld with most 'conflicts' (other homeworlds within 7pc) with a new star from the colonizable stars table. Go to 4
6. When all suitable stars (not all combinations) have been candidates, go to 1 (actually it retries with step 3 a few times, since step 1+2 is MUCH slower than steps 3--5 together).

This is much much faster, and six homeworlds can be selected well under 1ms on a core i7.

For the pedants: there is a slight change on the homeworld distance constraint. It is too improbable to be able to place six homeworlds on a small map without any pair being within 8 pc (probability maybe less than 0.00001). So on small maps the distance limit is lowered to 7 pc (for large galaxies it is 8 pc, and 9 pc for huge).

This new algorithm has not been pushed yet, and I am not sure if it should be default or not.

That's a great way to implement the placement algorithm.  I like parameterizing the distance based on the galaxy size, as you've done. Perhaps that could even be settable by the player.

Finally, I really like the effort by the original developer. However, I've been wondering if it would make sense to convert his work from C to Python and perhaps refactor the work? The idea here is that Python is generally more accessible (i.e. there are many code snippets on this forum alone) than C and I bet you could get a broader community effort. Plus, if the code were refactored to be more object-oriented, then over the long haul it'd likely be possible to make various aspects of the game more expandable. For example, if the community wanted to create a new race in the game it would be fairly challenging at this point -- the racial bonuses are set and used in a variety of places in the code. For example, you would have to change game_num to account for research bonuses and racial interaction defaults and then visit the various relevant functions to implement a racial check for their various bonuses. My idea is that you could develop an object oriented system where various bonuses and functions are implemented at the race level to streamline future expansion.

I'd be curious on your thoughts here.
Reply

(January 15th, 2019, 10:30)eMeM Wrote:
(January 14th, 2019, 12:33)Tapani Wrote: About AI
The human player also has advantages in scout vs scout fights. The current AI always flees, a feature greatly abused by experienced players.
My new AI so far does not flee, and instead all early scout fights end up in 50 turn marathon - with the AI winning every time. (The game has hard coded that the AI always wins a timed out fight with the human).  This does not make the game anymore fun. I'll probably change this to defending player winning, and / or in the case of unarmed ships, both fleets ending up in orbit and exploring the world without a fight. Or smth.

Developing good AI with same rules (no bonuses) is as hard as making a multiplayer version or even harder. Regarding scouts battle my proposition is: simple, easy & average difficulty = AI runs away. Hard & impossible difficulty = human player runs away. Question is what should happen when you have AI vs AI scouts battle. Defending player wins or both stay is also good.

AI vs AI battle algorithm is source of many problems. Sometimes you can see a fleet attacking enemy star system. They win a battle but missile bases aren't destroyed. Then if they somehow manage to capture new system, attacking fleet doesn't defend it so they will lose to other race few turns later. In AI vs AI Klackons and Meklars have much more chances to capture a new system than other races. Other races need to have a huge tech advantage to win a battle meaning most of the time only Psilons can do

Making a competitve AI is definitely really hard, while multiplayer is just straightforward coding that a competent software engineer can do even without caffeine.
Not sure my AI will ever be up to the task (probably not), but that is the fun of it: be able to pit my creativity against a hard challenge.

Also AI vs AI battles uses a simplified combat routine, that just tries to fake a reasonable result. I was hoping to see if the same algorithm as AI vs Human can be used in all battles, for more realistic results.

(January 15th, 2019, 10:30)eMeM Wrote:
(January 14th, 2019, 12:33)Tapani Wrote: About Multiplayer
My predecessor had a vision about a multiplayer MOO. Adorable, but I think the game is too unbalanced to be viable in multiplayer. Klackons and Psilons rule, and the initial techs researchable are decisive. This is an endeavour I will not pursue any time soon, but will try not to break what little is there.

Main problem here is 1oom needs original lbx files from old non-free DOS game. That's why making a multiplayer version is pointless because there aren't many players left who have MOO. It's different from other game which was re-released for free that you've made a famous patch.

LBX files are a problem, but that is a matter of graphics ... we'd need a graphics artist, and probably a rewriting of the UI layer to handle true colour graphics.

(January 15th, 2019, 10:30)eMeM Wrote:
(January 14th, 2019, 12:33)Tapani Wrote: Game Balance
Missile bases and planetary shields seems a bit overpowered / underpriced. Worried that making an AI that plays as good as possible, might have to use this strategy too - which would be pretty sad.
Also some early techs are a must - maybe guarantee that one of the early production boost techs is researchable (robotics control III, IV, and terraforming +20,+30 and +40).
Same way guarantee one missile, one bomb, one planetary shield, one hand weapon, one armor better than titanium, one engine faster than retros etc.
The optimized galaxy generator also guarantees that the habitable world each player gets is not ultra-poor.

For me random factor of MOO research tree is what makes games more interesting and more memorable. One of the main reasons why I still play this game after 25 years. It gives us great replayability factor. That's one of the main differences between MOO and other 4X games like Civ or MOO2. I wouldn't mess with it. Let say I don't have Improved Robotics or Eco tech. This forces me to trade, spy or attack race that does have it. Sometimes I don't have bombs but one of my opponents doesn't have planetary shields or there are opponent star systems in nebulas. If I need quick expansion to gain votes I'm forced to attack them first.

At least it is too hard to win on impossible level for me unless I get at least some production boost technology. As it is now, I might spend an evening on a game before finding out I was already lost from the beginning.
But, maybe it is not a general problem, just a me problem.

(January 15th, 2019, 10:30)eMeM Wrote:
(January 14th, 2019, 12:33)Tapani Wrote: Looks
Esthetics seems a little more important to me than my predecessor. The uiextra race selection screen looks like sh*t, and so does some other things (the huge year display in the galaxy map, the funny research bonus LED, the new meny with sound volume and stuff ... ).  Let's see when I have time.

Actually I changed the research bonus LED to be indicated by the research level instead. Bright red means bonus exceeded, and normal means max bonus.

Also my predecessor had a strong opinion of NOT making scaler etc for 1oom to be "prettier". I strongly disagree, but have refrained from pushing any changes that might cause controversy, in case he might return. But one day I have to assume he is dead, and go my own way without his guidance.
I think Remnants of the Precursors Java project will be more suited to get a better UI. I'm not sure it's worth your time to develop new UI unless it's just minor changes.

If he already stated on project website that he's dead it means there is no reason to wait.

People are known to change their minds, even about dying. Knowing from experience with other games (as you mentioned), I know how easy it is to think that this is it, I am done ... but in a few months feel the itch and return.

(January 15th, 2019, 10:30)eMeM Wrote: Other minor ideas:
  • Clicking right mouse button on a Build new colony screen cancels building. Sometimes I misclick it and it annoys me. I would prefer to have a button to cancel and right click building a colony. I'm not sure if others agree as in MOO UI right click always means cancel.
  • Same with choose the type of tech to steal screen. Right button cancels spying at all. Sometimes I misclick on this screen and I'm annoyed because I don't get a tech. I think it's a bug. It shouldn't be possible to cancel spying. There are different ways to stop spying.

That sounds like a you problem with left and right. At least I have never cancelled a colony build ...

(January 15th, 2019, 10:55)Bionic Commando Wrote: That's a great way to implement the placement algorithm.  I like parameterizing the distance based on the galaxy size, as you've done. Perhaps that could even be settable by the player.

Too much customization is confusing, and everyone ends up playing different games. I'd rather keep this parameter transparent, making a UI for setting it is not worth the effort, and as we have seen, there are settings that causes problems.

(January 15th, 2019, 10:55)Bionic Commando Wrote: Finally, I really like the effort by the original developer. However, I've been wondering if it would make sense to convert his work from C to Python and perhaps refactor the work? The idea here is that Python is generally more accessible (i.e. there are many code snippets on this forum alone) than C and I bet you could get a broader community effort. Plus, if the code were refactored to be more object-oriented, then over the long haul it'd likely be possible to make various aspects of the game more expandable. For example, if the community wanted to create a new race in the game it would be fairly challenging at this point -- the racial bonuses are set and used in a variety of places in the code. For example, you would have to change game_num to account for research bonuses and racial interaction defaults and then visit the various relevant functions to implement a racial check for their various bonuses. My idea is that you could develop an object oriented system where various bonuses and functions are implemented at the race level to streamline future expansion.

I'd be curious on your thoughts here.

Python ...  yikes  yikes

NOT. GOING. TO. HAPPEN.

I could go on a long rant against Python, but I will just mention my first experience with it:
Some time ago I found some data processing code in python that did almost what I needed. Nice! Maybe I could just modify it a bit and get away with a fifteen minute hack instead of spending the whole day making the code myself?

Well, after 2 days of 'pip', 'pip3', 'apt-get install', 'sudo pip', 'sudo pip3' (apparently 'sudo pip' and 'pip' are not the same!), having package versions magically changing, dependencies breaking in unexpected ways ...  I gave up. How can a maybe five year old program be so difficult to make working!? The language and its modules seem to break backward compatibility on almost a weekly basis, and NOBODY should build a long term project on such a platform.

My opinion is that standard C code is the most portable code there is. EVERY platform has a C compiler, and 1oom is quite well written in this respect.

And I just happen to love C heart
Reply

(January 16th, 2019, 08:48)Tapani Wrote: Python ...  yikes  yikes

NOT. GOING. TO. HAPPEN.

I could go on a long rant against Python, but I will just mention my first experience with it:
Some time ago I found some data processing code in python that did almost what I needed. Nice! Maybe I could just modify it a bit and get away with a fifteen minute hack instead of spending the whole day making the code myself?

Well, after 2 days of 'pip', 'pip3', 'apt-get install', 'sudo pip', 'sudo pip3' (apparently 'sudo pip' and 'pip' are not the same!), having package versions magically changing, dependencies breaking in unexpected ways ...  I gave up. How can a maybe five year old program be so difficult to make working!? The language and its modules seem to break backward compatibility on almost a weekly basis, and NOBODY should build a long term project on such a platform.

My opinion is that standard C code is the most portable code there is. EVERY platform has a C compiler, and 1oom is quite well written in this respect.

And I just happen to love C heart


Agree that software packages can be a nightmare. Docker is your friend for managing software versions and modules! It's life changing, trust me!
Reply

One questions to Tapani. Do you want to keep DOS version? I find it cool that 1oom still works under DOS but it might become limiting when you want to improve UI or use resource hungry algorithms.

Another UI proposal:
Mass transport window - choose multiple source star systems, choose one destination star system, choose % of population to transfer. Improved version could make all transport fleets arrive in the same turn if possible.

One of many reasons why AI is crippled is they use transport from one colony.
Reply

Guess it's safe to say that it's abandoned again. The last change was over three months ago. I've submitted a bug report together with an easy fix and it's been sitting ignored for over a month now.

I kind of want to make my own fork, but I wonder if there's anyone else who'd actually care about that. I don't have any grand plans like improving the AI, just:
  • fix the last remaining bugs (like speed reduction in nebulas)
  • make the 1.40m fixes more accessible: you should be able to activate them as a command line option without having to compile a mod file for the game.
  • maybe a game launcher so you can configure it without the command line - though I suspect you could get most of the benefit of a launcher with just two desktop shortcuts: one for classic mode, one for 1.40m mode + interface improvements.
  • I'd like to make it work for mac, but I don't have one to test it on.
Reply

I'm certainly interested!

ETA reporting through nebulae has resisted many attempts to correct it if it's still in 1oom at this point. (I haven't explored that lately.) I like your suggested updates but also lack a Mac on which to run tests.
Reply



Forum Jump: