Moderator: OpenTTD Developers
That reference is based upon an ancient post by me:brutesquad01 wrote: I am trying to make a train calculator in Excel, but my calculations are not working out in game. [...]
Calculations were based on TTDPatch mechanics.
There were numerous discussions about "realistic acceleration in OTTD", e.g.:
Trains accelerating too fast:
Weird Train Acceleration in Nightlies:
Both might be worth reading.
And there´s Peter´s calculator:
Disclaimer: I don´t know what the current status in trunk or JGR´s patch is.
The source code is freely available, you can read up to the last bit how it works exactly (unlike in the real world, where mother nature does not give us that insight).
I don't know what you're doing, but approximating that code with some set of continuous equations is going to fail. You compute things differently from the real code, which introduces errors, ultimately resulting in different answers than the real simulation.
This is a normal phenomenon in modelling though, any model is an approximation, and will give errors.
If you model a real-life train with a set of equations, you also get errors. However, we have studied real-world motion since Newton, so we have a pretty good idea how to do that, ie we have good models for real-life trains. (They still have errors though, eg Einstein says you should take relativity into account, which mostly likely is never done.)
In your case, you're trying to catch the behaviour of a computer producing speed of a virtual train. There is no friction or air in a CPU, or steel running on steel, so any real-life train model does not apply. The computer uses iterative discrete mathematics. Modeling that as a set of continuous equations is a valid approach, but discrete mathematics don't quite work the same as floating point, so it may introduce large errors.
Also, other OpenTTD developers may have different opinions.
I mean that I've asked not only here, but on reddit and other communities and the answers that I get back are old discussions with no definitive conclusion or old tools that give inaccurate results. No one has said "JGRPP works differently" or "here is the math that is used" or "the game also accounts for these variables." Yours is the most definitive answer I've got thus far, and it's little more than "it's in the code." So, if no one is able to answer my question, then I must conclude that no one knows. It's not a personal attack on the community or anyone in particular; maybe the person or people who knows how it works are no longer active in OpenTTD. That's fine if that's the case, not like anyone's getting paid for this.Alberth wrote:What do you mean, no one knows?
Unfortunately, I'm not a programmer (or a mathematician, or physicist, or any sort of technically trained person), so I don't have a clue where to even begin to look in the source code for the information, or even which code to look at. I hadn't considered your point that an equation will not match the game code perfectly. What I have right now isn't even close enough to be considered an approximation, though, so I don't think that's the problem. Maybe I would be better off to record data from in-game testing and derive an approximation from that? I don't know, I've been figuring this all out on my own (including Excel), so I'm just trying to get some help.
Look here. TE is pretty much sum(part_weight*part_te)*10000 div 256. And last time I checked it did yield the same TE as in game. There are some nuances with this calculation though which I don't remember.brutesquad01 wrote:I don't have a clue where to even begin to look in the source code for the information, or even which code to look at.Alberth wrote:What do you mean, no one knows?
Thank you! This looks like it has all the info I need, if I can decode it. That might take a while._dp_ wrote:Look here. TE is pretty much sum(part_weight*part_te)*10000 div 256. And last time I checked it did yield the same TE as in game. There are some nuances with this calculation though which I don't remember.