Recent Posts

Pages: [1] 2 3 4 ... 10
In such a case why not treat such broken links like no upgrade was specified? That seems the most logical approach.

This is required in case people make addons and the user does not want all the upgrades.

I also suggest fixing the incorrect references in the pakset with a merge request over at the pak128 Britain GIT. That would at least defer the problem for now.
It would still be a run time failure. But it would be a guaranteed immediate failure, instead of a failure only when someone takes and action involving a specific vehicle type.
I support the fail fast approach. Better to catch at build time rather than run time.
I have diagnosed the bug.

The immediate cause of the crash (for the above save) is that the upgrade for the vehicle 'lmr-4wheel-open-coach-short-wheelbase' is NULL, leading to a null dereference. This is a consequence of it being specified in the pakset as upgradable to 'lmr-4wheel-open-coach', which doesn't exist. The intended vehicle is actually named 'LMR-4Wheel-Open-Coach' (note the different capitalisation). Fixing this instance is straightforward; the discussion below is relevant to finding other such issues.

A causal factor is that there is no detection of missing upgrades, and they are not handled gracefully. There are two possible ways of 'fixing' this - either fail fast, or don't fail at all. Not failing at all is the more complicated (and likely messy) option.
Failing fast requires just a one-line change ( to the pakset writer, (it is the pakset itself that determines whether each missing reference is fatal). Since this will not affect existing pakset builds, then it will not cause any new breakages; it will of course require updating the pakset.

An underlying factor is that there appears to be no logging or display of missing references, which means that typos and errors in crossreferences in the pakset can easily go undetected. I think this should be changed also.

I'm going to look into adding better detection of missing references. Also, I think the fail fast approach (as mentioned above) is best, but would appreciate any further remarks on this. (E.g. are broken references used deliberately for WIP in pakset development?)
Splendid, thank you. I have now incorporated this.
I have put a merge request for the engines up to 1835. I will do more in the future.

Generally I have tried to scale per km cost with engine power, factoring in engines becomming more fuel efficient due to scale and better designs. Per month costs have been scaled representing the realitive complexity of the engine and number of crew needed.
Dr. Supergood - as an interim measure until full balancing can be put together after the new features are added, that would be very helpful.
Patches & Projects / Re: Sort Vehicles in Depot Window
« Last post by HyperSim on Yesterday at 07:48:43 AM »
A month have passed since last post.
Is there no opinions?
The server game is starting to hit the point where we are going to run out of viable trains. Only the very early trains have been balanced, with the ones being introduced now all having insane running costs.

For example the 59km/h train costs just 0.08c/km where as the new 80km/g train costs 7.70c/km. Seeing how they also lack monthly maintenance costs this points towards their data not being rebalanced.

I would be willing to hack together some reasonable sounding numbers that would work with the gameplay, however they would not be historically sourced.
Bumping because an edit might get overlooked.

This crash can be recreated using the bug demonstration map posted here...

Although the map's purpose is for the one train staff reservation bug, this crash is present in it as well. Select one of the 4 trains and hit the details button. The game immediately crashes.

Crash always occurs when pressing the button using latest nightly x86-64 build on Windows 10. Processor used is an I7 920, in case it is related to instruction set.
Pages: [1] 2 3 4 ... 10