Re: [OTTD] 2cc TrainsInNML - Current version: 2.0-alpha1
Posted: 13 Jun 2017 04:25
Thanks supermop, that confirmed what i thought so far. At least you saved me from having to do trial and error.
The place to talk about Transport Tycoon
https://www.tt-forums.net/
While the most recent versions do have the code restructured to make adding such a feature more trivial, I have no intention to add such a feature at this moment. Personally I do not see the big added value.Cadde wrote:IIRC, 2cc trainset (the non NML version) had variable running costs based on current consist speed. If the vehicle was stopped, running costs were low whereas if the consist went faster than one of it's wagons design speeds (required wagon speed limits to be off), running costs would exponentially increase with overspeeding.
Is there any chance of this happening in the NML version?
But if you really want, supermop has given a nice explanation on what it should look like, although I prepared the code in this set to have those pieces of code hidden behind some #defines from C/make, to allow a single point of definition.Or, can someone better versed in NML explain to me how to set up that particular callback because i looked around and the documentation is unclear at best on that particular subject. I.E, where does the declaration for "running_cost_factor" go when one wants to use a callback? I assume in the "graphics" block.
And how do i access the current vehicle speed from within the callback?
I am not forcing anyone's hand here. But allow me to explain why it's useful or at least how it can add to gameplay. Of course, everyone has their own tastes and desires so we should all keep that in mind.Transportman wrote:While the most recent versions do have the code restructured to make adding such a feature more trivial, I have no intention to add such a feature at this moment. Personally I do not see the big added value.
Yes, i see what you did. If i were to do that change then ofc i would make use of the defines rather than hardcoding it in each graphics. I just didn't know where to put the declaration for the callback and how to access variables other than "extra_callback_info" but now i see how that works.Transportman wrote:But if you really want, supermop has given a nice explanation on what it should look like, although I prepared the code in this set to have those pieces of code hidden behind some #defines from C/make, to allow a single point of definition.
Yes, that's entirely possible to achieve. There's no "acceleration" variable to get at but one can store the previous callback speed in permanent storage and use that to derive the current acceleration of the train.NekoMaster wrote:... Trains will cost the most to run when accelerating as their engines are revving up and gunning it to pull a train and thus are burning more fuel ...
I would have it as...NekoMaster wrote:I think NARS basically had somethig like this for the running costs
Stopped/Idling = 50% of the running cost
Accelerating = 150% of the cost
Running at the trains max speed (so no acceleration or slowing down) = 100% of the running cost.
Yes, it's of course possible to determine if the train is accelerating vs decelerating. It's also possible to determine how fast it's currently accelerating so a very heavy train could cost even more to accelerate, to the point where having two engines at 150% running cost each vs one running at 300% for longer could be beneficial. And of course make it so wagons aren't taking up the majority of the whole trains running costs. Say, instead of the engine having running_cost_factor 25 and it's wagons having a factor of 12 it could have 100 for the engine and 1-2 for each wagon. Or that's how skewed i find it currently.NekoMaster wrote:Also, would it be possible to have trains only cost more when accelerating and not slowing down? The way I see in that code posted a few posts ago, trains running at certain speeds will end up costing the most if its not running at full speed if I set that up.
Yes it does. I will put it on the tracker for you.Cadde wrote:Does the Italian FS ETR300 'Settebello' EMU have a typo by any chance? It's supposed to have a max speed of 200 km/h, not 300 km/h?
I would put it on the tracker but i don't feel like making yet another online account for it.
IIRC, NARS and UKRS use this system, maybe even Michael's DB set as well. Hasn't this been done to the Dutch set too, I can't recall...Transportman wrote:. Is there a set that implements such a behavior at the moment? Then I can look at that for the code instead of reinventing the wheel.
There is an out-of-date Google docs sheet with vehicle properties, but that is not complete and I didn't update it. However, in recent versions of this set (nightly only, I should make a proper alpha release one of these days) things like running costs are already in a DEFINE, although the DEFINE is empty for the callbacks and only sets the cost properties based on the other vehicle properties.Cadde wrote:I do not know of any NML version of that code off hand. Unless NARS which was mentioned is NML, i doubt it.
But i can give it a try on a particular vehicle and see what i come up with. The reason i haven't done it yet is because i too understand how much work goes into it.
However, i did replace all wagon running costs (all but the powered ones) with "running_cost_factor: 1" using regex. Making an inline conditional using a parameter in it's place would be trivial.
And i then made a small application to replace powered wagons running costs with half of what they were before.
Finally, i added 1/32, 1/64, 1/128, 1/256 and 1x32, 1x64, 1x128 and 1x256 running cost factors in the parameters. I don't know why because after the wagon changes, i am still only running 16 times running costs but i anticipated i would need more for some reason.
But that begs the question, do you keep a database of all vehicles parameters or do you manually edit each and every file? Because i've contemplated reading the files with an application and putting it all into a DB and then auto generating the NML with that application instead. Then, adding running cost callbacks to every file that matters would be trivial. Well, it's kinda trivial already as i can just use DEFINE as you said and just adding the related switches in the respective *_graphics files programmatically but if i were working on such a large set of vehicles from the start, then i would make a GUI for it where changing the vehicle parameters would be easier and i could use the same application to do some other monotone tasks automatically.
However it's not my set, i am just trying to play without OCD'in about certain things.
The Dutch set does not have this, but I'll have to check NARS and UKRS for this at a later moment.Voyager One wrote:IIRC, NARS and UKRS use this system, maybe even Michael's DB set as well. Hasn't this been done to the Dutch set too, I can't recall...Transportman wrote:. Is there a set that implements such a behavior at the moment? Then I can look at that for the code instead of reinventing the wheel.
Code: Select all
return current_speed * 100 / max_speed * running_cost_factor / 100;
or in numbers...
return 6 * 100 / 56 * 100 / 100; // = 10.7142857143
Code: Select all
2.0 ala CADDE - alpha 1 (19/06/2017)
-----------------------
- Add: New (optional) dynamic (speed based) running cost behavior for locomotives, coaches and regular, powered and unpowered wagons.
- Add: Modifiable running costs for locomotives, coaches and regular, powered and unpowered wagons as a percentage of the default values.
- Add: Modifiable reliability decay.
- Add: Parameters for the above mentioned additions. (NOTE: This requires a complete reload of the GRF, no NOT use this GRF on an existing save!)
- Changed: Modified loading speed of coaches. They used to be "Intercity" with a default value of 16 but now have a default value of 12. Coaches are slower to load now.
- Fix: Italy FS ETR300 Settebello max speed was incorrectly set at 300 km/h, it's now 200 km/h.
Code: Select all
var t0 = param_TYPE_running_cost == 0 ? 0 : VEHICLE_ID_running_cost_factor * 10000 / (10000 / param_TYPE_running_cost) / 100;
var t1 = param_running_cost_dynamic_idle_percentage == 0 ? 0 : t0 * 10000 / (10000 / param_running_cost_dynamic_idle_percentage) / 100;
Code: Select all
res = Min(255, Max(0, Max(t1, current_speed * 100 / max_speed * t0 / 100)));
Code: Select all
linearity = 200;
res = Max(0,
Min(255,
Max(t1,
Min(t0,
(t0 + 1) *
((1000000 - linearity * 1000000 / (current_speed + linearity)) /
(1000 - linearity * 1000 / (max_speed + linearity))) / 1000
))));
Code: Select all
res = Max(0,
Min(255,
current_speed < 1 ? t1 : current_speed < current_max_speed ? t0 * 150 / 100 : t1
));
I personally think it is a lot of work with little gain. Once you got your game running past the starting phase, running costs aren't that big of a factor anymore, as you get way more income. And if income is 100, and running costs vary between 1 and 20, it doesn't really matter (numbers purely for illustrative purposes).Cadde wrote:I wanted to try something more complex than just linear running costs. So i made some math happen...
If you are #hyped about this then let me know. I get the feeling i am wasting my time sharing these bits and bobs.
You are of course entitled to your opinion but i can assure you that in my game, with my custom profits for all cargoes which depend on several factors, running costs do matter. Picking the right locomotive for the job can make or break a route and then you've wasted a lot of effort for nothing.Transportman wrote:I personally think it is a lot of work with little gain. Once you got your game running past the starting phase, running costs aren't that big of a factor anymore, as you get way more income. And if income is 100, and running costs vary between 1 and 20, it doesn't really matter (numbers purely for illustrative purposes).Cadde wrote:I wanted to try something more complex than just linear running costs. So i made some math happen...
If you are #hyped about this then let me know. I get the feeling i am wasting my time sharing these bits and bobs.
I don't think anyone regularly playing does that. Yes I build such railways between industries, but I don't care about money.Cadde wrote:For me, the game is so much more than just dragging a train route from industry A to industry B and slapping on the fastest and most powerful train and waiting for it to make 50 million a year. ...
There are a lot of different ways to play the game, and one way is not better or worse than another way, it's just a difference in focus.Cadde wrote:... "A lot of work for little gain." Well, i did the work. And i find the gains to be well worth it for me. I am currently playtesting everything, then i'll make another release with the new parameters added.
The only waste of time i've had so far is posting about it here. I don't really mind, but if no-one is going to be using it i might as well save me the trouble of posting and keep it to myself.
Thanks for the report, I already had the idea that the lifetimes were a bit weird, but that is not the intention. I hope to get some time to fix that (along with several other issues).McZapkie wrote:This set have a huge flaw: many locomotives have engine life 2x longer than model life (for example 40 years of engine life vs. 20 years of model availability, in contrary to original openttd vehicles which have longer availability and shorter vehicle life).
It is very harsh to use this set while vehicle breakdowns are enabled, because engine have below 50% of reliability during most of their life. Additionally, option "replace when old" is completely useless.
May I ask to fix this issue?
The best option is to add 20 years to each model lifespan and additional "retire_early 20" line. Effectively locomotives would be available as it was previously, but reliability protection will be expanded, so at least locomotives purchased at the beginning of the offer should have chance to work properly until old.