In OpenTTD you can drag when building signals in order to create more than one signal (http://wiki.openttd.org/wiki/index.php/Drag_signal_density (http://wiki.openttd.org/wiki/index.php/Drag_signal_density)). I think simutrans is worth of this feature to ;)
But how to realise it? My suggestion is the following: If you use the signal tool and dragging the cursor, several signals will be built along the route. If you release the cursor, a little dialog will pop up and you can entry, that you want a signal each 3 tiles, e.g.
What do you think about it?
This seems like a good idea :-)
Useful, I support ;)
How do you think about the dialog to set up the 'signal density'?
I think this is a great idea, and I think a pop-up window with the signal density is probably the way to go with it.
It might also be an good idea to have the desired signal type in this pop-up window (e.g. presignal, one-way etc, and maybe also which direction one-way signals should point)
This idea is a very good one, although it is not very practicable.... If you use pak128 on a normal screen resolution (1024x768), not very much tiles will be on your screen at once. And then this tool is not very usefull, because you can't get many tiles....
But in addition to auto-mouse scrolling, this might be usefull....
Of course you could always zoom out...
yes!is very useful when in opentt
what about auto scrolling in general?
has this been suggested before (I think so...^^)?
was it rejected? why?
Auto-scrolling is better than acutal system, first it would free the right mouse button so it could be used for other things. For example, selecting a tile with both train, station, signal, currently we have to click several times to have the good window. Two mouse buttons could fix that.
[offtopic]
Sigh:
Does someone actually just look into the simuconf.tab. This game is highly customizable since ages.
only_single_info = 0
will open all info windows at once.
[/offtopic]
so what to say about autoscrolling with the mouse?
Yes and it's already activated but when you for example on a tile with :
_ a signal
_ a way
_ a vehicle
of course you want to open vehicle window but you have the signal window ...
When I change to
only_single_info = 0 in my simuconf.tab and try it in the situation you describe, I get all 3 info windows: vehicle, signal and way - all with just one click, just like prissi said...
ok but I don't want to have 3 windows if I would close two.
And how does the program decide which you want? I know, yes, normally the order is fixed, so you know what will open, but...
So you only want the order of the window different when they are opened with only_single_info=1, correct?
I don't think that this would require having a different function for the right mouse button or autoscrolling implemented (even though these maybe useful features as of themselves - but probably not needed for what you want)
Maybe an immediate window allowing for selection of the object, based on images? My friend did that in a project and received a good mark for "innovative interface".
Seriously... there is 1) what prissi mentioned, then 2) you can close windows downwards with Escape which is faster than clicking.
And this topic is now more than 50% offtopic :D
Now, a first version of the auto signal build patch is finished. If you drag with the signal tool, many signals will be created.
Currently, a signal is placed every 2 straight (or 4 curved) tiles, but this can be adopted (easily) in the source code. Maybe this should be adjustable via a gui?
Feel free to find bugs.
Yes, should definitely be adjustable via the GUI.
how does it choose the direction of the signals?
and i don't quite like dragging, i suggest something like
click -> normal signal
CTRL+click -> start; click -> end for multiple signals
With dragging you know the tile you came from => direction is know.
But I think an UI is required to select the spacing.
Can I place the GUI-cl**** directly in the wkz_roadsign_t cl****? It's better to place it in gui/, isn't it?
All gui should go into gui ...
Good.
One problem.
I cant build on elevated track or monorail track.
I tested these, and all of them didn't success.
- Normal elevated track
- Elevated track on road
- Elevated track on track
Can you support elevated track or monorail track with holding CTRL key ?
Thank you, z9999. The new version allows placing signs with ctrl (like the old behaviour). GUI isn't included yet.
Thank you, it works now.
This is not a bug report but a question, both behavior on screenshot is intended ?
- Upper track: it will stop at roadsign
- Lower track: roadsign was removed
I'm not sure how it should behave.
Currently, signals on intermediate tiles are removed. Is this ok?
Maybe we should also replace signals, when the existing sign is different?
Now with a little GUI.
"remove intermediate signals" will remove all signals on tiles, where no new signal is placed.
"replace other signals" will replace other signals on tiles, where new signals are placed (otherwise it would stop at such tiles).
Aha - GUI! Looking most promising.
I compiled with gcc.exe (GCC) 3.4.5, and strange thing happened.
Some text on window was disappeared.
Ups, I inserted a "return" into the drawing routine of the new world dialogue, in order to see what happens there. And I didn't remove it before posting...
Edit:
I think, I will mark the track, on which signals will be build, red. Therewith players can see the effect of the spacing.
Edit2:
I've looked in the code and I think it's difficult to mark ways red. Maybe we place a little bulldozer on each affected way? But this isn't consistent with the usage of the bulldozer in other situations. Any idea? [Implementation details: place the marks in set_values() and remove then in cleanup()]
maybe, you can mark the tiles? so a cursor fram is shown on each tile, where a signal is built? Like for instance the station coverage is shown when building new station buildings.
Now a little "bauigel" is drawn on every tile.
(Marking doesn't work nice, since the flag grund_t::marked is removed, when touching the tile with the cursor, and grund_besch_t::marker doesn't contain the border as one image.)
Edit:
Now also CTRL+click is supported (as fabio suggested).
nice!
but what about the marker used for station coverage??
EDIT:
and what about using the signal cursor instead of the bulldozer?
EDIT2:
thank you, dragging is fine, but it is not very laptop-friendly...
when it will be implemented ?
Internally this isn't managed as an image, so it can't be used.
I think, this will cause confusions, since the signal cursor looks like a signal itself.
One problem:
1. Click on track with CTRL key
2. Click on bare ground
In this case, first zeiger will disapper but first click is not canceled.
So, next click will became second click.
This behavior is different from way tools.
Thank you, z9999. It is fixed now.
New version against r2329.
HOW TO USE .patch?
You have to compile simutrans yourself to be able to apply patch files:
Get the source code first. Compile it.
Then you can use TortoiseSVN -> Apply patch (Windows) or the 'patch' command (under Linux).
If no conflicts arise, compile again.
Hmm, I'd forgotten all about this. This might be worth including in Simutrans-Experimental, once I have the new revenue model worked out.
I am in the process of incorporating this into the next release of Simutrans-Experimental: I must say - it works very well. It really does make the player's job a great deal easier. Thank you, Gerw, for the excellent work :-)
This has now been included in the latest version of Simutrans-Experimental (http://forum.simutrans.com/index.php?topic=1894.msg19644#msg19644).
did you still have this for testing?
I've uploaded it at tu-chemnitz.de/~gerw/patches/auto_sign_r2530.patch (http://tu-chemnitz.de/~gerw/patches/auto_sign_r2530.patch). I didn't test, whether it complies, I'm too tired now... I also have to update it with respect to the two_click_tool.
Edit:
We can't define this as a two_click_werkzeug, since it works a little bit different. A simple click should place a signal like in current implementation. But a two_click_werkzeug will start the route at the first click.
Does this patch work as intended in simutrans experimental? I ask, since I have tried to get this work by applying the diff. Everytime I move the mouse over a tile with an way the tool marks it as its start :P so I patched the patch (updated diff attached).
I will try to get this implemented as a two-click tool, that its behavior is more consistent with the other click-and-drag tools. And it needs to be changed for the network mode.
However, I am not that satisfied with the overall behavior of the auto-signal tool.
When should the dialogue appear? Everytime one uses the tool? Never (and use a value from simuconf.tab)?
What happens if one accidentally builds m****es of signals? Or signals with wrong directions?
Deleting of signals could be done with checkbox 'delete signals' in the gui. Or setting the signal space large enough and select 'remove intermediate signals'
Dwachs,
it is indeed broken in Simutrans-Experimental 7.1, and was even more broken after integrating the network code in the latest -devel (proto-7.2). Bernd has spent a lot of time working on it to try to fix it - I fear that there has been some duplication of effort! This does look like the sort of thing that ought to be in Standard, though.
Appearance could be like the station layout dialoge: only with control key.
When I tested original version before, it worked with signal, long block signal and choose signal.
But it didn't work with presignal.
(Presignal has only presignal bit.)
I don't use this feature with presignal, long block signal or choose signal.
So, it was not a problem for me but....
So then dont waste your time on this. If you have any other question about network mode, let me know. I would be glad to help.
I thought of the following implementation:
1) one click with mouse: place signal as it is now
2) click-and-drag: work like building overheadlines now (mouse button is not released)
3) ctrl-click: trigger the dialogue then activate the dragging mode
After the first click in 2 and 3 preview images are shown as with overheadlines, with second click the signals are built. In networkmode it is not possible to open the dialogue after the second click.
2) takes the configuration from the last call of the tool (or maybe from a tab file), if no valid data is there, then open the dialogue
2) cannot work in networkmode as the first click is not transfered (when the mouse button is not released)
2) should be able to work in networkmode, since normal preview works too ... The building should only done after release, or?
But normal waybuilding does build on the first click. In networkmode mode, only the work commands are sent, which means after releasing the button. So click-drag-release cannot work (currently) over networkmode and is deactivated there.
Here is an update. Not network compatible up to now.
It would be excellent if this was incorporated into Simutrans-Standard! This really does make signal building a great deal easier.
Update. It should now work also in network mode.
Usage:
1) ctrl-click on icon to get the dialogue with the space settings
2) click-and-drag to place multiple signals (these will be placed after mouse button is released); does not work in network mode
3) ctrl-click (and release) on a way tile to start the dragging - use this in network mode
MAybe there should be rather two different tools to avoid confusion for fast mousehandler to avoid placing unwanted signals when click on a border between two lines. OTherwise it would built many signals unintentianally.
updated the patch.
I added an additional check to prevent building of many signals by clicking on a tile border.
incorporated in rev 3830. New help file: signal_spacing.txt. See attachment.
Edit: help file already imported into simu-translator.
Topic splitted: compile problems with makeobj are in :
http://forum.simutrans.com/index.php?topic=6019.0
I find the help text easily enough in SimuTranslator, but I am having problem locating the strings in the dialogue themselves... (signal spacing, remove interm. signals, replace other signals and set signal spacing) Are they available for translation?
In principle yes, but they are not added yet in the translator.
Edit: strings are added.
It seems to me that the tool does not respect the directionality of existing signals. Could it be modified to do so?
F ex when adding more signals to allow more trains to queue up at a "meeting stretch" I usually start by placing oneway signals with the correct direction set on the "exit spur" at each end. However, then using the signal spacing tool gave me signals with no directionality set, forcing me to go over each signal individually to set the correct direction... then the time I saved using the tool was extremely small.. .*smile*
Hm. For me it places one-way signals exclusively. This is also the intention of the incorporated patch.
You got a lot of bi-directional signals?
Yes I did, maybe I did something wrong when building?
EDIT: Trying to reproduce, but failing... It is a bit odd for which direction the signals are placed, but I will get used to it. If I see it again, I will report back, but in the meantime consider it a non-problem!
EDIT 2: I modified the English help text adding the line: ''Signals will be built allowing trains to p**** only in the direction you dragged the mouse.'' Please inform me if this is not correct.
This is correct. (if no bugs are there ...)