Reversing to Orion - project 1oom

[1oom_aaron]

The project coder replies:

- It was easy to build on OpenBSD! Great work making it portable! I'll try to get it added to the package system when it's done.

Thanks. "Done" may take a while, I'd suggest adding v0.9 when it's ready.

- I can't get the music to sound the way I like it, and the -sdlmixersf option didn't help. With MOO1 in DosBox, I use a virtual MIDI interface to pipe the MIDI from DosBox into fluidsynth. Is there some way to add native MIDI output as an option with the SDL libraries?

Unfortunately SDL_mixer does not give the option. On Debian it's configured to use fluidsynth, so perhaps rebuilding SDL_mixer will give you what you want without virtual MIDI.

Replacing SDL_mixer with various MIDI backends is in the TODO. But that's post-v1.0 stuff.

- I like to see the Planetology research options after my first turn, so I set the Planetology slider to 100% and invested 1 bc from my homeworld into tech. This works in MOO1, but in 1oom I have to invest 3 bc in a single turn before I can choose a tech.

Sounds like a bug. Please provide a save with bug reports. This sounds easy enough to replicate, so I'll let it slide.

- Finally, what's the preferred way to ask questions and give feedback? Here in the thread, or would it be more convenient on GitLab?

Bugs and feature requests in GitLab. This thread is OK for questions and such.

I don't think it's a bug.

OK. Case closed.

To be fair, an explicitly verbose description of a bug, while nice, isn't totally necessary when the reproduction steps are infallible and the issue is obvious to behold. It's unfortunate that the stealth removal of the SDL2 executable was a thing here. From my perspective at the time, it was largely reasonable to assume that you'd see the same thing on your end as I on mine.

Fair assumptions. The SDL2 hiccup was a bummer. Now that we have been bitten by the unexpected, we will copy/paste the version from 1oom_log.txt as instructed, right?

The glitch may still exist. I could test that if you would be kind enough to tell which version you were using.

Will it be getting a general and/or PBX fix anyway? A nova event that is literally impossible to fix before time runs out strikes me as something that would be universally unwanted by practically everyone, regardless of whether it exists in vanilla or not.

No fix. I see getting screwed over by the RNG as part of the MOO experience. What would the fix be, anyway?

Perhaps the amount of RP required / turns left could be displayed somewhere on the colony panel (eg. close to "Nova") when uiextra is enabled?

The news announcements should be enough, but I'll think about it.

--

Ever wanted to tinker with the AI? Or perhaps the mooconomy? The barrier is now as low as it's going to get for a long while: How to build 1oom on Windows. Happy hacking!

[Jeff Graw]

Now that we have been bitten by the unexpected, we will copy/paste the version from 1oom_log.txt as instructed, right?

The glitch may still exist. I could test that if you would be kind enough to tell which version you were using.

Both the executable and the log are long since overwritten, but it was in the 0.6 branch, one of the later ones I think. Sorry that I can't be more specific, but I'll assume it's old enough anyway that you wouldn't be much interested in that particular wild goose chase.

No fix. I see getting screwed over by the RNG as part of the MOO experience. What would the fix be, anyway?

I see it a bit differently. While randomly dooming a colony to destruction is quite arguably poor design in and of itself, that's almost certainly not the original intention here. Besides the fact that the OSG paints the picture of a non-impossible task, it's completely counter-intuitive to give an impossible task to players in the guise of a possible one. For instance, if randomly dooming a colony is a thing, the message to the player should read along the lines of "X will go nova in Y years, and scientists predict that there is nothing that can be done in time to save X." You wind up with a design flaw, that is certainly unintentional, that no-one wants (I would argue that even masochistic players who enjoy the sometimes cruel affectations of RNG would tend to prefer something with some amount of actual counterplay), that on top of everything is presented to players in a deceptive fashion.

A fix could be something along the lines of:

cost = min(cost, 2 * numTurns * planetProduction * (1 - minEcoPercentForClean));

Or, to put in another way, never cost more RP than can be generated if, on the same turn, all production besides minimum clean is shifted to research and the colony is provided stimulus every turn from that point onward.

Ever wanted to tinker with the AI? Or perhaps the mooconomy? The barrier is now as low as it's going to get for a long while: How to build 1oom on Windows. Happy hacking!

I probably will in time. After all, I feel a bit bad complaining about things when I could just fix them myself. But I'm really quite busy right now, and will be for the foreseeable future, getting everything on my end ready for early access and/or crowdfunding which will have to happen soon-ish.

[1oom_aaron]

The project coder replies:

- I like to see the Planetology research options after my first turn, so I set the Planetology slider to 100% and invested 1 bc from my homeworld into tech. This works in MOO1, but in 1oom I have to invest 3 bc in a single turn before I can choose a tech.

1 RP is not enough to trigger the first tech on v1.3. On 1.40m it is, likely due to:

Code:

- the research BC now get no 90% discount when starting new technology project

Added PBX number first_tech_rp_fix in v0.8-24. One missing 1.40m fix down, N to go.

Both the executable and the log are long since overwritten, but it was in the 0.6 branch, one of the later ones I think. Sorry that I can't be more specific, but I'll assume it's old enough anyway that you wouldn't be much interested in that particular wild goose chase.

Oh well. Schrödinger's goose remains in the box.

I see it a bit differently. While randomly dooming a colony to destruction is quite arguably poor design in and of itself, that's almost certainly not the original intention here.

This is not a bug. I will not argue about design. I'm not interested in bolting safety wheels. This is MOO, not M.U.L.E.

After all, I feel a bit bad complaining about things when I could just fix them myself.

Don't feel bad about that. It's my "job" (for a lack of better word) to fix 1oom. Complain all you want, but provide saves.

But I'm really quite busy right now, and will be for the foreseeable future, getting everything on my end ready for early access and/or crowdfunding which will have to happen soon-ish.

Good luck in not starving.

[RefSteel]

1 RP is not enough to trigger the first tech on v1.3. On 1.40m it is, likely due to:

Code:

- the research BC now get no 90% discount when starting new technology project

The project coder is precisely correct. Specifically:

This is actually the same behavior as v1.3 (it's discussed on Sirian's site among other places, and is easy to see experimentally).  It was changed by kyrub in the unofficial patch.  In v1.3, only a fraction of the RP you invest when opening a new tech field (Plan, Prop, Weapons, whatever) for the very first time is actually applied, and the fraction is floored. (I'm not sure about the "90%" figure; there may be a couple of different divisions and floorings, but regardless, the effect is normal to original MoO.)

Note this only applies the very first time you start research in the field.  Sirian recommends spending ~20 RP when opening all six fields with the techs equalized, for instance.  Under kyrub's patch, there is no such "opening penalty" to research.

Added PBX number first_tech_rp_fix in v0.8-24. One missing 1.40m fix down, N to go.

I'll try to address some of the items from your list from upthread, insofar as I'm familiar with them, in another post below....

While randomly dooming a colony to destruction is quite arguably poor design in and of itself, that's almost certainly not the original intention here. Besides the fact that the OSG paints the picture of a non-impossible task, it's completely counter-intuitive to give an impossible task to players in the guise of a possible one.

Normally it is possible to save a colony with sufficient effort, but I suspect you ran afoul of an edge case. Specifically:

A fix could be something along the lines of:

cost = min(cost, 2 * numTurns * planetProduction * (1 - minEcoPercentForClean));

If I remember correctly, the cost is based on the planet's (then-current) production (in original MoO, which I think is being duplicated correctly here).  And saving the planet is sometimes/often/always impossible unless you increase production above the current level, e.g. by spending reserves.  But!  Any reserve spending you were already doing on the turn the event hits is included as part of the planet's production!  So if you have a new colony receiving reserves to speed it up the growth curve, it'll probably be fine once transports arrive and increase its productivity. Likewise, if you weren't feeding the place any reserves, you can help it out from the treasury and beat the event.  But if the planet is already highly populated (or not getting many transports soon) and already receiving reserves anyway, it may be irrevocably doomed.  Equally true in 1.3 and under kyrub's patch, though it comes up pretty rarely.

[RefSteel]

Okay, let's have a look at that list from a couple pages back:

i? - no more eternal alliances for AIs (reverted back to the vanilla version)

Yes, irrelevant:  This was a fix to a previous version of kyrub's patch, and merely reverted an aspect of AI behavior to the way it had been in v1.3.

r - the game now uses "Controlled Barren" on the Race report screen instead of strange "Control Barren ENVIRON"

This was an attempt to fix a display bug in v1.3 where the "environ" would overflow onto the left-hand side of the screen and/or tech names would be misdisplayed on this screen (e.g. Death Spores would appear as "Death Environment").  If I duplicate the display bug in 1oom, I'll try to post a bug report with relevant save etc.  I haven't played enough 1oom yet to be sure.  (Computer operating time has been limited for me lately.)

w - the annoying Scout II redesign feature lives no more [credit to Lydon]

This "w" ("not understood") is one you've already discussed with Jeff Graw:  The higher cost of the default ships relative to the cost of identical self-designed ships (Sirian called his self-designed identical-to-scouts ship design "Scout 2")

w - the races now have the appropriate choice of objective at the beginning of a game

So ... the various races' personalities and objectives (e.g. "Pacifistic Technologist") are "rolled" from a table at game start.  The starting point on the table in the actual (v 1.3) game does not match the manual/OSG, nor does it match other sources (e.g. Sirian's site).  A number of the actual in-game results are theoretically supposed to be impossible; I can look them up in detail if that would be helpful, but I think Pacifistic Sakkra and Erratic Klackons were common examples that were not supposed to exist (at game start) at all.  Also, if I remember correctly, Meklar were always Xenophobic 100% of the time, I think because of a table overflow issue.  Again, I can dig up more specifics on both the nature of the bug and the actual and intended results if desired.

m - the player (AI or Human) who commits an oath breaker is not taken as a victim anymore, but as the tresspasser

To be clear on what we're talking about:  In v1.3, if you break an agreement with another race (by attack or diplomacy) the AI apparently doesn't think it's a problem.  If an AI breaks an agreement with you, they are more reluctant to make deals with you afterward "because you have broken deals in the past."  Since this is listed as "m = maybe if there is interest" I'd like to at least express interest in having a fix available (by PBX or in a post-1.0 version at least).

w - AI-AI positive diplomacy problem corrected

I think this was just fixing a problem introduced in a previous version of kyrub's patch.

w - the AI now correctly uses the radius of action during its decision making

So apparently when the AI is deciding where to deploy e.g. zone defense fleets (and e.g. whether ships are "on the border" for purposes of getting upset and complaining about them) one factor it takes into account is the speed of its best engines - i.e. the number of parsecs its fastest ships can move in one turn.  And apparently in 1.3, instead of using this number correctly, it uses the square of this number in all its calculations.  This causes later-game complaints about ships "on the border" when your whole fleet is on the opposite side of your empire from them, and also results in the AI massing enormous stacks of doom in some areas but leaving other parts of a large empire exposed.  I have no strong opinion on whether anything should be done about this.

m - Alkaris and Mrrshans bonus for AI-AI combat corrected to reflect their race bonus

This would be cool to have available as an option; AI Mrrshans are sad enough even under kyrub's patch, and this should help them out.  "Cool" is not the same thing as "critical" though.

w - early tech decisions corrected to include a fourth decision point for all AI races

Wow.  I ... have no idea.  I'd have to dig deep to try to turn this one up.

a/x (hotkeys?) - rehaul of TECH screen, TAB runs through tech fields, hotkeys, the diodes lit under the tech level show when you reach max research bonus
a (hoykeys?) - rehaul of RACES screen, hotkeys, clickable portraits bring REPORT page

"Hotkeys" was a reference to keyboard commands kyrub set up to enable slider adjustments without mouseclicks on these screens.  They're not marked and not that intuitive, and are therefore rarely used; I think it's something like a = reduce Computers spending (or espionage spending on top-left race) b = reduce Construction spending (or espionage spending on middle-left race) etc. with the numbers 1-6 doing the opposite.  I'm sure if anyone uses these, they can specify which is which, or if you want I can play around with it and test it out; it was a good idea, but with no in-game documentation, it was rarely used.


I hope these are useful and not too late to help!

[Jeff Graw]

This is not a bug. I will not argue about design. I'm not interested in bolting safety wheels. This is MOO, not M.U.L.E.

If a behaviour isn't intended, then it's not design, it's (probably) a bug. Design is intentional. Sorry if my original phrasing was poor. What I was trying to say is "this would be poor design if intentional, but it's not intentional" (so it's not a design issue). Sometimes unintended behaviour is good and becomes a part of the design post-hoc the moment that the designer say to himself "I'm going to keep this." Sometimes bugs get left unfixed and become integral to the game ala. certain Doom bugs. I don't see either of those applying here.

If I remember correctly, the cost is based on the planet's (then-current) production (in original MoO, which I think is being duplicated correctly here).  And saving the planet is sometimes/often/always impossible unless you increase production above the current level, e.g. by spending reserves.  But!  Any reserve spending you were already doing on the turn the event hits is included as part of the planet's production!  So if you have a new colony receiving reserves to speed it up the growth curve, it'll probably be fine once transports arrive and increase its productivity.  Likewise, if you weren't feeding the place any reserves, you can help it out from the treasury and beat the event.  But if the planet is already highly populated (or not getting many transports soon) and already receiving reserves anyway, it may be irrevocably doomed.  Equally true in 1.3 and under kyrub's patch, though it comes up pretty rarely.

I'm fairly sure I wasn't spending any reserves at the planet in question the turn of the event. It was a well developed poor world, not the kind of world you give stimulus to in normal circumstances. But anyway, if RefSteel says that an unwinnable nova event doesn't happen in vanilla except in cases where there's stimulus spending the turn the event hits, he's most probably right.

[RFS-81]

1 RP is not enough to trigger the first tech on v1.3. On 1.40m it is, likely due to:

Code:

- the research BC now get no 90% discount when starting new technology project

The project coder is precisely correct. Specifically:

This is actually the same behavior as v1.3 (it's discussed on Sirian's site among other places, and is easy to see experimentally).  It was changed by kyrub in the unofficial patch.  In v1.3, only a fraction of the RP you invest when opening a new tech field (Plan, Prop, Weapons, whatever) for the very first time is actually applied, and the fraction is floored. (I'm not sure about the "90%" figure; there may be a couple of different divisions and floorings, but regardless, the effect is normal to original MoO.)

Note this only applies the very first time you start research in the field.  Sirian recommends spending ~20 RP when opening all six fields with the techs equalized, for instance.  Under kyrub's patch, there is no such "opening penalty" to research.

Huh. Is this a bug? I can't figure out why one would do that intentionally.

[1oom_aaron]

The project coder replies:

This was an attempt to fix a display bug in v1.3 where the "environ" would overflow onto the left-hand side of the screen and/or tech names would be misdisplayed on this screen (e.g. Death Spores would appear as "Death Environment").  If I duplicate the display bug in 1oom, I'll try to post a bug report with relevant save etc.

I did a possibly related fix where Advanced Foo Tech Z would get "environ" tagged at the end. Have not seen this overflow yet. SAVEx.GAM are OK too for this kind of bug if you happen to have one handy.

So ... the various races' personalities and objectives (e.g. "Pacifistic Technologist") are "rolled" from a table at game start.  The starting point on the table in the actual (v 1.3) game does not match the manual/OSG, nor does it match other sources (e.g. Sirian's site).

Ah, I thought this was about the initial AI decisions (sliders mostly). The tables used for the selection can be modified by the PBX numbers trait1_human, trait1_mrrshan etc so I guess this is a 'p'. I'll document it in doc/list_pbxnum.txt.

In v1.3, if you break an agreement with another race (by attack or diplomacy) the AI apparently doesn't think it's a problem.  If an AI breaks an agreement with you, they are more reluctant to make deals with you afterward "because you have broken deals in the past."  Since this is listed as "m = maybe if there is interest" I'd like to at least express interest in having a fix available (by PBX or in a post-1.0 version at least).

I've looked into it some time ago but did not notice the bug. The use of breaker/victim seemed consistent but your explanation would indicate that they are all wrong. I'll look into it again. If I manage to find/fix it (hopefully within a few days), it will be a part of the Classic+ AI.

And apparently in 1.3, instead of using this number correctly, it uses the square of this number in all its calculations.

Let's take a peek:

Code:

static void game_ai_classic_turn_p1_send_defend(struct game_s *g, struct ai_turn_p1_s *ait, player_id_t pi)
{
   int bestspeed = game_tech_player_best_engine(g, pi) * 30 + 20;
   ...
   if (util_math_dist_fast(pf->x, pf->y, pt->x, pt->y) <= bestspeed) {
   ...
}
int util_math_dist_fast(int x0, int y0, int x1, int y1)
{
   int dx, dy;
   dx = x1 - x0;
   if (dx < 0) {
       dx = -dx;
   }
   dy = y1 - y0;
   if (dy < 0) {
       dy = -dy;
   }
   return (dx > dy) ? (dx + dy / 2) : (dy + dx / 2);
}

I see no squaring but that "* 30 + 20" sure is weird. The other AI functions have other odd multipliers and offsets. I don't know what the correct values/code would be.

"Hotkeys" was a reference to keyboard commands kyrub set up to enable slider adjustments without mouseclicks on these screens.

If someone cares enough to check and post them (and they don't conflict with anything), I'll add them. Some I have already.

I hope these are useful and not too late to help!

Very useful indeed! Thanks a lot. I'll update the list and start working on the missing ones.

--

I'm fairly sure I wasn't spending any reserves at the planet in question the turn of the event. It was a well developed poor world, not the kind of world you give stimulus to in normal circumstances. But anyway, if RefSteel says that an unwinnable nova event doesn't happen in vanilla except in cases where there's stimulus spending the turn the event hits, he's most probably right.

Can't see anything wrong in RefSteel's description. I'm fairly sure that the code in 1oom matches v1.3 and is as described in the OSG Errata. I'll leave it up to you to calculate a scenario where the planet is doomed.

I won't be adding optional safety guards for this. However, I have no objections against a patch adding a nerfed_events PBX num.

--

Huh. Is this a bug? I can't figure out why one would do that intentionally.

Looks like an oversight. When a tech slider is zero, the game does "investment = (investment * 9) / 10" (rounding down to 0). This code is (mistakenly?) run also when no project has been started yet. The option first_tech_rp_fix (see doc/list_pbxnum.txt, fixbugs_pbxin.txt) wraps that code in "if (first_project_has_been_selected)". I don't know what 1.40m does to fix it.

See PHILOSOPHY if you wonder why this fix is optional.

[RefSteel]

I did a possibly related fix where Advanced Foo Tech Z would get "environ" tagged at the end. Have not seen this overflow yet. SAVEx.GAM are OK too for this kind of bug if you happen to have one handy.

Incredibly, I do have an ancient save handy that shows both bugs (or both versions of the same bug; I'm not sure which...) - I haven't tested to see if 1oom shows either bug after converting the save, so it's possible your "environ" fix got rid of one or both of these, but when loading this save in 1.3:

On the "Report" screen for the Silicoids, you can see "Death Environ" (instead of Death Spores) and "Improved Terraforming Environ" (instead of ... probably? ... IT +30).
On the "Report" screen for the Klackons, you can see multiple Controlled [planet class] Environment techs running off the right edge of the display box, including "Controlled Radiated Environment" with a portion of its final "T" wrapping around to the left-hand edge of the screen.

[RefSteel]

I see no squaring but that "* 30 + 20" sure is weird. The other AI functions have other odd multipliers and offsets. I don't know what the correct values/code would be.

I found kyrub's notes on this one! I remembered incorrectly: It's not squared; the "bug" is that the number it uses for each race's best engine is the relevant engine's tech level - so 6 for Nuclear engines, 12 for Sublights, 18 for Fusion, etc. - but then it calculates whether a target is close enough as though it were using those engines' warp speed - 2 for nukes, 3 for sublights, etc.

I think what's going on with the "* 30 +20" is that it's judging distance in tenths of a parsec (I believe this is a commonly-used unit of distance in the game) so, if my understanding is right, its "action radius" jumps from 5 parsecs for retros up to 20(!) parsecs for nuclear engines even though it takes twice as long to cover that distance even with the better engines - and then all the way up to 38(!!) parsecs for Sublights even though a 38-parsec journey at warp 3 would take almost three times as long as a 5-parsec journey at warp 1.

I'm not sure of these exact numbers because kyrub refers to engine level as starting with 0, not 1, and later says the game calculates (3 + [engine tech level]) * [constant] rather than 3 * [engine tech level] + [constant = 2] but I think that's the general idea....

[Edit: Also I had the tech screen hotkeys backwards: Number keys 1-6 reduced spending in computers/const/FF/plan/prop/weapons respectively, and a-f increased spending in those fields. I would guess that the spy spending on the diplo screen is similar but haven't confirmed.]

[Edit2: One more item from that list:

m - AI sabotage message continue = space

This was only specific to the sabotage message because it had been missed in a previous version of the patch, when all other screens where your only option was "continue" had been changed from a "c" hotkey to a [spacebar] hotkey in the patch. My preference would be to allow any key to continue (or at least space/esc/"c") on screens where "continue" is literally the only possible action, as an improved UI option - but you may already have built some version of that in. (Still haven't had much time to actually play around with 1oom's options....)]