Show convoy capacity in depot

[TurfIt]

Try moving the mouse off the vehicle you're adding and see if that makes more sense. It uses full tiles, but if you're adding a series of half tile vehicles you'll only ever see a half tile free. Suggestions for alternate behaviour welcome... This is one of many things thrown into this patch on an experimental basis. It actually works better than I thought it would, but it does take some getting used to. It could just be ripped back out entirely too.

I honestly have absolutely no idea what to do with the translations, if you care to update the patch as desired...

EDIT: List in post #66 updated to reflect best guess on translations and clarify. Updated patch in #68 - old text left where possible with a comment of what the translation must be. Change requiring simply a \n removed, hardcoded to add the missing instead of translation change.

[Dwachs]

Did not read everything. But:

Please include format specifier in translation string. Some time ago I implemented a check to ensure that format specifiers are consistently translated. Obviously this method needs to know the correct format to begin with.

Try '-debug 2' to see whether there are broken translation strings somewhere.

[TurfIt]

Any news?
I'd rather revert all changes needing translation modifications than let this languish...

[prissi]

I played a little around, especially with the bar below the convoi. Now it is green for max speed always possible, orange if overloaded for some wares and red if always overloaded. One could also think of less severe colors, like yellow for some overloading and ornage for complete. Any thoughs?

The other thing: If a convoi cannot attach any more something, them maybe supppres the next car indicator? (That would be easy, too)

If there is consens, then submit.

[Fabio]

It seems great. I would personally like to see it committed and if needed polished later.

[TurfIt]

I wonder if that's too many features all being done by the speedbar now, but interesting idea. The colors are a bit severe, I have no other suggestion. I say put it out there and see if any feedback comes in.

Suppression done.

I see you've recombined the show all and show obsolete buttons. Some languages now overlap, I've improved it a bit with only russian and slovencina overlapping now, but there's no room for the two buttons and the filter on the line with those langs. Are you ok with the overlap? or revert to the old layout here using an extra vertical line?

What about the rest of the translation changes - ok now? I thought they were the issue...

[prissi]

Actually, I am not sure which you changed and which you did not. After your post I assumed you reverted most of it. For the sake of base.tab (which I can create anyway), what is the current state of translations, please?

[TurfIt]

Updated patch attached. Integrates your new speedbar function, slight color tweak, more dynamic positioning for different languages - less overlapping text.

Current translation state:

Code Select Expand



New: (strings added to code)
"<no schedule set>"
"<individual schedule>"
"<create new line>"
"--------------------------------"
"Can't buy obsolete vehicles!"
"Cost: %6d$ (%.2f$/km)\n"
"Power: %4d kW\n"
"Weight:" - would require 4 different translation entries if format specifiers included
"Capacity:" - see below


Deprecated: (strings no longer in code)
"Move the selected vehicle(s) back to the depot"
"Lines are used to manage groups of vehicles"
"Add the selected vehicle(s) to the selected line"
"Aufloesen"
"%s\nCost: %d$ (%1.2f$/km)\nPower: %dkW\nTop speed: %dkm/h\nWeight: %dt\n"
"%s\nCost:     %d$ (%1.2f$/km)\nCapacity: %d%s %s\nWeight: %dt\nTop speed: %dkm/h\n"


Translation change required: (code has old text as requested, should be translated as follows:)
"Give the selected vehicle(s) an individual schedule" to "Edit the selected vehicle(s) individual schedule or assigned line" - tooltip
"Capacity: %d%s %s\n" to "Capacity: %3d%s %s\n" - could be combined with new Capacity: above if format string not translated.


Old but missing: (in code pre-patch but not in translator)
"1 convoi"
"keine Fahrzeuge" - should never happen - would be a logic error in the code if this is ever displayed.


I can create the base.tab changes after final translations are decided on.

For clarity - I'd revert the translations changes rather than throw the whole patch out, that'd only throw out 75%. I didn't do that yet, need to give you some time to look at things! But even better would be consensus on all the translations...

[prissi]

I also stumbles of weight. Especially since max speed is already handled this way too. I think translationwise it is ok.

[TurfIt]

Could you rephrase that last? I don't understand...

[prissi]

Sorry, "Max Speed:" is handled the same way than weight and is already in the translator. Then it make sense to have also only "Weight:" in the translator.

[TurfIt]

And 'Max Speed:' was also a result of one of my patches I believe, hence I did it wrong back then. At least wrong from the point of view of wanting format specfiers in the translator. Of course 'retire date' and 'intro date' among others are also done without specifiers. It's the inconsistency of it all that's so confusing.

[prissi]

This inconsistencies that comes with 15 year of development. You was at least spared three different dialogue classes and other more severe stuff. Not to mention the source code translation issues.

If the Simutranslator would be a little closer to the programming team, many nice stuff could be realized, like renaming entries or copying. But still it beats any system we had previously for translations. Nowadays, gettext would be the way to go. Another inconsistency, if you want.

But well, time is limited and so better back to ontopic posts

[TurfIt]

Committed at r6048.
base.tab updated - hopefully correctly.
Simutranslator suggestions entered for changed entries.

[Dwachs]

"Give the selected vehicle(s) an individual schedule" to "Edit the selected vehicle(s) individual schedule or assigned line" - tooltip

I would rather create a new entry at the translator site instead of hijacking an old entry. There are translations without active translators, which means wrong translation will persist.

any opinions?

Edit: What is the difference between the new string <individual schedule> and the old <no line> ?  As I understand the action of the entry, it would be better to phrase it <clear schedule>.

[prissi]

I think this is a bug. If you have a convoi with an individual schedule, selecting individual schedule should preserved the existing schedule. Same for create new line. If the convoi has already an individual schedule, create new line should rather copy this schedule to the new line (and of course still open the schedule window).

[TurfIt]

I would rather create a new entry at the translator site instead of hijacking an old entry. There are translations without active translators, which means wrong translation will persist.

any opinions?

I agree. However prissi stated a preference to reuse old strings, and said it's not critical to the dialog; But then stated better new untranslated text than a wrong tooltip. No wonder I'm confused on what's wanted with translator stuff...

Edit: What is the difference between the new string <individual schedule> and the old <no line> ?  As I understand the action of the entry, it would be better to phrase it <clear schedule>.

I thought <individual schedule> was more descriptive than <no line>. Also easy to confuse between a status and an action in the selector. Anyway I added <clear schedule> to make it clear that's what will happen when a line is assigned and that selection is made. Clearer I think.

I think this is a bug. If you have a convoi with an individual schedule, selecting individual schedule should preserved the existing schedule.

Fixed. Although a quick way to clear the schedule is handy...

Same for create new line. If the convoi has already an individual schedule, create new line should rather copy this schedule to the new line (and of course still open the schedule window).

I wouldn't call a missing feature a bug. 
Added.

[prissi]

About translations I propose:
Reuse stuff for critical things in dialiges as much as possible: But if dialoge functions have completely changed, or the working of tools then change related help file names or tooltips. Because those will not help but only confuse. In that cases a missing help might be better that a wrong one.

[prissi]

Bug report:
Built a depot, buy a convoi, create a new line (add stops), then try to change to individual schedule. This entry is not visible but two seperaqtores and scrolling up with arrows will just trigger "create new line". Assigning "individual schedule" is no longer possible. (I could of course edit the schudle and the connection to the line is lost, but this is not helping a beginner).

[TurfIt]

This can happen only when there's a single line. If you have more than one, the last selected line list item will get populated and block selecting create new line. I can't find a way to allow scrolling past the last selected without breaking things worse. Using the mouse always works.

As for inadvertently triggering create new line, I blocked it from being triggered when the droplist is closed. i.e. when selecting using the prev/next buttons. Didn't think of selecting using the keyboard with the droplist open. Only fix I can think of is for the keyboard to not select things until enter is hit. But the whole gui isn't setup for that, everything takes effect immediately.

[prissi]

It did happen with three lines, leaving the last line blank and hiding the topmost "clear schedule" entries. But your corrections have aparently fixed it. Thank you.

I just removed the double seperator, I found this not very elegant.

[whoami]

(So this is the thread about the new depot dialog? At first, I struggled with it, but then found the improvements very useful!)

Some remarks (as tested with r6162; may not even relate to this patch):

1) After opening a drop-down list, the <Escape> key does not do anything: it closes neither the list nor the window, and the latter persists after closing the list with the mouse - it does not close the window any more.

2) Double-clicking on the convoy (tail) to disassemble it completely (feature, right?) does not work reliably on my PC, perhaps the double-click threshold is too short. (Strg-Click shows no different effect.)

3) When setting up e.g. a combined bus and mail truck line: is there a better way than creating the bus line, release the busses, buy a mail truck and then get the line from the list again (should show up as second)? Retaining the line selection for the next convoy would fit me better. It would also be useful for renaming the line after sending out the convoys. EDIT: also, selecting a line and then buying a vehicle clears the line, which I stumble upon rather frequently.

4) When changing the number of vehicles in the view by the buttons "show all"/"show outdated", the scroll bar is not updated.

5) I remember that some time ago, all vehicle types with stored vehicles were shown even without "show all" being selected. I liked that more than the current view, where stored vehicles will be hidden if they cannot be chosen as next item. I think that they should only be hidden whenever a convoy is selected (to be changed) *and* they are incompatible (at this point or at all?).

[prissi]

Mosr issues with dropdown boxes and keys in depots are now hopefully solved. Please test with r6187.

Which scrollbar do you refer to?

[whoami]

If there are more vehicles (to choose from) than fit into the window, then a scrollbar appears. This scrollbar is not adjusted when the number of these vehicles changes. Again, more a Pak128 problem, but also Pak64 should have enough vehicles (without timeline or at a late year) to make this scrollbar necessary.

[Ters]

I think I've seen this with pak64 as well.

[prissi]

r6196 should fix this too. Please test it.

[whoami]

regarding
1): With r6197 Win-SDL (using pak64): ESC still does not close the drop-down list and - after this happened and the list has been closed with the mouse - the window. This does not occur at every attempt, but quite often.
4): fixed

[prissi]

Lists never closed with ESC, at least this key is not processed. YOu can close them by Enter.

[Dwachs]

For the record: I changed to "Cost %6d..." string of the depot window into the new one, introduced with r6293/4.

[TurfIt]

Thanks. Speedy 


---

2) Double-clicking on the convoy (tail) to disassemble it completely (feature, right?) does not work reliably on my PC, perhaps the double-click threshold is too short. (Strg-Click shows no different effect.)

Threshold is hardcoded to 400ms. Rather too long IMHO as it's easy to inadvertantly trigger...
The double click function is also used in text edit boxes to select words, and in the minimap to recenter. Does it work reliably for you in those places?

3) When setting up e.g. a combined bus and mail truck line: is there a better way than creating the bus line, release the busses, buy a mail truck and then get the line from the list again (should show up as second)?

Third item in the line list should be the last selected line. Saves one from having the scroll through the whole list searching again.

Retaining the line selection for the next convoy would fit me better. It would also be useful for renaming the line after sending out the convoys. EDIT: also, selecting a line and then buying a vehicle clears the line, which I stumble upon rather frequently.

Retaining the selection doesn't get along with multiplayer; I don't see an easy way to implement.
I've stumbled across that myself, I think it's from being so used to the old way where selecting the line first was natural. Maybe the line selection should be blocked until a convoi is present?

[VS]

Retaining the selection doesn't get along with multiplayer; I don't see an easy way to implement.

For the record: WTF? I trust you, but that kind of restriction... weird The code gets too complicated for outside understanding!

[prissi]

If there is a last_selected_line bound in said depot, it should be possible to reassign it. This could be done from the depot frame after creation of a convoi. But it would be a hack, since it would involve polling the state and set a waiting line bound flagto be executed in the clear_command_pending() call.

[TurfIt]

I'd tried this previously:

Code Select Expand


Index: simwerkz.cc
===================================================================
--- simwerkz.cc (revision 6198)
+++ simwerkz.cc (working copy)
@@ -6152,6 +6152,13 @@
depot->append_vehicle( cnv, veh, tool=='i', is_local_execution() );
}
}
+ // apply line only after vehicle added
+ if(  depot->get_last_selected_line().is_bound()  ) {
+ cnv->set_line( depot->get_last_selected_line() );
+ cnv->get_schedule()->set_aktuell( depot->get_last_selected_line()->get_schedule()->get_aktuell() );
+ }
+
+
}
}
}

Can't remember what all was wrong with it... (besides a player being able to change last_selected inbetween the command being issued and executed.)

Aside: Should a newly created line get set as last_selected?

[whoami]

---Threshold is hardcoded to 400ms. Rather too long IMHO as it's easy to inadvertantly trigger...

That is true. When I need to just remove two wagons in a train, it may often remove too much. On the other hand, double-click is often not recognized as such (as I wrote).

The double click function is also used in text edit boxes to select words, and in the minimap to recenter. Does it work reliably for you in those places?

The first seems to be OK, but I hardly use it, so there might still be similar glitches (in my environment). Minimap: single-click is enough, double-click does not seem to do anything different.
After testing this, I checked convoy disassembly again in the tram depot (pak64), and it worked perfectly. So I tried again in the train depot, and some (although few) double-clicks were taken as two single-clicks. There may be dependency on high CPU load (for one core), as it appears to behave better in pause mode. The problem might be that the first click removes one wagon/engine, and the second click is applied to the new state (as far as visible to me), yet double-click works most of the time. In Pak128, this might also interfere with non-standard vehicle lengths, because wagons positions may change (in this case, there is also a problem with hitting the right wagon due to clickable panes being misaligned to and having a different size from the wagon image). (This is on WinXP SDL.)

Third item in the line list should be the last selected line. Saves one from having the scroll through the whole list searching again.

This works after selecting a line from the list, but not after creation of a line. (A new line is not entered in the top entries of the list, even if there is no other remembered line, so this is likely not a feature.)

Maybe the line selection should be blocked until a convoi is present?

I would prefer to be able to select a line and then assemble a new convoy for it, if this is possible.