Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Mon Dec 18, 2017 5:20 am

All times are UTC




Post new topic  Reply to topic  [ 39 posts ]  Go to page Previous 1 2
Author Message
PostPosted: Sun Aug 09, 2015 12:38 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1709
Location: Ipswich
Valle wrote:
May I suggest a restriction based on a train's power to weight ratio or tractive effort to weight ratio? As far as I can tell, there are only independent restrictions for power and weight so far.

Individual restrictions on power and weight were in the original TTDPatch implementation, but I've not implemented them in the OpenTTD version because they weren't that useful on their own.

I'm open to the idea of power/weight or tractive effort/weight conditions, but I'm not really sure about some aspects of how the UI would work, units in particular.
It may be useful to add those ratios to the train info window as well to provide some reference.

_________________
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Fri Aug 14, 2015 12:23 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Oct 17, 2005 8:56 pm
Posts: 3259
Location: Estonia
JGR... Thank You bringing it into OpenTTD! But first I must to figure out exactly how to add patches to the game... sort of ended up nowhere all the time (lately haven't tried tough)

_________________
TT-Screenshot Of The Month - 2012 July, winner!
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!

My screen shot thread ---> Have a look


Top
   
PostPosted: Fri Aug 14, 2015 2:46 pm 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Tue May 15, 2007 11:35 am
Posts: 252
Location: Germany
Nice! Is it possible to expand this patch to disallowing/allowing trains to turn around for specific orders? As of now, it's only possible to toggle this for all trains in non-terminus stations through the extended settings. Setting whatever is picked there as default and allowing the player to adjust it for individual orders could improve the gameplay of complicated networks with a limited number of high-throughput station designs a lot, I think.

_________________
My screenshots


Top
   
PostPosted: Fri Aug 14, 2015 4:44 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1709
Location: Ipswich
ISA wrote:
JGR... Thank You bringing it into OpenTTD! But first I must to figure out exactly how to add patches to the game... sort of ended up nowhere all the time (lately haven't tried tough)

At some point I'll have to set up a cross compiler environment or a VM to make Windows builds.
Having users try to get a useful Windows dev environment going is not a good solution.

Valle wrote:
Nice! Is it possible to expand this patch to disallowing/allowing trains to turn around for specific orders? As of now, it's only possible to toggle this for all trains in non-terminus stations through the extended settings. Setting whatever is picked there as default and allowing the player to adjust it for individual orders could improve the gameplay of complicated networks with a limited number of high-throughput station designs a lot, I think.

I think that's a bit too out of scope for this patch really.
That may be something that could be implemented as a sperate patch though.


On an unrelated note, has anyone got any thoughts on possible sprites for restricted signals?
I've been pondering this for a bit, but am a bit limited in that I can't draw; so creating loads of sprites is somewhat problematical.

_________________
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Fri Aug 14, 2015 6:33 pm 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 6939
JGR wrote:
At some point I'll have to set up a cross compiler environment or a VM to make Windows builds.
Having users try to get a useful Windows dev environment going is not a good solution.
you could ask the openttd team to compile binaries for you. all that is needed is a publicly accessible repository (for example at openttdcoop)

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Fri Aug 14, 2015 11:56 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1709
Location: Ipswich
Eddi wrote:
you could ask the openttd team to compile binaries for you. all that is needed is a publicly accessible repository (for example at openttdcoop)

No need, in the end. I got it built by cross-compilation with less difficulty than I was expecting.
(Helpfully OpenTTD has human-readable configure scripts, and the dependencies were mostly well-behaved).
Everything is on github already, I'd rather not manage another repo unnecessarily.


Attachments:
File comment: Win32 build
openttd-custom-g29c4f244-tracerestrict-MINGW.zip [7.46 MiB]
Downloaded 20 times
File comment: Win64 build
openttd-custom-g29c4f244-tracerestrict-MINGW-win64.zip [7.8 MiB]
Downloaded 22 times

_________________
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Last edited by JGR on Sun Aug 16, 2015 11:53 am, edited 3 times in total.
Top
   
PostPosted: Sat Aug 15, 2015 12:24 am 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 6939
... a github repo should be fine.

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Thu Aug 20, 2015 12:00 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1709
Location: Ipswich
I've updated the patch to add a graphical indication of which signals are restricted.
The signal posts of restricted signals are coloured blue (except for semaphores and custom signals GRFs). This requires the GRF which is attached to this post.
Windows binaries are also attached. The source is on GitHub and in the first post.


Attachments:
File comment: Win32 build
openttd-custom-g46817994-tracerestrict-MINGW-win32.zip [7.46 MiB]
Downloaded 22 times
File comment: Win64 build
openttd-custom-g46817994-tracerestrict-MINGW-win64.zip [7.8 MiB]
Downloaded 24 times
File comment: GRF
tracerestrict.grf [526 Bytes]
Downloaded 36 times

_________________
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Top
   
PostPosted: Thu Aug 20, 2015 12:23 am 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 6939
i had this thought recently that in order to escalate the number of visually distinguishable signal types, without equally exploding the number of sprites needed, there could be a mast sign in company colour blue/green pattern, and the player can select recolourings for this pattern to indicate different types of restrictions.

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Wed Sep 02, 2015 11:59 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1709
Location: Ipswich
I've updated the patch again, additions include:
  • Program GUI changes to make 'or if' conditions easier to add, remove and use.
  • Add a 'reserve through' program action.
    If a restricted PBS signal sets this action, PBS reservations which would otherwise stop at this signal instead continue through it to the next signal/waiting point. In effect this allows the 'safe waiting point' property of a PBS signal to be conditionally turned off.
  • Improvements to the correctness and thoroughness of the program validator.


Attachments:
File comment: Win64 build
openttd-custom-g73b69c55-tracerestrict-MINGW-win64.zip [7.8 MiB]
Downloaded 30 times
File comment: Win32 build
openttd-custom-g73b69c55-tracerestrict-MINGW-win32.zip [7.47 MiB]
Downloaded 23 times

_________________
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Top
   
PostPosted: Fri Jun 17, 2016 2:38 pm 
Offline
Engineer
Engineer

Joined: Mon Nov 23, 2015 6:15 pm
Posts: 7
Hi!

I have downloded both the code and the patch and tried to compile both. I did patch latest build of OpenTTD, and the code was yours from github.
But both times I get the same error message. After some looking around I think I have found at what part it is complaining about and its in rail_cmd.cpp file.

Code:
4>------ Build started: Project: openttd, Configuration: Release x64 ------
4>rail_cmd.obj : error LNK2001: unresolved external symbol "unsigned int _opengfx_grf_file_index" (?_opengfx_grf_file_index@@3IA)
4>rail_cmd.obj : error LNK2001: unresolved external symbol "unsigned int _first_user_grf_file_index" (?_first_user_grf_file_index@@3IA)

static void DrawSingleSignal(TileIndex tile, const RailtypeInfo *rti, Track track, SignalState condition, SignalOffsets image, uint pos)
{
   <Code cut for clear reding>

   } else {
      /* Normal electric signals are stored in a different sprite block than all other signals. */
      sprite = (type == SIGTYPE_NORMAL && variant == SIG_ELECTRIC) ? SPR_ORIGINAL_SIGNALS_BASE : SPR_SIGNALS_BASE - 16;
      sprite += type * 16 + variant * 64 + image * 2 + condition + (type > SIGTYPE_LAST_NOPBS ? 64 : 0);
   }

   uint origin_slot = GetOriginFileSlot(sprite);
   extern uint _first_user_grf_file_index;      <<----  LINK 2001 error
   extern uint _opengfx_grf_file_index;      <<----  LINK 2001 error
   if (!is_custom_sprite) is_custom_sprite = origin_slot != _opengfx_grf_file_index && (origin_slot >= _first_user_grf_file_index);

   <Code cut for clear reding>
}


When I read the information on MSDN page that one is directed to. I can't find any clear information on what the problem can be.
Im running windows 10 and VS 2015, is this a wrongly set or missing compiler setting? Or is it some thing differerent?

A point in the right direction is gratly appreciated.

Regardes
OokamiChan


Top
   
PostPosted: Fri Jun 17, 2016 2:45 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1709
Location: Ipswich
OokamiChan wrote:
Hi!

I have downloded both the code and the patch and tried to compile both. I did patch latest build of OpenTTD, and the code was yours from github.
But both times I get the same error message. After some looking around I think I have found at what part it is complaining about and its in rail_cmd.cpp file.

Edit: looks like a type mismatch, I will update this soonish.
In the meantime replace 'extern uint' with 'extern int'.

_________________
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Fri Jun 17, 2016 3:59 pm 
Offline
Engineer
Engineer

Joined: Mon Nov 23, 2015 6:15 pm
Posts: 7
Thank you!

Its's now working. :mrgreen:

Regardes
OokamiChan


Top
   
PostPosted: Sun Nov 19, 2017 12:44 am 
Offline
Engineer
Engineer
User avatar

Joined: Tue Feb 21, 2006 10:17 pm
Posts: 8
Location: Campana
Hi there, :bow:

First, I have to say that I'm loving this patch... has really brought new life to OpenTTD for me... I've been playing a relatively large map[1] for the last month and a half that I'd have abandoned[2] long before that if it weren't for the features in this code patch :mrgreen:

As I said, one month and a half playing a big map (for me) and I didn't have a single crash/issue ever (not playing MP, though).

I was never been able to create a complex transport network without it becoming something ugly (due unrealistic constructions mostly) or really tedious to manage (for me at least)... but thanks to some of the awesome features in this patch, I found that it's really easier to grow in scale and manage your network to the point where it works with minimum tedium.

Two things I wanted to ask/comment:

1. Where I should relay some issues I noticed due to some different patches not playing well together (specifically, about hierarchical groups and template train replacements.)
2. I'd want to know how to use the "slots" feature in the routing restriction signals... at least, I'd want to know what is its intended use, so I can check if it will help me in enhancing my network or I can ignore it... ((I will probably end up checking the patch code in the end, if nobody knows/has time to explain, but I was hoping to get some answers first before getting to that... even a summary would do :) ))
3. Is there any guidelines/information on how to better use the new signals (both types) in good ways? (without overdoing it... I'd prefer some simple basic constructions and expand from that...) I'm mostly interested in traffic control/balancing and freight/passengers separations... has anyone here come up with interesting solutions yet that are somewhat easy to manage/implement? [3] I haven't found too much information on using those yet, nor here in this forums nor wiki, nor anywhere else :(


Thanks for your work integrating all these awesome patches and to the authors of those, of course! :bow:

Best regards!
------------
Notes below (feel free to ignore, mostly off topic... just wanted to explain my points in case someone was curious):

[+] Spoiler
  • [1] Just for the record, in case it matters, or serves to give a base for comparison: my current save scale is ~600 trains/~1700 road vehicles/~200 ships and ~100 aircraft ((which is way bigger than anything I was able to build and maintain before!)) in a 1024x1024 map, covering about ~60% of the serviceable towns for passengers and somewhat less than ~50% of cargo industries... using FIRS industry set temperate basic (I wish I had known about the Extreme setting with I started!). And also, using cargodist enabled for all cargoes, including freight.
  • [2] Mostly due to the way some patches change the way the game feels (for me):
    • I was only able to cover a small area of a map before the date was already 2000 (daylength patch) and I always ended abandoning the games once the date reached the end-of-line for end-game vehicle availability with only a small portion of a map covered.
    • I tend to like having somewhat realistic network layouts/setups, and having hundreds of trains and road vehicles was always to bothersome to maintain, hierarchical groups greatly reduces giving orders to a full set of vehicles and having them as granularly organized as needed, and template replacement is simply awesome!
    • The signals on bridges/tunnels also changed the way I can layout routes.
    • Routing restriction signals rock :)
    • Multiple cargo load/unload orders also rock :)
    • And the timetable automation also rock... and it works, I have never ever bothered with timetables before myself :)

  • [3] Specifically talking about routing restrictions signals and or programmable signals... not interested in the old way in which those issues used to be solved by combo signals and that sort of stuff!

(((Sorry if this is just mostly off topic, I just wanted to give my reasons... and there are others too, but don't want to extend too long!)))


Top
   
PostPosted: Mon Nov 20, 2017 12:19 pm 
Offline
President
President
User avatar

Joined: Sat Jan 18, 2014 6:10 pm
Posts: 946
What is difference between "reserve through" and "long reserve"?
If I understand properly, long reserve is trying to reserve current and next section, if it is not possible, only current section.
Is "reserve through" used for "reserve both sections or deny"?

_________________
My experimental openTTD server: 149.156.194.203:3979 non-standard client, now testing: JGRPP http://tiny.pl/ggnch
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, preindustrial houses, wired, ECS industry extension.


Top
   
PostPosted: Mon Nov 20, 2017 7:11 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Aug 08, 2005 1:46 pm
Posts: 1709
Location: Ipswich
leeus wrote:
First, I have to say that I'm loving this patch... has really brought new life to OpenTTD for me... I've been playing a relatively large map[1] for the last month and a half that I'd have abandoned[2] long before that if it weren't for the features in this code patch :mrgreen:

Many thanks :)

leeus wrote:
1. Where I should relay some issues I noticed due to some different patches not playing well together (specifically, about hierarchical groups and template train replacements.)

Probably the patchpack thread.
The template train replacement patch ignores group nesting at the moment.

leeus wrote:
2. I'd want to know how to use the "slots" feature in the routing restriction signals... at least, I'd want to know what is its intended use, so I can check if it will help me in enhancing my network or I can ignore it... ((I will probably end up checking the patch code in the end, if nobody knows/has time to explain, but I was hoping to get some answers first before getting to that... even a summary would do :) ))

It's a general purpose mechanism to assign and remove trains to "slots", which are analogous to dynamic groups.
A train can be in any number of slots at once.
Trains acquire/join and release/leave slots at signals, or by manually moving trains in the slot management panel.
Slots have a capacity (number of trains), when a slot is full and a train is trying to acquire it at a PBS signal using an "acquire or wait" it will wait until another train releases it. If a train used a "try to acquire" it will continue without waiting or acquiring the slot.
"Release (front)" releases a slot when the front of the train passes the signal, and "release (back)" does the same when the back of the train passes the signal. It's important to remember to use these, as otherwise you could jam your layout if a train which is holding a slot which is blocking other trains manages to leave the area without releasing it.
You can use the "train in slot", "slot occupancy" and "slot occupancy remaining" conditionals for more complex setups. These are particularly useful with the "wait at PBS signal" restriction.

You can use it for things like: bidirectional layouts with more than one train heading in the same direction, queueing sidings and programmable train regulation, preventing deadlocks when using junctions/movements with special requirements (e.g. reversals or complex layout), simpler signalling of single-train branch lines, etc.
I primarily use it for queuing sidings (i.e. diverting trains into holding areas if their destination slightly further ahead is full, so that they don't cause an obstruction by waiting across a junction or on the mainline).

leeus wrote:
3. Is there any guidelines/information on how to better use the new signals (both types) in good ways? (without overdoing it... I'd prefer some simple basic constructions and expand from that...) I'm mostly interested in traffic control/balancing and freight/passengers separations... has anyone here come up with interesting solutions yet that are somewhat easy to manage/implement? [3] I haven't found too much information on using those yet, nor here in this forums nor wiki, nor anywhere else :(

I'm not aware of any tutorials at the moment, I may look into drafting some at some point.
Programmable signals are somewhat less useful than they originally seemed before I integrated them into the packpack. I tend to stick to only using routing restrictions.

McZapkie wrote:
What is difference between "reserve through" and "long reserve"?
If I understand properly, long reserve is trying to reserve current and next section, if it is not possible, only current section.
Is "reserve through" used for "reserve both sections or deny"?

Yes pretty much.
"Reserve through" means that the reservation can't terminate at the current signal, it must continue until it finds somewhere else suitable to terminate. It is as if the signal was not there at all.
"Long reserve" tries to also reserve the next section, but if that's not possible the reservation up to the signal is still kept.
Both reserve through and long reserve can extend over multiple blocks (more than two).

_________________
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github


Top
   
PostPosted: Mon Nov 20, 2017 7:31 pm 
Offline
President
President
User avatar

Joined: Sat Jan 18, 2014 6:10 pm
Posts: 946
This "long reserve" feature is very useful, because it allow to make priority junctions without much effort in comparison to all these entry/combo/exit signals.
Moreover, it is probably the best way to make priority junction in case of bidirectional branch connected to dual track line (block signals are not useful, they lock both tracks).
The only issue is, that user need to insert this block each time.
Separate signal with such intrinsic "ready to use" long reserve function would be welcome (my dream is to have it in vanilla openttd together with newgrf support).

_________________
My experimental openTTD server: 149.156.194.203:3979 non-standard client, now testing: JGRPP http://tiny.pl/ggnch
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, preindustrial houses, wired, ECS industry extension.


Top
   
PostPosted: Mon Nov 20, 2017 7:38 pm 
Offline
Tycoon
Tycoon

Joined: Wed Apr 27, 2005 7:09 am
Posts: 5112
leeus wrote:
3. Is there any guidelines/information on how to better use the new signals (both types) in good ways? (without overdoing it... I'd prefer some simple basic constructions and expand from that...) I'm mostly interested in traffic control/balancing and freight/passengers separations... has anyone here come up with interesting solutions yet that are somewhat easy to manage/implement? [3] I haven't found too much information on using those yet, nor here in this forums nor wiki, nor anywhere else

There´s some info for JGR´s "restricted" and "programmable" signals from TTDPatch times:
http://uwe.s2000.at/ttdx/signal/restric ... hp?lang=en

And an example for using programmable signals with use of certain tracks in stations:
http://www.ttdpatch.de/grfspecs/PatchMa ... Alpha.html

HTH
Michael

_________________
Image


Top
   
PostPosted: Tue Nov 21, 2017 12:20 am 
Offline
Engineer
Engineer
User avatar

Joined: Tue Feb 21, 2006 10:17 pm
Posts: 8
Location: Campana
Heya!

michael blunck wrote:
<snip>
There´s some info for JGR´s "restricted" and "programmable" signals from TTDPatch times:
http://uwe.s2000.at/ttdx/signal/restric ... hp?lang=en

And an example for using programmable signals with use of certain tracks in stations:
http://www.ttdpatch.de/grfspecs/PatchMa ... Alpha.html

HTH
Michael


Thank you very much Michael! I didn't found that last URL before... so thanks for it, new stuff to read! The first one I had already found posted here in the forums before, but for some reason at that time that URL was dead to me.... I tried it again and now it worked! So I'll keep it open on one browser tab until I have some time to read it :) Thank you again!

JGR wrote:
leeus wrote:
1. Where I should relay some issues I noticed due to some different patches not playing well together (specifically, about hierarchical groups and template train replacements.)

Probably the patchpack thread.


Yeah, I'm sorry! I wrote that original post late late at night before going to bed, and I posted it in the wrong thread lol. I totally intended to post it in the Patch Pack thread, but I had open multiple tabs with multiple repeats of both threads and I just simply made a mistake, and when I realized it was already too late :)
But in the end it seems to have been OK, since I got too much good information relating the signals that would have been a bit off-topic in the patch pack thread, I think :)

JGR wrote:
The template train replacement patch ignores group nesting at the moment.


Yeah, I noticed that... but no problem for me, it didn't bothered me too much... it only adds some extra scrolling :mrgreen:

What I found is a very minor usability issue with the way the template replacement window areas are sized (I assume)... and I guess it's either related to the hierarchical groups or to the number of total groups... i.e. it could just be the fact that I have too many groups myself (the hierarchical nodes add a lot to have a larger group list than normal)

The issue is it gets confused when the list of groups is too long and you can't reach the end of the list for both the groups panel and the template selection panel. I'll try to capture some images from my game and post them on the correct thread during today or tomorrow!

JGR wrote:
leeus wrote:
2. I'd want to know how to use the "slots" feature in the routing restriction signals... at least, I'd want to know what is its intended use, so I can check if it will help me in enhancing my network or I can ignore it... ((I will probably end up checking the patch code in the end, if nobody knows/has time to explain, but I was hoping to get some answers first before getting to that... even a summary would do :) ))

It's a general purpose mechanism to assign and remove trains to "slots", which are analogous to dynamic groups.
A train can be in any number of slots at once.
Trains acquire/join and release/leave slots at signals, or by manually moving trains in the slot management panel.
Slots have a capacity (number of trains), when a slot is full and a train is trying to acquire it at a PBS signal using an "acquire or wait" it will wait until another train releases it. If a train used a "try to acquire" it will continue without waiting or acquiring the slot.
"Release (front)" releases a slot when the front of the train passes the signal, and "release (back)" does the same when the back of the train passes the signal. It's important to remember to use these, as otherwise you could jam your layout if a train which is holding a slot which is blocking other trains manages to leave the area without releasing it.
You can use the "train in slot", "slot occupancy" and "slot occupancy remaining" conditionals for more complex setups. These are particularly useful with the "wait at PBS signal" restriction.

You can use it for things like: bidirectional layouts with more than one train heading in the same direction, queueing sidings and programmable train regulation, preventing deadlocks when using junctions/movements with special requirements (e.g. reversals or complex layout), simpler signalling of single-train branch lines, etc.
I primarily use it for queuing sidings (i.e. diverting trains into holding areas if their destination slightly further ahead is full, so that they don't cause an obstruction by waiting across a junction or on the mainline).


Awesome!! Thank you for the very clear explanation! I kinda thought it was something like that from the way it was worded and the types of operations you had available (they sounded a bit to me like the Semaphores primitive in concurrent programming! Full circle, trains are threads and now signals are "semaphores" lol :P) and I managed to find the slots management window and played around a bit with it, but I didn't want to commit to using it without actually knowing what I was doing... since, I have many trains around, and a mistake can cause me to lose some (big) time afterwards cleaning the mess if they get confused and start to jam :) I already did that with the routing restrictions twice, and I preferred to load an earlier save rather than unlock the knot lol

JGR wrote:
leeus wrote:
3. Is there any guidelines/information on how to better use the new signals (both types) in good ways? (without overdoing it... I'd prefer some simple basic constructions and expand from that...) I'm mostly interested in traffic control/balancing and freight/passengers separations... has anyone here come up with interesting solutions yet that are somewhat easy to manage/implement? [3] I haven't found too much information on using those yet, nor here in this forums nor wiki, nor anywhere else :(


I'm not aware of any tutorials at the moment, I may look into drafting some at some point.
Programmable signals are somewhat less useful than they originally seemed before I integrated them into the packpack. I tend to stick to only using routing restrictions.


As a first approximation (and without putting too much thought into it,) when I updated my mainlines to six lanes, and decided to test putting some penalties on the inner lanes for cargo trains and in the middle lane for slow trains (something like <201Km/h that was the best cutpoint for me according to the trains I'm running atm.) and it seems to work OK. I also started sprinkling long reserve signals for passengers trains in areas where they are approaching a junction, so they have the right to pass... and that works OK too.

I've mostly only used Long Reserve, Reserve Through, Deny, Add Penalty and the conditions for checking train speed, cargo and entering from the back of a signal.

That last item is awesome for reserving a station platform for some type of train (like a goods trains getting into a city station.. I mostly want that train to use a single platform, just for the looks... i.e. the platform has a different station style than the rest and it wouldn't make sense to have passengers trains in it.) I also made a single use of the current order condition to apply a Deny to avoid trains using a stretch to track reserved for waypoint reversing.

But nevertheless, this is the first time of me playing with them, and I can see much usefulness to be had in the future from the extra operations! :mrgreen:

I still haven't found (but I really didn't spend too much time thinking) a good way to prevent cargo trains from blocking a junction entrance when they gain access to it earlier than the fast train (without using an accessory pre-signal stretch at the side entrance, like in the past... I tried using programmable signals for that, but I really couldn't find a way to do it properly but that's on me... I'll read a bit on the info provided and maybe I can come up with something) but as I said, I didn't spend too much time into it, the long reserve feature solves the 90% percent of the cases and for the rest, there's no real harm in having fast trains waiting a bit at the ML entrance from time to time :)

Now, from the sound of it... it sounds that the slot function *could* be used to solve this... I have to think about it and maybe make a test game and try it to see how you'd go about solving that... it's much easier than testing it on a real game with temperamental trains all around :P

On the topic of different restrictions... What I would wish I had (operative word wish, not asking or requesting... just throwing an idea :))) is some panel window that listed all the different type of restrictions already in use. I.e. the distinct programs you already made and that are shared by different signals around your network (and I wish you could name them too... but that's another matter :)))

What I thought about doing, is making some rail yard somewhere off and putting there one of each signal restriction I used in one signal there with a sign above it telling this one is this, that one is that. etc.

But it would be awesome to have that already available from the in-game information at some point :)
You could also make that window responsible for highlighting the signals on the track (using the already existing Zoning mechanism, for example... which btw., is awesome!) so you can have a more fine-grained look at where'd you put each type of restriction and/or where are they shared... and it's important to know which signals share a restriction when you thought about making a change to it, to see if all the signals you applied it before are "compatible" with the new restriction or you'd want to un-share them first (specially important when you want to make a restriction more 'restrictive' in any way... you have to check if there are enough alternative paths already existing everywhere.)

Also, I wish the signal panel would stay open after you used it to apply a restriction... I kinda suspect that's on the way the base game works though, and not on the way your patch is implemented, but it would certainly reduce the clicking/repeating required to apply restriction to signals over long stretch of tracks. Also, a way to reuse the last restriction applied (or, maybe, a way to share *from* an open signal restriction panel, instead of having to open the target signal panel and chose share on it) would certainly reduce the clicking a lot! But I'd totally understand if it's not feasible to do atm., or if it requires much more work than it's worth ((unless, of course, there's a way to do that that I missed... that could totally be the case too!))

JGR wrote:
McZapkie wrote:
What is difference between "reserve through" and "long reserve"?
If I understand properly, long reserve is trying to reserve current and next section, if it is not possible, only current section.
Is "reserve through" used for "reserve both sections or deny"?

Yes pretty much.
"Reserve through" means that the reservation can't terminate at the current signal, it must continue until it finds somewhere else suitable to terminate. It is as if the signal was not there at all.
"Long reserve" tries to also reserve the next section, but if that's not possible the reservation up to the signal is still kept.
Both reserve through and long reserve can extend over multiple blocks (more than two).


I found Reserve through very useful in junctions to be put in signals you normally have to either leave out or live with a bit of mess that sometime happens, but you would want to put there to avoid trains from selecting the wrong track (i.e. a one directional stretch reserved for entering or leaving) but you don't want to have trains wait on it blocking the rest of the junction connections if they can't get past that particular signal... so I normally left that signal out and lived with the mess sometimes happens, now I can have both :)


Thank you all for your awesome responses :)

Best wishes to all!

PS: Sorry for the humongous post... it started small, but it kept growing! Too much stuff to mention/praise and comment :)

EDIT: misused word


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 39 posts ]  Go to page Previous 1 2

All times are UTC


Who is online

Users browsing this forum: wallyweb and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2017 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2017.
Hosted by Zernebok Hosting.