The International Simutrans Forum

 

Author Topic: signal spacing  (Read 1481 times)

0 Members and 1 Guest are viewing this topic.

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
signal spacing
« on: September 06, 2019, 05:39:24 PM »
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.

« Last Edit: September 06, 2019, 06:01:18 PM by Phystam »

Offline Rollmaterial fi

  • Devotee
  • *
  • Posts: 590
  • Languages: EN, FR, DE, FI, SE
Re: signal spacing
« Reply #1 on: September 06, 2019, 11:32:26 PM »
Did you adjust the placing tool so that it places signals on diagonal track according to Euclidean distance?

Offline ACarlotti

  • *
  • Posts: 483
Re: signal spacing
« Reply #2 on: September 07, 2019, 02:16:05 AM »
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.

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: signal spacing
« Reply #3 on: September 07, 2019, 02:51:59 AM »
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.

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

Offline Ranran jp

  • *
  • Posts: 659
  • Languages: ja
Oh umlaut
« Reply #4 on: September 13, 2019, 12:19:36 PM »
Quote
I 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

Offline Freahk

  • *
  • Posts: 594
  • Languages: DE, EN
Re: signal spacing
« Reply #5 on: September 13, 2019, 01:17:02 PM »
+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.

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: signal spacing
« Reply #6 on: November 12, 2019, 12:00:21 PM »
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: https://github.com/Phystam/simutrans-extended/tree/signal-spacing-change2
In this version, I fixed the LF / CRLF errors.
« Last Edit: November 12, 2019, 12:26:36 PM by Phystam »

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9730
  • Languages: De,EN,JP
Re: signal spacing
« Reply #7 on: November 13, 2019, 12:05:17 PM »

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: signal spacing
« Reply #8 on: November 13, 2019, 04:59:16 PM »
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...

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19281
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: signal spacing
« Reply #9 on: December 19, 2019, 12:51:00 AM »
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.

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: signal spacing
« Reply #10 on: December 19, 2019, 01:45:59 AM »
The distance is now shown in km when the spacing is longer than 1000m.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2921
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: signal spacing
« Reply #11 on: December 20, 2019, 01:38:40 PM »
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.

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: signal spacing
« Reply #12 on: December 20, 2019, 02:34:45 PM »
Good idea. I want to do that too.

Offline Freahk

  • *
  • Posts: 594
  • Languages: DE, EN
Re: signal spacing
« Reply #13 on: December 20, 2019, 03:40:26 PM »
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:
Easier 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.
« Last Edit: December 20, 2019, 04:05:58 PM by Freahk »

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: signal spacing
« Reply #14 on: December 20, 2019, 07:46:54 PM »
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.

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: signal spacing
« Reply #15 on: December 21, 2019, 04:47:59 AM »
James,

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

Online freddyhayward au

  • *
  • Posts: 122
  • Languages: EN
Re: signal spacing
« Reply #16 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"

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19281
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: signal spacing
« Reply #17 on: December 21, 2019, 12:21:43 PM »
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.

Offline Freahk

  • *
  • Posts: 594
  • Languages: DE, EN
Re: signal spacing
« Reply #18 on: December 21, 2019, 12:37:46 PM »
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.
« Last Edit: December 21, 2019, 01:46:58 PM by Freahk »

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: signal spacing
« Reply #19 on: December 21, 2019, 06:03:37 PM »
Thank you. It is fixed.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2921
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: signal spacing
« Reply #20 on: January 16, 2020, 04:12:45 PM »
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".

Offline Phystam jp

  • *
  • Posts: 385
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
"Shortest distance"
« Reply #21 on: January 17, 2020, 06:20:07 AM »
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?

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2921
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: signal spacing
« Reply #22 on: January 17, 2020, 07:55:05 AM »
Definitely yes for semi Euclid (measured along the path)

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2921
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: signal spacing
« Reply #23 on: January 26, 2020, 02:18:13 AM »
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