Serious bug in -devel: "also reverse" and "Mirror schedule" are not saved! fixed

Topic: Serious bug in -devel: "also reverse" and "Mirror schedule" are not saved! fixed (Read 3243 times) previous topic - next topic

Serious bug in -devel: "also reverse" and "Mirror schedule" are not saved! fixed

July 09, 2010, 05:44:34 pm

The "also reverse" and "Mirror schedule" options for lines are not saved and so are lost on save/reload.
In addition, the information as to whether a convoi is travelling forward or in reverse appears to not be saved and to be lost on reload.

This makes these functions pretty unusable, although they're very nice apart from that problem.

EDIT: it looks like I simply have to upgrade the experimental version number to 9 in simversion.h. Doing so now.

Re: Serious bug in -devel: "also reverse" and "Mirror schedule" are not saved! fixed

Reply #1 – July 09, 2010, 10:04:43 pm

Nathanael,

the version is purposely left non-updated in -devel, as it may become necessary to add other save game changing features. If the version was incremented before a new 9.x branch was created (in which the save game format is fixed), games saved with earlier -devel commits would be incompatible with later -devel commits (and, for that matter, everything else). This technique is used in Standard, too. Not incrementing the save game version in -devel until the next version branch is forked is thus deliberate.

Re: Serious bug in -devel: "also reverse" and "Mirror schedule" are not saved! fixed

Reply #2 – July 10, 2010, 04:21:10 pm

Quote from: jamespetts – on July 09, 2010, 10:04:43 pm

Nathanael,

the version is purposely left non-updated in -devel, as it may become necessary to add other save game changing features. If the version was incremented before a new 9.x branch was created (in which the save game format is fixed), games saved with earlier -devel commits would be incompatible with later -devel commits (and, for that matter, everything else). This technique is used in Standard, too. Not incrementing the save game version in -devel until the next version branch is forked is thus deliberate.

I understand doing this, but I would simply up the version number and allow for certain version numbers to not be released if necessary. (If necessary, go straight from 'experimental 8.x' to 'experimental 10.x' without releasing 9.x).

What has to be done before releasing 9.x anyway? There's enough new functionality it's worth getting it into wider testing.

Re: Serious bug in -devel: "also reverse" and "Mirror schedule" are not saved! fixed

Reply #3 – July 11, 2010, 12:43:35 pm

I prefer to have a logical release schedule without skipping version numbers. -devel is not, after all, intended for playing, but for testing, so there is no pressing need to have full save integrity in -devel.

As to what needs to be done before 9.x, I need to integrate and test this feature, as well as implement a feature to require depots to be built within city boundaries and have them contribute to local employment to an extent depending on their "level".

Re: Serious bug in -devel: "also reverse" and "Mirror schedule" are not saved! fixed

Reply #4 – July 11, 2010, 03:22:35 pm

Quote from: jamespetts – on July 11, 2010, 12:43:35 pm

As to what needs to be done before 9.x, I need to integrate and test this feature,

Hmm. That's a nice feature, certainly, but the other changes in -devel probably deserve wider testing before it goes in.

Quote

as well as implement a feature to require depots to be built within city boundaries and have them contribute to local employment to an extent depending on their "level".

Ugh. Please don't require depots to be built within city boundaries. At the very least, make it possible for paks to turn this off. I would always turn it off immediately. It's horribly impractical. Apart from the obvious (ship depots on the open ocean would become impossible unless there was a coastal city), I often end up with an isolated industrial railway (supplying coal to a power plant or something) and it is NOT reasonable to require me to put my depot hours and hours away in the city.

I strongly suggest abandoning that proposed feature.

Re: Serious bug in -devel: "also reverse" and "Mirror schedule" are not saved! fixed

Reply #5 – July 18, 2010, 10:48:48 am

Quote from: neroden – on July 11, 2010, 03:22:35 pm

Ugh. Please don't require depots to be built within city boundaries. At the very least, make it possible for paks to turn this off. I would always turn it off immediately. It's horribly impractical. Apart from the obvious (ship depots on the open ocean would become impossible unless there was a coastal city), I often end up with an isolated industrial railway (supplying coal to a power plant or something) and it is NOT reasonable to require me to put my depot hours and hours away in the city.

I strongly suggest abandoning that proposed feature.

These are interesting thoughts. On the topic of ship depots, though, aren't they usually built in coastal cities in real life? Coastal cities usually extend their city boundaries well into the sea. The new feature to which I referred above will make it much more likely that there are coastal cities.

However, one option could be, instead of prohibiting depots outside cities entirely, just increase their maintenance cost to represent the additional cost of having to bring in staff from far away. The degree of increase could be set in simuconf.tab, enabling the feature to be disabled entirely by setting a zero increase.