Breaking Save Game Compatibility for v37

Some other changes needed

UNIT_SHARK to become UNIT_REEF_SHARK
UNIT_RAY to UNIT_EAGLE_RAY
UNIT_MANTA to UNIT_MANTA_RAY

All buildings _SONG to become _MYTH_EFFECT
 
Hehe, true that.
I can hold it off until someone else also got something that will break saves ready.

It's T-brd that would be most likely the biggest one to be impacted with all his current and recent changes. Run it by him and if no problem, then from me you will get a :thumbsup:.

JosEPh
 
  • Split Barbs into Animals and Barbs and reserve 5 player slots for these kinds of NPC groups.

What do you think about splitting the animals into 2 new groups, harmless and aggressive. We could then have spawns of harmless animals in player territory, like deer in forests, and end very weak animals attacking like when a dreadnought of mine got attacked by a cod with 0.02 strength.
 
What do you think about splitting the animals into 2 new groups, harmless and aggressive. We could then have spawns of harmless animals in player territory, like deer in forests, and end very weak animals attacking like when a dreadnought of mine got attacked by a cod with 0.02 strength.

I wanted to do something along these lines actually.
 
WARNING:

As of SVN 9099 all save games started Prior to SVN 9070 are Now Incompatible. Was able to continue a 9084 SVN save game that was not very far into the game. Anything prior and Loading Hangs at "Initializing" the save upon load.

ALT-Tab and you will get pop up for Save Incompatible. Had to ReStart computer from Task manager for Win 10 x64 as Desktop completely frozen.

So if you've Updated to SVN 9099 or beyond forget your old saves. They be kaput now.

JosEPh
 
What do you think about splitting the animals into 2 new groups, harmless and aggressive. We could then have spawns of harmless animals in player territory, like deer in forests, and end very weak animals attacking like when a dreadnought of mine got attacked by a cod with 0.02 strength.

Specific animals can already be defined as capable of spawning inside cultural territory by adding <bNeutralOnly>0</bNeutralOnly> to their SpawnInfo xml.
If the line doesn't exist it is assumed by default to be of the value "1".

And it's easy to deny specific animals the ability to attack:
<bOnlyDefensive>1<bOnlyDefensive> in the unitinfo xml.

I think it's enough for animals to take up only one new player slot.

@:Joe, thanks for putting the message out. :)
 
This is bad IMO. Any game started now is broken as soon as barbarians and animals are separated.

Does it even make sense to start a new game now?
 
I forgot that there is at least one folder that needs to be deleted as part of the compatibility changes. It contains some special units that we added then did not use. I will remove them after I get my version updated.
 
The last thing that needs doing for the breaking of saves, as far as I know, is the removal of the options that we no longer want.
 
The last thing that needs doing for the breaking of saves, as far as I know, is the removal of the options that we no longer want.

There's a LOT that could/should be done in the dll. The splitting of animals and barbs and such is one of those but while it's a big project, it's also about half of the cleanup I'd like to do.

I was hoping to hold off on this for a bit longer so that the break could be done over a much smaller amount of time. If we're going to keep the break we've done then it means I must immediately start working on this and I haven't done half the planning for it I would've hoped to have done to make it a smoother transition.

But... ah well.
 
There's a LOT that could/should be done in the dll. The splitting of animals and barbs and such is one of those but while it's a big project, it's also about half of the cleanup I'd like to do.

I was hoping to hold off on this for a bit longer so that the break could be done over a much smaller amount of time. If we're going to keep the break we've done then it means I must immediately start working on this and I haven't done half the planning for it I would've hoped to have done to make it a smoother transition.

But... ah well.

I thought u'll said it was discussed earlier thats why the break is in the current SVN, did someone "fudge.":rolleyes:
 
I thought u'll said it was discussed earlier thats why the break is in the current SVN, did someone "fudge.":rolleyes:

The break is being done with v37 but that does not mean it wont be done over many SVN releases. It may have been better to do a branch and no changes at all to the SVN until it was all done so we could merge the branch in but that is even more coordination effort.

Basically as a player you should not be updating your version from the SVN until we have everything done.

This is the first time we have bothered with fixing/removing stuff that will break compatibility. We may be able to learn from what we have done for the future but I don't see how we could coordinate better this time.
 
Basically as a player you should not be updating your version from the SVN until we have everything done.

I agree with DH and can not see what the problem is here. After all it is only for dedicated SVN players - who should know the risks.

Rename your current "Caveman2Cosmos" to "Caveman2CosmosPrev" (I actually use the date 01-23 etc.)

Create a new "Caveman2 Cosmos" folder and extract the new SVN to it. It may take a bit longer to do - but if the new version breaks the current save game. It only takes a few seconds to revert back to a working version, by renaming the C2C main folders.

Restricting crucial updates to keep save game compatibility (on the SVN) seems odd to me. Just play current long time games on an older version that you started with (I have to do that to use WorldBuilder - after it was corrupted last May) and then you test updates on the latest versions.

It is easy to switch between the two.
 
Back
Top Bottom