Use the "Forum Search"
It may help you to find anything in the forum ;).

Crash when upgrading class 430 to 442

Started by Vladki, February 01, 2020, 11:34:30 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Steps to reproduce:
1. (maybe optional) build BR 491 trailer set (with buffet)
2. attach BR 430 unit (with buffet) to it.
3. upgrade 430 (front part) to 442 - two vehicles get upgraded...
4. upgrade 430 (rear part) to 442 - crashes the server and hangs client (kill -9 needed)
Both display this error message:
FATAL ERROR: array_tpl<T>::[] - index out of bounds: 8 not in 0..7, T=P9vehicle_t


Thank you for the report: I believe that I have fixed this; I should be grateful if you could re-test.

However, I advise disassembling this combination before upgrading.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


Well, I have googled what is that upgrade... It seems that they just reused the engines and put them into different vehicle...
There are several more such upgrades where the upgrade is not usable as direct replacement of the original vehicle. And there is no UNDO for that. You have to know the railway history to use such upgrade. At least I expect that upgraded vehicle will be usable for the same purpose as original, just with some improvements - more power, cheaper to run, faster, more capacity, higher comfort, push-pull operation, etc. But upgrade from front motor to middle motor is quite confusing...


Thank you for your feedback. I should be interested in people's views as to whether to abolish the 4-REP to 4-WES (430 - 442) upgrades; is this more confusing than useful?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


Quote from: jamespetts on February 02, 2020, 01:04:27 AMI should be interested in people's views as to whether to abolish the 4-REP to 4-WES (430 - 442) upgrades
Imho, upgrades are meant for technical changes to existing vehicles, so if only the name and maybe the livery was changed but there are no technical changes reflected in simutrans, it should not be an upgrade but moreover a livery.

However, in this case we have a quite huge technical change. I don't think we should disallow that kind of upgrades but upgrades should clearly point out differences that may lead to incompatibilities by e.g. marking changed values that may cause incompatibilities in red and any other changes in green.


I'd argue that the different (Mk3) bodyshell does warrant an upgrade, as it uses the same electrical equipment (which saves money over producing it all-new)


The problem is that the upgraded car doesn't fit in the original train. So you have to buy some new cars, and scrap some old cars. Similar is with upgrades at beginning of 20th century when normal cars were upgraded to emu trailers.

If at least there would be some undo feature otherwise some upgrades are a trap. Also the fact that you pay monthly fees also for vehicles stored in depot, does not motivate players to keep old or unused stock in reserve for expansion or upgrades. It is better to sell it while it has some value.


The learning curve on this game is already very steep. If Vladki was caught out by it, new players are not going to have a chance. IMHO these vehicles should not be upgradable unless and until the UI is able to warn players that this could break their convoys.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese


It is an interesting question as to whether an undo feature would be useful. I wonder whether any of our UI programmers would like to have a go at this?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


Ideally, it should have a temporary convoy, like a replace window, and the player can complete it at any time by pressing the Done button. Players can start over until he press the Done button.

Typically, such upgrade GUIs should list the parameters before and after modification, and indicate the amount of change, so that changes in specifications can be compared.
But such modifications would require a significant amount of work. Since we are based on the standard GUI, adding features that do not exist in the standard can be very restrictive.

Another patch improvement that I happened to work on might slightly improve this problem.

Mouse over the vehicle you want to upgrade with that patch
1) Location of vehicle to be upgraded (This feature was recently added)
2) continuously upgraded vehicles automatically,
3) Coupling constraint error between upgraded vehicles and existing vehicles
4) Number of vehicles which is upgraded at the same time
is displayed.

(´・ω・`)ごろうじて? Check this out?

If the vehicle to be remodeled can be connected to the next vehicle, it will be displayed in purple. If an error occurs in the constraint, it will be displayed in red.
Well, it may be a little difficult to distinguish between purple and red. But it is common throughout the GUI. (´・ω・`)

Let's check another example

The convoy has only two vehicles, but upgrades have seven options.
I checked them one by one in that animation GIF. You can see that the third option does not cause any problems.
In the image, when the third option was selected, the color bar of the 2nd vehicle of convoy was displayed in purple. This indicates that the 2nd vehicle will be upgraded at the same time.

After performing the third option, one new upgrade option appears. Let's check this.
You can see that this is an upgrade that destroys the current convoy.
This seems to be a trap that traps the noob that is common in RPG games.
So you need to look into this upgradeable vehicle and do it.
Such upgrades should be avoided if you are not a geek.

Anyway, this patch will allow newbie to avoid such traps.
But we must note that this is far from the best.
For example, when upgrading A1 A2 A3 A4 to B1 B2 B3 B4, if the concatenation of group A and group B is not compatible and they are not the only combination, this improvement cannot determine if the upgrade is correct .


This is a great improvement to upgrading imho! Kudos and ありがとう!

About the external upgrade GUI with comparisation and so on, maybe we already have something quite simmilar and could adjust it: The replacement GUI.
It will let you draft perform upgrades. If you close the window without confirming the upgrade, nothing will happen.
The adaption required is to make it work from the vehicle currently sored in the depot instead of for a vehicle actually on the map.
There is another far from optimal point in the replacement GUI: You can set replacements to uncompleted vehicles, i.e. ones that cannot be sent out of the depot and there is no "auto completion" in the replacement GUI.

I guess if you can fix these two things and you somehow get it working with vehicles from the depot, we will have a good UI for upgrades. Still not perfect as we still won't have an "undo last step" function but at least we can cancel the whole replacement if we did something wrong.
Further, it does already provide a basic comparisation in between the current vehicle and the vehicle after the replacement, however that could also be improved a lot.


I Think There Should Be Option to Decide In WHat Arrangement You want Covoy to Be

Simutrans - the open source Transport Tycoon Deluxe clone.