Routing restriction discussion
Moderator: TTDPatch Moderators
Re: Routing restriction discussion
Yes I spotted it already, well already, too late actually. Sorry to have caused any grievances.
Another minor thing though. I have a transparent background, or even no background, for the signals menu position just below the TSignal, any idea as to why ? (this also happens when I start a new game)
I use the windows version of TTDpatch on Win Xp sp2.
Another minor thing though. I have a transparent background, or even no background, for the signals menu position just below the TSignal, any idea as to why ? (this also happens when I start a new game)
I use the windows version of TTDpatch on Win Xp sp2.
- Attachments
-
- image001.png (30.93 KiB) Viewed 4584 times
Wie zich gelukkig voelt met het geluk van anderen, bezit een rijkdom zonder grenzen. (F.Daels)
Still the best OS around
Still the best OS around
Re: Routing restriction discussion
As for the transparent/missing background for the button below tsignals, that is what I was referring to in the second part of my previous post...
The fix is already committed as of r1775.
Bug reports are quite alright, they are a necessary part of the development process
JGR
The fix is already committed as of r1775.
Bug reports are quite alright, they are a necessary part of the development process
JGR
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: Routing restriction discussion
I'm beginning to feel like there are too many signal-related switches: presignals, extpresignals, semaphores, pathbasedsignalling, tracerestrict, psignals, tsignals, and isignals, off the top of my head.
How much complaining would ensue if I were to replace tracerestrict, psignals, tsignals, and isignals with advsignalling.restricted, advsignalling.programmed, advsignalling.through, and advsignalling.invert12, respectively?
Of the four, only tracerestrict has a bit in the patchflags, but this isn't documented.
How much complaining would ensue if I were to replace tracerestrict, psignals, tsignals, and isignals with advsignalling.restricted, advsignalling.programmed, advsignalling.through, and advsignalling.invert12, respectively?
Of the four, only tracerestrict has a bit in the patchflags, but this isn't documented.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Routing restriction discussion
If you do it in a way that doesn't break everyone's config files then I'm sure that no-one will mind.
As for patchflagsfixedmap, I don't really know what it is supposed to do so, I can't really comment on that. (Although I have a vague feeling that it is to do with GRF action D).
Don't expect me to change all the flag checks in the code if you do change it though
JGR
As for patchflagsfixedmap, I don't really know what it is supposed to do so, I can't really comment on that. (Although I have a vague feeling that it is to do with GRF action D).
Don't expect me to change all the flag checks in the code if you do change it though
JGR
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: Routing restriction discussion
That there's the hard part. Even if I get TTDPatch to parse old files properly, external applications dependent on the XML won't be able to do so.JGR wrote:If you do it in a way that doesn't break everyone's config files
Action 7 var 85. Switches that it is GRF files might want to test using that should be accessible there. Others should not.JGR wrote:As for patchflagsfixedmap, I don't really know what it is supposed to do so,
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Routing restriction discussion
I think I can safely output an ENOPARSE for this sentence - something must be missing, or too much??DaleStan wrote:Switches that it is GRF files might want to test using that should be accessible there.
Re: Routing restriction discussion
That better?DaleStan meant to have wrote:Switches that GRF files might want to test using that should be accessible there
"If a GRF file might want to test the on/off state of a switch, that switch should be accessible there" might parse more easily, though.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Routing restriction discussion
Would somebody please explain to me what the "entered side of tile" restriction is supposed to do? I spent hours on trying to figure it out, but I'm still not sure how it works. The wiki does not explain too much about it as well.
Apart from that and some room for improvement in terms of signal graphics : Excellent work with all that new signalling stuff
Apart from that and some room for improvement in terms of signal graphics : Excellent work with all that new signalling stuff
Re: Routing restriction discussion
The simplest use is to restrict if "Entered side of tile is $SIDE_AWAY_FROM_STATION", which would cause a two-way signal to only allow passage into the station. You could also add an additional restriction based on depot of current order, so that trains that are looking for the nearby depot would go out a one-way ro-ro "backward" (thus being able to quite simply return to the station), while all others would go out forward.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Routing restriction discussion
Ok, I have finally gotten round to update my signalling guides to include information about routing restrictions and all that new signalling stuff.
@JGR and other devs: Please take a look and flame me if I wrote something wrong there. Some things were not easy to find out since they are so brandnew.
@JGR and other devs: Please take a look and flame me if I wrote something wrong there. Some things were not easy to find out since they are so brandnew.
Re: Routing restriction discussion
He, a nice crispy new design, and all in CSS.
I like it.
Must be much easier to maintain too.
I have used your guide quite often to get my brain trimmed into the right signaling direction to update my junctions.
Thanks for all your hard work on it.
I like it.
Must be much easier to maintain too.
I have used your guide quite often to get my brain trimmed into the right signaling direction to update my junctions.
Thanks for all your hard work on it.
Wie zich gelukkig voelt met het geluk van anderen, bezit een rijkdom zonder grenzen. (F.Daels)
Still the best OS around
Still the best OS around
Re: Routing restriction discussion
- It took me twenty seconds (which is about eighteen seconds too many) to find the English/German toggle.
- The vast majority of the Internet's users speak English. Consider making English the default.
... Now that I can actually read the text, ... - If use of anything other than the "ignore signal" button causes crashes (either train crashes or TTDPatch crashes), that is a bug and should be reported as such. It's still quite possible to mess up your network, though.
- Programmable signals do not override PBS at all, and they only override presignals in that they demote entry signals to (programmed) normal signals and combo signals to (programmed) exit signals, and then only until the programming is removed.
- Through signals are automatically promoted to PBS signals.
- "for the vertical tracks it's the one on the righthand (east) track facing down (south)." That doesn't agree with the image. Memory is failing me, but either the image needs to be reversed, or "facing down (south)" needs to be changed to "controlling downward (southbound) traffic." It might be advisable to make the latter change in any case.
- "Since programming can be combined with all other signal types, this solution is not the best because the player loses the pre-signal information." Not true. Note the vertical vs horizontal blue bars and see #4.
- "As with restricted routing, there are various criteria. If the criteria [sic] is fulfilled, the signal turns red." Also, "As with restricted restricted routing, a missing or incomplete criterion it is treated as true, which will tend to turn a signal red."
- English nitpick in the above: "criteria" is plural. The singular is "criterion". Same applies in the restrictions section.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Routing restriction discussion
-->Uwe
The guide updates seem very good, except for the points DaleStan already noted.
EDIT:
On your combined station page, the 3rd example will not work properly.
Trains can reserve up to the B signals from both sides, causing trains coming from the North-East to have to wait.
The B signals have to replaced with through signals as well, and train reversing at stations has to be turned on.
In the programmable signal section, it might be an idea to be more specific in what kinds of signals work with the signal status criteria. The signal must be one which, when changed would cause the current signals state to be re-evaluated.
So it has to be in the same block, and in the correct direction, heading out of the same block the current signal is heading into.
(ie. the same placement criteria for which pre-signal exits would affect a pre-signal entrance).
-->DaleStan
I would disagree with point 3, specifically with regard to train crashes.
Adding/removing/modifying signals or altering track layouts, when a train is in the same signal block, has a potential for causing train crashes, and is not something that can be considered a bug with, or prevented by, TTDPatch.
Furthermore:
There are still known bugs with PBS to do with track (de)reservation on reversing after waiting at signal, as, if my game network gridlocks for sufficiently long, inevitably some train in a PBS block somewhere manages to crash after reversing.
(I've previously looked at the code, but can't understand what is supposed to be going on).
These should still be reported though...
The guide updates seem very good, except for the points DaleStan already noted.
EDIT:
On your combined station page, the 3rd example will not work properly.
Trains can reserve up to the B signals from both sides, causing trains coming from the North-East to have to wait.
The B signals have to replaced with through signals as well, and train reversing at stations has to be turned on.
In the programmable signal section, it might be an idea to be more specific in what kinds of signals work with the signal status criteria. The signal must be one which, when changed would cause the current signals state to be re-evaluated.
So it has to be in the same block, and in the correct direction, heading out of the same block the current signal is heading into.
(ie. the same placement criteria for which pre-signal exits would affect a pre-signal entrance).
-->DaleStan
I would disagree with point 3, specifically with regard to train crashes.
Adding/removing/modifying signals or altering track layouts, when a train is in the same signal block, has a potential for causing train crashes, and is not something that can be considered a bug with, or prevented by, TTDPatch.
Furthermore:
There are still known bugs with PBS to do with track (de)reservation on reversing after waiting at signal, as, if my game network gridlocks for sufficiently long, inevitably some train in a PBS block somewhere manages to crash after reversing.
(I've previously looked at the code, but can't understand what is supposed to be going on).
These should still be reported though...
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: Routing restriction discussion
Thanks for the constructive criticism, I've changed the pages accordingly.
Re: Routing restriction discussion
Now its not finding this :Uwe wrote:Thanks for the constructive criticism, I've changed the pages accordingly.
Code: Select all
<link rel="stylesheet"
href="http://localhost/ttdx/style/style.css"
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
Re: Routing restriction discussion
Woah, my bad, it's fixed now.
Re: Routing restriction discussion
Looks good in both Firefox 2 and IE 6
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
Re: Routing restriction discussion
looking good. Just had a read trough the new guide and updating me with all the new possibilities.
Not sure if I understand it all, yet, but I will give it a try in my upcoming games. It sure looks like some very handy stuff.
Good work everyone. This is exactly the sort of stuff the Patch needs right now.
Not sure if I understand it all, yet, but I will give it a try in my upcoming games. It sure looks like some very handy stuff.
Good work everyone. This is exactly the sort of stuff the Patch needs right now.
*** Ce French Train Set ***
*** Visit my transport related pictures on Flickr ***
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch
"A committee is a group of men who individually can do nothing but as a group decide that nothing can be done" (Fred Allen 1894-1956 US radio comic).
*** Visit my transport related pictures on Flickr ***
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch
"A committee is a group of men who individually can do nothing but as a group decide that nothing can be done" (Fred Allen 1894-1956 US radio comic).
Re: Routing restriction discussion
I have NO idea what's happening with these new signal systems. I know Uwe has his guide but is there a simple breakdown of what you've introduced?
Just a list would be good
Just a list would be good
Official TT-Dave Fan Club
Dave's Screenshot Thread! - Albion: A fictional Britain
Flickr
Why be a song when you can be a symphony? r is a...
Dave's Screenshot Thread! - Albion: A fictional Britain
Flickr
Why be a song when you can be a symphony? r is a...
Re: Routing restriction discussion
Hi!
I have tried out these new features, routing restriction and programmable signals.
I would like trains to stop at the programmed signal if they are going for example to Puntwood Valley but the signal at the line to this place is red.
The same thing for the Puntwood Woods line.
The trains don´t seems to understand this. They will just go to the line that is free.
I post a screenshot of the problem.
What am I doing wrong?
I have tried out these new features, routing restriction and programmable signals.
I would like trains to stop at the programmed signal if they are going for example to Puntwood Valley but the signal at the line to this place is red.
The same thing for the Puntwood Woods line.
The trains don´t seems to understand this. They will just go to the line that is free.
I post a screenshot of the problem.
What am I doing wrong?
Who is online
Users browsing this forum: No registered users and 4 guests