Reversing to Orion - project 1oom

[DaveV]

I had terrible engine tech in another game, and my transports were still only had a speed of 1 when I was invading alien planets. One of my early targets was in a nebula, and the ETE was way off. The original estimate was five turns, but it actually took eight turns. I know kyrub did some work on nebula transit times, did that get lost somehow?

[RFS-81]

I had terrible engine tech in another game, and my transports were still only had a speed of 1 when I was invading alien planets. One of my early targets was in a nebula, and the ETE was way off. The original estimate was five turns, but it actually took eight turns. I know kyrub did some work on nebula transit times, did that get lost somehow?

I thought we had that fixed, but I think I remember that transports move slightly differently from regular ships inside nebulas.


About ships and bases fighting transports taking long: I think the best solution would be to just stop shooting when all transports are dead If I'm understanding the code correctly, the function doesn't even look at the number of transports and just returns how many can be shot down, even if it's a massive overkill.

Transport stacks are small: IIRC, the highest population maximum is 300. You can send half of that as transports, and transport stacks that arrive at an enemy colony on the same turn still "run the gauntlet" separately. If they run into a really huge fleet, it shouldn't take long to wipe them out. The theoretical worst case would be ten thousands of laser fighters plinking away at transports with fully upgraded armor and retro engines, but that's not going to happen in practice a lot.

[ignatius]

I had terrible engine tech in another game, and my transports were still only had a speed of 1 when I was invading alien planets. One of my early targets was in a nebula, and the ETE was way off. The original estimate was five turns, but it actually took eight turns. I know kyrub did some work on nebula transit times, did that get lost somehow?

Aaron based 1oom on moo v1.3 and not on kyrubs 1.4m version. So yes, unless he or anyone after him has fixed this again, the bug might very well have arisen from the dead.

ignatius

[RefSteel]

I don't know of any version of MoO that has managed to correctly display nebula ETA if the current version of 1oom hasn't gotten it right. I know kyrub's patch tried to fix it but was still off in some cases. The latest I've seen on the subject is from RFS-81, much earlier in this very thread.

[ignatius]

I had terrible engine tech in another game, and my transports were still only had a speed of 1 when I was invading alien planets. One of my early targets was in a nebula, and the ETE was way off. The original estimate was five turns, but it actually took eight turns. I know kyrub did some work on nebula transit times, did that get lost somehow?

I thought we had that fixed, but I think I remember that transports move slightly differently from regular ships inside nebulas.

Distance and transport time in MOO are a horrible mess. The latter is not even a metric as times are not symmetric if nebulae are present. The trouble is that game travel times are determined stepwise and implicitly in the animation code of all places. There are alternating baby steps of 5 and 6 dpc (Deziparsec) iirc with a different order for transports and ships, which together count as a 1 parsec step (one rounded down, one rounded up). This explains the slipstream effect in situations where there is no rounding down. The code to calulate these baby steps, besides being horribly inefficient, is buggy, too and iirc contains a one-off error near 45°. I did a bug compatible reimplementation of this once (see linked post).

In a nebula, one of the baby steps is skiped, so your speed effectively halved. According to the OSG, what should happen is that the loop is exited if you end a double step in a nebula, so its warp one in the nebula - which would also make more sense from a gameplay perspective imo.

About ships and bases fighting transports taking long: I think the best solution would be to just stop shooting when all transports are dead If I'm understanding the code correctly, the function doesn't even look at the number of transports and just returns how many can be shot down, even if it's a massive overkill.

Transport stacks are small: IIRC, the highest population maximum is 300. You can send half of that as transports, and transport stacks that arrive at an enemy colony on the same turn still "run the gauntlet" separately. If they run into a really huge fleet, it shouldn't take long to wipe them out. The theoretical worst case would be ten thousands of laser fighters plinking away at transports with fully upgraded armor and retro engines, but that's not going to happen in practice a lot.

Yes, this would be a better solution. What I did was insert

Code:

            while (vcur > 256 && dmgmax < 4096) {
              vcur >>= 1;
              dmgmin <<= 1;
              dmgmax <<= 1;
            }

which is small, simple and single point but introduces a slight (below 1%) inaccuracy.

ignatius

[Juffos]

Saving the game with a save name of 19 characters crashes the game. Unlikely to happen in practice but could be looked into.

If you do what the OSG calls the "Brothers Karamasow Strategy", you can try setting ECO mode (in the gov menu) to "Never build pop". The gov. never builds facts in advance of pop, so if you remove the pop each turn to send to the other "Brother", you should be OK.

This won't help when banking population for settling new planets or invasions. The governor will keep building factories, soon to be abandoned, without heavy micromanagement.

[ignatius]

Saving the game with a save name of 19 characters crashes the game. Unlikely to happen in practice but could be looked into.

I cannot reproduce the error here, as I'm unable to enter a longer name. Was this an old or converted save?

If you do what the OSG calls the "Brothers Karamasow Strategy", you can try setting ECO mode (in the gov menu) to "Never build pop". The gov. never builds facts in advance of pop, so if you remove the pop each turn to send to the other "Brother", you should be OK.

This won't help when banking population for settling new planets or invasions. The governor will keep building factories, soon to be abandoned, without heavy micromanagement.

Hm, why not simply turn the governor off, then, for the planets affected? In the early game this typically means your homeworld and your first colony (and any ultra poor worlds you happen to come across).

Anyway, with the current savefile format, we are extremely limited on stateful features.

ignatius

[RFS-81]

Saving the game with a save name of 19 characters crashes the game. Unlikely to happen in practice but could be looked into.

I cannot reproduce the error here, as I'm unable to enter a longer name. Was this an old or converted save?

That one's my fault. I already fixed it in master. It's a bug with ALL text input fields, so ... until I get around to uploading a new binary, just leave at least one space open. (That's what I get for assuming that the buflen variable stores the length of the buffer...)

Distance and transport time in MOO are a horrible mess. The latter is not even a metric as times are not symmetric if nebulae are present. The trouble is that game travel times are determined stepwise and implicitly in the animation code of all places. There are alternating baby steps of 5 and 6 dpc (Deziparsec) iirc with a different order for transports and ships, which together count as a 1 parsec step (one rounded down, one rounded up). This explains the slipstream effect in situations where there is no rounding down. The code to calulate these baby steps, besides being horribly inefficient, is buggy, too and iirc contains a one-off error near 45°. I did a bug compatible reimplementation of this once (see linked post).

Oh, I remember discovering that code in 1oom and finding out that it was basically accurate ... I swear, MOO wasn't programmed, it just mutated into existence on Steve Barcia's hard drive. If I remember correctly, the 1oom code determines travel time by simulating the fleet's flight path. (That is a change from MOO1.) But I guess it uses the ship-nebula movement also for transports which gives wrong results.

In a nebula, one of the baby steps is skiped, so your speed effectively halved. According to the OSG, what should happen is that the loop is exited if you end a double step in a nebula, so its warp one in the nebula - which would also make more sense from a gameplay perspective imo.

Do you mind elaborating why it makes sense? I really dislike moving around at Warp 1...

[ignatius]

In a nebula, one of the baby steps is skiped, so your speed effectively halved. According to the OSG, what should happen is that the loop is exited if you end a double step in a nebula, so its warp one in the nebula - which would also make more sense from a gameplay perspective imo.

Do you mind elaborating why it makes sense? I really dislike moving around at Warp 1...

Essentially, you answered your own question. ;-)

It's about territoriality. MOO is very weak on territoriality: With galaxy map creation always producing homogenous galaxy (stars are placed in a grid plus some random offset), besides the occasional astroid planet, the nebulae are the only source of topological structure. But for this to work, they have to make meaningful barriers.

As is, nebulae have some influence in the early game where they can make a difference of a couple of years. But once you have better engines, they become meaningless. If you also have better range (6+) the likelihood of major unsurmountable gaps approaches zero. So from early midgame on, the topological aspects of the map cease to matter. (I did a tool once which allowed you to "thin" out a map by turning random stars into asteroid fields to push this back a few decades.)

The OSG rules would reduce the nebula influence early (no difference when you're moving with retros) where 4 / 5 / 6 pc distances still make a difference, but would become more meaningful over time while the latter vanish.

Enter custom maps and remove the current 4 nebula limit (both of which is already supported by the current savefile format) and things can get even more interesting. This was one motivation for doing the hi-res galaxy map. My branch can already handle homogeneous maps of arbitrary size (no more dependencies on galaxy_size). For arbitrary layouts (rings, spirals, etc.), the monster movement code has to be rewritten as it currently relies on the grid-placement of stars and uses galaxy_w and galaxy_h.

Of course, osg_nebula_movement would have to be done as an option for variants. The current way is far too deeply entrenched and would have to remain default behavior.

ignatius

[DaveV]

Any chance of adding some sort of auto save? For the second time, I crashed out of the game by typing in too long a ship name ("Dead Colony" is just too ingrained in my typing fingers) and lost everything (i.e., no Continue save).