transport costs in MOO?

[RefSteel]

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).

That's good news!  I think a lot of kyrub's changes are included in "fix bugs" and "Classic+ AI" but there's some UI stuff I'd miss.  I can certainly manage without it; LEDs on research sliders and so on certainly aren't deal-breakers!

On suggested exploit fixes:  Ha - brilliant!  I wasn't considering enough options!

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).

Regardless of which pages we each were on then, this analysis certainly seems sound to me now.  One note:  In addition to forcing the wardec, you would have to make sure that for purposes of diplomatic relations, the AIs treat this specific situation as one where the player violated any deals that may have been in effect, rather than the AI that performed the wardec in the code.  (For that matter, if this is implemented, I presume a "Declare War" button could be added to the diplo screen that forces the target to issue a wardec with the same effect....)

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).

Fixing the AI to not fall for tricks like this would be best if doing it sounded like fun to someone coding it, but I certainly agree it could get complicated, and the benefit wouldn't be worth the effort if it was a chore. I think we still disagree on your suggested rule though: I don't think forcing unarmed ships to retreat in the presence of friendly bases would effectively prevent intentional baiting; a lone, fast, small ship is still good bait ship and still dirt cheap. If a major AI fix is too complex, maybe a minor one would work though: In tactical combat, the AI should retreat all its forces IF enemy missile bases are present AND none of their fleet's weapons can harm the planet, independent of other considerations. There are some edge cases where this might not be the best plan for the AI to follow, but in most cases, if it's attacking a planet and can't hurt the planet, it should just get out of Dodge.

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

Presumably it would also include all the "fix bugs" changes too, right? The exploit list has always had a number of holes and issues anyway, and it would be pretty cool to just replace it with the words, 'Use the "RBO" game setting in 1oom.'

[ignatius]

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).

That's good news!  I think a lot of kyrub's changes are included in "fix bugs" and "Classic+ AI" but there's some UI stuff I'd miss.  I can certainly manage without it; LEDs on research sliders and so on certainly aren't deal-breakers!

The LEDs are also there (I frankly, I couldn't live without them any more and I would also miss the auto-tech option.)

As for game options: There is currently some disagreement on how to integrate and present them to the player. I hope all will work out for the best, but we will see.

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).

Regardless of which pages we each were on then, this analysis certainly seems sound to me now.  One note:  In addition to forcing the wardec, you would have to make sure that for purposes of diplomatic relations, the AIs treat this specific situation as one where the player violated any deals that may have been in effect, rather than the AI that performed the wardec in the code.  (For that matter, if this is implemented, I presume a "Declare War" button could be added to the diplo screen that forces the target to issue a wardec with the same effect....)

An unconditional "Declare War" option would make no sense for the player. You can already cancel treaties and warning the opponent is to your disadvantage. So declaring war has to be a risk (as with threats) or a side effect (getting an ally) for something you want.

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).

Fixing the AI to not fall for tricks like this would be best if doing it sounded like fun to someone coding it, but I certainly agree it could get complicated, and the benefit wouldn't be worth the effort if it was a chore.  I think we still disagree on your suggested rule though:  I don't think forcing unarmed ships to retreat in the presence of friendly bases would effectively prevent intentional baiting; a lone, fast, small ship is still good bait ship and still dirt cheap.  If a major AI fix is too complex, maybe a minor one would work though:  In tactical combat, the AI should retreat all its forces IF enemy missile bases are present AND none of their fleet's weapons can harm the planet, independent of other considerations.  There are some edge cases where this might not be the best plan for the AI to follow, but in most cases, if it's attacking a planet and can't hurt the planet, it should just get out of Dodge.

I have not looked into the code yet (as of yet, the RBO stuff is just an idea of mine), but I'm confident that some solution can be found.

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

Presumably it would also include all the "fix bugs" changes too, right?  The exploit list has always had a number of holes and issues anyway, and it would be pretty cool to just replace it with the words, 'Use the "RBO" game setting in 1oom.'

Yes, at least that would be the plan. In fact, I want to have all game opts tied to the savefile, so only the game sponsor has to (and is able to) set stuff (this being one aspect of the current controversy).

ignatius

[RefSteel]

The LEDs are also there (I frankly, I couldn't live without them any more and I would also miss the auto-tech option.)

Yup! I just missed them because they're displayed differently! The tech level is highlighted in brighter red when your existing labs are fully staffed instead of using a separate "LED" image.

An unconditional "Declare War" option would make no sense for the player. You can already cancel treaties and warning the opponent is to your disadvantage. So declaring war has to be a risk (as with threats) or a side effect (getting an ally) for something you want.

Probably true, except for occasional variant purposes. Good point.

Yes, at least that would be the plan. In fact, I want to have all game opts tied to the savefile, so only the game sponsor has to (and is able to) set stuff (this being one aspect of the current controversy).

I think it would be great to have game options tied to the save file so players can just open a game and play it without worrying about their game configuration, but if others feel strongly that it shouldn't be, I don't think it's worth serious controversy. Being unable to set stuff once the game starts seems like it would be a bit annoying for sponsors, but again I'm honestly happy either way.

[ignatius]

Being unable to set stuff once the game starts seems like it would be a bit annoying for sponsors, but again I'm honestly happy either way.

Could you elaborate on that? I honestly fail to see the problem here.

Generally, I don't like the idea of changing the rules mid-game. Also, it would get in the way if we ever decide to do incremental saves. OTOH, it would be useful for debugging. I'm considering doing a "lock" option but I'm still undecided on the issue.

I'm currently in the process of reorganizing the handling of game options, which is somewhat ugly within the constraints of the current savefile format.

ignatius

[RefSteel]

Could you elaborate on that? I honestly fail to see the problem here.

Generally, I don't like the idea of changing the rules mid-game. Also, it would get in the way if we ever decide to do incremental saves. OTOH, it would be useful for debugging. I'm considering doing a "lock" option but I'm still undecided on the issue. Also, it would get in the way if we ever decide to do incremental saves. OTOH, it would be useful for debugging. I'm considering doing a "lock" option but I'm still undecided on the issue.

For me at least, I've found it useful as a sponsor to have access to as many knobs and dials as I can to adjust things, but the simplest example would be:  A player starts a casual game, saves the 2300 start, and in the course of the game finds that it's a really interesting galaxy, and would make for a great Imperium or just a challenge for other players, perhaps with a specific variant suggested by the galaxy.  (Several games around here have actually started this way, including my original Meklar Challenge!  Some also started from later saves when a player didn't make or keep one for 2300.)  If such a game was started without the RBO setting, it would be good to be able to load the starting save, set the RBO rules, and offer it as (e.g.) an Imperium.  As another example, if ALT-GALAXY (works in 1oom and) can be disabled by one of these settings, a sponsor could use it to check on the map and then go back and change the settings in the starting save to disallow it for the actual game.  None of this is vital though, as the game could always just be played under the rules it was started under as before - and an option to lock settings in during the game itself would certainly be compatible with it.  (What do you mean by incremental saves?)

I'm currently in the process of reorganizing the handling of game options, which is somewhat ugly within the constraints of the current savefile format.

Just out of curiosity, what constraints are causing the problem?

[Bionic Commando]

Related to transportation costs is general population growth. I'm trying to write a couple simulators to play with a couple scenarios and I'm having trouble syncing my results with what I see in kyrub's m patch. I'm just doing a basic 1PE and am comparing to the OSG formula (I've even included the 1 tenth population carryover).

My data:

year,UI pop,Sim pop
2300,40,40
2301,42,42
2302,45,44
2303,47,47
2304,51,52
2305,53,54
2306,56,56
2307,59,59

Not a huge deal, I suppose, but I'm sort of curious. Does it somehow happen to relate to ecology spending since the UI has a limited number of "ticks"?

[ignatius]

Could you elaborate on that? I honestly fail to see the problem here.

Generally, I don't like the idea of changing the rules mid-game. Also, it would get in the way if we ever decide to do incremental saves. OTOH, it would be useful for debugging. I'm considering doing a "lock" option but I'm still undecided on the issue. Also, it would get in the way if we ever decide to do incremental saves. OTOH, it would be useful for debugging. I'm considering doing a "lock" option but I'm still undecided on the issue.

For me at least, I've found it useful as a sponsor to have access to as many knobs and dials as I can to adjust things, but the simplest example would be:  A player starts a casual game, saves the 2300 start, and in the course of the game finds that it's a really interesting galaxy, and would make for a great Imperium or just a challenge for other players, perhaps with a specific variant suggested by the galaxy.  (Several games around here have actually started this way, including my original Meklar Challenge!  Some also started from later saves when a player didn't make or keep one for 2300.)  If such a game was started without the RBO setting, it would be good to be able to load the starting save, set the RBO rules, and offer it as (e.g.) an Imperium.  As another example, if ALT-GALAXY (works in 1oom and) can be disabled by one of these settings, a sponsor could use it to check on the map and then go back and change the settings in the starting save to disallow it for the actual game.  None of this is vital though, as the game could always just be played under the rules it was started under as before - and an option to lock settings in during the game itself would certainly be compatible with it.

I understand. I didn't think about this possibility (going back to make a game you played an Imperium). This is of course a legitimate concern. OTOH, the way I currently intend to do options (use some 20+ currently unused bytes in the game header) would be trivial to manipulate with a hex editor.

Good idea about an option to disable the builtin cheat functions. Maybe I could combine it with a lock feature.

(What do you mean by incremental saves?)

See this post. I really like the yearly saves, but they clutter the saves dir and the lead to problems when you (or your kids) play more than one game at the same time and/or if you play on different machines. Also, one of the features I liked most about original civ was the replay. I even did a program to generate a text report form the yearly saves for the original moo once (some of my imperia reports were based on it).

With incremental saves, you would have the complete history of your game in one file. Reloading then simply means truncating the file to an earlier state (or disabling that for an ironman option). You could then also separate persistent data from game state. The rules would have to go to the former.

Just out of curiosity, what constraints are causing the problem?

The fixed file size. I think than all changeable options should be reflected in the save file. However, there a far too many of them if you consider all the pbx-stuff, where you can change stuff like amoeba specs, researchable techs etc. Most of it is only relevant for rare variants. They are too many and too heterogenous to make them in-game settable. And there is no place in the savefile to put them.

A clean way to do it, would be to have the pbx input (the textual input, not the compiled pbx file, as this is afaik tied to the specific build) appended to the savefile. Even that would require major changes in the way the pbx-options are handled (mostly, the pbx stuff cannot be treated as a patch to the binary as it would have to be tied to a game and has to be reset to defaults once you load a different save. Currently, the defaults are simply overwritten at same startup and there is no way to reset them), but at least it seems feasible.

However, if you do that, it would make sense to do an extendable format, which also allows for new UI-state variables or new in-game state (e.g. for improved AI or diplo options). But this cannot reasonably be done in a backwards compatible way.

So at least for the moment, it will be the unused header bytes. Ugly, but slightly less ugly that what we have now and at least somewhat extensible and backwards compatible considering the de-facto fork we have now.

ignatius

[shallow_thought]

Could you use the unused header bytes as a reference to a new, extended format file? That is, have your new file with all its features, but have the game also save a snapshot in the classic-compatible format, with some ID / filename in the unused bytes pointing at the "big" save? So the short save could be copied or loaded by someone else with the classic game?

Having two files could be awkward - there's definitely use case around passing only the long file around, and you want this all to be as transparent as possible to the end user - but I wonder if it could solve some of the problems.

[ignatius]

Could you use the unused header bytes as a reference to a new, extended format file? That is, have your new file with all its features, but have the game also save a snapshot in the classic-compatible format, with some ID / filename in the unused bytes pointing at the "big" save? So the short save could be copied or loaded by someone else with the classic game?

Having two files could be awkward - there's definitely use case around passing only the long file around, and you want this all to be as transparent as possible to the end user - but I wonder if it could solve some of the problems.

This would not solve the ugliness problem but will make it worse IMO.

My current solution allows for up to 23 game options, there are still some unused bytes left for further extensions and it is backwards compatible.  A new, incompatible format would only make sense with incremental saves. And then still having yearly saves around would defy its very purpose.

ignatius

[ignatius]

Related to transportation costs is general population growth. I'm trying to write a couple simulators to play with a couple scenarios and I'm having trouble syncing my results with what I see in kyrub's m patch. I'm just doing a basic 1PE and am comparing to the OSG formula (I've even included the 1 tenth population carryover).

My data:

year,UI pop,Sim pop
2300,40,40
2301,42,42
2302,45,44
2303,47,47
2304,51,52
2305,53,54
2306,56,56
2307,59,59

Not a huge deal, I suppose, but I'm sort of curious. Does it somehow happen to relate to ecology spending since the UI has a limited number of "ticks"?

1oom reproduces the UI pop, both with and without slider adjustments.

ignatius