Moderator: OpenTTD Developers
It is OK in case of random map (or heightmap) played, but in case of scenario used for multiplayer server (and breakdowns enabled),
whenever server starts, all vehicles have reliability same as when scenario was created. It narrows choices of vehicles, because in case of each multiplayer session,
all vehicles have assigned same maximal reliability, as in previously ones.
My proposal is to distinguish between sav and scn loading: while .sav should preserve all stats (for sake of proper network sync), max reliability would be randomized
when server is initiated by .scn loading (it occurs only when server is starting with -g parameter and file name ends with .scn, or by choosing "play scenario" menu)
A lot of people play with breakdowns turned off, so let me ask you: What would your game look like if each vehicle had a different power or a different maximum speed each time you started a new game?
This was my objection to the generally random reliability. When it comes to adding randomness to loading scenarios, the argument against is the issue of competitiveness: if someone would like to organize an offline tournament, each player would have vehicles with different parameters.
This randomness may have been good when the vehicle selection was very limited, but not currently when there may be hundreds of vehicles to choose from in the game.
I would have another suggestion here:
So that the reliability is constant and determined by the developer of the add-on, not random and changing every time you run it. This would allow some advantages or disadvantages to be added to the selected vehicles which could outweigh other advantages or disadvantages of the vehicle.
Thanks to this could be available to choose a cheap but quite unreliable locomotive, and another one, more expensive but with clearly better reliability parameters.
In case the author did not specify this parameter, the reliability would be random, but invariant for a saved game or script.
There might also be an option for the add-on developer to specify the randomness range of this reliability as well as the initial reliability.
Option without random failures,
But minimizing caused from the user's decision :
Rule A) similar to the principle of slowdown when driving through many corners (bends) ,
More junctions ('railway crossover') under the driving composition is a infrastructure failure
and slowdown temporary
Rule B) The train can only stop when it has low reliability and one locomotive in the composition
Users browsing this forum: No registered users and 3 guests