Transport Tycoon Forums

Ben1338 wrote:JGR. Do your new signals that you made work for ottd?

No

OTTD does not support newsignals and hence does not support this GRF.
Furthermore: as OTTD does not support restricted, inverted, through or programmable signalling, there is no reason why you would want to use this GRF with OTTD.

I can think of one reason why you should:

What if someone didn't want to transfer to ttdp.

Anyway thanks for telling me.

Ben1338 wrote:I can think of one reason why you should:

What if someone didn't want to transfer to ttdp.

Anyway thanks for telling me.

I can't wait for DaleStan to see that.

If you don't want to transfer to TTDP, then why don't you write the code for the special signal states that JGR has created to work in OTTD.

Until then, pipe down, youngster.

Ben1338 wrote:I can think of one reason why you should:

What if someone didn't want to transfer to ttdp.

Then you wouldn't be able to use these signals, they serve no use in OTTD. I thought JGR made that perfectly clear.

JGR wrote:OTTD does not support newsignals and hence does not support this GRF.
OTTD does not support restricted, inverted, through or programmable signalling

And you wonder why people dislike you

Ben1338 wrote:What if someone didn't want to transfer to ttdp.

First they would remove the chip from their shoulder and lay it carefully upon the ground so that they would not trip over it as they headed, with hat in hand, over to an OTTD developer and ask that developer in a very polite manner as to why Path Based Signaling and all its related features supported by TTDPatch are not yet available in OTTD.

Depends on whom you ask, but for my part it's because I don't have the skill, time or patience to try it.

Ben1338 wrote:I can think of one reason why you should:

What if someone didn't want to transfer to ttdp.

Anyway thanks for telling me.

I cannot make this GRF compatible with OpenTTD.
This is true on a multitude of levels...

The GRF is written to a spec which OTTD does not support, for the sole purpose of displaying signals not supported by OpenTTD in a rather odd and complex manner such that I had to do less sprite work for the large number of combination involved.

As it so happens, I am a TTDP contributor, and hence TTDP implements this spec, which is very tightly tailored to, and developed for the sole purpose of displaying, the newer signalling systems of TTDP (some of which I added for other reasons, which I won't go into here), and is frankly not yet finished.
I am not an OTTD developer, and therefore could not really add this (or the associated signalling systems) to OTTD.
My C skills are not that good, and my coding style would not be appreciated...
Furthermore PBS is something very much out of my depth to implement (it was done very well by Josef Drexler) and is pretty much a prerequisite to make practical use out of/implement much of the added signalling systems.

To conclude; whilst I have nothing against OTTD, do not expect to be able to use this GRF with it.

Maedhros wrote:Depends on whom you ask, but for my part it's because I don't have the skill, time or patience to try it.

At least your reasons are valid.

I can't understand computer talk that well but now I understand now. Thanks for explaining it to me and also for answering the question.

hope that that's enough thanking. But I can't shake the feeling that I've neglected to say something.

now, can we have anything on the track?
if so, we can use the AWS board to free up some space.

Not a bad idea actually. Not necessarily realistic for the reasons but the idea is there.

The biggest problem I have with it is that you can't see it if a train is traveling or stopping above it.

wallyweb wrote:

Ben1338 wrote:What if someone didn't want to transfer to ttdp.

First they would remove the chip from their shoulder and lay it carefully upon the ground so that they would not trip over it as they headed, with hat in hand, over to an OTTD developer and ask that developer in a very polite manner as to why Path Based Signaling and all its related features supported by TTDPatch are not yet available in OTTD.

Close, but you forgot the other option:

First they would remove the chip from their shoulder and lay it carefully upon the ground so that they would not trip over it as they headed over to their development and testing environment, and very carefully start implementing, for OpenTTD, Path Based Signaling and all its related features supported by TTDPatch, testing for equivalent behaviours with the TTDPatch install that mysteriously appeared at about the time that the chip was laid carefully on the ground.

I did some quick mockup concerning the signalling stuff, perhaps it is useful. The main ideas are:
1. Top row signals the state of the signal, red or green.
2. Pre-signalling stays as it is.
3. The second and third row are for signal restrictions and PBS, using yellow (or better orange, yellow and white seem rather difficult to distinguish) for PBS and white for restrictions.
4. Programmed signals get a red (or orange) bar instead of the bluish one, as this might be easier to see against the green of the grass. In addition, the positions for the restriction and PBS are swapped.
5. Inverted signals might be created by turning the signal lights upside down, so that the red/green is the bottom part.
6. Through signals are special and not covered here. In fact, I like the basic white light the way it is now. Perhaps one could make a through signal show red and a dark yellow in order to distinguish the state of the through signal.

The picture shows from top to bottom: normal and pre-signals, PBS + pre-signals (yellow light on bottom), restricted (white light in middle), PBS + restricted (white in middle, yellow on bottom). The programmed signals are in the same order, they have the position of the white and yellow light swapped, so it's white on bottom and yellow in the middle, in addition to the red bar. Thoughts? Anything I haven't thought of?

Another idea I had was to make the signals triangular in shape, that is, two lights on top next to each other, and two below that, so one would get a total of four lights, while the signal post would remain the same height.

@wallyweb: I don't mind redoing all screenshots, but prior to that, the signal graphics have to be finished.

___Experimental release version of newsignals GRF___

Support for differentiated display of inverted signals is now supported.
This is most definitely a test case as I've just stuck the through-signal stumps on top of the signal to indicate inversion.
By happy coincidence of the y-rel values, it fits on top (relatively) neatly.

Advice on better things to stick on top/decent spites is appreciated, due to my poor drawing skills and time constraints.
The indicator is unlikely to move from the top, as it would require me to rewrite/lengthen a not insignificant chunk of the GRF NFO to make the head sprite selection code relatively position neutral, and certain more complicated positioning schemes would require changes to the spec/be impossible.

I know I'm very behind schedule on this one...

Furthermore, r1796 (next nightly) will be required to display them due to a now-rectified bug/mysteriously-non-existent-code-issue with isignal/newsignal signal display.

JGR

Jonathan,

I´d like to have a go with a new release of NewSignals, including graphics for all your newly defined signals, but I´m unsure about how many combinations of them would be needed. Could you please post a list of all reasonable signal combinations?

regards
Michael

Select one from each line:

• Lighted | Semaphore
• Normal | Presignal entrance | Programmed entrance | Presignal exit | Presignal combo | Programmed exit
• Non-PBS | PBS | PBS-through
• Non-restricted | Restricted
• Normal routing | Inverted routing

This comes to 144 types, which I think is reasonably close to the 256 that there would be if the presigs/programmed and PBS/through pairings were independent.

Sorry in advance for topic-resurrection, but I can't help thinking I'm missing something. I currently have the last grf in this topic, and both through and invertible signals activated in the grf. However, I can only ever get the through signals to show in the GUI (plus managing to do that seems to have deactivated semaphore signals).

This link should help with getting the feature working. http://uwe.s2000.ws/ttdx/signal/restric ... hp?lang=en
In the event that the routing bar at the bottom of the signal-GUI is blank, there is likely a language text issue, but you can still click it.
If this is not the problem, can you be more specific in detailing at what point in the procedure the problem arises?

Apologies for the delay, I rarely look at this subforum (thread notifications now enabled...)

As for semaphores, nobody had drawn through, inverted, restricted or programmed semaphore graphics. The GRF just uses light-signals instead.

Circeus wrote:However, I can only ever get the through signals to show in the GUI

Can you provide a screenshot?

JGR wrote:In the event that the routing bar at the bottom of the signal-GUI is blank, there is likely a language text issue, but you can still click it.

A blank button where one is not expected to be is my fault. Or my job to fix, anyway. The code that makes missing translated texts fall back to the English version is mine. Again, I'd like to see a screenshot.

(Yes, I like screenshots. "Possibly ... [we] are both looking at exactly the same display but you think it's wrong and know it's right." Screenshots make this problem vanish in a puff of pixels.)