The place to talk about Transport Tycoon
https://www.tt-forums.net/
That's it! Thanks.JGR wrote:You should change the category to "expert" to show all settings.
Does this mean that I am no longer an expert?Edit: I've moved them to the advanced category now.
Thanks again!JGR wrote:This seems to be a known issue https://github.com/OpenTTD/OpenTTD/pull ... -141317975, I'll see about applying a fix soonish.ISA wrote:JGR thanks for the fix! All running fine now
One little problem tough and I'm not sure its related Your patch pack.
After update I cant build waypoints in \ direction (see picture below). Other way around its all okay.
Edit: Fix applied
It´s not in the spec, because nobody put it there. I would have done it myself, but I seem to be "excluded" from the wiki for some unknown reason.JGR wrote:I can look into implementing something equivalent to this.michael blunck wrote: [bridges over stations]
NMF introduces a new property "bridge height" (prop 1B). It defines minimum clearances required for a bridge for each tile type of this station (or zero to not allow any bridge).
That said, the property doesn't appear to be in the spec. What is to stop there being a ID collision when trunk decides to add an unrelated station property, which would most likely also be numbered 1B?
But then again, why introduce a problematic feature (bridges over stations) without allowing for the needed framework to ensure proper functionality for newgrfs? Given the fact, that station newgrfs are heavily being used?JGR wrote: I'm keen to avoid creating compatibility problems for myself in the future, especially when it comes to problematic areas like NewGRFs.
michael blunck wrote: The second feature request (disallow station building for certain track types) seems to be a much easier task IMO. There is already a note in the code (in newgrf_station.cpp):
because, at that point, the railtype of the station tile to be built is already known, and could be made avalailable to CB 13 (in var10 or var18, as the station isn´t built yet).Code: Select all
case 0x42: return 0; // Rail type (XXX Get current type from GUI?)
In fact, available vars for CB13 are totally unspecified in the nfo/grf specs, and I think ATM only the current date could be used here. Now, with OTTD´s railtype feature available since years, it doesn´t make sense to have the same station graphics available for every railtype. Being able to check station availability with regards to the current railtype would be very helpful here, both for the coder and the player, in linking special stations with fitting rail types.
In case this isn´t already included in your patch (I can´t check it ATM), could you please include that check for var42?cirdan wrote: The attached patch should do what you want, I think. It should make variable 42 return the railtype for stationless station resolution (as in the GUI or just before building a station).
Thanks for the quick fix, I'm pretty sure the different crashes were caused by the same issueJGR wrote:Thanks for letting me know about these, they are fixed and will be in the next release.
I'll enjoy it while I canwallyweb wrote:Awww. That could have made for some interesting April 1 scenarios.I notice now though that it is possible to build bridges over airports, which seems a bit daft. That should be fixed shortly..
(although for some reason they disappear when on an airport - on the other hand docks and road stations work great) I'm in favour of leaving it up to the discretion of the player whether it looks good or not. It wouldn't make sense in a trunk release but it does here, especially for the more advanced playerbase who use patchpacks with experimental features and newGRFs. This leaves it compatible with older NewGRFs which won't ever be updated to support the new feature, and also allows creators to enable the new property to prevent glitches.michael blunck wrote:But then again, why introduce a problematic feature (bridges over stations) without allowing for the needed framework to ensure proper functionality for newgrfs? Given the fact, that station newgrfs are heavily being used?
michael blunck wrote: It´s not in the spec, because nobody put it there. I would have done it myself, but I seem to be "excluded" from the wiki for some unknown reason.
Other than this, since 2013 there hasn´t been any new property added for stations in trunk. Last one was prop1A (advanced sprite layout, still "to be documented").
Since the next free property number was "1B", this one had been chosen by cirdan. Or would you prefer a different one?
If the user turns on the setting and then creates a high station under a low bridge, it is the user's responsibility, and other than it looking bad, nothing untoward will happen.michael blunck wrote:But then again, why introduce a problematic feature (bridges over stations) without allowing for the needed framework to ensure proper functionality for newgrfs? Given the fact, that station newgrfs are heavily being used?JGR wrote: I'm keen to avoid creating compatibility problems for myself in the future, especially when it comes to problematic areas like NewGRFs.
It isn't implemented in my patchpack at present, but it seems reasonable, and ought to not cause regressions. I will look into it.michael blunck wrote:BTW, at that time, cirdan implemented another proposal for stations in NMF:
michael blunck wrote: The second feature request (disallow station building for certain track types) seems to be a much easier task IMO. There is already a note in the code (in newgrf_station.cpp):
because, at that point, the railtype of the station tile to be built is already known, and could be made avalailable to CB 13 (in var10 or var18, as the station isn´t built yet).Code: Select all
case 0x42: return 0; // Rail type (XXX Get current type from GUI?)
In fact, available vars for CB13 are totally unspecified in the nfo/grf specs, and I think ATM only the current date could be used here. Now, with OTTD´s railtype feature available since years, it doesn´t make sense to have the same station graphics available for every railtype. Being able to check station availability with regards to the current railtype would be very helpful here, both for the coder and the player, in linking special stations with fitting rail types.In case this isn´t already included in your patch (I can´t check it ATM), could you please include that check for var42?cirdan wrote: The attached patch should do what you want, I think. It should make variable 42 return the railtype for stationless station resolution (as in the GUI or just before building a station).
regards
Michael
I´m with Eddi here.Eddi wrote: there is no reason why the newgrf specs should solely represent the status of trunk.
Yes, of course it needs to be documented. Could somebody please do it then?JGR wrote: Probably the easiest solution is to document it as "reserved but not implemented (in trunk)" in the same way as property 19.
I have seen different people making additions/modifications to the specs over the last years. In the end "it´s a Wiki!".JGR wrote: I don't know who is the NewGRF spec gatekeeper these days.
Obviously, "older" newGRFs had been designed under the prerequisite that stations couldn´t be built under bridges (or bridges over stations). There´s no need to question it now. OTOH, the implementation of a new feature which could break it (even "only" visually) should be assisted by means to ensure proper functionality of said feature. At least that would be common behaviour.Emperor Jake wrote: I'm in favour of leaving it up to the discretion of the player whether it looks good or not. [...] This leaves it compatible with older NewGRFs which won't ever be updated to support the new feature, and also allows creators to enable the new property to prevent glitches.
I see. Well what can I say, I'm a patient gamer. And renewable city growth works really well when averaging values ranging from 72 to 6000, especially with games starting in the late 18th century. Its a shame, but thank you for looking into it!JGR wrote:p4nzer wrote: I'll take a look into this, thanks for the bug report.
Edit: It appears to be caused by the change in https://github.com/OpenTTD/OpenTTD/pull/6763
Note point 1 in the "So what it actually changes" section.
Probably this is something to raise with the GS developers, if you need town growth rates slower than 880 days per growth event.
Code: Select all
this->timetable_duration += o->GetTimetabledWait() + o->GetTimetabledTravel();
No. First, you need to modify the save/load code to deal with new limits. And there surely will be many code where they assume the limit (I can tell you, for my scheduled dispatch patch, if you increase the Max. Day length factor (currently max is 125) it will definitely have problem due to how data is packed when send to DoCommandP)TrainLover wrote:Random question, but if I changed all the int variables to longs, does that "increase" the hardcoded limits?
I don't think that this is a numeric overflow/type width issue.MagicBuzz wrote:Hello,
I think I found an issue with timetable and especially separation patch.
On long routes (about 50 000 ticks to complete) I often have trains with an enormous early timer instead of being a bit late.
After a very quick look in the code (not actually in the involved code, but some random lines about timetable and late counter) I found some strange types used.
The Ticks type is an alias of int32.
2147483647 ticks for a timetable is very enougth. Even for a complete game I guess.
But when I look at timetable computing, other types are involved :
GetTimetabledWait() returns a uint16, so 65536 as max value.Code: Select all
this->timetable_duration += o->GetTimetabledWait() + o->GetTimetabledTravel();
GetTimetabledTravel() returns a uint16 too.
So if there is more 65536 ticks between two orders, there will be an overflow. And when computing lateness or separation, the whole table length is analyzed, so if using uint16 where will be problems.
Thus, I'm not sure, but when doing some subtraction between uint16, the values might be casted to int16 before calculation in order to handle properly negative values.
Vehicle lateness_counter is a int32.
I don't know exactly what happens and where, but I'm almost sure there is an overflow somewhere.
In any case, IMHO all time related variables and properties should be expressed in Ticks rather than int32, uint16, etc.
Here is a save game with the problem.
This is fixed now and will be in the next release.FulliAutomatix wrote:I've been getting some crashes on a multiplayer server, all come up with "signal.cpp" and it's been hindering playing multiplayer as the save now just crashes about a minute after loading and I don't know why.
I hope this helps in some way or another
Here's the crash log and the save
That one is fixed already.FulliAutomatix wrote:We've also been having an issue where you can't place waypoings on the NW-SE axis for some reason, so we've been using stations with "go via non-stop" orders. Waypoints on NE-SW axis have been fine though.
This is not in Cirdan's code, it does not look like he has implemented it, unless he's done so privately and not published it.michael blunck wrote: It´s not in the spec, because nobody put it there. I would have done it myself, but I seem to be "excluded" from the wiki for some unknown reason.
Other than this, since 2013 there hasn´t been any new property added for stations in trunk. Last one was prop1A (advanced sprite layout, still "to be documented").
Since the next free property number was "1B", this one had been chosen by cirdan. Or would you prefer a different one?
michael blunck wrote: The second feature request (disallow station building for certain track types) seems to be a much easier task IMO. There is already a note in the code (in newgrf_station.cpp):
because, at that point, the railtype of the station tile to be built is already known, and could be made avalailable to CB 13 (in var10 or var18, as the station isn´t built yet).Code: Select all
case 0x42: return 0; // Rail type (XXX Get current type from GUI?)
In fact, available vars for CB13 are totally unspecified in the nfo/grf specs, and I think ATM only the current date could be used here. Now, with OTTD´s railtype feature available since years, it doesn´t make sense to have the same station graphics available for every railtype. Being able to check station availability with regards to the current railtype would be very helpful here, both for the coder and the player, in linking special stations with fitting rail types.
I've added an implementation of this, but it hasn't been tested.michael blunck wrote:In case this isn´t already included in your patch (I can´t check it ATM), could you please include that check for var42?cirdan wrote: The attached patch should do what you want, I think. It should make variable 42 return the railtype for stationless station resolution (as in the GUI or just before building a station).
regards
Michael
You have a PM.JGR wrote: This is not in Cirdan's code, it does not look like he has implemented it, unless he's done so privately and not published it.
I had a quick search on the forums and couldn't find any reference to this.
You can set 'Deny' at the top level and then explicitly allow special cases. Of course, others may have a different approach to this.p4nzer wrote:Does the signal routing restrictions patch have an if and only if command? I think it should, if possible.
Thinking it the other way around – and especially the illustrating screenshot – is very helpful for me. Thank you.vrn wrote:You can set 'Deny' at the top level and then explicitly allow special cases.p4nzer wrote:Does the signal routing restrictions patch have an if and only if command?
michael blunck wrote: It´s not in the spec, because nobody put it there. I would have done it myself, but I seem to be "excluded" from the wiki for some unknown reason.
Other than this, since 2013 there hasn´t been any new property added for stations in trunk. Last one was prop1A (advanced sprite layout, still "to be documented").
Since the next free property number was "1B", this one had been chosen by cirdan. Or would you prefer a different one?
This is implemented now as per the new specs in the wiki.wallyweb wrote:You have a PM.JGR wrote: This is not in Cirdan's code, it does not look like he has implemented it, unless he's done so privately and not published it.
I had a quick search on the forums and couldn't find any reference to this.