News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

How do people use pre-signals?

Started by jamespetts, April 02, 2011, 12:18:19 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

I am interested to know what the function of pre-signals is in Simutrans and how people use them in practice. Are they useful, do people find? I cannot think of where one would use them (because I'm not sure what advantage that it is for a train to wait a long way rather than a short way behind a red signal, which is, in effect, all that current pre-signals do), but I might have missed something, so I should be interested in how people use them in their games.

The reason that I ask is that I am doing some work on enhancing signalling in Experimental, and I am looking in particular at the function of the pre-signal and whether it can be made more like a distant signal. I have also been looking at this thread with interest. However, before I change the existing function of the pre-signal, I should like to know whether, by doing so, I shall be erasing some useful function that only the pre-signal in its present form can perform. Input would be appreciated!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Lmallet

#1
The only use I have for pre-signals are at junctions.  This way you can stop a train before the junction if the next signal is red, and you don't block it for other trains.

I am not sure if a distant signal would have much use, as all it does is warn about the state of the next signal, but is not absolute (while the pre-signal is).  They could be used as a mechanism to force trains to slow down before a red signal, but in that case I think a better approach would be to introduce three colour signals, with yellow being the "slow down for next signal" aspect.

Combuijs

The only signals I ever use are normal signals and choose-signals. I always get the job done with them.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



jamespetts

Interesting feedback. Lmallet - at your junction scenario, is there a reason that you have the second (basic) signal in place at all if trains will block a junction if they stop at it? In other words, could you not get the same effect by replacing the pre-signal with a basic signal and removing the second basic signal near the junction entirely?

As to the function of a distant signal - they have no use as things are currently constituted, but I am currently working on code for Experimental to make trains have to slow down the appropriate distance before signals, and assume that a signal will be red unless they have received a clear aspect from a preceding distant signal. I am also planning to introduce multiple aspect signalling to make this process more efficient - but only in the modern era. This additional complexity will be optional.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Lmallet

Quote from: jamespetts on April 02, 2011, 10:47:43 AM
Interesting feedback. Lmallet - at your junction scenario, is there a reason that you have the second (basic) signal in place at all if trains will block a junction if they stop at it? In other words, could you not get the same effect by replacing the pre-signal with a basic signal and removing the second basic signal near the junction entirely?
Well, looks like I learned something.  Yes, in most cases, simply arranging signals properly can allow you to avoid pre-signals.

There are still some cases where they could be needed (see picture).  In my case, I have a choosesignal near a junction, and the track is too short to hold a train.  The presignal prevents trains from blocking the junction if it cannot clear the choosesignal (there was a bug with this, we had a discussion here http://forum.simutrans.com/index.php?topic=6151.0).  That being said, this is a very specific case, and I could probably get around it with some track reconfiguration (or maybe not.  I am at the edge of the map, and the area is full of stuff).


jamespetts

Interesting. Could you not put a choose signal where the pre-signal is, and remove the existing choose signal? I think that it will only find paths to station platforms, will it not?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Lmallet

Wow, did choosesignal behaviour change in the last little while?  In older versions, if a train was coming from the upper-right of the image towards the lower right, it would stay stuck at the signal, since it had no station platform to choose from.  I can see now that this is no longer the case.  (I need to play more Simutrans, if only the baby would sleep more/let me sleep more :)  ).

I withdraw my comments.  Carry on.  :)

Erik

Yes the behavior of choose signals is chanced.
However sometimes I use the pre-signal on the same way.

The pre-signals in the game now are useful in some specific situation, but I think presignal is a wrong name. Becouse on the real world a pre-signal give a indication of the next signal. If it signs that the next signal is red. The train driver has to slow down so he can stop the train for the next signal on time.
I thing chain-signal or something is better.

@ jamespetts:
Thank you for viting me in.

This is a intresting treat indeed.
Also because I want to make some changes of the whole way how signals are working.

Looking at the way of the source code.
The train checked the signal and put it on the best option.
But in real. Signals are not controlled by the trains. The trains are controlled by the signals.
So actually the whole build up of the source code is outdated.

This is a big chance, I know.
Iḿ glad if I can help with it.  :D


sdog

#8
the rail section where the line from Shrewsbury splits up in a branch towards Taunton and one towards Wolverhampton from my large game.

All 4 incident lines have a choose signal directly in front of that section, with a signal directly behind that rail section.

A shorter rail block is reserved, and the intersection is not block so long, if two trains two different branches follow each other. (e.g first a train to Taunton then one to Wolverhampton).

Another use is to make a work around to get a one-way signal on a very short branch that is not long enough for a train to stop. For example to short-cut a double track line, with a spacing of one field.

Putting a pre-signal before the point and one normal signal each after the point on the main track, one on the short-cut.


Also on Lmallet's picture, i wouldn't do it in a different way, now since choose and pre-signals work together again. Putting the choose signal before the point, at the place of the pre signal could have unforseen consequences, with trains taking strange ways to get to a free platform. Also it would require an end-of-choose signal on the right bridge, going  north and a second choose signal on the south-bound bridge, if trains from the north should call at that station.

jamespetts

Sdog,

hmm - perhaps I'm being dim, but how is the effect in your layout different to having a basic signal immediately before the junction and removing the first signal immediately after it?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Lmallet

Quote from: jamespetts on April 02, 2011, 11:58:45 PM
Sdog,

hmm - perhaps I'm being dim, but how is the effect in your layout different to having a basic signal immediately before the junction and removing the first signal immediately after it?
Or to put it another way, why put a signal after the crossing if you don't want trains to stop there?  (That is what I realized today).  I used presignals before to deal with certain signal behaviour, but these have changed now.

sdog

A train comming from the right, going left reserves goes past the pre-signal and passes the rail block of the junction. As soon as it is past the signal right after the junction, the rail block in the junction is free for the next train. Another train, comming from the right, going up will be able to continue right at this time. If the signal was at a sufficient spacing after the junction it would have to wait until the first train moved 10 more tiles.

The effect comes to play if the pre-signal pre signals for two different simple-signals, on different lines.

For two consecutive trains going to the same branch, this is not an advantage though.

Erik

Sorry, but still I do not see the value of the pre-signals here.

If the first train from the right has past the junction.
Each other train form each direction can go further except to the left.
I see no diffrence tan if you remove all the normal signals just after the junction and repals the pre-signals with normal signals.

Or do you see that the entire junktion isn't free until the first train has past the next signal?
This is not true. tiles direct after the train comes free. Soon as the train has past the junction completely.The junction is free for the other trains.


ӔO

in the newer demo.sve for pak.britain128, the yellow player's Bere Valley light railway freight/passenger lines can be jammed when the freight is at the ends, while the pax is one station behind it. Example: freight @ melchester, pax @ melchester north. They can be unjammed by adding pre-signals on both sides of the pax station at Emminister Halt.

that's about the only time you need pre-signals.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

VS

I am an old, rigid player, used to having only normal signals and nothing more. My layouts use maybe 5 "special" signals altogether, if I run into some complications...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

TurfIt

Two limited specialized uses I've had in the past. 

1) Holding area for trains loading at the station. Signal between holding siding and station due to the distance. Couldn't build siding closer due to buildings, industries, etc., in the way. So pre-signal at the exit of the siding to hold trains back the extra block.  Pak128 - pre-signals have the yellow light.



2) Bi-directional single track branching off double track main. Signal on single track again due to distance. Things in the way again preventing double track. Pre-signal to hold trains on the main unless there's room for them to clear the single track section.

arnoud

I didn't get the difference with a Longblock signals.

ӔO

long block will try to reserve 3 sections ahead.
only good when you have a long stretch of single track, but there are 3 stations on that single track.

just think of it as
regular signal = 1
pre-signal = 2
long-block = 3
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

arnoud

OK thank you
I didn't know that a longblok signal blocks 3 blocks

prissi

A long block signal will reserve only a single block, but checks through stations and the like until the train returns its schedule.

arnoud

you said: same as pre-signail but check station to.

prissi

No a long block signal will not reserve/check through a signal.

Ters

I normally only use pre-signals when what I really need is a single-sided signal that allows traffic to pass both ways, like when I have layouts similar to TurfIt's second picture.

Recently, I have also used some pre-signals as departure signals on stations shorter than my normal signal spacing. These serve no practical function and only fulfil my desire for signals at station exits. A normal signal then follows at the regular signal spacing. Typically, the station will eventually grow up to the signal once engines become powerful enough, eliminating the pre-signal.

Djohaal

So far I've found presignals useful in very specific niche situations, however such situations are often unsolvable without them. Keep in mind according to the simutrans data they will obey the next true signal, so you can in theory set up chains of presignals (due to what reason I have no idea though).

The distant signal seems to only be useful if accurate braking physics were simulated, what, due to excessive complexity, I hope won't happen in SE (well unless one can turn it off  ;) ).

A similar (but potentially more useful) use for a kind of distant signal would be making it tell trains that cross it to slow down (but not to a full stop). This could give the train in the next occupied block more time to leave and free the block, and could potentially streamline the train flow in a way since the trains would just slow down before the stop signal, maybe having time to free up the next block, not losing precious time having to slow down to 0 and accelerate back. (Specially painful in low traction trains)

jamespetts

Djohaal,

the plan is to implement more accurate signalling/braking, but to have it as an optional feature that can indeed be turned off :-) The purpose of this thread was to ascertain whether I could replace the existing pre-signals with distant signals, or whether I'll need to add distant signals to the existing pre-signal logic and create new types of signal. I think that it will have to be the latter, as people have come up with genuine uses for pre-signals here.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Djohaal

Quote from: jamespetts on April 11, 2011, 09:53:50 PM
Djohaal,

the plan is to implement more accurate signalling/braking, but to have it as an optional feature that can indeed be turned off :-) The purpose of this thread was to ascertain whether I could replace the existing pre-signals with distant signals, or whether I'll need to add distant signals to the existing pre-signal logic and create new types of signal. I think that it will have to be the latter, as people have come up with genuine uses for pre-signals here.

It's just a small peeve I have with SE, it has a lot of features which I -personally find very interesting, but some of them not-so-much, and I'm pro being able to choose which ones to play with ;)

Also what you think of my slowdown signal idea?

jamespetts

The idea of the distant signal that I am planning on implementing is that, unless the distant signal is at clear, the train will slow in time to stop at the next stop signal unless and until it is within sighting distance of the next stop signal and the next stop signal is clear, which is how distant signals actually work. The idea of doing this is to simulate the top speed/capacity tradeoff with different signalling arrangements, as well as the impact of braking ability on average speeds (particularly important for early railways, where poor braking severely limited top speeds in most cases), and give players an incentive to upgrade to better (but more expensive) forms of signalling in later years, such as multiple aspect and (later) moving block signalling. Is that close enough to what you had suggested to be useful?

Edit: Incidentally - which of the features do you find interesting and which less so?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Erik

#27
A signal that slows the train down if the block after the next signal is occupied.
http://forum.simutrans.com/index.php?topic=7090.new#new
Here I have al ready made one.

About programming.
Now the source code of all the vehicles is situated in one file.
It will give more overview if we split that.
Also it will give a better opportunity to make a more advanced traffic control for each vehicle.
The picture on the attachment gives perhaps better view by what I mean.

EDIT: The way that a signal works and witch signal has it to give is divined in the control center source.
The train source code has divined how the train has to act by a given signal.


Djohaal

Quote from: jamespetts on April 12, 2011, 12:07:17 AM
The idea of the distant signal that I am planning on implementing is that, unless the distant signal is at clear, the train will slow in time to stop at the next stop signal unless and until it is within sighting distance of the next stop signal and the next stop signal is clear, which is how distant signals actually work. The idea of doing this is to simulate the top speed/capacity tradeoff with different signalling arrangements, as well as the impact of braking ability on average speeds (particularly important for early railways, where poor braking severely limited top speeds in most cases), and give players an incentive to upgrade to better (but more expensive) forms of signalling in later years, such as multiple aspect and (later) moving block signalling. Is that close enough to what you had suggested to be useful?

Edit: Incidentally - which of the features do you find interesting and which less so?

On the signals system, I beleive such an idea would be very interesting if one likes to fiddle with their railways with such a detail, which probably is an important portion of our community, but there also are players who prefer a more simple approach to signal management (I have to admit I only learned how to properly use signals and one ways this year, and I've played simutrans on and off since 2006 or so). This could eventually lead to a schism between SE players, what wouldn't be very productive.  I do hope we'll be able to adjust the features of SE individually to better serve our tastes :)
I'll make a thread with my thoughts on SE on its own forum, lets not derail (pardon the pun  ;D ) this thread. (I can't seem to send PMs yet T_T)

On the presignals, I think either we have a miscommunication issue (blame my bad english) or we are talking about the same idea. To avoid any confusion I decided to put it on a graph:


http://i.imgur.com/IkvbB.png Full link

Anyway my point is that my suggestion (item 2) could be used both in a reallistic braking scenario and on a simplified (vanilla-like) braking simulation. The advantage of the "slowdown" signal would be that if the next section gets freed when the train reaches the signal, it won't have to re-accelerate from 0, instead having slowed down just a bit. The slowdown gap however, could be just enough time to allow the train in the next section to free it up, so traffic would not be as disturbed.

jamespetts

Ahh, as stated above, the idea is that the new signalling system will be optional by means of a simuconf.tab setting, as I am aware that a detailed simulation of signalling is not everyone's cup of tea.

As to the signals, the existing pre-signals are not the same as the proposed distant signals. The purpose of this thread was to ascertain whether the existing pre-signals are useful in their own right (it seems that they are), to see whether I could simply replace the existing pre-signals with distant signals, or whether I'd have to add a new sort of signal.

Pre-signals simply reserve two blocks ahead, the train stopping behind the pre-signal itself, not the later stop signal. This, rarely, can be useful, as described above.

Distant signals will do something similar to your diagram on the left, except that the train will not necessary start to slow down at the pre-signal itself, as it may already be going so slowly that it does not need to slow down until it is nearer the next stop signal. The same will apply to multiple aspect signals showing a caution aspect.

Your diagram on the right implies an element of moving block signalling, in which the trains are signalled, not by intermittent trackside signals, but automatically and constantly, measuring the exact distance to either the train in front or the next point through which a path has not been reserved and going at a speed slow enough to stop in time for the respective hazard, taking into account, in the case of a moving train ahead, its own speed and the time that it would take that train to stop. I do intend to model a form of moving block signalling with the new signalling system, but only in the advanced mode.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Djohaal

Quote from: jamespetts on April 13, 2011, 12:00:21 AM
Your diagram on the right implies an element of moving block signalling, in which the trains are signalled, not by intermittent trackside signals, but automatically and constantly, measuring the exact distance to either the train in front or the next point through which a path has not been reserved and going at a speed slow enough to stop in time for the respective hazard, taking into account, in the case of a moving train ahead, its own speed and the time that it would take that train to stop. I do intend to model a form of moving block signalling with the new signalling system, but only in the advanced mode.

Nope, it doesn't need a constant signaling system. I recall reading this on a superficial book about railway signaling (not sure what system it used). The semaphores could be red or yellow. When red they'd mean the section right ahead has a train, and the conductor would stop his alrady slowed down train to avert the collision. When yellow, it'd signal there's a train -two- signals ahead (the next signal would be thus red), so the conductor would start slowing down the train, but not enough as to be at 0km/h on the next semaphore. If the next signal after him, which was supposed to be red, turned out to be yellow or even green (meaning the train head of him would already be further away), he could keep moving or even accelerate a little to avoid the energy loss from having to stop a whole train and having to restart it again.

This would mean that after seeing a yellow distant signal (not presignal, I wrote it wrong on the image), the train would start to deacelerate, but not enough to be at 0km when it encountered the next section signal. It'd arrive there at like 25% of its base speed, and come down to stop if the signal is indeed red, but reacelerate if it isn't.

This is superflous in lines where all trains have the same speed profile (eg, all the convoys are the same) as the standard full stop signals tend to eventually sync the trains so they don't have much, if any, stop time, however if you are in a shared line, the trains might get inneficiently jammed.

jamespetts

I'm not sure that I quite follow: the train passing a distant signal at caution would need to decelerate enough so that it was able to stop at the next signal if it was at danger. Only when that next signal comes into sight and is not, in fact, at danger, can it either stop decellerating or even begin to accelerate, provided, if the next signal (presumably in this case a multiple aspect signal) is at caution, that the train is going slowly enough to stop at the next stop signal.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Djohaal

Quote from: jamespetts on April 13, 2011, 12:31:04 AM
I'm not sure that I quite follow: the train passing a distant signal at caution would need to decelerate enough so that it was able to stop at the next signal if it was at danger. Only when that next signal comes into sight and is not, in fact, at danger, can it either stop decellerating or even begin to accelerate, provided, if the next signal (presumably in this case a multiple aspect signal) is at caution, that the train is going slowly enough to stop at the next stop signal.

Yes, that's pretty much how it worked. You have a point though, the system used semaphores that could have three states: red-yellow-green. Not simple signals which can be on-off.

jamespetts

Quote from: Djohaal on April 13, 2011, 12:33:40 AM
Yes, that's pretty much how it worked. You have a point though, the system used semaphores that could have three states: red-yellow-green. Not simple signals which can be on-off.

Ahh - the UK didn't have multiple-aspect semaphores. That won't be fixed in the code, though, so, when multiple-aspect signalling is implemented, pakset authors will be able to implement multiple-aspect semaphores if they wish (whether a signal is a semaphore or not is in any event only a matter of graphics in Simutrans),
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Erik

Graphs are nice. :D
Here (on the attachment) two graphs about how the signal wrok I have made.
Perhaps this is a bit more clear.


jamespetts

Erik,

I thought that your signals reduced speed by half? Also, I wasn't aware that you had created more than one new type of signal (or is your single type of signal always capable of being a four-aspect signal?).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Erik

I have made just one new type with three possibility's. (red [stop], yellow [slow down], green [go full speed])
The second graph gives a situation the train meets two times a signal is yellow and the third time red.

Reducing speed by half did seem a bit to radical.
If the signals stands a bigger distance from each other, the signal could make it worse.
Then reduce the speed by half till the next signal could be during longer than a total stop and pull up till maximum speed.
So I have made a formula where it give a maximum speed compare to it actual speed and the distance to the next signal.
signal_speed_limit = min( signal_speed_limit, cnv->get_min_top_speed() ) * ((double)next_signal/((double)next_signal+6)*0.7 + 0.2);
In other words
speed-limit-by-signal = actual-speed-limit * ( [next-signal / (next-signal+6) ] * 0.7 + 0.2 )
If the next signal is far away the speed limit will be reduced by somewhere at 10% but if the next signal is just a few tiles the speed limit will be reduced more. This all calculated from the yellow signal. (Not from the train.)

To prevent that a train has slow down to much. (That it nearly stand still.)
The maximum speed reducing is 75% of the maximum speed of the train.

Sorry for the confusion. It is a bit difficult for me to explain it right without writing a whole book. ;)


Djohaal

Keep in mind that kinetic energy is proportional to the Square of the velocity, so a reduction of 100 to 90km/h is much bigger than from 10 to 0 in terms of kinetic energy. Speed reduction should be managed on a non-linear fashion.

arnoud

Djohaal you're right. but by 100 km/h did you've more air resistance than by 10 km/h.

so it has a greater brake.

Djohaal

I might be wrong, but I think air resistance on ideal models is linear to speed, isn't it?

TheUniqueTiger

I had once suggested multi-aspect color signalling (MACL) for Simutrans about 3-4 yrs back considering association with reality but was promptly denied by Prissi because it would mean the rail network would move at a snail's pace with stops/starts due to traffic ahead & behind. So here I take this opportunity to voice my opinion again as most of you don't know what I had originally suggested.

A MACL signal (3 aspect) which shows red, yellow, green with appropriate graphics can be used as follows... (In India we use double yellow as well between green & yellow. (4 aspect) In my opinion 4-aspect signalling in Simutrans would be an overkill.

1. A non-branching stretch of track can have many MACL "auto" signals in place of normal signals. These just check whether the next block is free (yellow), and whether the next 2 blocks are free (green) and allow/reduce speeds accordingly and reserve the one/two blocks ahead. Red color behavior is taken for granted.

New suggestions are as follows:
2. The above pattern should use a different approach when approaching a signal which guards a junction ("control" signal). There should be a check if the junction is being approached by more than one train. In that case the train that has higher priority is allowed to pass (or may be higher speed) and reserve the one/two blocks ahead while the other comes to a halt at its respective control signal. This would decrease instances of a high speed passenger train being blocked at the last minute by a slow freight train which was waiting to cross a junction.

3. The signals which guard a junction can also have two directional projections (top-left or top-right or both) which show the direction where the train is supposed to go in case it branches off.

Thanks.

prissi

Did you even played OpenTTD. There you have many of such signals, and it is a complete mess for beginners. Forcing the player to use different signals in front of crossings is not good. Furthermore those aspect signals force a certain speed like 70 kph.

Simutrans is a transport simulation. Imho making a mode of transport too complex does not really balance such simulations. And your behaviour is already present in normal signals: If the next block is three tiles away, maximum speed is 200, two is 100 and one is 50. Thus if signals are two tiles separated they would impose a 100 speedlimit even two tiles before the signal. With a presignal you could extend this one block further.

Erik

It's true that for beginners the different types of signals is a mess.
But, would that be a reason not building new signal systems?


sdog

i wouldn't be surprised if the majority of people having played simutrans never found out how to an two trains on a line. That's not the people who read this forum, but those who played a couple of hours and at some point lost interest. See those point to point lines in online games all of the time.

going to more complex signalling is only a small step after hving understood signalling at all. It could be tried out in experimental. If it works well, you could just take it into trunk and turn it off by the pak set for new players (eg in pak Hajo).

arnoud


Erik

#45
I've been thinking.
Could a beginner mode or tutorial be an option?

When I begun with Simutrans the biggest trouble to begin was to make a vehicle at all.
I didn't know that I had to build a depot for it.
After discovering that the rest was quiet easy.
However there was only one type of signal then.

(I'm afraid it starts to get a bit off topic)

EDIT: I'm just finding that this already in discussion on a other topic. :D


paco_m

Quote from: prissi on April 14, 2011, 11:48:59 AM
Did you even played OpenTTD. There you have many of such signals, and it is a complete mess for beginners. Forcing the player to use different signals in front of crossings is not good. Furthermore those aspect signals force a certain speed like 70 kph.

As far as I know these "yellow" signals exist for 60 and 40 km/h, it is actually a speed limit (at least here in german and austrian railroads) that they are using quite often to avoid fullstops on high frequented lines.

As for the complexity of this I think it is harder to understand the current implementation of presignals in Simutrans as they have nothing in common with real presignals ;)
Anyway it would be a pakset decision, if you want to keep a pakset simple and beginner friendly just don't use such signals but why do you think it is a problem to allow it for other paksets that might be addressed to experienced players or players that know how real signals work?