Topic: Way info window

[Ves]

Well, I could not resist but to try and make a button in the way info window that sets the viewpoint to the train which currently has reserved the track. It has succeded, so the button now exists and is workable, I have one issue though:

The button which is used to focus the view to the vehicle should appear and disappear automatically, also when the window is open. It is however not the case:
When the window is open while there is no reservation, the button will not appear even though the track gets reserved. If you close and reopen the window, you will see the button, but when the train has passed on, the button does not disappear but stays fixed in the window.

I have used is_reserved() to check wether the track is reserved or not.

How can I make the button appear and disappear automatically?

[jamespetts]

I have not looked into this dialogue recently at all, so I should have to do as much detective work as you to work it out; but one guess would be that this window does not automatically update (or, if it does, your code is not called from the update for some reason).

[Ves]

Thanks, I am digging into the ::draw parts as I think this is where it is done. I have succeded in making the button disappear and reappear, but oddly enough only after some time, as if the window only gets updated at certain intervals. Have not just yet wrapped my head around it properly to understand exactly how I can get the buttons to reliably appear and disappear. Any input from anyone is most appreciated!

Anyway, here is a development picture of the way window, which I hope you would consider implement:



New information:
- A button next to the reserving vehicle name, centering the map onto the vehicle (and follows it too).
- Type of reservation. If directional reservation, then also which direction, ie heading, the track is reserved. I have also added the not yet existing reservation type "priority". When that is implemented, there maybe can be some other juicy information extractable to put in the "heading" part.
- Distance to the reserving vehicle, following the same decimal convention as the signals distance meter.

Also, I added a line of text if the track is not reserved by any vehicle.

One thing I would like to add is under which working method the track is reserved. I have not yet figured out how to convert the convoi_t (which the schiene_t gets its information from) to rail_vehicle_t, where the get_working_method() is located.

[jamespetts]

To answer your latter question, you need to take the front vehicle of the convoy (cnv->front()), and, only if you can be sure that it is a rail vehicle, cast it to rail_vehicle_t before calling a rail vehicle specific method on it.

As to the distance to vehicle, hopefully this does not involve any significant computational overhead?

Otherwise, looking good!

[Ves]

As to what I can see, I don't notice any difference in performance. It is exactly the same code that finds the distance between signals and their boxes, and it should only be computed when the window is open and there is a reservation. Have not tried having multiple windows open though.

[jamespetts]

If it is only run when the window is open, this should not be a problem.

[fam621]

Noice.

[Vladki]

Great idea Ves. I often struggle to find out which train has some forgotten reservation.

Sent from my ONEPLUS A3003 using Tapatalk

[Ves]

Great idea Ves. I often struggle to find out which train has some forgotten reservation.

Me to, hence the idea to this patch! 

I cannot get my head to wrap around the ::draw section of the code. When that is included, the button does not work and the entire point with it is gone, as well as it does not update reliably.
Would you mind if I completely amend that, and the button will stay visible all the time? I think that with some practice from other parts of the code, I can revisit this at a later day to make it function correctly.

edit:

But appart from that, I think that the reservation section is finish. It currently looks like this:



What is new/changed:
* Name and button to the vehicle
* The current working method of the train
* What type of reservation, HOWEVER, only if it is not normal reservation (called "Block" reservation). Reasons for its exclusion is that it felt too obvious and also it could be misguiding. Ie, time interval has no "blocks", neither do drive by sight.
* If the reservation type is "Directional reservation", the direction in which the track is reserved is also shown.
* Distance to vehicle, along with its current speed and current direction. I included the speed to easier see if the train was operating, and its current heading to give the player an approximation from which direction it will come (as it is only the directional reservation that will show the direction of reservation otherwise). I think it should be clear the way the last three bits of information is presented?
AND, the button is visible at all times!

If you like it, you can pull from here: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/track-finds-reservationtrains
Otherwise, tell me what I can do better! 


I would also like to rearrange some of the information in the rest of the dialog also if you dont mind?
Additional usefull information could be:
montlhy costs
which directions it has
Maybe a text that tells you if you may use the way (because of restrictions from other player)
....
Some more suggestions?

[jamespetts]

That is splendid - thank you. I have now incorporated this: I should be grateful for any feedback from testing.

Can you let me know when you think that the .dat file for the texts is unlikely to be altered furhter in the immediate future so that I can upload it to Simutranslator? Once you so notify me, you will need to start a new translation text file.

[Ves]

I was thinking of having these maintenance numbers visible:

Maintenance per tile
Maintenance per km

- if also containing a wayobj: -
Maintenance per km + wayobj maintenance pr km

However, that means that there will be three maintenance numbers visible if the way has ie a catenary, and that might be too excessive.
Which numbers would you guys suggest? What do you think is important?

Also, what about the visibility to other players. Do you think it matters to show the costs to other players? It might be confusing, but at the same time its informing and you can already see the vehicle income from other player I think.

[jamespetts]

I can see that it would be useful to show these things; and perhaps also the cost of renewing the way tile with the selected renewal way? Thank you for all your work on the UI - it is much appreciated.

[Ves]

That was a very good idea!


edit:
Looking into this, I have found this you have done which appears to get the price of upgrading:

Code: [Select]

const sint64 price = desc->get_upgrade_group() == replacement_way->get_upgrade_group() ? replacement_way->get_way_only_cost() : replacement_way->get_value();
However, when taking the value "price" and show it, it shows the upgrade costs for two tiles of way not one. It is easy enough to get around, I will just divide by two, however I just want to make sure that I am not making bad assumtions by doing that?

--
another edit:
Is there a good replacement word for the word "wayobject"? I want to specify that the way object is making some alterations to the way, but the word "wayobject" is bugging me. I cant call it catenaries, as it technically might not be catenaries. Also, calling it by its name is way too long. Any suggestions?

[jamespetts]

I am a little confused in relation to the price being for upgrading two tiles of way: this exact number (that given in "price") is what is actually booked as the cost of upgrading a single tile of way. Can you elaborate on how you reach the conclusion that this refers to upgrading two tiles of way?

In relation to "wayobject", that is not an English word, but there is no clear alternative description but to use the two separate English words from which that composite was defined, "way object".

[Ves]

I have made a commit that will show what I mean here: https://github.com/VictorErik/Simutrans-Experimental-Ves/commits/track-finds-reservationtrains
However, do not incorporate it into the game yet (you should compile from the branch, if possible) as it is not in a finish state, yet all the translations are missing.

* In the code, open the weg.cc and look at line 641, there you can see that I have copied a line from another place in the code (namely, line 1264 in the same file) and divided it by 100.
* Compile the game and press on a waytile in the game. There, the costs of the upgrade are shown under the "to be renewed with" section, first the cost per tile, below, the cost per km.
* Build the oldest, badest waytype possible and specify that it should be renewed with the newest waytype (shiftdragging). The infowindow should now update with some more information. Pay attention to the upgrade cost section.
* Now, manually upgrade the piece of way with the same waytype as you specified it should upgrade to. Look at the cost of doing so. you will see that the number in the information window matches the cost for two tiles of way upgrading, not one tile. Likewise, the upgradecost per km will show how much it costs to upgrade two km.

But as I said, it is no problem for me, I can just divide the cost by two. I just wanted to point out in case something is not working as it is supposed to do.

[Ves]

There is a problem with this patch that I have big problems with:
Try open a runway info window, it will show a text stating that the track is not reserved yet and the "go to vehicle" button will be visible underneath. When an airplane enters the runway, or try to land on it, the game crashes.
I assumed it was because it would try to locate the working method of the airplane and have therefore tried to make some "if air_wt...." to make sure that it did not search for that information, but I have failed in doing so. The game keeps crashing no matter what I do. On top of this, I simply fail to create a debug build so I could debug it myself, so I would like to ask you if it would be possible if you could take a look when you have time to somehow see if there is an easy solution to this?

[jamespetts]

I think that I have managed to fix this - would you be able to re-test? I should be most grateful.

[Ves]

Thank you very much! It appears to be fixed! Im sorry to introduce bugs that I cannot myself resolve! 

[jamespetts]

Splendid, thank you for checking.

The thing to learn here is that you had a pointer variable initialised to NULL that was only given a non-null value in certain conditions, yet you did not check whether it was NULL before trying to read one of its data members.

[Ves]

Ok, while being a little bit stuck on the transfer time display, I spent some time making this patch to a more finish state. It is not complete, for instance the infowindow for ways tends to duplicate the name a bunch of times, making the window a bit more messy than it already is. This is due to the window taking information from different parts of the code and then put it together in one window. That is smart, so you can have a general information like name and tile season displayed on all windows and only add specific elements to the specific window. Backside is that it is way less flexible!

link: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/track-finds-reservationtrains

What it currently shows:

Top speed of the way, and wether it is reduced due to being inside a tunnel, on a bridge, by the wayobject or inside a city. It doesnt hit perfectly all the time, but mostly.
axle load
if bridge or runway, max weight
if runway, runway direction and length
Monthly cost
monthly cost incl wayobj

then James information about the upgrading way, but I have added the following:
Renewal cost
increased or decreased axle load/max weight
increased or decreased speed
increased or decreased maintenance cost
increased or decreased durability, in percent

Lastly, the "low bridge" message and "electrified" message are showed together with the permissive and prohibissive constraints.



There is a linespace missing on the mothballed way, but that should be corrected

I think that the window is a little bit clogged up. Especially the maintenance costs that very much would like to spend two lines, breaking the one line policy.
Please come with some suggestion how to improve readability! 
Or if you would like to see other information in the window.
Also, one could play with colors, potentially removing some text, but that might become cloggy too.

[jamespetts]

Thank you very much for this - that is very helpful. Before I integrate this, I should be grateful for people's views on whether this much information is helpful, or whether it might be a little too much to take in and/or overwhelming.

Incidentally, if you are stuck in relation to the transferring goods display, may I suggest that you post about the problems that you are having in the relevant thread so that I can see whether I can assist? If you have already done so and I have missed it, my apologies.

[Vladki]

I welcome this detailed info. Much better than looking at the tool tips.

Sent from my ONEPLUS A3003 using Tapatalk

[fam621]

Noice.

[Ves]

Yes, I will post questions regarding the other subject in that thread, however, this way window learnt me some techniques that might be helpful to the other one.

My reasoning behind much of the information is that it is only found in the tooltip. That means that if a way gets obsolete, the player have no way of knowing is how expensive it is or its duration strength (that is actually not included here, only a percentage between new and old).

My reasoning for the differences between, and not the new actual values, for upgraded ways, is that now you should be able to only look at that area of the window to tell if the way you consider as an upgrade is suitable. If I show the new values, you would have to compare with the existing values and if I show no values, you would have to compare with the tooltip. I find that part of the window quite easy to read, but I might have been blindfolded by looking at it too much.

A big point to consider is actually also: what are the info windows (of all objects) meant to be? I myself like lots of details, so I can analyze and calculate and understand why things are doing like they are doing (hence the many entries now to begin with) as long as I easy can see what's what (and I think I'm on the edge in some cases in the current window). Then there is the opposite corner, that the info window only states whats obvious, i.e. "This is a way".
For beginners to the game, the "this is a way" window might actually be more helpful information than the current version of it, since that helps them keep it separate from ie "this is a railway".
After the first few game sessions, that information is however obvious, and more details are desired instead.
I think a good info window is a window that reaches out to both ends, so some information that might be obvious to experienced gamers is really helpful to beginners as well as some information that might be like the Greek language to beginners makes complete sense to the advanced players. This is also why I have some written out texts in the signal info window if the signal creates directional reservations or if it only clears with two blocks and I wanted to have the text that it protected a junction.

But as also James stated, more people's view would be very nice (thanks vladki and fam )!

[jamespetts]

Thank you very much for the detailed explanation - that is very helpful. May I ask whether anyone else has any views on the subject?

[fam621]

Since your doing that way info business, can I suggest that if possible you could add a metric setting for people who use MPH or KMPH wherever they live.

[jamespetts]

Since your doing that way info business, can I suggest that if possible you could add a metric setting for people who use MPH or KMPH wherever they live.

That is a somewhat different subject - if this were implemented in one place, it would have to be implemented everywhere, and would be quite a job.

[fam621]

Fair enough.

[jamespetts]

Having had only good feedback on this, and having a clear and compelling explanation as to why it is worthwhile, I have now incorporated this (plus a fix to a bug which would cause crashes in some cases).

Thank you very much for working on this - it is much appreciated.

[Ves]

Most welcome! I find it fun to do
Now when it is incorporated, it might also be easier for others to get a view of what the way info window is all about and if they find it helpfull or distractive.

[jamespetts]

Indeed - any further feedback would be appreciated.

Incidentally, I have uploaded base_texts_extended_signals.dat to Simutranslator, so any new translation texts for new/revised features should now go into a different file.