One useful addition would be the ability to specify a priority list of ways to which a way should upgrade when it is no more available itself. This would prevent auto-upgrading from downgrading ways. For example in pak128.Britain-Ex, Steel track (109 lb/yard) (160 km/h, 22 t) is upgraded by default to Steel track (85 lb/yard) (90 km/h, 17 t).
I have split this from the topic containing the .dat file reference because this is more in the way of a feature request and bug report than a discussion of the reference itself.
I write bug report because the automatic replacing on degradation should not result in the way being downgraded in either weight limit or speed. Can you set out in a little more detail the circumstances in which this issue can be reproduced and I shall see whether I can fix it when I get home to-morrow (or thereafter)
It occurs after the 109 lb/yard track is retired (June 1968). After that date, it is by default upgraded to 85 lb/yard, even after the introduction of Steel track - continuously welded (110 lb/yard).
Is this because at the time the 109 pound track is withdrawn, there is a gap? I think this gap was fixed though (in the pak-set). But if your pak is not entirely up to date it might not have this fix.
Rolermaterial - can you check with the latest version of the pakset if possible to see whether Junna is correct about the cause?
The gap is already fixed in my version (half-heights 7ad2a2e).
I think that I may have found and fixed this bug (as well as slightly improving the system that automatically finds replacement ways by taking into account the wear capacity).
I have not had time to test this, however. Do you care to re-test? I should be grateful for your results.
Now the whole game crashes when loading the pakset :/
My apologies: I forgot to commit all the code, so this was incomplete and non-working code. This should be fixed now. Could you re-test?
It isn't fixed. By the way, should the fix also correct it for ways that are already default-set to downgrade? I'm only asking this to know if I can directly test it in my save or if I have to run a test game like I just did.
What do you mean by already default-set to downgrade here? The upgrading mechanism works by having a specified way to renew the current way for each tile of way. By default, that is the same type of way as the current way, but this can be changed by SHIFT+dragging another way over it. If, however, the specified upgrade way is obsolete at the time when an upgrade is due, the code to find an alternative is invoked, and it is that code that I have attempted to fix here.
In light of that, can you confirm that the error remains (and let me know specifically how you tested it so that I can reproduce your test)?
By default-set, I mean ways that are already about to downgrade due to the bug from earlier. Does the fix automatically correct it for these?
Quote from: jamespetts on February 04, 2016, 08:08:39 PM
If, however, the specified upgrade way is obsolete at the time when an upgrade is due, the code to find an alternative is invoked, and it is that code that I have attempted to fix here.
Do you mean that the code is run at the time of upgrade?
Quote from: jamespetts on February 04, 2016, 08:08:39 PM
In light of that, can you confirm that the error remains (and let me know specifically how you tested it so that I can reproduce your test)?
I ran a test game starting in 1968 and placed two stretches 109 lb/yard track, one in January and one in March after introduction of the 110 lb/yard track. When the 109 lb/yard track became obsolete, both showed 85 lb/yard track as their next upgrade.
The code is indeed run at the time of upgrading. I will look into this further.
Edit: I think that I have found and fixed a further bug with this, and my initial tests suggest that this appears to be working. Do you care to re-test and confirm?
Now it literally upgrades my ways to the 200 km/h track. I guess this isn't exactly what's intended :D
Can you let me know which ways in what years and months are upgraded to the 200km/h track so that I can narrow down the issue further?
The 97,5 lb/yard and 109 lb/yard tracks in my save that until then were to be downgraded.
Looking into this, this appears to be a pakset issue rather than a code issue: my new code makes sure that the wear capacity of the way to which the current way is to be upgraded is no less than the wear capacity of the current way, and the 110lb/yard rail had a lower wear capacity than the 109lb/yard rail, so when the 130lb/yard high speed rail was introduced, it would upgrade to this by preference because of its higher wear capacity. I have fixed this by increasing the wear capacity of this and the 98lb/yard continuously welded rail in the pakset.