Savebreaking Changes. Mapmakers/modmodders update your scenarios/modmods for SVN 11132+.

Yeah.

And other similar ones, like these:
FEATURE_LUNAR_CRATER1 -> FEATURE_MEDIUM_CRATER
FEATURE_LUNAR_CRATER2 -> FEATURE_LARGE_CRATER
FEATURE_LUNAR_CRATER3 -> FEATURE_SMALL_CRATER
FEATURE_CRATER_SUBCATEGORY

Renamed those
FEATURE_BURNT_FOREST -> FEATURE_FOREST_BURNT
FEATURE_YOUNG_FOREST -> FEATURE_FOREST_YOUNG
FEATURE_ANCIENT_FOREST -> FEATURE_FOREST_ANCIENT
FEATURE_MEDIUM_CRATER -> FEATURE_CRATER_MEDIUM
FEATURE_LARGE_CRATER -> FEATURE_CRATER_LARGE
FEATURE_SMALL_CRATER -> FEATURE_CRATER_SMALL
 
I think I need to fix P2K_CIV4UnitInfos - my improvement/resource/feature/terrain renames broke it - that is units can do something if present on those places.
Essentially they have python actions in XML file.

Now they are fixed in my branch - they didn't have prefixes like TERRAIN_
 
Last edited:
So same thing should be done to coasts/seas/oceans/trenches?
Yes and no because water features depth, temperature and navigation indicators in their name.

Navigation
  • Coast = can see land from a raft or deck of ship
  • Sea = can not see land from raft but can from the crow's nest of a large ship
  • Ocean = can't see land even from the crow's nest
Temperature
  • Tropical
  • Temperate (default, so usually left off)
  • Polar
Depth
  • Shallows (not yet implemented)
  • Shelf (default, so usually left off)
  • Trench
  • Abysmal Plain
This means you may want to add some things to the names.
 
I'll comment on what I can since I said I would and forgot about it til now.

GAMEOPTION_AGGRESSIVE_AI - damages AI
Yes, but its a huge favorite and it might not be as damaging as it was. The settler inhibition it created was pretty brutal. It's not as bad now but the problem that still remains is that this extra aggression can tend to unbalance the AI's approach to the game and lead to an early determination of what player wins because they're constantly going hard for a military edge and any way to use it. This means they ignore building up their empire and possibly outteching opponents before trying to engage them. This might be an option that in the future could be retooled to be more useful if it allows the AI to be a bit more intelligent and less brutish. I've never had the time to fully investigate but figure it should be at some point.

GAMEOPTION_ONE_CITY_CHALLENGE - mod is too full of stuff for this option
Again, some people like it still and if I'm not mistaken, Toffer was doing his darnedest to make it functional, even if it will always write off some aspects of the mod. I mean, it always HAS written off a lot of the game before so that's not exactly a total killer for the option to not have access to some buildings. And if we write some exception rules for those buildings/techs that are critical if this option is on, we may be able to make it playable still.

GAMEOPTION_NEW_RANDOM_SEED - causes problems with debugging
Yes, but when we have a truly stable platform, this may not be so bad to re-enable someday. When we turned it off, it was because we were really crashing a LOT and needing the reports to correct that. With further devel we'll probably start having more again too, but I like leaving it here for the more advanced player who understands the consequences of it and is willing to use it anyhow.

GAMEOPTION_LOCK_MODS - ?
Vanilla option that I really don't understand but wouldn't dare to remove in full.

GAMEOPTION_NO_GOODY_HUTS - ?
We took this invisible because who really wants this? And we have a lot of options as it is and are trying to keep the list shorter if we can. However, if someone really doesn't like them, I don't mind them being able to go into the xml and turn it off easily enough.

GAMEOPTION_RUTHLESS_AI - damages AI - same as the aggressive one but another layer of stuff. Not sure what the intended difference was except to be something of an inbetween setting I think.

GAMEOPTION_NO_FUTURE -
I'd really prefer to see this become a drop selection on all map scripts what the last era they player wants to allow in the game is so killing this option may be ok BUT it also would be a faster one to get debugged and up and running in the meantime so that's why we've left it there. It's very bugged IIRC though.

GAMEOPTION_STRENGTH_IN_NUMBERS - WIP
Yes, WIP and under some scrutiny at the moment...

GAMEOPTION_SCALE_CITY_LIMITS - ?
I really don't know what this is supposed to do exactly but if it's simply made a part of the other city limit happiness penalties option then it can probably be removed.

GAMEOPTION_LS612_TRAITS
I think we gotta just leave this here for now, though Joe's suggest about making it a modmod may work instead of having it as an option.

GAMEOPTION_HEART_OF_WAR - WIP
GAMEOPTION_BATTLEWORN - WIP
GAMEOPTION_UPRANGE - WIP
GAMEOPTION_EQUIPMENT - WIP
Yeah all works in process and TBH, Heart of War is heavy on my mind as something that may be just about ready to go as soon as the unit review is finished. Battleworn as well is right there potentially if I can work out some of the odds stuff that goes with it. Uprange and equipment might be a little bit more of a wait but a lot of platform stuff has gone into uprange progress, particularly with a few things I will be including in the unit review.

GAMEOPTION_MAXIMUM_POPULATION - ?
I think this is something DH was considering working on and thus it was made an option to work with for that project.

GAMEOPTION_ONGOING_TRAINING - WIP
Yeah, and another I'd LOVE to get some progress on that the unit review is going to help me to do much easier.

GAMEOPTION_NIGHTMARE_MODE - was changed to be normal handicap, removed in savebreaking branch
This could be removed if we've set it up as an extra difficulty and all the challenges in doing so have been overcome. I'm not sure where we are with that.

GAMEOPTION_OUTBREAKS_AND_AFFLICTIONS - WIP
I'm very passionate about getting this done but want to make sure the unit review is in place first and all current property unit needs are filled before pushing forward further here.

Those options are hidden and enabled for various reasons (It seems like shouldn't be optional).
GAMEOPTION_MOUNTAINS - can build mountain mines, removed in savebreaking branch (now always active here)
I kinda figured DH refused to let this go...

GAMEOPTION_ASSIMILATION - allows assimilating other continental cultures - removed in savebreaking branch (now always active here)
I'd like to think that the Ideas project will obsolete this when it comes.

GAMEOPTION_ECOLOGICAL_ANIMALS - few animal units need this option - removed in savebreaking branch (now always active here)
DH's option and I'm not entirely sure what it's for, even though he's tried to explain a few times I think.
 
GAMEOPTION_MAXIMUM_POPULATION - ?
I think this is something DH was considering working on and thus it was made an option to work with for that project.

Those options are hidden and enabled for various reasons (It seems like shouldn't be optional).
GAMEOPTION_MOUNTAINS - can build mountain mines, removed in savebreaking branch (now always active here)
I kinda figured DH refused to let this go...

GAMEOPTION_ECOLOGICAL_ANIMALS - few animal units need this option - removed in savebreaking branch (now always active here)
DH's option and I'm not entirely sure what it's for, even though he's tried to explain a few times I think.

GAMEOPTION_ECOLOGICAL_ANIMALS already commented on this one. It is a big project and probably needs to be part of the Dynamic World Project which places Earth biomes based on the map generated not Earth latitude and longitude.

GAMEOPTION_MOUNTAINS not me as far as I recall. The way mountain mines have been implemented is different to the way other improvements have been implemented meaning we can't define other mountain improvements without editing the dll. I think two projects had been done together and accidentally combined. Movement over mountains and improvements on mountains. There should be no special code in the dll needed beyond limiting those improvements in the XML to the correct terrains to account for mountains.

GAMEOPTION_MAXIMUM_POPULATION - I did not know this one had been made available. Basically the idea is that cities can't grow beyond a certain size if you don't have the infrastructure present. In Civ III this meant that you needed an aqueduct to go above size 6 and a hospital to go above size 13. This represents people dieing (dag nab it - the dictionary says that is the correct spelling as dying; both also mean to colour or stamp with a die) because there are not the facilities for them to survive. I was going to use Cholera in the place of this... no more that pop 1 if no fresh water, no more that 6 if no aqueduct... but I was going to have the disease strike and kill off excess population instead with the chance of an outbreak increasing exponentially with excess population and decreasing linearly with health care facilities and workers.
 
Yes and no because water features depth, temperature and navigation indicators in their name.

Navigation
  • Coast = can see land from a raft or deck of ship
  • Sea = can not see land from raft but can from the crow's nest of a large ship
  • Ocean = can't see land even from the crow's nest
Temperature
  • Tropical
  • Temperate (default, so usually left off)
  • Polar
Depth
  • Shallows (not yet implemented)
  • Shelf (default, so usually left off)
  • Trench
  • Abysmal Plain
This means you may want to add some things to the names.
They were left untouched in the end.

GAMEOPTION_ECOLOGICAL_ANIMALS already commented on this one. It is a big project and probably needs to be part of the Dynamic World Project which places Earth biomes based on the map generated not Earth latitude and longitude.

GAMEOPTION_MOUNTAINS not me as far as I recall. The way mountain mines have been implemented is different to the way other improvements have been implemented meaning we can't define other mountain improvements without editing the dll. I think two projects had been done together and accidentally combined. Movement over mountains and improvements on mountains. There should be no special code in the dll needed beyond limiting those improvements in the XML to the correct terrains to account for mountains.

GAMEOPTION_MAXIMUM_POPULATION - I did not know this one had been made available. Basically the idea is that cities can't grow beyond a certain size if you don't have the infrastructure present. In Civ III this meant that you needed an aqueduct to go above size 6 and a hospital to go above size 13. This represents people dieing (dag nab it - the dictionary says that is the correct spelling as dying; both also mean to colour or stamp with a die) because there are not the facilities for them to survive. I was going to use Cholera in the place of this... no more that pop 1 if no fresh water, no more that 6 if no aqueduct... but I was going to have the disease strike and kill off excess population instead with the chance of an outbreak increasing exponentially with excess population and decreasing linearly with health care facilities and workers.
First two options were nuked from existence, only third one is still around here.

As for Nightmare Mode it was fully converted to normal handicap now.
 
First two options were nuked from existence, only third one is still around here.
This is what happens when the push to perfect collides with project loose ends. Of course, it appears to have been sitting forgotten so *shrug*.
 
How often and how long will save games be broken? As both Civic test games are now giving the "Unreadable Save Game" pop up. "Save format version is not compatible, version=(1) expect version=(2)!"

I suppose I need to stop updating thru GitHub desktop or even the SVN till this phase is complete. :sleep:
 
How often and how long will save games be broken? As both Civic test games are now giving the "Unreadable Save Game" pop up. "Save format version is not compatible, version=(1) expect version=(2)!"

I suppose I need to stop updating thru GitHub desktop or even the SVN till this phase is complete. :sleep:
Switch to release branch and stay here for a while here.
If playing on SVN then stay at 11119 for a while.

We have no idea how long we will be doing savebreaking updates.
 
Why not do all the savebreaks at once? Are some savebreaks prereqs for others?
 
Why not do all the savebreaks at once? Are some savebreaks prereqs for others?
We are doing various savebreaking projects.
Now Toffer is removing building/unit classes so game uses less memory and works faster.
@alberts2 was meant to do other savebreaking stuff, but he disappeared.

Also he left some notes about savebreaking code in savebreaking notes.
 
Last edited:
We are doing various savebreaking projects.
Now Toffer is removing building/unit classes so game uses less memory and works faster.
@alberts2 was meant to do other savebreaking stuff, but he disappeared.

Also he left some notes about savebreaking code in savebreaking notes.
But couldn't all those changes be included in one SVN revision?
 
Yes they can be, if you can wait few weeks if not couple of months for next SVN ;)
Well 1. if all they're doing is breaking saves then yes we can, but 2. there's nothing stopping you from making non-savebreaking updates in the meantime (ie. with all savebreaks in a separate 'branch', which seems like a no-brainer anyway).
 
Well 1. if all they're doing is breaking saves then yes we can, but 2. there's nothing stopping you from making non-savebreaking updates in the meantime (ie. with all savebreaks in a separate 'branch', which seems like a no-brainer anyway).
Sure, we can cherrypick what we include in SVN updates to avoid savebreaking as much as possible for a while.
 
Sure, we can cherrypick what we include in SVN updates to avoid savebreaking as much as possible for a while.
Thanks, but I was just trying to get a sense for time before this work is completed. I knew it was coming. But I have not kept up with the emails from Git as closely as I had before December.

I know this Save breaking must be done. And that it will have effects upon my Civic test games. I can continue them by using the last SVN they worked with, just that I will know that some of the results of the testing will change. And I accept that.

This save breaking build up had to be addressed at some point in time. And now that there are more coders to deal with it then good! And so " git 'er done!". :)
 
Why not do all the savebreaks at once? Are some savebreaks prereqs for others?
You can do that to a degree but at a point you start getting so much changed in the code that it would make other changes so capable of corrupting the work you've done that it just needs to get in place. There's a lot of things we're doing here. I urged for a little more delay but I can see why we'd be moving forward on this now.
 
As I stated in the Civics thread, right now my time for testing is limited. So getting the Save breaking fixes in now is at a good time for me. Was just curious about how long it might take. And no intention of rushing anyone at all.

I still update my GitHub desktop every day. But as you know I've not been on Discord for a long time. And my posting here is way down too. Just don't have the time and energy for it right now.
 
As I stated in the Civics thread, right now my time for testing is limited. So getting the Save breaking fixes in now is at a good time for me. Was just curious about how long it might take. And no intention of rushing anyone at all.

I still update my GitHub desktop every day. But as you know I've not been on Discord for a long time. And my posting here is way down too. Just don't have the time and energy for it right now.
Hope you start feeling better!
 
Top Bottom