ProgSigs - Programmable Signals patch

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

User avatar
ChillCore
Tycoon
Tycoon
Posts: 2658
Joined: 04 Oct 2008 23:05
Location: Lost in spaces

Re: ProgSigs - Programmable Signals patch

Post by ChillCore »

Cadde wrote: OK, i have one coming to you soon... But it will be against r19639 if that is OK with you?
r19639 is fine.
Take your time I will not be doing that today anyway. It is nappy time for me. :)
I guess you are right, I just didn't look hard enough... Fixing this now.
If I am not mistaking "svn add file" for each file while your source is clean will fix that for you. If you then pull a diff they should be in there, I think.
Most of the times I do not do that as I often reuse the same folder to test multiple patches.

I just copy the new files from the the patch, change the headers and attach them to the end of the svn patch I pulled. See the last four files of the patch I posted to see what the headers should look like.
-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.

Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

ChillCore wrote: I have a few more ways to crash the patch. See attachments.

Crash one: After specifying the signal to depend on, delete both the programmable signal and the specified signal in one go. Deleting them one by one does not crash the game.
Ooh. I think I know what causes this one, and its rather evil, since its an interaction with the OpenTTD code
Crash two: Setting the specified signal but by accident, or not, clicking a tile without rail.
That one is very interesting as I have done that many times... I think... I'll have to have a closer look
Then I have found an inconsistency. Programming a signal depending on a bidirectional signal is not allowed but after having specified a one way signal it is possible to change the signal into a bidirectional signal.
When removing this bidirectional signal the game crashes also. Since I can only have three attachments here is the crashlog in codeblock.
crash three:
There is actually no technical reason why you cant point it at bidirectional signals. Its just like that because I don't know how to make it possible to select which of the two to connect to; I'm therefore not going to remove the ability to change the signal's direction, just make it so that, when you do, it invalidates the dependant signals.
Ps:
What happened to your diff? It seems to contain much more than progammable signals ...
As it turns out, Solaris and projects/generate don't get along

(By the way, can I request that, in future, you try running with the parameter -dmisc10? That should generate a lot of handy debugging output.)

User avatar
ChillCore
Tycoon
Tycoon
Posts: 2658
Joined: 04 Oct 2008 23:05
Location: Lost in spaces

Re: ProgSigs - Programmable Signals patch

Post by ChillCore »

Owen wrote:
ChillCore wrote: I have a few more ways to crash the patch. See attachments.
Crash one: After specifying the signal to depend on, delete both the programmable signal and the specified signal in one go. Deleting them one by one does not crash the game.
Ooh. I think I know what causes this one, and its rather evil, since its an interaction with the OpenTTD code
Actually the last test I did with this crashed the game if I removed the exit signal before the programmmable signal.
Deleting the programmable one first works fine.
Owen wrote:
Chillcore wrote: Then I have found an inconsistency. Programming a signal depending on a bidirectional signal is not allowed but after having specified a one way signal it is possible to change the signal into a bidirectional signal.
When removing this bidirectional signal the game crashes also. Since I can only have three attachments here is the crashlog in codeblock.
crash three:
There is actually no technical reason why you cant point it at bidirectional signals. Its just like that because I don't know how to make it possible to select which of the two to connect to; I'm therefore not going to remove the ability to change the signal's direction, just make it so that, when you do, it invalidates the dependant signals.
That may confuse people. Maybe display a warning when the sinal is invalidated.
By the way, can I request that, in future, you try running with the parameter -dmisc10? That should generate a lot of handy debugging output.
Sure, no problem. I always try to reproduce crashes before reporting them anyway.

Edit:
I have cleaned up the patch a bit. See attachment.
The versions against r19638 reverted most(all?) changes made from r19628 and later.
Also I have applied coding style except for the new files, as I have not done the svn add file thingy they are not included when I pull a diff.
I hope I have not forgotten to include something. Back to testing. :)
Attachments
ProgSigs_r19642.diff
(134.76 KiB) Downloaded 153 times
-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.

Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

Code: Select all

=) oshepherd on sidewinder at ~ -> sudo mdadm --detail /dev/md0 
/dev/md0: 
 Version : 00.90 
 Creation Time : Thu Nov 8 22:08:41 2007 
 Raid Level : raid1 
 Array Size : 156135616 (148.90 GiB 159.88 GB) 
 Used Dev Size : 156135616 (148.90 GiB 159.88 GB) 
 Raid Devices : 2
 Total Devices : 2
Preferred Minor : 0
 Persistence : Superblock is persistent
 Update Time : Sat Apr 17 13:49:10 2010
 State : clean, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
 Spare Devices : 1
 Rebuild Status : 2% complete
 UUID : 791c29d5:d5828735:2d814f49:e0a3deee
 Events : 0.2158017
 Number Major Minor RaidDevice State
 0 8 2 0 active sync /dev/sda2
 2 8 18 1 spare rebuilding /dev/sdb2
In case you couldn't guess, this is Good News (TM) as far as progsigs development is concerned

User avatar
ChillCore
Tycoon
Tycoon
Posts: 2658
Joined: 04 Oct 2008 23:05
Location: Lost in spaces

Re: ProgSigs - Programmable Signals patch

Post by ChillCore »

Hello Owen,

While ColdIce was compiling my patchpak he had some issues to be able to compile.

The first problem was that he could not compile, just like Cadde, while #include "strings.h" was in programmable_signals.h.(line 14)
Removing the line solved the problem but some performance warnings remain. See codeblock.
Removing the line from my build does not seem to make a difference. Am I missing something or is the line really not needed? Can I leave it out without problems to be expected?
Anyway still enjoying your patch very much.

Code: Select all

os_timer.cpp
openttd.cpp
network_udp.cpp
..\src\programmable_signals.cpp(112) : warning C4800: 'uint32' : forcing value to bool 'true' or 'false' (performance warning)
..\src\programmable_signals.cpp(466) : warning C4800: 'DoCommandFlag' : forcing value to bool 'true' or 'false' (performance warning)
..\src\programmable_signals.cpp(538) : warning C4800: 'DoCommandFlag' : forcing value to bool 'true' or 'false' (performance warning)
..\src\programmable_signals.cpp(657) : warning C4800: 'DoCommandFlag' : forcing value to bool 'true' or 'false' (performance warning)
network_server.cpp
network_gamelist.cpp
network_content.cpp
network_command.cpp
network_client.cpp
network.cpp
Oh yeah, I should mention that ColdIce is using VC++ 2008 as compiler.
-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.

Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

The include strings.h is a mistake, and pulls in a backwards compatibility header on GCC.

As for the warnings - I hate MSVC so, so much. I'm aware of them.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

New release!

This version fixes the bugs spotted by ChillCore, and also updates the patch to the latest head.
Project files have been regenerated properly this time (woo!)

ChillCore:
I am unable to merge any of your changes because, on the transit from Git to SVN, the patch has lost the revision information required to merge it into my repository (This is a general issue when working with SVN, and one of the reasons why I went for git). If you want to help out on the patch (And believe me, I would love assistance), the best thing to do would be to grab it from my repository via Git.
Attachments
ProgSig-a280617-r19677.diff
(139.11 KiB) Downloaded 591 times

User avatar
ChillCore
Tycoon
Tycoon
Posts: 2658
Joined: 04 Oct 2008 23:05
Location: Lost in spaces

Re: ProgSigs - Programmable Signals patch

Post by ChillCore »

I did not change that much.
Just a bit of coding style here and there and reverted the reverted trunk code.
There is a sticky at the top of the development section about coding style. I have found out that it is easier to apply it while you are writing the code rather then doing it afterwards.

Git is not capable of adding svn patches?

I have a few git clients installed but I am no good with them yet.
With SubCommander, when I try to commit changes it wants to push them to trunk. Good thing trunk is protected from unauthorized users. Lol.
I also have Cola git installed but I have not yet tried to play around with it much. I did however manage to recover my old git instal instal (from my crashed windows disk) and I can still checkout my old braches.
Merging your source with my modified one is a good excuse to dig a bit deeper in it. I will have a looksie if I can find a solution for applying svn patches to git.

I would not mind helping a bit here and there but be aware that I am still learning myself.
I quit school when I was 15 (I was bored, young and stupid.) so some stuff is simply to complicated for me. ;)
-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.

Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

Git can apply SVN patches - but only against a pristine repository thats in the same state as the SVN one was when the patch was taken (Or a similar state). If the repository is modified - like mine - it can't, because it doesn't have the information required in order to backtrack through the history.

ashaw
Engineer
Engineer
Posts: 16
Joined: 07 Aug 2008 11:53

Re: ProgSigs - Programmable Signals patch

Post by ashaw »

Could one add a palate that contains often used programs, filled initially with the common ones
AND
OR
XOR
NOT
NAND
NOR
NXOR
This would make it more efficient to use.

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

ashaw wrote:Could one add a palate that contains often used programs, filled initially with the common ones
AND
OR
XOR
NOT
NAND
NOR
NXOR
This would make it more efficient to use.

Ideally we would have a text box where we could type in the conditions we wanted.

Wiremod - (an addon on Garry's Mod. Which is a mod of the source engine... lol?)
In Wiremod there is this thing called an expression gate. It can have N number of inputs and N number of outputs and they are treated as variables. The gate expressions are saved as a plain text file and they can look like this:

(With TTD flavored functions and whatever)

Code: Select all

@name High capacity train line
@inputs I1 I2 I3 I4
@outputs S1 S2
@persist TrainCounter

if (I1) {
    if (I2) {
        S1=1
    } else {
        S1=0
    }

    if (I3) {
        S2=1
    } else {
        S2=0
    }
    if (I4) {
        S1=0
        S2=0
    }
}
If (I1.HasTrain | I2.HasTrain | I3.HasTrain | I4.HasTrain) { TrainCounter++ }
Now, i know that doesn't make much sense but that is just a preview of what it could be doing.
If you are interested then read the following: Wire Expression 2
It also has a formatting page (HERE) to give you more examples of what it would look like in game.

Now i know ProgSigs are not gonna become everything that E-gate 2 is but if anything could be used off the way E-Gates work i would be a happy camper.
All it takes is a LOT of work... :wink: :bow:

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

Cadde wrote:
ashaw wrote:Could one add a palate that contains often used programs, filled initially with the common ones
AND
OR
XOR
NOT
NAND
NOR
NXOR
This would make it more efficient to use.

Ideally we would have a text box where we could type in the conditions we wanted.
If I was going to implement something like that... I would have just used the Squirrel interpreter OpenTTD already ships. The intention was that it should be possible for non programmers to use.

Additionally, your proposal has another issue: How do these files get into the game? How do you handle this in network games?

As for presets: I intend to add them. And sorry I've been a bit lax maintaining the patch as of late. I have exams starting in about a month, so things may be slow for a while.

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Owen wrote:If I was going to implement something like that... I would have just used the Squirrel interpreter OpenTTD already ships. The intention was that it should be possible for non programmers to use.

Additionally, your proposal has another issue: How do these files get into the game? How do you handle this in network games?
Ah i see so there already is an engine to support it, that's good to hear.
Considering the current implementation of ProgSigs i think it's already a bit too much for the average Joe to take in IMO. Here's the timeline that i am just thinking up on the fly:
  1. Learn to build rails, build one rail for every train. (The very beginner)
  2. Learn to put two way signals on rail to allow more trains on that rail at the same time.
  3. Learn to build double tracks for one way traffic.
  4. Learn to make junctions that doesn't needlessly cross tracks that wouldn't take a train going over/under it.
  5. Learn to build RoRo or other complex stations with path-based signals. (or if you are really fancy or started playing before working PBS, pre-signals, combo signals and exits)
  6. *Possibly* learning more advanced techniques such as load balancing (with signals) and priority tracks.
At this point in time, most people should have a fairly basic understanding of logical operation on train tracks. However, they might not know what IF, ELSE, AND, NOT, OR, XOR etc means.
Let's call those that do know this "conditional programmers" thus Programmable signals requires at least some knowledge of programming conditional statements... Right?

Sorry to take it this far just to prove a point but the point is that ProgSigs are already quite complex for those who don't know programming or have worked with logic operators in the past.
And the reason i would rather have a text box to input my program to is because every time i see a need for ProgSigs i feel the work behind setting them up is quite tedious because of all the clicks all over the place.
Instead of just having a textbox where i can do:

Code: Select all

@inputs a b
@outputs c
if (a & b) { c = true }
Then it's just a matter of hooking up a and b to a source of data. Like clicking a button for input a and then clicking on a signal from where to get the data.
When in the input/output mode one could even have lines drawn that point to the various inputs and outputs. As it is right now i have to set up sign posts to show where my ProgSig is taking in data.
And with the possibility of having an output you might not even need to have a special programmable signal in the first place. Instead you have a new type of object that is placed on the ground that can control the state of an entire block of signals.

To make this work in multiplayer (while i have limited knowledge of the inner workings of OTTD) i would just suggest doing it like they do in wiremod, every time an expression gate is changed it uploads the code to the server and the server runs the code. The expression on the client is in plain text but when sent to the server as a program it's more like op codes. It's compiled so to speak but very crudely.

That way, the client isn't actually running the program but the server is.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

Cadde wrote:
Owen wrote:If I was going to implement something like that... I would have just used the Squirrel interpreter OpenTTD already ships. The intention was that it should be possible for non programmers to use.

Additionally, your proposal has another issue: How do these files get into the game? How do you handle this in network games?
Ah i see so there already is an engine to support it, that's good to hear.
Considering the current implementation of ProgSigs i think it's already a bit too much for the average Joe to take in IMO. Here's the timeline that i am just thinking up on the fly:
  1. Learn to build rails, build one rail for every train. (The very beginner)
  2. Learn to put two way signals on rail to allow more trains on that rail at the same time.
  3. Learn to build double tracks for one way traffic.
  4. Learn to make junctions that doesn't needlessly cross tracks that wouldn't take a train going over/under it.
  5. Learn to build RoRo or other complex stations with path-based signals. (or if you are really fancy or started playing before working PBS, pre-signals, combo signals and exits)
  6. *Possibly* learning more advanced techniques such as load balancing (with signals) and priority tracks.
At this point in time, most people should have a fairly basic understanding of logical operation on train tracks. However, they might not know what IF, ELSE, AND, NOT, OR, XOR etc means.
Let's call those that do know this "conditional programmers" thus Programmable signals requires at least some knowledge of programming conditional statements... Right?
I think that the average person can understand the concept of "If number of green signals equals 3" pretty well. Perhaps the "Else" node should be relabeled as "Otherwise" though, but thats perhaps all.
And the reason i would rather have a text box to input my program to is because every time i see a need for ProgSigs i feel the work behind setting them up is quite tedious because of all the clicks all over the place.
Instead of just having a textbox where i can do:

Code: Select all

@inputs a b
@outputs c
if (a & b) { c = true }
Then it's just a matter of hooking up a and b to a source of data. Like clicking a button for input a and then clicking on a signal from where to get the data.
OpenTTD doesn't at present have a multi-line text editor. Implementing one would itself be a lot of work. Additionally, it doesn't at present have support for dynamically creating widgets (to my knowledge)

And if a person doesn't have a clue what "if" or "else" means, how the hell are they going to undertand "if (a & b)", boolean logic, and such?
When in the input/output mode one could even have lines drawn that point to the various inputs and outputs. As it is right now i have to set up sign posts to show where my ProgSig is taking in data.
Having some way of graphically connecting inputs to the relevant signal is something that is possible at present anyway.
And with the possibility of having an output you might not even need to have a special programmable signal in the first place. Instead you have a new type of object that is placed on the ground that can control the state of an entire block of signals.
Something significantly more complex than implementing a new type of signal
To make this work in multiplayer (while i have limited knowledge of the inner workings of OTTD) i would just suggest doing it like they do in wiremod, every time an expression gate is changed it uploads the code to the server and the server runs the code. The expression on the client is in plain text but when sent to the server as a program it's more like op codes. It's compiled so to speak but very crudely.

That way, the client isn't actually running the program but the server is.
OpenTTD's server is nothing more than a glorified client. Everyone needs the code. It also needs to go into the save file.

In an editable form: Multiple players can control one company and undoubtedly will want to modify the signals. Other players may want to inspect competitors signals.

And you fail to understand just how huge an undertaking implementing a programming language, as you propose, is. Even if I took the easy route and just used Squirrel, I would have to (for network safety) destroy and rebuild the virtual machine each time, and deal with the possibility that someone might code a signal to do "for(;;);" and try to hang the system.

Yes, at present things are a bit laborious. But I'm working on that. And I think, of the options you have proposed, the present one is the easiest to use.

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Fair enough. I guess i am just too deep in my thinking that...

"In code, nothing is impossible"

Then it's just a matter of will it run smoothly on our current hardware and how much work would it take to implement it.
And that leads me to the conclusion OTTD is very restrictive due to performance reasons as we have huge maps and whatnot. (Not that i have ever experienced horrible slowdowns though)
But also the fact that making anything happen in OTTD, anything at all basically needs a lot of tinkering about with a restrictive codebase that is very complicated to expand on without breaking everything and anything in between.

My dreams will simply be of a TT game that isn't this restrictive at it's core. Or i will just play TT in Garrys mod ;)

Either way, thanks for bringing us the ProgSigs you have. They are still 100% better than what we had before. (which was nothing)

Bibbydude
Engineer
Engineer
Posts: 2
Joined: 20 Aug 2009 14:40

Re: ProgSigs - Programmable Signals patch

Post by Bibbydude »

I dont know how realistic this is but i was having a similar idea, if each of your ProgSigs had an ID like a sort of auto increment where you can use than ID in the function of the signal

eg.

three signals 1, 2, 3 : the track forks from a single track into two separate lines signal 1 is on single line and 2 + 3 on the forks

on signal 1 you can apply a basic function ' if 2 or 3 = green; then self green'
or another example is you want to split the traffic onto to lanes. on signal 3 'if 2 =green: then self = red' on 2 'if 3 = green; then self = red'.

Having never worked on the development side of openTTD I have no idea how capable the program is. I also disagree that these ideas are two complex for the average player not on the fact that they are easy to understand but that they are 100% optional and not key to gameplay.

Another point is I am on a Mac everything compiled and runs fine although the signal UI has shifted 1 square to the when clicking, ie. if i click on block signal it selects entry signal etc, then clicking 1way path selects blocks.

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: ProgSigs - Programmable Signals patch

Post by Eddi »

I have a suggestion:

"force proceed if <condition>" : a path signal is not considered a safe waiting point during path reservation, if <condition> is met.

E.g. when you have 6 tile passenger train station, but 10 tile freight trains, you don't want them to stop inside the station, where the too long train would block the junction. Or a one way path signal may be set to never be a safe waiting location, if it's in the middle of the junction [people request that fairly often].
You might not exactly be interested in Ferion, but if you are, have fun :)

nighthawk_c_m
Engineer
Engineer
Posts: 26
Joined: 14 Apr 2010 06:26

Re: ProgSigs - Programmable Signals patch

Post by nighthawk_c_m »

I have no idea if this has been asked/ suggested before, but is the signal capable of detecting the load / cargo of a freight train? If so, would it be possible to code its conditional reaction to be based on the cargo?

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

nighthawk_c_m wrote:I have no idea if this has been asked/ suggested before, but is the signal capable of detecting the load / cargo of a freight train? If so, would it be possible to code its conditional reaction to be based on the cargo?
Indeed it has been suggested before and he's saying it won't come from him. Please feel free to add that functionality though! 8)

nighthawk_c_m
Engineer
Engineer
Posts: 26
Joined: 14 Apr 2010 06:26

Re: ProgSigs - Programmable Signals patch

Post by nighthawk_c_m »

I have no clue about coding - nor do I have the time to get into openttd coding - well lets wait and see, maybe someone else one day codes it.

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 6 guests