Dave:
Ultimately, how much stuff is displayed on the signal is up to the GRF author.
Not everybody wants all of the information associated with a signal to be displayed on it visually, as well as in the landinfo waindow. (I am the sort of person who would like that though).
This is more about a framework for having:
possibly dynamically composed signals (you probably couldn't tell the difference visually, but it may save GRF authors time/sprites)
type of signals varied at draw time, ie. snowy signals, different signals per different track types, signal gantries even, etc.
Michael:
You have a good point, you obviously are faster and more efficient at drawing stuff than I am.
(I am not an artist).
How long it would take to code the actual feature is not that much of an issue. We are not in a hurry.
This is also future expansion for if/when things like four aspect signals, or whatever other kinds of signal visuals are thought up (snowy, gantries, etc.), are done as well.
Even if this is implemented you can still use an action5 and block define all the signal combinations.
If you are worried about overcomplicating the GRF, using single sprites possibly with somesort of choice, for example snowline, still ought to take less than a half dozen simple GRF actions extra.
(I'd rather write more code and draw less sprites, but I don't expect everyone to do it that way)
Features have been added that some people don't like or don't use, either because they don't need it, they don't work as they like/want, or they prefer to use something else. You can either turn it of in your cfg file or just ignore it.
If it turns out that when/if I implement it nobody uses it except me to have weird looking variable signals based on as few sprites as possible
, then I don't mind, although that is not the idea.
Dalestan:
I've haven't started looking into the possible syntax of the GRF file, so I'll defer to your judgement...
It's probably easier to get a firm idea of exactly what needs doing first.
About recolor sprites; I think that we should try and stay away from trying to apply large numbers of recolour sprites, as its a pain to keep track of all of them, if there is one for each combination (which is one of the things I'm trying to avoid), and as eis_os says, TTD won't draw with multiple recolour sprites, and if large numbers of recolourings could be done it would probably adversely affect performance.
I haven't actually checked the possibility of this yet, but it ought to be feasible: Just use one recolour sprite, defined in memory would be easier, and set the few values which need to be changed each time, immediately prior to drawing, either by the draw code or by the GRF.
Set the other entries to identities.
This enables the 'bull's eye' signal problem to be avoided, and there are already signals with different colours in the same spot which are otherwise identical, eg. combo signal and PBS combo signal.
This would be neater than juggling recolour sprites.
Still this is only an idea, and may turn out to be hopelessly impractical.
Recolouring should definetely be made optional or off by default, if the entire sprite with the correct state is already available, and the GRF is being used only as a sprite selector.
JGR