Transport Tycoon Forums

Very cool 2457.

These 1:1 splits were in my mind, among other things, when making this patch. Very happy to see it is working.

I have no idea why using a newGRF trainset broke it though. Maybe someone with more knowledge can answer this one.

hmm, actualy i was thinking moooar people will post here.
but seems like i was wrong

oh well, i still do hope this patch makes it into one of the nighlys, and then to stable, it is allready far too
good to leave it out. actualy since the introduction of PBS signals this is the first thing that has my full attention.
finaly something to get rid of the "logic tracks".

Has anyone else tried the patch? Did it work as expected? I am waiting for more feedback as well.

I've applied the patch and have found it really useful; although ultimately it may be worth looking at expanding it's features to encompass all of the features available to TTDP players as described here;

http://uwe.s2000.at/ttdx/signal/restric ... hp?lang=en

OTTD is far behind TTDP in terms of signalling and i hope that your work will continue to go some way to improving that situation. Other than that i don't really have any suggestions, but will report any bugs

actualy the TTDX style of signals i would not prefer...
I better like this approach.
Actualy there may be a few more , not jut or and xor logic, and a switch to make the default signal behaviour switch between block and pbs.

it should be in the trunk/nightly, for sure.
sofar i em extreemly statisfied.

if at least 4 people post here, i can set up a server with the patched version, so we can experiment in multiplayer.
i can leave it on 24/7.

Perhaps substitute "Link" with "Input" in these method names. It does seem to fit better with the concepts of your patch.

Perhaps define an enum for the sub_cmd parameter and use the Extract<> method instead of GB so that we get a compiler error if the enum is extended (and the Extract-definition) without updating the command procedure.

In the final version of your patch, only increment the savegame version with one step.


AI API
I notice that your patch do not yet address AI support. This is something that in general should be separated into a second patch in a patch queue. Eg. please consider to add it, but use HG queues or the Git equivalent to separate AI support into a separate .patch file as AI support include quite a few bit of generated code which will create a somewhat long patch on itself.

That said, for your initial patch, you should run src/script/api/generate_widget.sh to update the GSWindow class which include references to all widgets in the game.

All files related to AI (and Game Script) API is located in src/script. Eg. add code to src/script/api/script_rail.*, document API additions in src/script/api/ai_changelog.cpp, run src/script/api/squirrel_export.sh to generate some new glue code. If it makes sense, programming signals can possible be included all in AIRail, but it may need also new API classes for the API to make sense. Maybe there should be a AIProgrammingSignalList that list all tiles that contain a programming signal.

Thanks for the feedback Zuu and others.

As we know, there now exists a few different patches for advanced signal types in openttd. My patch is one way to do things, but I am not saying in any way it's the best or correct approach. The community needs to have a discussion of what new signal type (if any) should be added to openttd, and eventually included in trunk.

That being said, I am likely not going to continue development of this patch in the immediate future. The reason is that interest in my patch appeared relatively low in the end. If that changes, I will try to become more active with it.

So lets start the discussion of what new signal type should be included in trunk, if any.

maddy_ wrote: That being said, I am likely not going to continue development of this patch in the immediate future. The reason is that interest in my patch appeared relatively low in the end. If that changes, I will try to become more active with it.

So lets start the discussion of what new signal type should be included in trunk, if any.

Well, there was already a comprehensive post by Eddi on page 1 of this thread, and there were also hints to take a look on TTDPatch which already implemented both programmable and restricted signals (amongst others).

Just to re-iterate myself, most important would be restrictive signals. These would allow to split lines according to train´s needs, thus getting rid of spoiling the map with "waypoints" and the need to include them into schedules. OTOH, programmable signals are a bit more exotic, and have already turned out to address only a minority of players. But o/c we´d need both of them, at least in the long run.

The current lack of advanced signalling is a severe handicap in OTTD, and it would be an important step forward to include this feature.

regards
Michael

maddy_ wrote:As we know, there now exists a few different patches for advanced signal types in openttd. My patch is one way to do things, but I am not saying in any way it's the best or correct approach. The community needs to have a discussion of what new signal type (if any) should be added to openttd, and eventually included in trunk.

I haven't seen anything like it really. Care to explain?

maddy_ wrote:The reason is that interest in my patch appeared relatively low in the end. If that changes, I will try to become more active with it.

Interest is pretty high if you'd ask me, it's just that OpenTTD doesn't have that big of a playbase and even less check out the forums and actually want to mess around with patches because it can be very difficult if you've never done anything like it before.
Maybe put some sort of [compiled] tag in the thread name so people know. And "OpenTTD Development" doesn't sound like a download area for actual new game functions, something should really change here.

I'm willing to help if I can do anything at all, maybe uploading new binaries or something similar?

Edit: I just made a new thread here, it includes this patch and 3 others. I'm planning to upload more things soon.

Regards,

Melvin.

michael blunck wrote:Just to re-iterate myself, most important would be restrictive signals.

How about rail signs?

I mean a kind of signals with fallowing characteristics:

• The way it affects movement of a train can be based on the train.
• It's static (don't change in time).
• Have nice looking sprites allowing you to differentiate rules.

For example:

• no pass
• pax/freight only
• short/long only
• fast/slow engine only

adf88 wrote:How about rail signs?
For example:

• no pass
• pax/freight only
• short/long only
• fast/slow engine only

I thought somebody made patch for that back then ?

YNM wrote:

adf88 wrote:How about rail signs?
For example:

• no pass
• pax/freight only
• short/long only
• fast/slow engine only

I thought somebody made patch for that back then ?

Like this one?

The key of my suggestion is "Have nice looking sprites allowing you to differentiate rules.". This means non-programmable probably (you can just build a sign of a certain type).

Maddy,

Thanks for making this patch. I have a bug report. I am trying V2 of this build here.... http://www.tt-forums.net/viewtopic.php?f=33&t=68654

It seems that the regular path signals and regular one-way path signals are both broken. They are behaving like block signals. Makes it impossible to make big stations. Let me know if you need a save file or anything.

Thanks,

Guvnor

Edit: In the attached screenshot, the second train refuses to pass the one-way path signal to enter the second bay of the station.

Guvnor wrote:Maddy,

Thanks for making this patch. I have a bug report. I am trying V2 of this build here.... http://www.tt-forums.net/viewtopic.php?f=33&t=68654

It seems that the regular path signals and regular one-way path signals are both broken. They are behaving like block signals. Makes it impossible to make big stations. Let me know if you need a save file or anything.

Thanks,

Guvnor

Edit: In the attached screenshot, the second train refuses to pass the one-way path signal to enter the second bay of the station.

I just tested V2 and it works properly.
I think you used a programmable signal instead of a one-way path-signal, their graphics are currently the same. You test if it is a programmable one by using the program-a-signal button thing, it has the same icon as the options menu.
A programmable signal is also green when no train is behind it (like a block signal) if not programmed, while a path signal is always red until the train asks if it's allowed to continue.

Regards,

Melvin.

MasterMeNL wrote:

Guvnor wrote:Maddy,

Thanks for making this patch. I have a bug report. I am trying V2 of this build here.... http://www.tt-forums.net/viewtopic.php?f=33&t=68654

It seems that the regular path signals and regular one-way path signals are both broken. They are behaving like block signals. Makes it impossible to make big stations. Let me know if you need a save file or anything.

Thanks,

Guvnor

Edit: In the attached screenshot, the second train refuses to pass the one-way path signal to enter the second bay of the station.

I just tested V2 and it works properly.
I think you used a programmable signal instead of a one-way path-signal, their graphics are currently the same. You test if it is a programmable one by using the program-a-signal button thing, it has the same icon as the options menu.
A programmable signal is also green when no train is behind it (like a block signal) if not programmed, while a path signal is always red until the train asks if it's allowed to continue.

Regards,

Melvin.

I had originally been running V5 of your patch pack Melvin and it was crashing so I reverted to V2 so I could continue to play the same map. But I believe the save file wasn't compatible and so the signals were off (which is what prompted my post above). I have since started a new map with V2 and have had no problems so far.

Guvnor

Guvnor wrote:I had originally been running V5 of your patch pack Melvin and it was crashing so I reverted to V2 so I could continue to play the same map. But I believe the save file wasn't compatible and so the signals were off (which is what prompted my post above). I have since started a new map with V2 and have had no problems so far.

Guvnor

I have only found 1 bug so far which I added on the post of the compilation pack. It happens when a path signal checks a tunnel or bridge with signals on it. It always crashes for some reason. But besides that there shouldn't be any problems or I'm not aware of them.

Regards,

Melvin.

I have difficulty with signal logic. No matter what signal color and logic operation I choose, the train is not moving.

I would expect, that if signal is not programmed ( default state ), it should let trains to pass.

Muzzly wrote:I have difficulty with signal logic. No matter what signal color and logic operation I choose, the train is not moving.

I would expect, that if signal is not programmed ( default state ), it should let trains to pass.

I think that if it's not programmed it acts like a block/path signal to prevent crashes.

Regards,

Melvin.

I tested it a bit more. I seems that in a circle should always be at least two path signals in order train to move. Sorry, it was not your fault. With two programmable signals (with default green light) it also works !!!

Train window status has confused me. Should it not be "Waiting for free path" for pragrammable signal too?