News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

[gui] haltdetail lineinfo update

Started by hreintke, December 07, 2018, 04:00:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

hreintke

Hi,

Attached are two patches which add some updates to the haltdetail window.
Based on the git master branch from today, dec7, 2018

1/ Add linetype to "Lines serving this stop".
The lines are split by linetype and sorted alphabetically
See attachment haltdetail.jpg

2/ Add lineinfo to "Lines serving this stop"
The lineinfo is extended with f.e. <2> (100,0) -> this line has two convoys and on this halt will load to 100%, no waiting time.
See attachment haltdetail2.jpg

Comments are welcome.


THLeaderH

First one is very nice. I support this patch 8)

Second one is good, but the meaning of format <**> (a, b) is not easily understood by players without any descriptions. Also, IMHO, line names can be seen so complicated with this feature. If the count of convoy, load condition, and waiting time are displayed in the halt detail line info, this should be able to be turned off by players to make line names simple.

As of the patch_lineinfo1.diff, please use uint32 or other integer types instead of raw int, at least for local variables.

prissi

But even with the same line the convois can have induvidual loading and time settings. So my favor goes rather to the linetypes.

hreintke

Did not know about the possibility to have convois with individual load/waiting settings, always made multiple lines with different characteristics.
Will use this feature from now on.
Like to update my personal patch to include that information, can you tell me where that information is kept/stored ?
Can't find it in simline or simconvoi

Made a new patch for the linetypes. Ints are replaced by uint16/sint16.



Dwachs

That information is in the schedule-entries of the individual convoys.
Parsley, sage, rosemary, and maggikraut.

hreintke

#5
Thanks, found the location in the convoi/schedule/schedule_entries.

Although you have to be careful to use this feature.
When updating the schedule (f.e. by adding a station) you loose the individual settings as they are replaced/removed by the line settings.

prissi


Sirius

In the meantime, something simmilar was implemented to extended for some time, in addition to a few more very useful informations.
If you like those changes, I might search for the commit.


In the first line, you get a brief overview of how many lines of which type and player serve this station.
In the following lines, you can see the amount of passengers related to the capacity of the station. The grey part of the bar is the passengers that are currently in transfer to the station, so not relevant to standard, just like stops internal transfer times themselves.

prissi

Since the haltinfo detail is now just a tab of the haltinfo, that infomation is already in the same dialoge on another tab.

TurfIt

Quote from: prissi on September 04, 2020, 05:36:49 AM
patch 1 incorporated in r9209

Is there a reason for the following change to weg.cc that was committed along with the 'patch 1'?

+++ b/boden/wege/weg.cc
@@ -102,7 +102,7 @@ const char *weg_t::waytype_to_string(waytype_t wt)
case narrowgauge_wt: return "narrowgauge_track";
case road_wt:        return "road";
case water_wt:       return "water";
- case air_wt:         return "air";
+ case air_wt:         return "air_wt";
default:


This breaks all paksets speedbonus.tab 'air' entries. i.e. all paksets need to change to 'air_wt', and no backwards compatibility provided.

prissi

The translator did not handle cases correctly. Hence Air and air was the same. Thus one was planes "air_wt" and one was runways "Air". But for speedbonus, this is not intended, indeed.

TurfIt

It looks like for all instances of "Air", that's an incorrect word for the usage context.
e.g. We have track_wt -> "Train", road_wt -> "Truck", air_wt -> "Air". ??? That doesn't work. Perhaps "Aircraft" as a generic word for airborne vehicle? (Needs to cover airship, plane, helicopter, ...)

There's also get_waytype() in get_waytype.cc that links air_wt to "air" still. Hence the broken chain "air" -> air_wt -> "air_wt" -> dbg->fatal("get_waytype()","invalid waytype

If get_waytype() is changed to "air_wt" to maintain consistency, then every .dat file for aircraft in every pakset needs updating, not just speedbonus.tabs
I'd suggest reverting to "air" and change "Air" to something else...