Transport Tycoon Forums

Roujin wrote: *SetBit(_me[t].m7, 4) -- is this still free? Are devs willing to sacrifice that bit in the map array for traffic lights? If not how else should it be stored?

According to the files in the docs folder, yes. However I have noticed that sometimes when loading old games/maps (eg.Cindini Map) trafficlights are added to roads rather randomly.
I fixed that in afterload.cpp ... I have not yet noticed this behaviour when loading games made after the patch is included.

*ClearAllTrafficLights() -- This is called when trafficlights setting is set from true to false midgame. It looks a bit as if it could be broken for multiplayer (only executed on server), not sure though. Should be checked.

I can not test multiplayer games. I will disable changing the settings for clients in a later version.

*I feel the "towns build traffic lights during road construction" setting does not make too much sense without the "random road construction" patch I made originally as part of this patch, but split off later. Because without that, towns will only ever have road construction if a player funds it. So either take that feature out or also add the random road construction back into the patch. Unfortunately, this adds new problems: road constructions happen on all roads roads near/inside a town, also player owned ones. With the random road construction + traffic lights patches, players complain that towns will do road construction and place traffic lights on players' "highways" that happen to be too close to the town...
In vanilla OpenTTD, nobody complains about that fact, because (I reckon) the fund road construction option is really really rarely used.
Problem is that it's not trivial to fix. Allow towns only to do road construction on self-owned roads? Bad idea because towns grow into roads placed by players, but never "annex" those roads, so such a mechanic would be needed first. This on the other hand could lead to new griefing possibilities in multiplayer.
So all in all this is opening a can of worms...
(note that my knowledge about implementation of e.g. the roadworks in OpenTTD is from back when I did these patches, so stuff may be different now than how I remember it)

Something to think about indeed ... I left it in for the moment.

* I don't know if devs agree with my idea and/or its implementation of the traffic light consists (adjacent tiles with traffic lights placed on them are merged to one big crossing) at all. I thought I was pretty clever with how I implemented them back then However looking at it now I'm not fully satisfied, there may be better ways of implementing them.

I like this feature of the patch, so much in fact that I have extended it to allow for 3 by 3 roadgrids to be synchronised too.
To not upset the Devs , I have also included an option where one can select how far trafficlights look to be synchronised. Minimum setting is 0 so it can be disabled completely.

* devs would maybe want newgrf control over more than the sprites (which would come with properly including them in openttd.grf), say tl phases controllable via newgrf callbacks, or such.

The goal is to have the sprites in the source ... but will that still allow to select the type of signals one wants to use? Devs could pick the version they prefer and add those?
Anyway I am not comfortable with all those grf callbacks (yet) so I will not be adding that code, if needed, for the moment.

* Maybe take out the hardcoded offsets for left-and-right roadside, specify the sprites relative to tile normally. Double the amount of sprites to have left-side-driving and right-side-driving variants (e.g. for half-arc-type TLs that bend over the road, the current offset scheme won't do).

Not comfortable with that neither ... I could use some help here ... Is Someone present?

Unfortunately I'm not really interested in picking up work on this patch again, but if anyone else is (well ChillCore, you're already at it it seems), be my guest

No problem. I had to recompile your grf(s) with DOS sprites for the patch to work correctly with current trunk.
Would you mind linking to them from the first post and is it OK if I continue using your thread? Or would you rather have me creating a new one to avoid confusion?
Final question: I have not added a lisence to the grfs because I could not find which one you want(ed) to use. Would it be OK for me to add the GPL lisence, same version as OpenTTD?

Thank you for the many usefull coments Roujin, below is what I have changed so far.

Zephyris wrote: I think I'll just jump in and express my support for any continued development of this patch, I think it can make the game more interesting, fun and, dare I say it, realistic!

Enoy the attached version. Do grab the recompiled GRF(s) you will need them to avoid pinky sprites.



Changes:
- Added a new file -> trafficlight.h (I have put the arrays here that are used by the patch).
- Added headers to the new files -> mentioning that OpenTTD's source is GPL.
- Little bit of coding style in the documentation.
- Trafficlight can now look 4 tiles away for synchronising themselves (square).
- Added option to select the distance trafficlights look for synchronising themselves (min is 0 -> no synchronising), max is 4 -> for 3 by 3 road grids))
- Added two more error messages (building trafficlights is disabled and building them on town roads is disabled).
- STR_ERROR_DRIVE_THROUGH_ON_TOWN_ROAD -> STR_ERROR_TRAFFIC_LIGHTS_NOT_ALLOWED_ON_TOWN_ROADS
- Removed the debugging code.
- Recompiled the GRF(s) with DOS sprites and removed debugging sprite.
- The sprites are re-introduced in the old way so most likely when sprites are added to openttd.grf there is no need for adjustments.
- Savegamecode adjusted to ini files where needed.
- TL_SV instead of 200 in savegamecode.
- When loading older savegames loop over the entire map and remove all trafficlights that ay be present (I do not know i this bug was present in a version before I bumped the patch)

How Do I Install This In The Game Do I Just Put In The Data Folder

It's a patch that you have to compile into the source code.
http://wiki.openttd.org/Category:Compiling_OpenTTD

Just an idea - would it be possible for an additional config where if a light is placed in an area which is "rural" (say, under 2000 people) that the lights are replaced with stop signs?

that kinda totally defeats the point of having traffic lights, if no actual lights are placed.

Not really. Most areas that have little to no population or traffic do not normally invest in stop lights, but stop signs. As the population grows, the area gets more traffic, then the stop signs are replaced with stop lights.

To me, it's not so much about the actual light, but the fact that traffic has to obey the signs, whatever they may be.

I'd lean more towards putting Diagram 602 (Give Way) signs on those junctions, effectively putting a priority on the road being joined.

How do you install this?

Westo454 wrote:How do you install this?

Most people will point you to this.

You will need to compile the source code (of a very old revision of OTTD) for this to work.

Are there any newer versions of this patch around (or how can one make one)?

I've just figured out how to patch and compile and I would like to use this patch in a later version of OTTD.

AFAIK, ChillCore has been the only person making updates, which have only been applied in his patch pack.

Kamnet wrote:

Quast65 wrote: Are there any newer versions of this patch around

AFAIK, ChillCore has been the only person making updates, which have only been applied in his patch pack.

I did not have a separate version after the one I posted and I did not have the need to update it neither as my patchpack is still based on a revision very close to the latest patch posted above.
Anyway I made one and have attached it below.
The game runs and trafficlights can be built but testing if everything still works correctly is is for you.

Quast65 wrote: (or how can one make one)?

I've just figured out how to patch and compile and I would like to use this patch in a later version of OTTD.

The easiest way is applying the "old" version to the correct revision, then bumping your source while solving all conflicts.
Then you compile while solving errors that still may be present; errors (often codechanges in trunk) that the bumping process does not tell you about are common.

You could try doing it yourself and then comparing your diff with mine if you get stuck in the middle.

Thnx for making this! It nicely compiles (I'll test it out a bit later)

However, how does "bumping" work? As I have another patch I would like to apply (signals in tunnels), that is for another version (r24031), that I might want to try to "bump".

Is it even recommended to apply multiple patches on one version?

Sorry for asking this, but having just found out how the compiling works has made me curious.

the typical process of "bumping" goes like this:

1. pick the last known "good" revision
2. compile, to check whether things work
3. apply the patch to that revision
4. compile, to check whether things work (possibly also run some functionality tests)
5. pick a step size (100 revisions seems to be a good start)
6. run an update for this step size
7. check if there were merge errors
8. compile, to check whether things work (possibly also run some functionality tests)
9. 1. if things worked, save your current progress in a new patch file, and go back to step 1, until you reached the current revision.
   2. in simple cases, you try to fix the errors directly by looking at the context, then proceed with step 7
   3. if nothing helps, go back to step 1, and choose a smaller step size in step 5, to isolate which revision failed, then check that revision for clues how to fix your errors (often it contains similar changes in other places)

knowledge in programming languages are necessary for step 9b/c

you should not try to bump two patches simultaneously. bump each patch individually and then merge them in the end.

Hello,
the patch has so far worked out quite well, except for the 2 bugs that I've described here last post.

Hello,

I trafficlights_r24349.diff "Apply SVN patch" to run properly.
If I start a new game I'm going to Advanced Settings> construction and I am now on the setting "Traffic Lights" is click the above is the error message:

Message: Assertion failed at line 59 of D :/ Spielen/OTTDSource/MinGW/msys/1.0/home/emily/svn.openttd.org/trunk/src/strings_func.h: size <= parent.num_param - parent.offset

OpenTTD hangs.

Yes I have noticed that the patch crasches in this case (after you mentioning it).

There are some errors in the language files that I am trying to solve and should fix the issue.
Almost there.


My understanding of the German language is not that good.
Can you please tell me about the second error that you mentioned?

Thank you for reporting.

Hello chill core,
The second error was caused by me when I tried to translate to the language file englisch.txt ind german.txt, then came the error:

Warning: Param idx # 0 'STRING' does not match with template command 'String1'

Look here, the black DOS window.

The patch does not translate german.txt to Settings> Construction now when I click the option "traffic light" then click on the warning window appears and goes out with OpenTTD crash.log.

The picture "compiler_fehler.jpg" suggest multiple things:
- you did not use "STRING1" in the german translation did you? STRINGx is reserved for the english strings ... other languages are supposed to use STRING here (I changed STRING1 to STRING2 for now in english.txt to avoid the crash).
- There is a line mentioning the use of the same string twice ... you did not apply the patch twice without reverting the new files to dummy files did you?
- You should upgrade your version of svn as it is outdated

The assertion that happens in "trafficlight_fehler.jpg" is due to the errors that I have partially solved in the language files (I think).
The crash does no longer happen in the attached patch but there still is an error present; when you set "Advanced Settings -> Construction -> Trafficlights -> Maximum TL consist size" to zero then a date will appear.
The date appearing is the first error; being able to set it to "zero" is the second as the minimum is specified as 1 in table/settings.ini.
I absolutely have no clue yet why this happens.

The crash.txt you attached sais "Version: r (0)" ... how did you obtain the source of OpenTTD? Did you dowload the zip from openttd.org and patch that?
Better is to check out the source using your SVN client as instructed here http://wiki.openttd.org/Category:Compiling_OpenTTD ; that way your source is under version control and you will be able to update it to a different revision.

Hello chill core,

I update my trunk after each revision, the revision number was from the beginning, since I use TortoiseSVN, not sent or registered. I have the latest version of TortoiseSVN v1.7.7 and still get the "Subversion 1.7 or greater" message. I already have about 10-15 Compiles and revisions can live with that without number.

Yes, I have the *. source.zip these patches from the trunk and is updated each version from the trunk.
I have now and get your trafficlights_r24349.diff the warning window patching.