In save six, a retreating scout (upper left hand corner) can be redirected to the system it just retreated from (enabled retreat fix, config files included in archive). The fleet then disappears from the screen completely and reemerges the next turn when its presence triggers a space encounter.
In save five, the second combat event that occurs that turn crashes the game. It crashes part way through on auto, but also part way through when I attempted to manually resolve.
If you select a fleet and then click on a destination, and then click on the system they are orbiting the UI will let you dispatch the fleet to the system they are already orbiting. They'll move to the left side of the planet and will go back to the right side after you hit turn.
(EDIT: This is actually also present in vanilla 1.3, but becomes far more noticeable an issue with fleet reselect)
One suggestion for fleet reselect on dispatch is that in the event that the fleet will end up with 0 ships selected (eg. after sending both scouts), to select the entire remainder of the fleet. Eg. Instead of going send scout -> send scout -> select colony ship -> send colony ship, you would be able to remove the second to last step.
Jeff Graw Wrote:Mouse pointer handling needs lots of work.
Things have hopefully improved since this message. Does v0.5-48 (or later) still have issues on your setup?
Quote:In that case, doing the adjustment right after sending transports (only if the resulting ECO position would lead to waste) instead of during turn processing could be a better idea.
Consider the following scenarios. (These may be erroneous, correct me if I'm mistaken.)
Terraform:
Player is terraforming with a large ECO investment.
Player sends transports to elsewhere; ECO does not drop to waste.
Next turn: waste is cleaned, terraforming continues.
ECO is now where it was.
v1.3:
Player has ECO at minimum clean (A) on a growing planet.
Player sends transports to elsewhere; ECO drops to waste.
Next turn: all waste is not cleaned, but ECO is autoadjusted to new minimum clean near the end of turn processing.
ECO is now at minimum clean (B > A).
Next turn: remaining waste is cleaned, ECO is not autoadjusted as it is above the minimum clean.
ECO is now above minimum clean.
Adjust on transport:
Player has ECO at minimum clean (A) on a growing planet.
Player sends transports to elsewhere; ECO drops to waste and autoadjusts to minimum clean (C > A)
Next turn: waste is cleaned and ECO is not autoadjusted to minimum clean (since ECO is above minimum clean).
ECO is now above minimum clean (C > A).
Next turn: ECO is not autoadjusted as it is above the minimum clean.
ECO is now above minimum clean.
I think C > B as the amount to clean all the waste must be more than the remaining waste. This results in adjusting on transport making the overshoot worse. As a sidenote, the autoadjustment is done on game load so there is a very tedious way to trigger it.
Smart adjustment would have to kick in (again) at the *next* next turn at which point distinguishing between terraforming/cloning and post-transport mess is troublesome.
Governor:
Player has ECO at minimum clean (A) on a growing planet.
Player sends transports to elsewhere; ECO drops to waste.
Player toggles the governor off/on (or on/off); ECO is at minimum clean (C > A).
Next turn: waste is cleaned and ECO is not autoadjusted to minimum clean (since ECO is above minimum clean).
Governor on: ECO is set to minimum clean (D ~ A). Governor off: ECO is above minimum clean; toggle on/off to set to minimum clean (D ~ A).
At this point I won't add any more calls to the autoadjustment. The governor can help.
Going through game_turn_build_eco with a fine-tooth comb revealed two translation bugs which resulted in overeffective waste cleanup. Daily production not wasted.
Quote:This is assuming that values above minimum clean but below +1 POP give some unlisted benefit to POP growth, which admittedly isn't something I've thought about before but judging from your comment sounds like the case.
The game tracks population tenths. In the MOO1 SAVEx.GAM saves these are at offsets 0xb8 * N + 0x70. As for the unlisted benefit, see game_turn_build_eco and game_get_pop_growth_for_eco in the source (or disassembly if you suspect a translation error).
Quote:Alternatively, or more likely additionally, cloning could display to the tenth decimal place when <10 POP/Turn. Besides giving more information to the player, this way when one sees something like "+0.1 POP" it's a marker that some amount of overshoot has occurred, rather than needing to play around with the slider to tell.
Let's say there are 8 of existing population tenths. If the ECO production would add 3, is that "+0.3" or "+1.1"?
The current related "clean" or "+1" answer seems to be the latter, but the code may actually be counting the tenths twice (in game_get_pop_growth_max and game_turn_build_eco/game_planet_get_slider_text/starmap_draw_sliders_and_prod). What a mess.
Implemented the "+0.3" version for -uiextra. Unfortunately the + did not fit. (v0.5-50)
(July 11th, 2018, 13:52)Jeff Graw Wrote: Found a few issues.
Thanks, will take a look. A small request: please use zip or 7z, rar is not very Free software friendly.
So... anyone got late game saves with near max tech and huge fleets? SAVEx.GAM is OK too. Gimme.
(July 12th, 2018, 01:53)1oom_aaron Wrote: Things have hopefully improved since this message. Does v0.5-48 (or later) still have issues on your setup?
It's perfect now
(July 12th, 2018, 01:53)1oom_aaron Wrote: Smart adjustment would have to kick in (again) at the *next* next turn at which point distinguishing between terraforming/cloning and post-transport mess is troublesome.
Yeah, looks like it's all more complicated than I assumed it would be. To be honest, I don't fully understand how waste works in MoO 1. It does strike me though that if waste is >minimum clean and <+0.1 POP it should be safe to adjust downwards. Otherwise, isn't it throwing away production? Or does that excess production get carried forward into future turns? If not, then alternatively (or additionally) excess ECO production that would otherwise go nowhere and do nothing could be treated like a reserve infusion?
(July 12th, 2018, 01:53)1oom_aaron Wrote: Going through game_turn_build_eco with a fine-tooth comb revealed two translation bugs which resulted in overeffective waste cleanup. Daily production not wasted.
Good to hear. I did have a feeling that after sending transports colonies would often repopulate more quickly than I seemed to recall. I bet that was related to the bug. But it's also possible I'm mis-remembering.
(July 12th, 2018, 01:53)1oom_aaron Wrote: Implemented the "+0.3" version for -uiextra.
Yeah, I agree that makes the most sense. Other way would be inconsistent with how factory production is reported.
I also want to let you know that 1oom is now absolutely my favourite way to play MoO 1. My work on DG has kind of spoiled me to the point where I can't much stomach vanilla MoO 1 because of the more cumbersome interface and lack of combat auto resolve. But MoO 1 is still a wholly different and great game that DG doesn't completely replace (not to mention DG is also unfinished), which means that for the last couple of years I've been left with something of a MoO 1 itch I couldn't satiate. Thanks to 1oom, I can finally get my MoO 1 fix again
Jeff Graw Wrote:In save six, a retreating scout (upper left hand corner) can be redirected to the system it just retreated from (enabled retreat fix, config files included in archive).
Redirection is not possible with the (PBX made from the) provided PBXIN. Did you forget -file fixbugs.pbx? Config file is irrelevant as -file is not saved there (or anywhere else). An attempt at better documentation is up.
Quote:The fleet then disappears from the screen completely and reemerges the next turn when its presence triggers a space encounter.
This happens in v1.3 too. Fixed.
Quote:In save five, the second combat event that occurs that turn crashes the game.
Fixed. It was due to a mistranslation in the Ion/Neutron Stream Projector code. (SI == defender index, DI == attacker index messes up my brain.)
The save also shows that cloaking was not working.
Quote:If you select a fleet and then click on a destination, and then click on the system they are orbiting the UI will let you dispatch the fleet to the system they are already orbiting.
I suppose this could be used as a part of a DDOS (distributed denial of spacefleet) attack where the player floods the fleet enroute table to prevent opponents from sending fleets. Since that is a bit farfetched and this is v1.3 behaviour, I'll leave it as is for now. Thanks for pointing it out.
EDIT: Thought about this again and decided to fix it (v0.5-74).
Quote:One suggestion for fleet reselect on dispatch is that in the event that the fleet will end up with 0 ships selected (eg. after sending both scouts), to select the entire remainder of the fleet.
Good idea. Done.
(July 12th, 2018, 03:52)Jeff Graw Wrote: To be honest, I don't fully understand how waste works in MoO 1.
Same here. Having waste on a planet seems to be beneficial for population growth.
Quote:It does strike me though that if waste is >minimum clean and <+0.1 POP it should be safe to adjust downwards. Otherwise, isn't it throwing away production? Or does that excess production get carried forward into future turns?
What if the player set it to 0.2 but it temporarily dips to clean-but-almost-0.1 due to transports?
The 0.1 production (or 0.2 for Silicoids) goes to population tenths. Anything below is thrown away (assuming no terraforming etc). I won't be changing how the MOO economy works.
Also should mention that besides transports, the planet can drop to waste due to increased tax, security, spying, trade...
I think the adjustment automation is currently sufficient. Too much of it can get in the way.
Quote:I did have a feeling that after sending transports colonies would often repopulate more quickly than I seemed to recall. I bet that was related to the bug. But it's also possible I'm mis-remembering.
Plausible. I'll do a few side-by-side tests. EDIT: Now the growth seems to be just as fast as in v1.3, too lazy to check the past 1oom versions.
Quote:I also want to let you know that 1oom is now absolutely my favourite way to play MoO 1.
Glad to hear that! Your input has really helped the project. I'll peek at DG when you post a git URL
(July 12th, 2018, 01:53)1oom_aaron Wrote: So... anyone got late game saves with near max tech and huge fleets? SAVEx.GAM is OK too. Gimme.
You mean a save file from a game played in 3.1 (or kyrub's patch) would work for the purpose too? Those shouldn't be too hard to dig up; I'll look around.
Is there a simple way to convert MoO's .gam files to 1oom's .bin files and vice-versa, by the way?
Also: I've not had much time to play around with 1oom, but from 50ish turns of messing around in the basic Classic mode, I found a couple of bugs:
1) Techs at the very top of their rung (i.e. whose tech level is a multiple of 5) appear to open two rungs above them on the tech tree; e.g. completing Improved Eco Restoration (tech level 5, tier 1) gave me the option to research Controlled Toxic Environment (tier 3) and completing Duralloy Armor (tech level 10, tier 2) gave me the option to research Zortium Armor (tier 4). These techs should only open up the very next tech tier.
2) When you reduce tech spending in one field to 0, the screen displays a ("one click wide") blue bar in that field, slightly displaced to the left of the tech bar. In MoO, this graphic appears when you have exactly "half a click" in a field (i.e. 1% of your total research budget) - when you have no research in the field, no blue bar is displayed at all.
(July 18th, 2018, 12:48)RefSteel Wrote: You mean a save file from a game played in 3.1 (or kyrub's patch) would work for the purpose too? Those shouldn't be too hard to dig up; I'll look around.
Saves from v1.3 will work for my purposes. I'm not sure about saves made with kyrub's patch, but it would be interesting to find out.
Quote:Is there a simple way to convert MoO's .gam files to 1oom's .bin files and vice-versa, by the way?
1oom_saveconv is for that very purpose. Simplicity is in the CLI of the beholder. The documentation should be clear enough but could use improvements.
Quote:Also: I've not had much time to play around with 1oom, but from 50ish turns of messing around in the basic Classic mode, I found a couple of bugs:
Thanks for the report, will take a look. EDIT: Fixed in v0.5-74.
- Saves made with kyrub's patch are indistinguishable from saves made with v1.3, and load equally in both versions; just to be sure though, I just used with your 1savconv tool to convert a saved game that was originally created with kyrub's patch, and loaded it successfully in 1oom! That being the case, here are a handful of example save files in .gam format:
- The final save from OSG-33 (this site's most-recent succession game here!) in 2524 with techs like Zeon missiles in hand.
- Codehappy's final save from Imperium 27 which does feature end-game tech. There are also a number of ships, buuuuuuuuut ... well, have a look for yourself. Of these three, this is the only one that was originally created and played in v1.3 without kyrub's patch.
- The save attached to this post from a game Maniac Marshall went on to win in spite of the fact that as of this save, his Silicoids are in Final War! The techs involved in this save are much earlier than the other two, as I recall, but I'm guessing this one probably has (by far) the largest number of AI fleets of the three.
Are these the sorts of things you're looking for? And should I try to dig up more?
(July 19th, 2018, 04:54)RefSteel Wrote: Are these the sorts of things you're looking for? And should I try to dig up more?
Yes! Thanks. These will do for now. Time for some grueling overflow debugging...
EDIT: After taking a closer look, the fleets here are not quite big enough. The saves did help to spot and fix 5 bugs.
The specific situations I'm hoping to debug are:
AI has fleets with high tech and/or (say) 3000+ ships but is afraid to send them to enemy planets.
AI attacks with big fleet but retreats from battle even with overkill numbers and/or tech.
Saves demonstrating #1 would be very helpful. I think I can tackle #2 by editing the OSG-33 save. The save editing process (1oom_saveconv -o t) is rather tedious if the available techs need to be altered.
EDIT 2: If there is interest in forum archaeology then digging up the posts referenced in the unofficial patch post would be a big help in implementing the 1.40m fixes in 1oom.
The project has reached a point where the game is fully playable, not crashing all the time and actually fighting back.
Many of the undoubtedly remaining bugs will need MOO1 expertise to spot. If you can beat MOO1 on impossible (which the project maintainer has yet to do) then please give this a whirl and report any oddities you encounter.
On the other hand, many of the remaining bugs will be obvious once bumped into. Play and report! Onward to v1.0!
Still looking for big endian hardware test results.
(August 2nd, 2018, 22:33)thrawn Wrote: I don't know how you've coded it and perhaps it's already done, but as an idea I imagine that if you structure it as a game engine to which clients connect, it will be very easy to add multiplayer functionality, and it will allow us to play with the AI and implement a completely independent AI player in whatever language we are most comfortable.
Refactoring for client/server is a multi-month effort that I will not attempt before v1.0 is out. Note that implementing AI as a client in such a model would not allow it to cheat.
While waiting, one can add src/game/game_ai_external.c which hooks to whichever language you prefer. (Just don't expect it to get merged.)
