transport costs in MOO?

[ignatius]

In my current game with 1oom, I have an ultra poor planet w/o factories (my 2nd colony of course ...). With 52 pop it produces 29 RPs in tech (I play the Humans and have some trade income).

When I try to send half the pop away, the tech output drops to only 3 RPs (probably my trade income). I checked with MOO 1.4m and the behaviour is the same. Is this a bug, present in both versions, or does MOO have transport costs after all? I know the OSG mentions 1 BC/pop, but I always thought this is unimplemented. Anyway, this would only add up if the pop to be transported would also work for its ticket before departure.

What I always have thought before, was, that the production increase stems from the fact that pop scheduled for transport does not work - so you get a waste cleanup problem and have to adjust eco. Now it looks like departing pop does put in a last year of work but that they have to pay for the ticket and the production drop is merely the ticket price.

Is this correct?

ignatius

[RefSteel]

Now it looks like departing pop does put in a last year of work but that they have to pay for the ticket and the production drop is merely the ticket price.

This is an old interface bug from v1.3. I believe kyrub fixed it in one of the older versions of his patch, but the fix turned out to have problems of its own so he reverted it by 1.4M. You are correct that the interface reports production-to-be as though you will be paying 1BC per transport but receiving the labor of the departing population, but your earlier assessment of the way it works was also correct - about what the game actually does in EoT processing: You pay nothing for the transports directly, but the population departing in them provides no production (neither on the turn of departure nor on the turn of arrival at another planet) and operates no factories. The numbers can sometimes work out to be kinda sorta more or less the same, but there are other times (a lot of times!) when it isn't very close. On a planet with high RC levels and all its factories, the game will severely overestimate what the planet can produce when a large raft of transports is launched. On a populous non-Klackon planet without waste reduction or eco restoration and factories equal to current population, the game will severely underestimate what the planet can produce, especially since it will severely overestimate the amount of ECO spending required to keep the planet "CLEAN" (and if you put the slider at the "appropriate" levels, the extra will be spent on the next ECO project, like growing population).

[ignatius]

Thanks for your reply. This is most interesting. Looks like 1oom is again bug compatible here. The real question is: What is the correct thing to do? Fix the production (to make it match the display and the OSG) or fix the display (to reflect what actually happens and leave production as is). Or combine both (i.e charge 1 BC and don't let passengers work).

Thematically, it makes sense that for a 1 year journey, you miss out on one year of production. But in that case a 1 BC transport fee would be too high to move 1/2 the pop from a planet w/o factories, as the other 1/2 could only earn about half the fare (with low planetology level) of those leaving (and empire taxes and maintenance would further complicate the issue). Maybe similar considerations led the original authors to change the rules vs. the OSG. So I would tend to let production as is (i.e. no fee, passengers don't work) and fix the display.

On a related issue: I got the impression (w/o seriously investigating the issue), that with large trade income, the game tends to adjust the ECO sliders wrongly so that "WASTE" is occasionally displayed. Does this ring a bell with you?

ignatius

[RefSteel]

Sounds right to me. On the related issue, I'm not aware of a bug like that with a large trade income; someone else might have seen it?

Only semi-relatedly: Is there a hotkey in 1oom for setting a planet's ECO slider to the minimum CLEAN? In 1.3 (and kyrub's patch) the game would automatically increase the Eco slider for any planet in WASTE up to CLEAN any time the game was loaded from a save file, which allowed the silly work-around of just dropping planets into Waste, then Quitting and immediately Continuing, which wasn't really time-consuming in spite of being utterly silly, but this doesn't seem to work in 1oom.

[ignatius]

I don't know of a hotkey, but there is an entry in the hidden menu (click left right corner of the starmap screen) called "Readjust Eco" and for governed planets there is "readjust all governed planets" in the governor menu (right click on planet name).

[ignatius]

Thinking about it, the wrong production display with scheduled transports is only the tip of the iceberg. AFAIK, MOO does not consider pop growth, too. At the start of a game, the display usually says you can build 2 scouts. If you max the ship slider, however, you end up with 3 new scouts. It seems like things work the following way:

1. grow pop
   
2. calc production
   
3. add pop from eco production and transports
   

while the following order would make much more sense (and would better align with the current slider display):

1. calc production
   
2. add pop from growth, eco production and transports
   

So current moo/1oom allows child labor but hides it from the statistic.

I would really like to have the sliders reflect the correct production, but the best solution would slightly change the existing game mechanic. What do you guys think? And Ref, do you remember what the problems were, kyrub ran into with his own attempted fix of the transport issue, so we can avoid the same pitfalls.

ignatius

PS: seems like the truth is much worse:

Obviously, ECO and TECH spending are calculated from production before growth, while SHIPS, DEF and IND spending are calculated form production after growth (and ECO spending). So it is impossible to simply match the display to the actual production figure, because there is no (single, consistent) production figure. So any fix would necessarily require fixing the broken game mechanic first.

[RefSteel]

So current moo/1oom allows child labor but hides it from the statistic.

I would really like to have the sliders reflect the correct production, but the best solution would slightly change the existing game mechanic. What do you guys think?

Yup; this is all down to the details of EoT processing order. I think the best thing to do would indeed be to change those mechanics to reflect the colony display rather than trying to make it work the other way around. Changing the order of production (e.g. ind before eco) just shifts the problem around as far as I can tell, but it should be possible to change the big picture order so the game stores the EoT information in memory (for all colonies, before starting the production sequence) and makes all production calculation on the basis of this "old" information instead of the "new" information as population growth and so forth are applied. (Departing transports would have to be included out, which we want to do in the interface anyway; arriving transports could continue to work as they do at present: They have nothing to do with the production cycle and are only added at the end of the interturn after checking to make sure they haven't been shot down.)

And Ref, do you remember what the problems were, kyrub ran into with his own attempted fix of the transport issue, so we can avoid the same pitfalls.

I don't remember for sure (and won't have time to try digging it out of his old threads for a while) but I think it was some combination of the difficulty of working with MoO's old binary files (which shouldn't be an issue with 1oom) and this:

So it is impossible to simply match the display to the actual production figure, because there is no (single, consistent) production figure. So any fix would necessarily require fixing the broken game mechanic first.

I think there are also empire-wide effects that get dynamically updated too as population grows - and trade agreements might get updated before handling planetary production? (Not sure.) I know he basically concluded there was no way to make the interface perfectly reflect the actual production given the way MoO handles EoT processing, which is why I suggest making the latter match the former instead!

[ignatius]

So current moo/1oom allows child labor but hides it from the statistic.

I would really like to have the sliders reflect the correct production, but the best solution would slightly change the existing game mechanic. What do you guys think?

Yup; this is all down to the details of EoT processing order.  I think the best thing to do would indeed be to change those mechanics to reflect the colony display rather than trying to make it work the other way around.  Changing the order of production (e.g. ind before eco) just shifts the problem around as far as I can tell, but it should be possible to change the big picture order so the game stores the EoT information in memory (for all colonies, before starting the production sequence) and makes all production calculation on the basis of this "old" information instead of the "new" information as population growth and so forth are applied.  (Departing transports would have to be included out, which we want to do in the interface anyway; arriving transports could continue to work as they do at present:  They have nothing to do with the production cycle and are only added at the end of the interturn after checking to make sure they haven't been shot down.)

Good to see that we are on the same page here. This is exactly what I did in my latest patch (currently awaiting merge). Curiously, the production gets calculated and stored - but twice!

Code:

  [...]
A: game_update_production(g);           /* sets planteary production */
   game_turn_build_eco(g);              /* does eco projects and then natural growth */
   game_update_total_research(g);       /* sets total research spending */
   game_update_have_reserve_fuel(g);
   game_turn_update_trade(g);           /* only now we update trade */
   game_spy_build(g);                   /* spy growth */
B: game_update_production(g);           /* now we update production again???? */
   [...]
   game_turn_build_def(g);
   game_turn_build_ship(g);
   game_turn_reserve(g);                /* collect reserve tax */
   game_turn_build_ind(g);
   [...]  /* includes spying, which might change tech and sabotage facts */
   game_tech_research(g);               /* only now we do research, but use total from A */
   [...]
C: game_update_production(g);
   [...]

The fix is simply to disable (B), so every build uses the same production figures from (A). I made it conditional on a new pbx option hidden_child_labor, as the most visual effect is that for SHIP, DEF and IND, new grown pop gets put to work. I hope that I have not overlooked some undesirable side-effects here.

I found another curiosity:

The game seems to give a 1 BC bonus for having at least a tick on the ship-slider. In game_turn_build_ship():

Code:

           prod = game_adjust_prod_by_special((p->slider[PLANET_SLIDER_SHIP] * p->prod_after_maint) / 100, p->special);
           prod += p->bc_to_ship;
           if (p->slider[PLANET_SLIDER_SHIP] > 0) {
               ++prod;
           }

I don't know what the point here is. I've never heard of this bonus. Maybe some kind of fallback so that the AI does not get stuck in certain situations. Turned out that this feature is behind the 2 scout / 3 scouts discrepancy. Without it, the difference in ship production would have been 23 (w/o child labor) vs. 24 (with child labor), but the +1 BC bonus puts both over the threshold.

On another issue: RFS is planning a quasi "official" beta release of 1oom. I would love to have 1oom become the new default for RBO Imperia and SGs. I understand that one problem for this is Mac binaries. I have another idea: It would be possible to make some of the RBO house rules into configurable game options, so that they are enforced automatically. What do you think? 

ignatius

[RefSteel]

Good to see that we are on the same page here.

Cool!

This is exactly what I did in my latest patch (currently awaiting merge). Curiously, the production gets calculated and stored - but twice!

Weird! Also weird is the ship-building bonus BC.

I don't know what the point here is.

I wonder if it was somehow meant to kindasorta make up for the rounding error usually eating 1-2 BC of production in most configurations, but that's pure speculation.

On another issue: RFS is planning a quasi "official" beta release of 1oom. I would love to have 1oom become the new default for RBO Imperia and SGs. I understand that one problem for this is Mac binaries.

Yeah, I feel like the three main things holding this back from happening are the Mac compatibility issue, the need for PBX files (or a clear explanation of how regular users can get them to do what they want, e.g. 1.4M emulation) and ... the relative dearth of recent Imperia and SGs. If people are interested in correcting the third while trying out a 1oom beta's improved interface, I'm all in favor!

(And speaking of the improved interface - I never got around to thanking you for pointing out the hidden menu and governor options to me! It took me a moment to find the former, clicking all the way in the lower right-hand corner beyond the edge of the "game" button, but its readjust eco option was exactly what I was looking for!)

I have another idea: It would be possible to make some of the RBO house rules into configurable game options, so that they are enforced automatically. What do you think?

Interesting! I'm not sure how many are enforceable by the game, apart from stamping out bugs (like infinitely-recharging specials) but removing the option to request a wardec against a race with which you're not yourself at war, and maybe including the "retreating ships can't redirect" option, though it's stricter than the "official" exploit rules we use, might very well be doable. (I don't know how you'd enforce the rule against e.g. the missile "Yo-yo trick" short of programming the AI to not fall for it....)

[ignatius]

On another issue: RFS is planning a quasi "official" beta release of 1oom. I would love to have 1oom become the new default for RBO Imperia and SGs. I understand that one problem for this is Mac binaries.

Yeah, I feel like the three main things holding this back from happening are the Mac compatibility issue, the need for PBX files (or a clear explanation of how regular users can get them to do what they want, e.g. 1.4M emulation) and ... the relative dearth of recent Imperia and SGs.  If people are interested in correcting the third while trying out a 1oom beta's improved interface, I'm all in favor!

Tapani has remote access to a Mac, so he could do builds (but not test them). The pbx files are no longer necessary if all you want are the bug fixes, if you use the new game options (we have "pbx", which does nothing, "fix bugs" and "moo v1.3" ATM).

I have another idea: It would be possible to make some of the RBO house rules into configurable game options, so that they are enforced automatically. What do you think?

Interesting!  I'm not sure how many are enforceable by the game, apart from stamping out bugs (like infinitely-recharging specials) but removing the option to request a wardec against a race with which you're not yourself at war, and maybe including the "retreating ships can't redirect" option, though it's stricter than the "official" exploit rules we use, might very well be doable.  (I don't know how you'd enforce the rule against e.g. the missile "Yo-yo trick" short of programming the AI to not fall for it....)

There are two ways how handle  exploits: Forbid the exploit or change the game behavior so that the exploit no longer works. For yo-yo, it would have to be the latter.

A "retreating ships can't redirect" option is already in there IIRC (only effective when you don't have hyperspace com). One might add code such that only fleets with spent ammo count as "retreating" and ignores present hyperspace com. What you cannot do then, however, is split the fleet to have the beam ships stay in the system.

As with the spec wars, i can remember our discussions (we were not on the same page then ;-) ). The problem was that MOO does not support war declarations. The AI may take planets from you and you still would not be allowed to ask for help. A clean solution would thus also be of the second kind: Make it so that when your demand is successful, the target race will declare war on you (or do a silent war declaration, as we have no game assets to do it the other way around).

Baiting can be fixed either way. My preferred way (now and then) for the first kind: Unarmed ships retreat when friendly missile bases are present. There are still corner cases, though: An unarmed ship might survive the attack, in case the attacker only has bombs (or missiles he spends on the planet) and thus save the planet. 2nd kind would be fixing the AI not to fall for it (which might get complicated).

I was thinking about adding a 4th game option "RBO" to select the respective pbx-options in game and tie them to the savefile.

ignatius