Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

signal spacing

Started by Phystam, September 06, 2019, 05:39:24 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Can we show signal spacing option with meter unit? Maybe such kind of feature would be very useful to build signals automatically.

I made a small patch for this feature.
Github branch is here.


Did you adjust the placing tool so that it places signals on diagonal track according to Euclidean distance?


I notice that the Github diff suggests that you've changed every line in those files - this usually means you've accidentally converted from LF to CRLF line endings (or vice-versa). This should probably be avoided - I think there's some Git setting to specify what line ending to use in source control. I also notice that you are defining a local variable meters_per_tile and not using it.

Finally, does your screenshot show correct values? 600m for 24 tiles looks like it might be a factor-of-ten error for a 250m/tile pakset.


Rollmaterial -- No, the tool itself is still same as previous.

ACarlotti -- Okej, I will change it.
And the screenshot is okej, since pak256-Ex pakset has 25m/tile scale.

I checked the line breaking codes --- these are... like chaos. ASCII (LF)
ai_option_t.h: ASCII (LF) ASCII (LF)
banner.h: Shift_JIS (LF) ASCII (LF)
base_info.h: ASCII (LF) Shift_JIS (LF)
baum_edit.h: ASCII (CRLF) Shift_JIS (LF)
city_info.h: Shift_JIS (CRLF) Shift_JIS (LF)
citybuilding_edit.h: ASCII (LF) Shift_JIS (LF)
citylist_frame_t.h: ASCII (CRLF) Shift_JIS (CRLF)
citylist_stats_t.h: Shift_JIS (CRLF) ASCII (CRLF)
climates.h: ASCII (CRLF)
components: ASCII Shift_JIS (LF)
convoi_detail_t.h: Shift_JIS (LF) Shift_JIS (LF)
convoi_filter_frame.h: Shift_JIS (CRLF) Shift_JIS (CRLF)
convoi_frame.h: Shift_JIS (CRLF) Shift_JIS (LF)
convoi_info_t.h: Shift_JIS (LF) ASCII (CRLF)
convoy_item.h: ASCII (CRLF) Shift_JIS (LF)
curiosity_edit.h: ASCII (LF) Shift_JIS (CRLF)
curiositylist_frame_t.h: ASCII (LF) Shift_JIS (CRLF)
curiositylist_stats_t.h: Shift_JIS (CRLF) ASCII (LF)
depot_frame.h: Shift_JIS (CRLF) Shift_JIS (LF)
display_settings.h: ASCII (LF) ASCII (LF)
enlarge_map_frame_t.h: ASCII (LF) Shift_JIS (CRLF)
extend_edit.h: ASCII (LF) Shift_JIS (LF)
fabrik_info.h: Shift_JIS (LF) ASCII (LF)
factory_chart.h: ASCII (CRLF) Shift_JIS (LF)
factory_edit.h: ASCII (LF) Shift_JIS (LF)
factorylist_frame_t.h: ASCII (LF) Shift_JIS (LF)
factorylist_stats_t.h: Shift_JIS (LF) Shift_JIS (CRLF)
goods_frame_t.h: Shift_JIS (CRLF) Shift_JIS (LF)
goods_stats_t.h: Shift_JIS (LF) Shift_JIS (LF)
ground_info.h: Shift_JIS (LF) Shift_JIS (CRLF)
gui_frame.h: Shift_JIS (LF) UTF-8 (BOM) (CRLF)
gui_theme.h: UTF-8 (BOM) (CRLF) Shift_JIS (BOM) (LF)
halt_detail.h: Shift_JIS (BOM) (CRLF) Shift_JIS (BOM) (LF)
halt_info.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
halt_list_filter_frame.h: Shift_JIS (BOM) (CRLF) Shift_JIS (BOM) (LF)
halt_list_frame.h: Shift_JIS (BOM) (CRLF) Shift_JIS (BOM) (CRLF)
halt_list_stats.h: Shift_JIS (BOM) (LF) UTF-8 (BOM) (CRLF)
help_frame.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
jump_frame.h: Shift_JIS (BOM) (LF) ASCII (BOM) (LF)
karte.h: ASCII (BOM) (LF) Shift_JIS (BOM) (LF)
kennfarbe.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (CRLF)
label_info.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (CRLF)
labellist_frame_t.h: ASCII (BOM) (CRLF) Shift_JIS (BOM) (LF)
labellist_stats_t.h: Shift_JIS (BOM) (LF) UTF-8 (BOM) (LF)
line_class_manager.h: Shift_JIS (BOM) (LF) ASCII (BOM) (CRLF)
line_item.h: ASCII (BOM) (CRLF) ASCII (BOM) (LF)
line_management_gui.h: ASCII (BOM) (LF) Shift_JIS (BOM) (CRLF)
load_relief_frame.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
loadsave_frame.h: Shift_JIS (BOM) (CRLF) Shift_JIS (BOM) (LF)
map_frame.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (CRLF)
message_frame_t.h: Shift_JIS (BOM) (LF) ASCII (BOM) (LF)
message_option_t.h: ASCII (BOM) (LF) Shift_JIS (BOM) (LF)
message_stats_t.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
messagebox.h: ASCII (BOM) (LF) Shift_JIS (BOM) (LF)
money_frame.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
obj_info.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
onewaysign_info.h: Shift_JIS (BOM) (LF) ASCII (BOM) (CRLF)
optionen.h: ASCII (BOM) (LF) ASCII (BOM) (LF)
overtaking_mode.h: ASCII (BOM) (LF) ASCII (BOM) (CRLF)
pakselector.h: ASCII (BOM) (CRLF) ASCII (BOM) (LF)
password_frame.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
player_frame_t.h: ASCII (BOM) (CRLF) Shift_JIS (BOM) (CRLF)
privatesign_info.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
replace_frame.h: Shift_JIS (BOM) (LF) EUC-JP (BOM) (LF)
savegame_frame.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (CRLF)
scenario_frame.h: Shift_JIS (BOM) (CRLF) ASCII (BOM) (LF)
scenario_info.h: ASCII (BOM) (CRLF) UTF-8 (BOM) (LF)
schedule_gui.h: Shift_JIS (BOM) (LF) ASCII (BOM) (LF)
schedule_list.h: ASCII (BOM) (LF) Shift_JIS (BOM) (CRLF)
schiene_info.h: Shift_JIS (BOM) (LF) Shift_JIS (BOM) (LF)
server_frame.h: ASCII (BOM) (CRLF) Shift_JIS (BOM) (LF)
settings_frame.h: Shift_JIS (BOM) (CRLF) ASCII (BOM) (LF)
settings_stats.h: Shift_JIS (BOM) (CRLF) Shift_JIS (BOM) (LF)
signal_info.h: Shift_JIS (BOM) (LF) ASCII (BOM) (CRLF)
signal_spacing.h: ASCII (BOM) (CRLF) ASCII (BOM) (LF)
simwin.h: ASCII (BOM) (LF) Shift_JIS (BOM) (CRLF)
sound_frame.h: Shift_JIS (BOM) (CRLF) Shift_JIS (BOM) (LF)
sprachen.h: ASCII (BOM) (CRLF) Shift_JIS (BOM) (CRLF)
station_building_select.h: Shift_JIS (BOM) (LF) ASCII (BOM) (CRLF)
themeselector.h: ASCII (BOM) (LF) ASCII (BOM) (LF)
times_history.h: ASCII (BOM) (LF) ASCII (BOM) (LF)
times_history_container.h: ASCII (BOM) (LF) ASCII (BOM) (LF)
times_history_entry.h: ASCII (BOM) (LF) ASCII (BOM) (LF)
tool_selector.h: ASCII (BOM) (LF) Shift_JIS (BOM) (LF)
trafficlight_info.h: Shift_JIS (BOM) (LF) UTF-8 (BOM) (LF)
vehicle_class_manager.h: Shift_JIS (BOM) (LF) ASCII (BOM) (LF)
welt.h: ASCII (BOM) (CRLF)


QuoteI checked the line breaking codes --- these are... like chaos.

This issue often bothers me. (´・ω・`)
As you all know, Simutrans was born in Germany. :hat:   The simutrans code sometimes contains umlauts.
Since umlauts cannot be displayed in the Japanese Shift-JIS environment, MSVS converts those character codes when opening a Shift-JIS format file that has them (a warning message pops out). So German characters are not preserved correctly.  :warning:
If we save that auto converted file, those characters will be garbled. Because there is no umlaut in Japanese Shift-JIS environment! The alliance between Japan and Germany has been destroyed.  ::'(
So if the file is in Shift-JIS format, I am careful not to update the German mixed lines every time. I manually exclude those lines...

And sometimes Github somehow rejects that file, so immature Ranran can not push that file directly...

Oh umlaut, umlaut! why are you umlaut? (´・ω・`)
I dropped out of the German class because I don't like you! I can not even say your name.  :P


+1 for "umlauts" :D Did not know these are really called umlauts. Sounds just as crazy as Schnitzel in an english sentence.

You should try to open the files in iso-8859-1 encoding, which was typicall used in Germany before utf-8 was introduced. However, this has nothing to do with linebreaks.

Also, I am wondering if there is any linebreak convention for simutrans code, so we could replace wrong linebreaks for consistency reasons.

Edit: for globalisation reasons, we should think about converting from iso-8859-1 to UTF-8, however, I am aware that this could cause problems, when not done carefully.


Now the signal spacing window looks more better like this:

Now you do not have to calculate the actual length in meters from the tile number. Just putting value in meter unit, that's all.
The diagonal length is now calculated using Euclid length.

github branch:
In this version, I fixed the LF / CRLF errors.



I think that we should always use the UTF8 encoding and LF line ending. If someone (maybe James or A.Carlotti) changes the text encoding system using .gitattributes, such problems will never happen...


Thank you for this - this is a very helpful addition, since braking distances are shown in meters rather than tiles and braking distances are important for signal spacing.

One thing that emerges from testing, however, is that the text is too large to fit into the buttons in Pak128.Britain-Ex - the "m" goes out of the end of the button when the number of meters is a four figure sum. Perhaps the way to resolve this would be to use kilometers when the distance is >=1km, so that instead of "1000m", we display "1.0km", which, although the same number of characters, should take less space with a variable width font as the"." will take very litle space.

Thank you again for your work on this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


The distance is now shown in km when the spacing is longer than 1000m.


I like this patch.

Will you be able to make another change - perhaps a check box or Shift-drag, that would build the signals "backwards" ?

I usually start by building signals around the station (start & home signals), and then want to put distant or block signals at given distance from existing home signal. So what I would like to do is to click on existing signal (which will stay as is even if it is of different type), and then drag in opposite direction and have signals built facing in the direction of drag.


Good idea. I want to do that too.


When you are already working at signalling placement, there is a tiny request in the Current development projects: coding help welcome thread about signal replacement, that would also be pretty useful.

I will just quote it here:
Quote from: jamespetts on October 07, 2011, 01:29:05 AMEasier signal replacement [*S]

At present, when replacing a signal or road sign, it is necessary to delete it and then add another. It might be easier if it were possible to replace a signal or road sign in a single step, by CTRL+clicking on the old sign/signal with the tool for the new signal selected: this should work in the same way as if the player had first bulldozed and then added the new sign/signal except that it should check the cost of both first and only demolish/remove if the player can afford both steps combined.

James only mentioned ctrl-clicking a single signal but I guess it would be pretty useful to also allow for ctrl-dragging, which would only replace existing signals with the new type but won't place any signals in between.


Vladki and Freahk,

Thank you. I implemented 2 features as you mentioned.
As a figure below, I added an option 'place signal backward.'
This makes much easier to construct distant signals at a fixed distance from the home signal.
Usage is just dragging backward from a home signal tile. The home signal will not be deleted.

The second feature is easier signal replacement.
CTRL+click has already have another meaning, so I changed the feature to SHIFT+click.

When you use these 2 features at the same time, the home signal will be replaced and 2 distant signals will be constructed.
I pushed the latest feature on my github branch.



I added showing distance in meters in tooltip, and added translation text on the simutranslator.


This patch works well on regular games, but completely breaks on server games - i tested on a localhost server using an empty map and I still get "cannot build without signalbox etc...". If i use ctrl+drag I can get the signals placed, but clicking for details reads "controlled from: none"


Quote from: freddyhayward on December 21, 2019, 09:59:34 AM
This patch works well on regular games, but completely breaks on server games - i tested on a localhost server using an empty map and I still get "cannot build without signalbox etc...". If i use ctrl+drag I can get the signals placed, but clicking for details reads "controlled from: none"

Thank you for the report - I believe that I have now fixed this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


It seems something went completely wrong with directions of dragged signs.
I just drag-placed one way signs on stephenson-siemens and these were placed in opposite direction (place signals backwards unchecked)
One can change the direction by clicking on the sign, but for diagonals this will toggle between bidirectional permitted directions, thus effectively ignoring the sign from both directions, or "unknown" direction, which will also be ignored from either side.

edit: this was observed before James comment. Did not yet test a freshly compiled version.

update on that: And I can't place any signal at stephensom-siemens. When I try to, signalbox will get deselected.
It is likely to be what James fixed. I will see when tomorrows nightly has arrived at the server.



Hello. thanks for the work done on this.

I noticed that the distance on diagonals as measured by building tool is different to what signal info says about the distance to next signal. It seems to me that the building tool is properly counting diagonal distance, but the signal info counts "manhattan distance".


I did not touch that code area.
maybe we need to change all of the distance calculations into "Semi-Euclid distance".
now the signal placing algorithm uses the semi-Euclid, but other parts are using Manhattan distance.
Is it better to use semi-euclid distance for all distance calculation?


Definitely yes for semi Euclid (measured along the path)


Just a minor glitch - when building signals backwards, they are show as bidirectional, but info dialog displays only one direction. Building over makes it truly bidirectional..

Also this dragging should treat one-way signals in the opposite way, or ignore them cpmpletely