1.0C ON EXPERIMENTAL BRANCH: A NEW... NUMBERING SYSTEM

I've noticed a significant performance improvement with the update.

Mmm, coffee crops are still broken, any chance this could be changed before release, since you fixed tobacco? It's just a one-line change in crops.edb

 

Now the Barmans don´t refill the booze of the bar. They pick up and drop the booze forever

 

That's a good news to me, the next one (that im still waiting for) is 'add a frontier road (or gravelpath/dirtwalkway/etc.) to the game'

Keep forward, comrade!!

 

Endgame hasn't improved , colony still crashes without noticeable reasons, also with a count of of 137 colonists the game feels still a little sluggish (noticeable pause between walking animations) and

 

Is the old rule about experimental not guaranteeing sane behaviour when loading saves from a previous version still applicable?

 

Yes, the behaviour of a lot of things won't be fixed by a new release. But the sluggish behaviour shouldn't be affected by it, because the colonists are picking up new jobs and getting the current fixes by it. The game crashes seemed to be related to fire animations when fighting selenians so they should get new fixes either.

But to be honest, when a game reaches 1.x state i personally expect that save game compatibility AND application of fixes of newer versions should be a matter of course

 

That basically is the same as not having any experimental at all.

There's an optional experimental branch for a reason.

 

No, experimental is for testing out things..it may break things, it may crash more times, it may occasionally no longer load your save (in which case i would file a bug report so it may be fixed). But yet in some time it will become a productive version and my personal expectation for a fully released game is that the next productive version provides downward compatibility to the older one....
But if you think that bugs in the end game will be found at all if you need to start a new game everytime, well, that's your decision

 

You are welcome to try your old save. Just no guarantees it will work. And it is pointless to send in error reports as it could be a compatibility problem.

 

My naturalist refuses to restock paper on this build D:

 

Here we see Tillie Cogburn, in her eternal struggle to pick up Pulque without immediately dropping it again, and store it in a booze vat. Sisyphus eat your heart out:

(PS: It appears to still work for spirits)

 

Seems like REDACTED spores spawned by REDACTED impacts, rather than killing a REDACTED, still have to be explicitly forbidden and reclaimed, and spawn in the weird not-forbidden-but-actually-forbidden state when the REDACTED falls.

 

Awwww, c'mon...

 

It happened me with Foreign Office, just unasign the overseer and asign it again to the job and it solved that for me.

 

Nicholas, is this assumption valid? (The save files appear to contain script/XML that's presumably generated by the version that started the game originally, does this risk mismatching anything or yielding inconsistent behaviour compared to a fresh game?)

 

I think you have been misreading what i meant to say.
The save game contains states of the game objects but not scripts. It neither contains game object definitions. If you load a previous save there may be game objects that have a copy of the game object definition in their own state. These game objects (e.g. farms) won't get fixes, because they don't lookup the current game object definition in the current game installation.
You can test this with the coffee farm (see bugs forum) in a pre 1.0c game. The solution to replace outputCommodity = "crate_of_coffee_fruit" with the correct bushel_of_coffee_fruit won't work on an existing farm because farms store the crop commodity definition in the state of the farm that is saved in the save game. But if you would build an additional farm next to the existing coffee farm the new one would start to yield coffee (even though the game was loaded from 1.0 or 1.0b). The old farm remains broken.

So the answer about inconsistent behaviour depends very much on what you are asking about. If a colonists takes an entire new job the chances are pretty good that it will work as expected. But if it relies on fixes made in other game objects this may no longer be true, because these game objects might have been loaded from the old definition.

For me it is an display of a very bad programming style (sorry gaslamp) because there is no need to store a static definition inside the state of a game object...it is an unnecessary impact on the memory footprint and leads to problems as such as the farms show. This could easily be solved by looking up the current definition in EntityDB the moment it is used in the code instead of accessing a local gameobject state, because the information stored in there is the same as in every other game object of the same type.

So the answer to yield inconsistent behaviour, yes that may happen, but it depends on the circumstances and could (and should) be prevented in the code by reinitializing or working with the actual definitions from the game base.

PS: Maybe it's time for a scripts and modding forum