Signal Auto-completion (no Signal GUI) Latest build: r5435

[Hazelrah]

Signal Auto-completion allows you to drag only a couple of tiles, and it will build signals along the entire stretch of a track. It will work around corners, and under bridges (new for this version), and it will find the other end of tunnels and bridges and continue building from there until it hits the end of the track or a junction.

Signal Auto-completion is based on the code that Hackykid wrote more than a year ago which also included a Signal GUI(original thread). I've removed it from the Signal GUI since it is better to have small independent patches. (I'm planning on implementing the Signal GUI in a separate patch now).

There are three new options available in the Construction Patches:

1) Use signal auto-completion
- Enables the auto-completion

2) Auto-complete drag limit type:*
- Disabled (Always activate auto-completion on drag)
- Max (Activate auto-completion if drag is shorter than drag limit
- Min (Activate auto-completion if drag longer than drag limit)

3) Auto-complete drag limit:
- The actual limit for option 2

* Of course if Auto-completion is disabled through option 1, options 2 and 3 have no effect.

The patch and binaries are in the next post.

[Hazelrah]

*NOTES ON COMPILING*
This patch can stand by itself, but it contains code that is dependant on other patches. If you have a patch listed below, please #define the appropriate variable.

Code: Select all

Bridge Branch  -> BRIDGE_BRANCH_INCLUDED

Todo:

• -Check out why the dry run fails when removing signals and the drag runs off the edge of the track
  -Run Autocomplete upto the first red light instead of failing if there is a train in the way

Changelog:

Patch files and code to previous versions availible upon request.
July 1st, 2006(r5435):

• -Changed Patch Options to be less confusing.
  -Removed GetRailWaypointAxis becuase GetWaypointAxis() does the same thing. (Make up your mind on naming conventions! )
  -Replaced spaces with tabs in english.txt (thanks to richk67)
  -Now works with Signal GUI without the #define SIGGUI_PATCH_INCLUDED
  -Bugfix: Auto-completing from a PBS signal no longer causes semaphores to be built.

June 22nd, 2006(r5333):
[list]-Moved HasSignalAgainstTrackdir() from rail.h to rail_map.h to conform with changes in r5309.
-Removed IsWaypoint() from my patch because IsRailWaypoint() does the exact same thing.
-Ready for Signal GUI patch (still pending). If/When you install the new Signal GUI, define SIGNALGUI_PATCH_INCLUDED. If you don't, semaphores will not work properly.[/list]

June 16th 2006(r5286):
[list]-Bugfix: Added a check required when the "Stuff under bridge" code was removed
-Bugfix: Could cause an assert if trying to add a signal under a rail bridge. Probably introduced by removal of Bridge code.
-NOTE: If the Bridge code is added to your copy, you may disable the relevent check by defining BRIDGE_BRANCH_INCLUDED so that it will build signals under the bridge again.[/list]

June 6th 2006(r5142):
[list]-Simplified Next Track Finding Code. (Thanks to Hackykid)
-Removed some un-needed debugging code.
-Cleaned up bridge/tunnel handling code some more
-Subtract 1 from the drag distance, so now it means "the distance away from the first tile, not including the first tile"
-Compiler Warning: Initialize exit_tile to INVALID_TILE (thanks richk67)
-Bugfix: TrackdirBitsToTrackBits() not removing top 8 bits properly (hopefully will be fixed in trunk soon)
-Bugfix: Consecutive small bridges/tunnels in a row would cause signals to be placed farther appart than they should[/list]

June 4th 2006(r5090):
[list]-Fixed network desync problems (Thanks to Timberwolf)
-The clients can now choose to use or not use auto-completion independantly of each other[/list]

June 4th 2006(r5085):
[list]-Seperated the code from the signal GUI
-Added option to enable/disable auto-completion in the patches
-Added option to set the maximum drag distance for auto-completion in the patches.
-Updated code to work with signals under bridges
-Removed all direct references to the map array
-Cleaned up a lot of magic numbers in the code
[/list]

[Timberwolf]

That's great! Signal auto-completion is something I got addicted to in a couple of the integrated nightlies, but I never got on with the signal GUI all that well. One little question I have, though, is this:

Code: Select all

SDT_VAR(Patches, signal_autocompletion_max_drag,SLE_UINT8,S,0,2,0,10,STR_CONFIG_PATCHES_SIGNAL_AUTOCOMPLETION_MAX_DRAG,NULL)

I just had a quick test of this over the network, and it seems if you set this value (max drag) differently on both clients, you get different signal configurations in the clients.

As far as I can see, CmdSignalTrackHelper(...) must be called as part of a DoCommand. Different signal drag densities work, though... I'm guessing that's because the density gets passed in parameter p2:

Code: Select all

 p2 = (bit 24-31) - user defined signals_density

Problem is, you then have this:

Code: Select all

	if (_patches.signal_autocompletion 
	&&  ( drag_distance < _patches.signal_autocompletion_max_drag
	|| _patches.signal_autocompletion_max_drag == 0)) {

Which is using the local client variables, where max_drag isn't synchronised. I'm not really sure of the best way round this. The way I see it, there are two easy options:

1. Make signal autocompletion and drag distance network synchronised. Downside: every player must suffer what the host wants.

2. Make the minimum drag distance equal to the "signals every n tiles" value. That seems a sensible length to use. Downside: what if you autocomplete/drag signal-every-tile? (Maybe using signals-per-n-tiles + 1...) What if this isn't necessarily a good value for the player?

There might also be a way to get the per-client settings across the network, or find some way of re-writing the patch so it autocompletes in a network-independent way, but I think those would be pretty hard to do.

Excellent patch, though. Just trying to throw a few ideas into the mix

[Hazelrah]

Timberwolf,

Yeah, I should have mentioned that network games was untested. It was about 3 o'clock in the morning for me

So here's the deal, in the previous Signal GUI, Autocompletion was actually passed in as a single bit in p2[1]. I was going to do this again, but I guess I got tired. Just to figure the code out I put it directly into the track helper function.

I'm still a fairly new at this and didn't realize that the network code is already syncronized there. Does it syncronize at the first call of DoCommand? If so, passing in a bit again should fix the problem, right? I just need to calculated that bit before DoCommand instead of after.

I'll try it this way and see if I can't get a test network going here. Thanks for the info!

-Hazelrah

[richk67]

Changelog:

June 4th 2006(r5085):

• -Seperated the code from the signal GUI
  -Added option to enable/disable auto-completion in the patches
  -Added option to set the maximum drag distance for auto-completion in the patches.
  -Updated code to work with signals under bridges
  -Removed all direct references to the map array
  -Cleaned up a lot of magic numbers in the code

June 4th 2006 (r5089):
Added Signal Auto-Completion to branch/MiniIN.

[Hazelrah]

*New Version: r5090*
A couple of bug fixes dealing with the network. Thanks to Timberwolf! See the second post above.

-Hazelrah

PS, sorry for changing it so quickly on you RichK67!

[sc79]

Considering how often I switch autocomplete on and off currently, I'd really love to see a GUI toggle for this. Personally, I dont think the config setting will be even remotely as easy to use as an on/off toggle, but its hard to tell without playing around with it (see below). If the GUI is a pain to work with, I'd settle for just a hotkey

Also, isnt your max drag distance the wrong way around? Would make much more sense to me that if you dragged less than this setting, it would use the normal method (ie. im dragging a small distance, i only want a couple of signals) and if you dragged further than it, it used autocomplete (im dragging a long distance, i want the whole section done).

As it stands, theres no way to use the normal method to add signals to a short section of track, especially a pain when changing a section with active trains already.

[Hazelrah]

Considering how often I switch autocomplete on and off currently, I'd really love to see a GUI toggle for this.

That really realy is next on my agenda. I'll get to it!

Also, isnt your max drag distance the wrong way around?

Really? Huh, I guess I never really used it much for short tracks myself. Really my fist idea was to make it so the auto-completion only triggered on a drag lenght of two (the minimum). Obviously you could set it to do that yourself (signal_auto_completion_max_drag = 2).

So you really do add signals to short tracks all the time? Anyone else have oppions on this? Should I make it a switchable min/max or is that going too far?

-Hazelrah

[Hackykid]

I'm not really active with OTTD anymore, but sometimes i still lurk around, and i just had to reply to this

Signal Auto-completion is based on the code that Hackykid wrote more than a year ago which also included a Signal GUI(original thread). I've removed it from the Signal GUI since it is better to have small independent patches.

Funny, my original autocompletion patch didnt have GUI either, and the lack of a proper interface was the main reason for it being rejected.

Of course your solution with patch settings is a lot better than my pre-gui solution, namely yet another obscure use of the control button.

Anyway, nice work!

Hmm, i just looked at the patch, and that autocompletion function i wrote back then...... is just horrid . I wrote it before i started working on pbs and became so familiar with npf and trackdirs and stuff.

Mainly that huge switch statement could be replaced by a few lines of code heh. hmm, lemme see..

Code: Select all

607 	  } else {
608 	    ts = GetTileTrackStatus(dst_tile, type);
609 	  }
610 	  trackdirbits = ts & TRACKDIR_BIT_MASK; /* Filter out signal status and the unused bits */
611 	
612 	  DEBUG(npf, 4)("Next node: (%d, %d) [%d], possible trackdirs: 0x%X", TileX(dst_tile), TileY(dst_tile), dst_tile, trackdirbits);
613 	  /* Select only trackdirs we can reach from our current trackdir */
614 	  trackdirbits &= TrackdirReachesTrackdirs(src_trackdir);
615 	  if (_patches.forbid_90_deg && (type == TRANSPORT_RAIL || type == TRANSPORT_WATER)) /* Filter out trackdirs that would make 90 deg turns for trains */
616 	    trackdirbits &= ~TrackdirCrossesTrackdirs(src_trackdir);

this piece of code from npf.c does something very similiar of not exactly the same as that switch statement. Now after this you'll need to check if
trackdirbits only has 1 bit set, in which case that is the correct trackdir you need. If it has more than 1 bit set, it mean there is a junction in that tile, which means autocompletion cant continue.

Hope this helps! And thanks for keeping this feature alive!

[sc79]

Let me make sure I've got this right

2) Max drag distance for auto-completion
-Allows auto-completion to be used together with the more traditional auto signals. If you drag less than this Max drag distance, auto-completion is used. If you drag more than it, than normal auto signals is used. Setting this to 0 will always use auto-completion.

I set this to, for example, 4. If i want to drag signals normally, I have to drag 5 or more squares. If I want to autocomplete, I have to drag less than 5. Doesnt that seem the wrong way around to you?

It makes more sense to me that the further the distance you want to place signals, the further you would drag.

What if I have to edit a small section of track (such as to change the land to allow for a tunnel etc), and want to re-place the signals on that small section? With trains active, I cant use autocomplete, but I cant drag signals normal that short a distance, so I'm forced to place them individually.

Even irrespective of how it works gameplay-wise, it just sounds really really confusing to me as is.

Note; When i say a 'short' distance, its totally dependent on personal preference on signal spacing and when you'd want AC to kick in. Im talking about the 'gap' at the low end where you might want to place 2-3 signals, but cant drag because AC overrides it.

[Hazelrah]

@Hackykid: Hey, glad to see that you still hang around here. I really did love this patch (I'm not the only one I think) so I couldn't let it die. Thanks for the tip on that swtich statement. I'll definitly give it a look! It'll probably speed up the calculations, as right now it can take upwards of a second to place signals on a long stretch.

@sc79: I understand where your coming from, really! The situation which you described is just not how I personally have done it myself, and so it did not pop into my head. If it were me, I'm patient enough to wait for the track to clear enough so that I could place signals using AC, even with trains running.

In my case I use AC way more than I use normal Auto Signals. So I wanted it to be as quick to use as possible, ie only having to drag one or two tiles. Now, this would mess up anybody who has the signal density set to 1, but I was under the impression that most people don't do that.

I'm trying to work out a solution that we can have our cake and eat it too. I've got two ideas to make us both happy and I'd love to hear your oppinion.

• 1) Add in a boolean switch. If it's on, the limit is a maximum drag distance. If it's off, the limit is a minimum drag distance.
  
  2) Actally add in a third parameter: drag distance minimum. AC would activate on (minimum drag distance <= user drag <= maximum drag distance).

Personally, I'm leaning towards #2. I think it is less confusing. Of course you could disable either or both parameters (disable minimum and/or disable maximum) so that you can have it what ever way you like.

What do you think?


EDIT: I think I may have misunderstood what you think to be part of the problem. Just to clarify, if there are trains running on the track, Signal Auto-complete should actually build signals up to the first red light. The only time it should fail, is if there is a train between the first tile and the next light. If this is not the case, then the code has a bug and needs to be fixed.

-Hazelrah

EDIT #2: "First red light" --> "next light" in first edit

[Sebastiaan]

I like this feature very much and therefore thanks that it's being maintained again!

As to the problem of dragging distance, i have no real opinion, however it seems logical to drag further the more signals you want and therefore having a minimum before this feature activates.

As to the 2 proposed options, i tend to lean to the first one, because it's easier to grasp and easier in gameplay. I can't imagin having to count every time i want to use this to be between min and max tiles. So, simply a minimum seems fit to me. One sidenode: does a minimum still work if the track makes a curve before you reach the minimum?

One other option that might be considered:
instead of failing if there is a train on the track, could the function put signals everywhere where there is no train at the moment? (And then message accordingly of course. Then you just have to do it over for the places a train was present instead of having to wait until no train is on that track at all. (which mostly implies quite long waiting times in my case)

If possible, but this sounds more like SF, the algorithm could wait until the train has passed and then retroactively place the signals?? (just dreaming )

[bobingabout]

i think i'd have it set to a short max distance, like 2 tiles. therefore if i drag more than that, that is as far as i want it, but if i only drag it by 1 or 2 tiles, i'll be wanting it to autocomplete. when i used to use autocomplete, i only used to drag a short distance when autocomplete was on anyway.

good work.

[sc79]

Just to clarify, if there are trains running on the track, Signal Auto-complete should actually build signals up to the first red light. The only time it should fail, is if there is a train between the first tile and the next light. If this is not the case, then the code has a bug and needs to be fixed.

Currently it works exactly the same as any other version I've used; any train on the section of track causes AC to fail.

when i used to use autocomplete, i only used to drag a short distance when autocomplete was on anyway.

Me too, usually. I admit most of my 'issue' with the way you have it currently is that logically, it doesnt make sense to me, and that bugs me

Personally, I'd be quite happy with the simple on/off toggle, and would probably disable the drag activation anyway.

I'd go with #1, i think. It might be a little confusing (though a couple of mins playing with it ingame should make it clear), but its not a setting thats going to get changed very often anyway.

[Hazelrah]

Currently it works exactly the same as any other version I've used; any train on the section of track causes AC to fail.

Dang, your right... Hmm, sorry, obviously I'm terrible at testing things. Maybe the direction of the signals matter. Either way, I wanna look into fixing that. I really do think that autocomplete should succeed at least to the first signal on a blank stretch of track.

Me too, usually. I admit most of my 'issue' with the way you have it currently is that logically, it doesnt make sense to me, and that bugs me

Personally, I'd be quite happy with the simple on/off toggle, and would probably disable the drag activation anyway.

Alright, I get what your saying. I'll try to get the GUI going again soon. But I'm on vacation for a week starting this Thursday, so you may just want to stick with the old patch for a while until I get it the new GUI going.

I can't imagin having to count every time i want to use this to be between min and max tiles. So, simply a minimum seems fit to me. One sidenode: does a minimum still work if the track makes a curve before you reach the minimum?

Yeah, I'm agreeing that counting tiles would suck. I'll try putting in a min/max switch.

I've also got Hackykid's replacement and a bugfix on the horizon here.

-Hazelrah

[richk67]

Bug in rail_cmd.c: glx pointed out that the TileIndex exit_tile; needs to be initialised with exit_tile = INVALID_TILE; . Currently although it is set OK in 2 halves of an if, some compilers dont like it.

[Hazelrah]

*New version: r5142*

A couple of bug fixes, and the min/max switch that we've been talking about. See the first and second posts of this topic for details.

I implemented the min/max like I promised, but I have to say, I'm not really all that happy with it. Not because I think it's a bad feature, but because I think it's rather confusing. If you look at my first post, it basically took me a whole paragraph to describe how to use it. If anybody can reword those sentences to be shorter and more precise, I'd be most grateful.

I'm also not happy with the wording on the Options screen. I realized as I was uploading this that it should work a little more like the Review Vehicles mode, which rotates between text. The option would then look like.

Code: Select all

< > Drag Limit is a <minimum> to activate Signal Auto-complete.

Clicking on the arrow would change minimum to maximum.

I haven't gotten a chance to look at building upto the first red signal. I want to do the GUI before looking at that.

-Hazelrah

[Hazelrah]

*New Version: r5286*

Back from vaction! A couple of bugfixes related to the fact that the Bridge Branch code was removed from the trunk. It now treats track under bridges the same way as way points.

See the first post for details.

I'll get an executable of the new version going when I get some time this weekend.

-Hazelrah

[gkirilov]

An update?

[Ryalla]

Yup. An update. ;D It's great what you've done with this, Hazelrah.