Topic: All info in signal window

[Ves]

Great, hope you like it!
No, I have no access to the simutranslator!

[jamespetts]

In which case, may I suggest that you ask Mackie to gain access to this? This will be helpful whenever you add GUI features as well as if you ever wanted to maintain the Swedish translation.

Once you have access, you can add the base texts to Simutranslator yourself.

[Ves]

True, I will look into getting that acces. In the mean time, could you perhaps upload it so we dont forget it?

[jamespetts]

Done.

[Ves]

Great, thanks. I just got response from Makie, that a limit of three accounts can upload basefiles for extended, and those three are all taken. So until that limit is expanded, Im afraid I will have to ask you to upload the basefiles for me.

[Matthew]

Also, as mentioned earlier, there is a new button in the window that will open up the info window of the connected signalbox and set that as the "default signalbox" from which to buy new signals.
And also, the feature of showing the next signal, junction, or end of line, in the signal window. It has the limitations I outlined earlier in the thread.

Yesterday I used these new Quality of Life features for the first time and they saved a lot of clicking, so thank you! Planning & buildings signal can be complicated, but it's easier when you don't have to keep hunting for the right signalbox.

[Phystam]

I translated these translatable texts of this patch into Japanese.

[Ves]

Im happy you found it useful!

I have now also looked into the possibility of having it display on the ground like pressing the "V" key for stations, and unfortunately that is working the same way I realize.
However, I am looking into a method of displaying a ring of tiles by marking them individually and not as a clump. If it works, that might be a possibility, perhaps also for displaying coverage radius when building signalboxes/signals. Note that the ring for big coverage radiuses would be pretty big and out of screen if too big...

[Ves]

https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/signalbox-range-display

If you click the clickbox, the range of the currently selected signalbox will be displayed on the ground like in the picture above. The cross on the ground is to show which signalbox the circle is surrounding. Usefull especially for larger signal box ranges, where you cannot zoom out to get a view of the entire range circle. The cross could even made to grow when the range is bigger to help locate the signalbox, alternatively extend all the way out to the circle.
Should be ready for integration.

[Matthew]

https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/signalbox-range-display

If you click the clickbox, the range of the currently selected signalbox will be displayed on the ground like in the picture above. The cross on the ground is to show which signalbox the circle is surrounding. Usefull especially for larger signal box ranges, where you cannot zoom out to get a view of the entire range circle. The cross could even made to grow when the range is bigger to help locate the signalbox, alternatively extend all the way out to the circle.
Should be ready for integration.

Amazing work, Ves! That's a really useful Quality of Life feature for Extended. Thank you for your work on this!

[jamespetts]

Thank you for this - this is a most useful feature. Two things needing to be done before integration: first of all, the new TOOL_SHOW_SIGNALBOX_COVERAGE needs to be placed after TOOL_CHANGE_ROADSIGN=0x0080, as all Simutrans-Extended specific tools need to have a number >= 128 to allow for future Standard tools to be added without causing disruption, as has happened in the past.

Secondly, I will need a .dat file for the new translation text in the display dialogue.

Thank you again for this!

[ACarlotti]

first of all, the new TOOL_SHOW_SIGNALBOX_COVERAGE needs to be placed after TOOL_CHANGE_ROADSIGN=0x0080, as all Simutrans-Extended specific tools need to have a number >= 128 to allow for future Standard tools to be added without causing disruption, as has happened in the past.

Specifically, it should be added after every existing Extended tool, so as not to change the numbers of existing tools.

[jamespetts]

Specifically, it should be added after every existing Extended tool, so as not to change the numbers of existing tools.

Yes, this is correct - thank you for the clarification.

Incidentally, can anyone suggest a good keyboard shortcut key for this (that is not already spoken for)?

[Ves]

What would this be specifically?

Code: [Select]

enum {
// simple one click tools
.....
TOOL_SHOW_RIBI_DEPRECATED,
TOOL_RECOLOUR_TOOL_DEPRECATED,
TOOL_ACCESS_TOOL_DEPRECATED,
SIMPLE_TOOL_STANDARD_COUNT,
TOOL_CHANGE_ROADSIGN=0x0080,
TOOL_SHOW_RIBI,
TOOL_RECOLOUR_TOOL,
TOOL_ACCESS_TOOL,
TOOL_SHOW_SIGNALBOX_COVERAGE,
SIMPLE_TOOL_COUNT,
SIMPLE_TOOL = 0x2000
};
This is the end of the section. Everything before "TOOL_CHANGE_ROADSIGN=0x0080," is Standard stuff and everything after is Extended I suppose?. I guess that the two last entries ("SIMPLE_TOOL...") has to be at the very end, so is the position correct as I have put it?

Edit:
The translation basefiles are uploaded to the translator now!

[ACarlotti]

This is the end of the section. Everything before "TOOL_CHANGE_ROADSIGN=0x0080," is Standard stuff and everything after is Extended I suppose?. I guess that the two last entries ("SIMPLE_TOOL...") has to be at the very end, so is the position correct as I have put it?

Yes

[Ves]

Great, thanks! The fixes should be online now.
As for a shortcut key I have noe clue... "s" as in "signalbox", or "r" as in "range"?

[jamespetts]

Thank you for that : I will look into this when I have a moment.

As to the shortcut keys, I believe that all the letter keys are taken, so we only have a few symbol keys left available.

[jamespetts]

I have now incorporated this. I have set the keyboard shortcut to the $ symbol, as there are very few vacant keyboard shortcuts left.

[ACarlotti]

There is a mistake in the change - you have modified the loadsave routine in dataobj/environment.cc without putting the new code inside a version check. The result is that the game will crash when trying to read settings-extended.xml.

[Ves]

There is a mistake in the change - you have modified the loadsave routine in dataobj/environment.cc without putting the new code inside a version check. The result is that the game will crash when trying to read settings-extended.xml.

Ok thanks! What is the principle with putting the stuff inside the version checks?
I suppose I need to put it in one of these checks, but which:

Code: [Select]

if(file->get_extended_version() >= 6)
{
file->rdwr_bool(hilly);
file->rdwr_bool(cities_ignore_height);
}

if( file->get_extended_version() >= 9 || (file->get_extended_version() == 0 && file->get_version()>=102003))
{
file->rdwr_long( tooltip_delay );
file->rdwr_long( tooltip_duration );
file->rdwr_byte( front_window_bar_color );
file->rdwr_byte( front_window_text_color );
file->rdwr_byte( bottom_window_bar_color );
file->rdwr_byte( bottom_window_text_color );
}

if(file->get_extended_version() >= 9)
{
file->rdwr_long(number_of_big_cities);
file->rdwr_long(number_of_clusters);
file->rdwr_long(cluster_size);
file->rdwr_byte(cities_like_water);
}

if(  file->get_version()>=110000  ) {
bool dummy = false;
file->rdwr_bool(dummy); //was add_player_name_to_message
file->rdwr_short( window_snap_distance );
}

if(  file->get_version()>=111001  ) {
file->rdwr_bool( hide_under_cursor );
file->rdwr_short( cursor_hide_range );
}

if(  file->get_version()>=111002  ) {
file->rdwr_bool( visualize_schedule );
}
if(  file->get_version()>=111003  ) {
plainstring str = nickname.c_str();
file->rdwr_str(str);
if (file->is_loading()) {
nickname = str ? str.c_str() : "";
}
}
if(  file->get_version()>=112006  ) {
file->rdwr_byte( background_color );
file->rdwr_bool( draw_earth_border );
file->rdwr_bool( draw_outside_tile );
}
if(  file->get_version()>=112007  ) {
file->rdwr_bool( second_open_closes_win );
file->rdwr_bool( remember_window_positions );
}
if(  file->get_version()>=112008  ) {
file->rdwr_bool( show_delete_buttons );
}
if( file->get_version()>=120001 ) {
file->rdwr_str( default_theme );
}

if(  file->get_version()>=120002 && (file->get_extended_version() == 0  || file->get_extended_revision() >= 10 || file->get_extended_version() >= 13))
{
file->rdwr_bool( new_height_map_conversion );
}
// server settings are not saved, since the are server specific and could be different on different servers on the save computers
}


[jamespetts]

In general, any code that reads and writes anything from the saved game needs to be in a version check. The load/save format is very basic, in that it is just a string of game data with no control data of any sort telling the loading routine what the data are. Thus, the code needs to know precisely what order that the data will be in. It does this by knowing the exact version of the saved game file. Any changes, however slight, to what data are loaded and saved requires incrementing the file version and having code that detects for whether the file is the old version (in which case, only the data in the old version should be read/written) or the new version (in which case, the new data are read/written).

There are two version numbers: the extended_version and the extended_revision. The extended_version is the major version (currently 14) and the extended_revision is the minor revision. For making anything other than very major changes (such as those on the vehicle management branch), increment only the minor version (that is EX_SAVE_MINOR; EX_VERSION_MINOR has no effect on the saved games). Because the revision number (EX_VERSION_MINOR) is reset whenever the version is incremented, you will have to have a double check; the new code needs to be read if and only if the major version is 14 (the current major version) AND the revision is equal to or greater than whatever number that you have incremented it to (presumably 12), OR if the major version is 15 or greater whatever the revision number.

[Ves]

Thanks, how do I check what number the revision is incremented to?

[jamespetts]

It is the number that you manually type in in simversion.h in place of the existing number. It should be 1 greater than the existing number.

[Ves]

Ok thanks, I believe I understand!

I have made this entry now in environment.cc:

Code: [Select]

if ((file->get_extended_version() == 14 && file->get_extended_revision() >= 12) || file->get_extended_version() >= 15)
{
file->rdwr_byte(signalbox_coverage_show);
}

And altered this entry in the simversion.h to read 12:

Code: [Select]

#define EX_SAVE_MINOR 12which was previously at 11.

Is this correct and sufficient?

[jamespetts]

This would be correct if this had been done in the first instance. However, the current situation is more complex, because we now have people who have run the incorrect version and saved contaminated files. Luckily, these particular data are saved in a separate .xml file (~/simutrans/settings-extended.xml) and not with the saved games. If this had been saved with the saved games, serious problems would have occurred, because two incompatible saved game formats, one with and one without this datum, would have existed, both with the same version number and would thus be indistinguishable by the code in trying to read them.

I have made and committed this change. Users will have to delete their ~/simutrans/settings-extended.xml to be able to load the game.

[Ves]

Oh, I am sorry I have caused this! Thank you for doing the fix and explaining how things should work.