News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

passenger and mail classes

Started by Ves, August 24, 2017, 12:02:46 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ves


jamespetts

Because branch switching takes a little time, I am trying to fix all the significant master branch bugs first; however, I have noted that, and will look into that when I get a chance after I have merged the master branch and your latest work into the passenger-and-mail-classes branch.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

#37
Thank you very much for all your work on this, and apologies that I have not had a chance to look at this earlier. I have now merged and pushed your latest work onto the passenger-and-mail classes branch after merging from the master branch and fixing the bug to which you refer above.

I am in the process of reviewing this, so I may amend this post in due course, but one thing that I notice is that the passenger display always separates passengers by class. It seems to me that this really ought to be optional, as there are many situations when it is more useful to know the total number of passengers than the details of the class; a simple checkbox, perhaps, which, when unticked, reverts to the old behaviour of treating passengers from all classes alike.

Edit 1: I have made one or two minor fixes and changes to some GUI elements. One query, if I may: does the comfort display in the depot window take into account catering? The former comfort display used to show the comfort level with and without the effect of the catering on board a vehicle.

Edit 2: Similarly, it would be extremely useful to be able to see the combined passenger capacity in the deopt/replacer window for each vehicle that a player may purchase.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Quote from: jamespetts on October 20, 2017, 07:40:57 PM
Thank you very much for all your work on this, and apologies that I have not had a chance to look at this earlier. I have now merged and pushed your latest work onto the passenger-and-mail classes branch after merging from the master branch and fixing the bug to which you refer above.

Great! I will check up on that!

Quote
I am in the process of reviewing this, so I may amend this post in due course, but one thing that I notice is that the passenger display always separates passengers by class. It seems to me that this really ought to be optional, as there are many situations when it is more useful to know the total number of passengers than the details of the class; a simple checkbox, perhaps, which, when unticked, reverts to the old behaviour of treating passengers from all classes alike.
This was the trade off from incorporating it directly in the simconvoy_t and simhalt_t instead of in freight_list_sorter_t. A better way overall would be to have it in the freightlistsorter, changing the sort button to a scrolled list and add a bunch of new sort options, but I had to give up on that since I could not figure out all required steps in the freightlistsorter. I think some remains of my attempts are commented out in that file.
Therefore, I initially did not want to do too much work in the sim..-files. I do, however have an idea that should be quite easy to implement that would achieve what you want.

Quote
Edit 1: I have made one or two minor fixes and changes to some GUI elements. One query, if I may: does the comfort display in the depot window take into account catering? The former comfort display used to show the comfort level with and without the effect of the catering on board a vehicle.
I have made the comfort display in the depot window (and elsewhere) follow this syntax:
"Base comfort + catering comfort"
So if the catering car has a comfort of 100 and is a catering car, it would look like:
"100 + 20"
I like to know the logic behind the comfort, and I think doing it this way helps the player see through the mechanism.
What do you think?

Note that the "+20" only comes visible if the cars class matches its catering level.

Quote
Edit 2: Similarly, it would be extremely useful to be able to see the combined passenger capacity in the deopt/replacer window for each vehicle that a player may purchase.
So you mean in the depot window something like:

P_class[0]: 100
P_class[1]: 50
Total: 150

That would actually also solve the overcrowded display issue.

jamespetts

Quote from: Ves on October 21, 2017, 09:17:23 AM
This was the trade off from incorporating it directly in the simconvoy_t and simhalt_t instead of in freight_list_sorter_t. A better way overall would be to have it in the freightlistsorter, changing the sort button to a scrolled list and add a bunch of new sort options, but I had to give up on that since I could not figure out all required steps in the freightlistsorter. I think some remains of my attempts are commented out in that file.
Therefore, I initially did not want to do too much work in the sim..-files. I do, however have an idea that should be quite easy to implement that would achieve what you want.

Excellent - do let me know how you get on or if you have any queries.

QuoteI have made the comfort display in the depot window (and elsewhere) follow this syntax:
"Base comfort + catering comfort"
So if the catering car has a comfort of 100 and is a catering car, it would look like:
"100 + 20"
I like to know the logic behind the comfort, and I think doing it this way helps the player see through the mechanism.
What do you think?

Note that the "+20" only comes visible if the cars class matches its catering level.

This is good except for one issue: the catering level used by each passenger depends on the class of passenger, not the class of accommodation. A wealthier passenger does not buy a cheap meal simply because he/she has decided to travel in a lower class of accommodation. We do need to show the comfort modification for the catering irrespective of the class of accommodation.

Quote
So you mean in the depot window something like:

P_class[0]: 100
P_class[1]: 50
Total: 150

That would actually also solve the overcrowded display issue.

Yes, indeed, that would work well.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

#40
Quote from: jamespetts on October 21, 2017, 08:42:45 PM
This is good except for one issue: the catering level used by each passenger depends on the class of passenger, not the class of accommodation. A wealthier passenger does not buy a cheap meal simply because he/she has decided to travel in a lower class of accommodation. We do need to show the comfort modification for the catering irrespective of the class of accommodation.

Hmm, I dont really understand. Are saying that a p_class[4] passenger riding in a p_class[2] accommodation in a train featuring a catering car level 2 would not get the bonus comfort?
Or do you mean that a p_class[4] passenger riding in a p_class[2] accommodation in a train featuring a catering car level 4 would go and eat in that car, even though he has purchased a p_class[2] ticket?
I did write it a bit clumpsy however and it might just be a misunderstanding:
The +20 will come to all classes at or above the catering level. Should it do something else?
Quote
Yes, indeed, that would work well.
Great! It will be located above the class sections if there are two classes or more!

edit:
clarification

jamespetts

#41
Actually, the comfort modifier of catering is currently class insensitive; however, yes, a class 4 passenger would buy a class 4 meal even if travelling in a class 2 compartment - but this only affects catering revenue, not the comfort modification.

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Ok, so how precisely does the catering affect the comfort in a convoy? I think Im still a bit confused  :P
But I think I then will rephrase the "catering_income_pr_km_(when_full)" to something like "estimated_catering_income_pr_km" to illustrate that it is difficult to predict.


I have now made a button, both in the convoy window and in the halt window.
I do however have one problem:

I wanted the window to remember the state of the checkbox, so you dont have to tick it every time you open a window. I have made what I think is correct, however the state is not saved!
Even so, in the convoy window, the state randomly alternates between checked and unchecked upon opening convoy windows...
suggestions?

the changes are live on my usual github branch (dont touch the translation basefile yet please! :) )

jamespetts

#43
The catering affects the comfort very simply: there is just an increase of a fixed amount in the comfort of the whole convoy when one or more catering vehicles of a given level is added to the convoy. This is separate from the catering revenue.

As to making the state saved, may I suggest using a static variable?

Edit: I have now had a chance to review your latest changes: thank you for that. One bug that I have noticed is that, in the vehicle classes display, when a vehicle has multiple classes, the wrong capacities appear to be shown: if you use the testing saved game that you sent to me and reset the classes on the passenger trains, you will see that the displayed class capacity for each class is only 48 when the class separation display is enabled, whereas it shows it correctly as being >400 when it is disabled.

Another issue with the vehicle class display is that, while it shows something different from the stop classes display (i.e., what class of accommodation that the passengers occupy rather than their underlying class), the display appears to be exactly the same, which is likely to cause players to think that something is wrong when some passengers marked in a stop as "medium" board a vehicle and immediately become "low". Do you think that you could make it clear that different things are being represented here?

Also, I notice that the new checkbox takes away some vertical space from the convoy and halt information windows; could this not be positioned so that it does not do this? The current position reduces the useable window space.

In the depot window, the total capacity display is very useful, but I notice that it is only used when a vehicle has more than one class. It would be much easier to interact with, I think, if it were consistent, and displayed the total capacity even when a vehicle had only one class so that players would have only to look for a single total capacity display for every vehicle. Also, is there any need to have a new translation text, "total_capacity" for this? Would not the existing "Capacity" text be better, to take away the need for this text to be re-translated into a large number of languages?

Thank you again for your work on this - it is much appreciated.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

#44
I must say that the

freight_list_sorter_t::sort_freight(pass_fracht, buf, (freight_list_sorter_t::sort_mode_t)freight_info_order, &pass_capacity, "loaded");

.. is really neat and simple, but oh my god so unflexible! :redx:

"pass_fracht" will mix together all good of the same type, all being passengers = all classes are mixed together resulting in just one block of all passengers.
So, solution seems to be to have one "freight_list_sorter_t::sort_freight( .... )" per class, which works nicely.
Then we also can have different "loaded" text for each class, namely what class the block of passengers belong to.
BUT!!!
the "&pass_capacity" gets totally confused about this and wonders what is going on! the "&pass_capacity" have been told that there are, say two classes of passengers with xx amount in each class, and then it is told to display twice, which now results in four accommodation entries!

So it seems to be a catch 22 here, or am I missing something? I know I really only have very basic programming skills and it has been quite hard for me to sort out how that "&pass_capacity" works, and I think Im not far off in my description.
Trying to do a similar "&loaded" containing different classes text strings, but I dont know enough about it to make it work, and it seems that the ::sort_freight(..) doesnt accept such a value either. And then there would still be the issue with all passengers mixing up...

So I think I will have to dig deaper into the freight_list_sorter anyway .....  :::)

-----

Regarding some of the other issues, I have modified the depot window as you suggested and with the old translations as well.
I had initially also fixed the different display in the vehicles info window, to specify that it was in an accommodation of a certain class, but that had to be revised due to above rant  ;D
The issue with the wrong amount displayed in the vehicle window has also its roots in the above rant and is "fixed" in the sence that the correct numbers is sent to the freight_list_sorter now!

With regards to the catering vehicle, I am not sure how it would be best displayed, but I must say that I lean towards the current implementation, and maybe an additional text in paranthes below the comfort rating in the class manager window displaying when a catering car is present: "(p_class[X] or higher passengers in this accommodation +XX)".
This text would only be visible in accommodations lower than the catering level.
What happens if you put two catering cars of different catering level in the same convoy?

Im sorry about the rant part! Obviously it is designed this way with a purpose and it really only is my own lack of programming skills that creates my frustration. So no hard feelings!  ;D

edit:
Ok, so I have taken the first step on this, and this was, I think, to make the sort buttons in the vehicle and halt info windows into comboboxes. As I am highly likely about to add more sort options, I really think that the push button is making the player loosing the overview (already, I tend to loose the overview and constantly overshoot the sort option I want). I hope that you would agree that this is a good idea  :)
Now it look like this, and I believe it works as it is supposed:



I think that I will remove the classes checkbox again, and incorporate it in the sort options. If I can make it work, we could have a "sort by class amount" and a "sort by class via". Other suggestions?
Other sort options I had in mind could be "sort by commuting/visiting" but first I need to get things running!

The changes, incl the fixes mentioned earlier, are on my github: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/gui-classes

jamespetts

Splendid, thank you for your work on that. One comment at present is that the station combobox is too narrow to fit in the phrase, "destination (detail)" without clipping to the right, so this probably needs widening somewhat.

There does seem to be sense in reducing the number of separate buttons/controls and making the sorting option set into a combobox given the number of options that are now necessary, and your ideas for further options are interesting, too (subject to making sure that there is enough horizontal space to display the text).

---

In relation to the &pass_capacity, I have not had a chance to examine this issue in detail, but I wonder whether you understand quite how passing parameters in this way works? A confusion as to this might be behind the issue.

Let's start from the beginning. Suppose that we have a variable "kittens". We define it thus:


uint32 kittens = 5;


This is very straightforward. If we pass this variable to a function in the normal way:


cuddle(kittens);


then we pass a copy of the variable to the function. The original variable is not changed.

We can alternatively take a pointer of "kittens". This is a variable containing the address in memory of another variable. So, we can have:


uint32 kittens = 5;
uint32 kittens_pointer = &kittens;

cuddle_pointer(kittens_pointer);


Note the following:

cuddle_pointer(&kittens) does the same here as cuddle_pointer(kittens_pointer) and the function signature of "cuddle_pointer" would have to accept a pointer. Thus, for the first example, it would be:



uint32 cuddle(uint32 cuddly_thing)


whereas in the latter it would be


uint32 cuddle_pointer(uint32* cuddly_thing)


In the function itself, to get to the thing being pointed at (in this case, the number 5), we have to dereference the pointer. So, for "cuddle" we could simply say:


uint32 cuddle(uint32 cuddly_thing)
{
    return cuddly_thing + 10;
}


but for "cuddle_pointer", we would have to provide:


uint32 cuddle_pointer(uint32* cuddly_thing)
{
   return *cuddly_thing + 10;
}


In both of these cases so far, the function of "cuddle"/"cuddle_pointer" is identical, and no difference is made when we use the pointer. However, when we pass a pointer (otherwise known as passing the variable by reference, any changes that we make to the variable in the function to which it is passed are permanent. Thus, suppose that we have the following code:


uint32 cuddle(uint32 cuddly_thing)
{
   cuddly_thing += 10;
   return cuddly_thing;
}

uint32 cuddle_pointer(uint32* cuddly_thing)
{
   *cuddly_thing += 10;
   return *cuddly_thing;
}

uint32 kittens = 5;

uint32 result = cuddle(kittens);

cout << kittens;
cout << result;

uint32 pointer_result = cuddle_pointer(&kittens);

cout << kittens;
cout << result"


the output when running this code would be:


5
15
15
15


Indeed, in the case of the cuddle_pointer function, one could simply omit the return value and provide:


void cuddle_pointer(uint32* cuddly_thing)
{
  cuddly_thing += 10;
}

void cuddle(uint32 cuddly_thing)
{
  cuddly_thing += 10;
}

uint32 kittens = 5;

cuddle(kittens)

cout << kittens;

cuddle_pointer(&kittens);

cout<<kittens;


which would give the result


5
15


I suspect that what is happening with pass_capacity is that this is being overwritten multiple times before the output on screen is generated.

---

In relation to catering vehicles, where two catering vehicles of different levels are in the same convoy, the catering vehicle of a lower level is ignored for the purposes of comfort and catering revenue. Really, the only change needed to your implementation here is to show the catering level's effect on comfort in the way that you already do irrespective of the class of accommodation that that vehicle carries (and making sure, if you have not done this already, that this applies to the maximum comfortable journey time as well as the numerical display of comfort.


---

Thank you again for all of your ongoing work on this - it is much appreciated.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Thank you for your detailed explanation. I have read it a couple of times and will need to read it again a bunch of times to better understand how it works and how it can be used.

Yes, the combobox in the halt info is too narrow, and then I had already widened it a bit from original! I will widen it even further, perhaps as wide as in the vehicle info. That depends on how the other buttons behave when window is resized.

jamespetts

Splendid, thank you. Do let me know if you have any more queries about the coding principles to which I referred.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

So, now it is starting to get somewhere:

I have created two new sort modes in freight_list_sorter, by_class_detail and by_class_via. They are essential identical as their normal counterpart, except they are permanently sorted by class. The first sort option looks very much like the sort layout that the version 1 looked like.
This is now online on my github branch and I think there are no bugs in that part.

However, that was the halt window, the convoy window is way more complicated by some reason. First, the same exact culprit-parameter, the &capacity, apparently makes some funnynes together with what code I have written. It makes the class sections in the good window melt together, but do only show a max capacity of the topmost class. Replacing &capacity with a "NULL" in the simconvoy fixes all issues, however, no capacities is written at all.

Which brings me to the real major issue:
Wen a class sorting mode is selected, we want it to sort by accommodations, and not classes. This was easy in simconvoy, as we can count the classes there and fix all issues with that.
In freight_list_sorter, there doesnt really seem to be a way to check where the good is. In fact the only way to check that is to see if a &capacity value is given, and if there is, the cargo is in a convoy of some sort. There is no way to see which classes the convoy has, and even less which passengers are sitting in which classes! I have not found anything in the simware_t either.

Therefore, I would REALLY be happy if there was some way to tell where a package of ware_t is. So... is there?

jamespetts

Thank you for that. I have noticed an issue with the translation, however: I have added translations for the class names to the en.tab for Pak128.Britain-Ex in the passenger-and-mail-classes branch (you might want to fetch the latest version of this and compile it for your testing purposes). However, the translation for the class names do not work in the halt list when they are shown after the details as to whether the passengers are visiting or commuting - instead, the untranslated text is shown. I suspect that this is because you are not translating the exact same string, perhaps translating something that contains a format specifier, instead of using the format specifier to produce a finalised string that is identical to the translated string, and then translating it.

In terms of telling where a ware_t packet is, the only way of doing this is to sort through the vehicles themselves and check which ware_t packets are stored in which arrays. It would take too much computational effort and memory bandwidth to pre-cache this information in every single ware_t packet in the game just for a GUI feature.

Thank you again for your work - it is much appreciated.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

#50
Quote from: jamespetts on October 27, 2017, 09:58:21 PM
Thank you for that. I have noticed an issue with the translation, however: I have added translations for the class names to the en.tab for Pak128.Britain-Ex in the passenger-and-mail-classes branch (you might want to fetch the latest version of this and compile it for your testing purposes). However, the translation for the class names do not work in the halt list when they are shown after the details as to whether the passengers are visiting or commuting - instead, the untranslated text is shown. I suspect that this is because you are not translating the exact same string, perhaps translating something that contains a format specifier, instead of using the format specifier to produce a finalised string that is identical to the translated string, and then translating it.

In terms of telling where a ware_t packet is, the only way of doing this is to sort through the vehicles themselves and check which ware_t packets are stored in which arrays. It would take too much computational effort and memory bandwidth to pre-cache this information in every single ware_t packet in the game just for a GUI feature.

Thank you again for your work - it is much appreciated.

Hmm, that is rather odd as I have tried to make sure that all translations of the classes are done before any formatting to them and cant initially find anything strange with this example. I will check it up though and with a new pakset!

Ok, that is a valid point. I had a thought about adding a new parameter to the sort_freight(....), namely an array of *something* that I could use in the freight_list_sorter. The risk of doing something stupid, if at all working, however, I feel is quite big, so I am hesitating a big bunch before doing that.
Do you have any suggestions as to how to store a list of classes to go along with the good, which I then can pull out in the sorter? Is now a good time to get friendly with the & -sign?

edit
found the translation issue: I translated it one step too early, before i had combined p_class[%u] and the number to replace the %u. Should be solved now!
Wow, after been staring and swearing so much to the untranslated texts, it looks really strange to see something else there now! :P
One suggestion if I may: I think it is very confusing that you have only translated it to "high" "very high" etc. "high-what??" the player will ask. Would it not be a better idea to call it "high class" "very high class", "low class" or in some other way incorporate the word "class" into your translation? The way I have constructed the gui, somehow require the names of the classes to be a little bit self explanatory. Otherwise the translation system would be very unflexible for other languages.

jamespetts

Thank you very much for your fix of this issue: that is much appreciated. I will test this when I have a moment (I am rather preoccupied with other things this week-end).

As to the & sign, there is never a bad time to learn about that: you will need to learn first about pointers generally and then about the special case of references in C++ (which is a somewhat cosmetic modification of pointer syntax, the underlying logic being the same).

In relation to "high", "medium" and "low", etc., these terms were intended to be made clear by their context: "high class" would not be clear on its own, as, in English, that would tend to imply something of fine distinction rather than just people who can afford to travel in Pullman carriages (and, similarly, "low class" would suggest something degenerate, not just people who can only afford to travel by 'bus if at all). "Class: low" or "Class: high" (etc.) would not have these connotations, as they come with the specific stock phrases. The actual translations of the class names should not, however, have to signify by themselves that they are names specifically of classes rather than of anything else.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

I have now had a chance to test this; I found a few bugs which I have now fixed, and I have also made clearer the textual description explaining which classes that passengers/mail are travelling in aboard vehicles.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Sorry for my absence lately, I have had quite alot to do!

I saw your commit on the github, the things are, however, not yet really finish so I dont think there is much point in trying to correct stuff just yet, especially not in the convoy-window :)
I see you rearranged some things in the freight_list_sorter as well, and although your solution looks neater than my original implementation, some functionallity seems to be lost, namely that the classes in the detailed good view dont need to be shown if the good is already sorted by class.

Regarding the translation of the classes, what if you translate the classes like this:
p_class[0]
Class: Low

.. then you get no confusion what is "low", and we dont enforce other translations to have to translate a "Class:" every time it is shown, like in the detailed good view described above?

jamespetts

Ahh, I did not realise that you had not finished: my apologies. Do feel free to re-add any useful feature that you think that I have accidentally removed, provided that it works.

As to the class translations, surely it is more flexible and less redundant to have the names of the classes translated separately from the word describing what sort of thing that they are naming?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

I will try to explain with an example.
Look at how you have translated the way constraints:

Quote from: en.tab
#__________________________________Way constraints__________________________________
#__________________________________Way constraints__________________________________
# Permissive
Permissive 0
DC Third Rail Electrification
Permissive 1
DC Overhead Catenary
Permissive 2
AC Overhead Catenary
Permissive 3
DC Fourth Rail Electrification
Permissive 4
Waterway
# For the DLR - reserved for future use.
Permissive 5
Light rail electrification
Permissive 6
[Unused] Permissive 6
Permissive 7
[Unused] Permissive 7
# Prohibitive
Prohibitive 0
Tramway
Prohibitive 1
Tube tunnel
Prohibitive 2
Barge canal/small river
Prohibitive 3
Tub boat canal
Prohibitive 4
Narrow canal
Prohibitive 5
Ship canal/medium river
Prohibitive 6
Large ship canal/large river
Prohibitive 7
[Unused] Prohibitive 7
Here, you see that the name of the constraints are self explanatory. This means that, if just ever this text appears on the screen we know what *this* is about. So to explain what constraints a vehicle can travel with, you only need this:
May use:
Ship canal/medium river


If, say we play with renaming the constraint of some of the "prohibitive" -rivers to:

QuoteProhibitive 2
Small
Prohibitive 4
Narrow
Prohibitive 5
Medium
Prohibitive 6
Large
... the information would, principally, be the same, but you would need other elements of the GUI just to explain *what* this is. The current translations of the classes makes these extra gui-elements required, because otherwise the classes entries in the gui makes no sense in for the player.
Following the example, we would get a text like this in the depot window:
May use:
Medium


This is why I am concerned with how the classes are translated and what GUI-elements it would enforce.

For pak.sweden, I was considering something like this:
Lyxklass (Luxuary class)
Finklass ("fine" class (dont know if there is a direct translation other than that))
Almänklass ("public"(or similar) class)
etc...

jamespetts

This does get linguistically a little complex, as there is no direct equivalent. The way constraints, importantly, do not say "Constraint: tramway": they just say "Tramway".

The complexity is that, in English at least, the words for describing classes of accommodation ("first class", "third class", "steerage", "tourist class", "business class", etc.) are not the same terms as apply to the description of the people who can afford to travel in each class, for which there are no standard terms. The only way of describing classes is to have a word indicating "class" somewhere and then the names of the individual classes following. It would be very redundant to have the word "class" repeated for each description of each class (and there is no such repetition with the constraints).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

QuoteThis does get linguistically a little complex, as there is no direct equivalent. The way constraints, importantly, do not say "Constraint: tramway": they just say "Tramway".
If I do not misunderstand what you write, this example exactly illustrates what I mean!  ;D
We can indeed say "tramway", and everybody will understand what we are talking about, however the same cannot be said about "low". At least I would not have any clue that it would refer to classes, if I did not read it anywhere else.

I think somewhere that what I clogg myself up about is, that "low" really is only an adjective. Per definition, it requires another word to give meaning at all. In addition, almost everything can be low: people, rates, chairs, amounts, prices, houses, humor etcetc. As it stands in the good view section in the cargomanifest of stations and vehicles, it is just a simply "low", like this:

8 passengers > Railway depot (electric) <228, 24> (Tumpbourgh, commuting, Very low)
So what is very low? their mood? their motivation? their satisfaction? their transfer rate?
It would even be better to use the word "cheap", since its not that many things that are called cheap, like "low", and people generally think of the word cheap in an economic way (I guess), so the step to think of a class to be cheap would not be that far away:
8 passengers > Railway depot (electric) <228, 24> (Tumpbourgh, commuting, Very cheap)
Well, the simple solution seems to simply add a "class:" from the GUI-side everywhere these misunderstandings might happen. But designing a flexible GUI around adjective entries is different than designing GUI around other kinds of entries, like the constraints. Forcing a "class:" down on every language can be very limiting for them and will also feel inconsistent when some parameters have a descriptor and some do not. What comes naturally in english might be quite arbitrary in other languages.
Even though the sentence: "Class: Very low" would not change in size if the "Class: " -part is in the GUI or in the class name, it can really be redundant and take up space in the window in other languages. like in Danish: "Klasse: Luksusklasse" ("Class: Luxuary class") which could have been written much more efficiently omitting "Klasse: ".

To use some other words:
Your translation are telling the rates of the classes, instead of the names of the classes.


But I do understand that it seems to not work grammatically with, say "low class". Also I understand why you want to use the vocabulary "low" "medium" "very high" as it is kind of universal and would apply for all ages. Names like "tourist class" would not look well in the 1800, and "pesant class" would not look good today. Suggestion for changing names dependent on era incoming? ;D
However, some words, like luxuary class, I do not really understand why it could not be called. If a passenger is a luxuary class passenger, he/she would prefer to travel on the luxuary class at any time? Simply put, the passengers p_class[ x ] value is only their prefered method of travel?

But what do you suggest we do then?

jamespetts

The ultimate problem is that there is not a good, simple vocabulary to describe what we want to describe. We either have to specify something like:


Class:
15 Very low
12 Low
25 Medium
1 High
0 Very high


or something like


15 Class: Very low
12 Class:  Low
25  Class: Medium
1 Class: High
0 Class: Very high


The latter is somewhat redundant, although I note that the former might cause difficulties for other languages. Bear in mind that "luxury class" does not really make sense in gameplay terms, as it is quite possible for a very low comfort vehicle to be assigned to a high class (Concorde, for example, was cramped compared to even economy class on contemporary airliners, and early aircraft such as the Ford Trimotor were really very uncomfortable compared to luxury carriages on railways, but wealthy passengers used them because of their great speed advantage).

One possible modification is to use the word "Wealth" when describing passengers and "Class" when describing different accommodation in vehicles, which might at least alleviate the confusion between the use of these terms in the vehicle and stop windows. This would, of course, necessitate the splitting of the terms that describe each class/wealth level from the terms that describe whether it is a class or wealth level, to give this sort of result:


Wealth:
15 Very low
12 Low
25 Medium
1 High
0 Very high


and



Class:
15 Very low
12 Low
25 Medium
1 High
0 Very high


with the "Wealth" and "Class" translation texts being distinct from the "Low", "Medium", etc. translation texts for the descriptions. How well would this translate to Swedish, do you think?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

The first example you give is obviously much better looking than the second example, so I understand the reason not to use "class: very low" as the translation.

Quotewith the "Wealth" and "Class" translation texts being distinct from the "Low", "Medium", etc. translation texts for the descriptions. How well would this translate to Swedish, do you think?
Do you mean that you would just call it classes and wealth instead of just only classes, but the actual class names are still "Low", "medium"?
I dont think that changes anything, since you would still end up with "low"-what? in certain gui-elements.
My example changed the name from "low" to "cheap". The list of names could be something like this:

Very cheap
Cheap
Economic
Expensive
Very Expensive

Admittedly, translating it to such, although it might help the player understand what he looks at more than "Very low", "Low" etc, might as well confuse the player into other misunderstandings about the class system.

We could do a compromize, where we make two sets of translations: One set is for all places where there is no doubt what it relates to, and the other set needs a more fullfilled name (ie. "Class: Low") to places where confusion might arize? So each class would have this: p_class[ x ] (short version) and p_class[ x ]_full_name (long version).
With this, you would be able keep the "Low", "High" and other languages could do that as well, or they could have more like real class names, making any clarifications unnecesary for them.
Only downside is that it gets more complicated to maintain, as well as more translator-work...

jamespetts

The idea is that the GUI would always indicate, using the words "Class" or "Wealth" (which would be separate, specific translation texts) to what the names "low, "very high", etc. are referring. "Cheap" and "expensive" makes no sense, as this would not meaningfully refer to the passengers themselves rather than the accommodation (and in any event, it would be more elegantly expressed as "Price: Very low", "Price: High"). A system in which the reference to the kind of thing that is low or high (etc.) is part of the very same text as the low or high itself, even in only some places, will always result in the sort of inelegant duplication seen in the second example in my previous post.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Incidentally, I have noticed an issue with the UI for buildings: in all town buildings, there is a display of "visitors_from_this_building" and "commuters_from_this_building". However, this does not correctly represent the position.

For residential buildings, there needs to be a single display showing the same data as for "visitors_from_this_building" currently. This should be labelled "Passenger wealth", "wealth of passengers residing here" or similar.

For non-residential buildings, the existing two displays need to be retained, but the labels need to be amended, as "visitors/commuters from" the building makes no sense for destination buildings. "Wealth of visiting/commuting passengers demanded" or similar would be a better description.

For industries, there is currently no information given about class proportions, which is where it might be especially helpful for players, particularly given the importance of the logistics feature.

Thank you again for your work on this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

#62
Are you sure you want to use the word "wealth" for passengers? Will it not be confusing when passengers is sorted by "wealth", but the vehicles has "classes"?

Anyway, I will take a look at the issues!

In the industries window, I have to remake parts of the window in order to show the classes, I will start on that as soon as possible!

In order to save space in the building window, what about a syntax like this:

wealth of visitors (commuters):
20% (10%) Very low
30% (45%) Low
35% (30%) Medium
etcetc...

or:

wealth of visitors/commuters:
20%/10% Very low
30%/45% Low
35%/30% Medium
etcetc...

.. that would help alot in the industries window!

edit:
Maybe also make the window a bit more intelligent:
If "Visitor demand: 0", we dont need to show visitors classes
If "Jobs: 0" (that is, there is no jobs in this building), we dont need to show commuters classes
makes sense?

jamespetts

The idea is that it will be less confusing, as a passenger of one level of wealth might board a different class in some circumstances, so it would be very confusing if they were represented to be identical, as it is important for players to be able to distinguish between these two importantly distinct concepts easily.

I do not think that "wealth of visitors" is a good phrase here, as this implies that what is being represented is the wealth level of the passengers who have in fact visited in the past: "wealth of visiting passengers demanded" avoids that problem by describing what is being displayed accurately. Certainly, it would make sense not to repeat the phrase and to have

"10% Very low
20% Low
20% Medium..." (etc.)

after that designation. Were you asking more about compacting visitors/commuters? The first example seems to me to be apt to confuse (it is not clear what being in brackets designates). The second is slightly better, but it is still not absolutely clear that what is being referred to in each line is, in turn, the wealth of visiting passengers demanded then the wealth of commuting passengers demanded. I think that it would be clearer just to have two separate lists where applicable, although I definitely agree that, where there is no visitor or commuter demand, the respective section should be omitted.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

While it might be more obvious with separate lists, the information will take up double amount of space. In some windows, there might already be a very long list of other things (industry windows shows consumers, suppliers and list of goods), so having a 13 row long section of class information will be heavy in the window. I think the second one of my suggestions will work just fine, and then translate the description to:
"Wealth of demanded visitors / commuters:"
This is even more important if new features requires even more information in the windows.

jamespetts

I see the point about compactness of windows. I suppose that, ideally, one would have a tabulated display with columns, but I imagine that that would be much more difficult to write?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

I have putted together a variant looking like this:


I could not find a building with only visitors and no workers, which is also not a residental house.

Suggestion:
Renaming "passengers" to "residents" in the RES-building?

Question:
What does the  "Passenger success this year (visiting)" actualy mean? Is it residents of this building finding a destination? or is it a combination of residents of this building and visitors to this building?
I get confused when the same parameter (say, the get_passenger_success_percent_last_year_visiting()) returns a percentage of 100%, while the "passenger_success_percent_last_year_visiting" returns a number.
Personally I would like it to stay plain numbers and no percentages.

Lastly, what appears to be a bug:
In the "Sawmill" window, the "commuters this year" returns a strange number. The code is duplicated from the buildings window.

jamespetts

Splendid, thank you for your work on that. In respect of the industry commuters: these are processed differently for industries, and players need to refer to the graphs to see the number of commuters, so the "Commuters this year" line needs to be removed.

To answer your question, "Passenger success this year (visiting)" refers to the proportion of visiting passengers generated by the building that have successfully completed their journeys this year (and the same applies to the equivalent for commuting passengers and the previous year). It is only relevant to passengers generated by that building, and is not affected by passengers visiting that building.

I agree with your suggestion of renaming "passengers" to "residents".

Thank you again - this is all most helpful.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Hmm, then I think the numbers doesnt match somehow:
Visitor demand: 2
Jobs: 126

.. so you would expect these figures to somehow show up in the charts. However:
The passenger demand diagram says: 12, and have been doing that for alot of months.

So something is not scaling properly.
Also, it doesnt say in the charts wether we talk commuters or visitors.
Technically, commuters (filling the job slot) are the ones that should fix the boosts, however, visitors should also do that for some industries, like shops etc.
How is all this related, or is it not really related yet?

I would be really happy if we could display the "commuters this year" benieth visitors (as in the screenshoot), since this would give the player a very good overview instead of looking in the charts.
Is this not possible at all?
edit:
Also, not to forget, the player is used to be able to see "commuters this year" in other buildings.

jamespetts

The factory system is quite complex, since the boost system introduced in Standard some time ago does not fit well with the passenger generation system introduced in Extended in circa 2013; however, plans to reform the boost system radically will need to wait before being implemented, as this would be a huge amount of work.

I did spend quite a considerable amount of time recently looking into the calibration of industry passenger demand and fixing quite a number of bugs, but this was a few months ago now, and I can no longer remember all of the details. You can always look back at the Git commits a few months ago to find what I modified as far as industry passenger demand was concerned.

If you really want to have a "Commuters this year" display, you could always just take the information from the graphs (or, rather, from the data that comprise the graphs).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.