News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

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

Hi James,

I wonder how this works exactly:

A passenger enters a vehicle, lets say it is a p_class[3] passenger enters a p_class[3] class, but the compartment is a reassigned p_class[2] compartment.
Does the passenger know it is sitting in a p_class[2] compartment, or does it only know that it is traveling in a p_class[3] class?

I would very much like to know in which COMPARTMENT the passenger travels, so I can display it correctly in the convoy details window. Currently, I can not get that functionality to work (if it is even possible) with the result of either the passenger manifest disappear when changing class, doubles up when a vehicle has two compartments with the same class, or nothing is displayed at all.
Also, how does the passenger know which compartment to put himself in when two compartments have the same class but different comfort? I would asume that the passengers would put them self in the compartment with the highest comfort in such cases, but they appear to sit a bit random.

Also, I think there is a bug in this part of the simvehicle.cc:
uint16 vehicle_t::get_total_cargo_by_class(uint8 g_class) const
{
// Take into account class reassignments.
uint16 carried = 0;
for (uint8 i = 0; i < desc->get_number_of_classes(); i++)
{
if(class_reassignments[i] == g_class && desc->get_capacity(i) > 0)
{
carried += fracht[i].get_count();
}
}

return carried;
}


It does not produce any number, and comparing it with the get_freight_info(), I have tried with this instead, which appears to work:
uint16 carried = 0;
if (desc->get_capacity(g_class) > 0)
{
if (!fracht[get_reassigned_class(g_class)].empty())
{
FOR(slist_tpl<ware_t>, const& ware, fracht[get_reassigned_class(g_class)])
{
carried += ware.menge;
}
}
}
return carried;


although that creates the errors I mentioned above.

There is a new version, available here: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/passenger-and-mail-classes-gui-combolist
However, the convoy details window is currently a bit buggy with flashing displays. I wont fix that now until I have resolved the issues I mentioned above.

jamespetts

Quote from: Ves on August 24, 2017, 12:02:46 AM
Hi James,

I wonder how this works exactly:

A passenger enters a vehicle, lets say it is a p_class[3] passenger enters a p_class[3] class, but the compartment is a reassigned p_class[2] compartment.
Does the passenger know it is sitting in a p_class[2] compartment, or does it only know that it is traveling in a p_class[3] class?

If things are working correctly (if there are errors, I should be grateful if you could post a full bug report), the reassignment means that the original (default) class designation is irrelevant, and all that is detected by either passenger choice or revenue calculation is the new, reassigned class.

However, if you are writing new code interfacing with this, you will need to make sure to use the class reassignments array every time that you access vehicle class data (I cannot remember immediately whether this is already automatically implicit in methods returning class data - I think that it may well be in at least some cases, but you should check).

QuoteI would very much like to know in which COMPARTMENT the passenger travels, so I can display it correctly in the convoy details window. Currently, I can not get that functionality to work (if it is even possible) with the result of either the passenger manifest disappear when changing class, doubles up when a vehicle has two compartments with the same class, or nothing is displayed at all.

When a vehicle has two sets of accommodation ("compartments"; but this is misleading, as the term "compartment" has a very specific meaning in the context of railway carriages which is not consistent with usage here) of the same class (which will only happen when one or more has been reassigned), surely the passengers should all simply be shown as being in accommodation of that class? I did not set up the data structures to distinguish between accommodation that was originally of, say, class 3 reassigned to class 2 and accommodation that was originally of class 2. All that is relevant is the currently assigned class of accommodation.

QuoteAlso, how does the passenger know which compartment to put himself in when two compartments have the same class but different comfort? I would asume that the passengers would put them self in the compartment with the highest comfort in such cases, but they appear to sit a bit random.

There is no decision mechanism here, and it is indeed random, just as it was before classes were introduced when a train had carriages of different levels of comfort: the comfort levels were simply averaged. Bear in mind that only an experienced passenger will work out which carriages are more comfortable in that situation.

Quote
Also, I think there is a bug in this part of the simvehicle.cc:
uint16 vehicle_t::get_total_cargo_by_class(uint8 g_class) const
{
   // Take into account class reassignments.
   uint16 carried = 0;
   for (uint8 i = 0; i < desc->get_number_of_classes(); i++)
   {
      if(class_reassignments[i] == g_class && desc->get_capacity(i) > 0)
      {
         carried += fracht[i].get_count();
      }
   }

   return carried;
}


It does not produce any number, and comparing it with the get_freight_info(), I have tried with this instead, which appears to work:

uint16 carried = 0;
if (desc->get_capacity(g_class) > 0)
{
   if (!fracht[get_reassigned_class(g_class)].empty())
   {
      FOR(slist_tpl<ware_t>, const& ware, fracht[get_reassigned_class(g_class)])
      {
         carried += ware.menge;
      }
   }
}
return carried;


although that creates the errors I mentioned above.

The error appears to be the counting of the number of packets of passengers/mail without taking into account the number of units inside those packets. I have pushed a fix for this error, and used this corrected method instead of the "class_compartment" method that you had written. I have not had a chance to test this other than briefly, however: I should be grateful if you could check whether this works.

I should note, however, that the method as I had originally written it did produce numbers: just not quite the right numbers as described above.

Quote
There is a new version, available here: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/passenger-and-mail-classes-gui-combolist
However, the convoy details window is currently a bit buggy with flashing displays. I wont fix that now until I have resolved the issues I mentioned above.

Thank you for this. I cannot see any flashing displays, but I do notice that the passengers are not properly summed/condensed in their descriptions, e.g.

"2 passengers > King's Cross
3 passengers > King's Cross
1 passenger > King's Cross
2 passengers > Finsbury Park
4 passengers > Finsbury Park"

instead of

"6 passengers > King's Cross
6 passengers > Finsbury Park"

Thank you very much for your ongoing work on this, incidentally: 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.

passengerpigeon

Dear Jamespetts,
When passenger classes are implemented in Simutrans, how will single-class vehicles be handled? Will there be a special parameter that allows vehicles like city buses to carry passengers from any class in varying quantities, or will first class passengers not take short distance transport at all, instead travelling to long-distance rail stations/airports by car? Also, is the implementation of classes intended to resolve the current unrealistic situation whereby every passenger can afford air travel on any route? For example, if I set up a flight and a long-distance coach line between the same two stations currently, nobody will ride the coach. If, however, Economy Class air travel was coded in as one class higher than the bus, people would use both forms of transport. Is this intended to be the case?
Thank you,
Passengerpigeon.

Rollmaterial

Lower-class vehicles will be able to carry higher-class passengers. Avoiding every passenger travelling solely by air is the very purpose of the feature.

jamespetts

As Rollmaterial wrote, passengers of a higher class will always be able to travel in lower class transport without any special parameters. By default, 'buses will be configured to accept the lowest class of passengers, so all will be able to travel.

Higher class passengers will be more likely to have access to a car. At present, private cars can only be used to make complete journeys. However, a car parking/park and ride feature is planned (although it may take some time to implement unless more people are able to assist with coding) that will allow passengers to make part of their journey by car and part of their journey by player transport.

As to the latter question, the simple answer is "yes".
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 August 24, 2017, 12:58:32 AM
If things are working correctly (if there are errors, I should be grateful if you could post a full bug report), the reassignment means that the original (default) class designation is irrelevant, and all that is detected by either passenger choice or revenue calculation is the new, reassigned class.

However, if you are writing new code interfacing with this, you will need to make sure to use the class reassignments array every time that you access vehicle class data (I cannot remember immediately whether this is already automatically implicit in methods returning class data - I think that it may well be in at least some cases, but you should check).

When a vehicle has two sets of accommodation ("compartments"; but this is misleading, as the term "compartment" has a very specific meaning in the context of railway carriages which is not consistent with usage here) of the same class (which will only happen when one or more has been reassigned), surely the passengers should all simply be shown as being in accommodation of that class? I did not set up the data structures to distinguish between accommodation that was originally of, say, class 3 reassigned to class 2 and accommodation that was originally of class 2. All that is relevant is the currently assigned class of accommodation.

Well, yes you are right that all passengers show up as "that class", however, since we now have two accommodations with the same class, the passenger manifest for both accommodations shows the combined capacity. get_capacity_by_class() doesnt think of accommodation at all what I can see?
If you change a class on a running vehicle (open convoy detail and click the new button class manager), the passenger manifest will either disappear, or merge with similiar entries, dependent on wether you set it to a new class or a similar class as an existing one.

Quote
There is no decision mechanism here, and it is indeed random, just as it was before classes were introduced when a train had carriages of different levels of comfort: the comfort levels were simply averaged. Bear in mind that only an experienced passenger will work out which carriages are more comfortable in that situation.

Quote
Thank you for this. I cannot see any flashing displays, but I do notice that the passengers are not properly summed/condensed in their descriptions, e.g.

"2 passengers > King's Cross
3 passengers > King's Cross
1 passenger > King's Cross
2 passengers > Finsbury Park
4 passengers > Finsbury Park"

instead of

"6 passengers > King's Cross
6 passengers > Finsbury Park"

Thank you very much for your ongoing work on this, incidentally: it is much appreciated.
Thanks, I will look into that!

jamespetts

Quote from: Ves on August 26, 2017, 06:23:12 AM
Well, yes you are right that all passengers show up as "that class", however, since we now have two accommodations with the same class, the passenger manifest for both accommodations shows the combined capacity. get_capacity_by_class() doesnt think of accommodation at all what I can see?
If you change a class on a running vehicle (open convoy detail and click the new button class manager), the passenger manifest will either disappear, or merge with similiar entries, dependent on wether you set it to a new class or a similar class as an existing one.

This is intended, as there is no use in a player having to add up two different entries of the same class to see how many passengers of any given class are travelling: this is similar in a way to the second issue reported with multiple passengers for the same destination.
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 August 26, 2017, 10:38:06 AM
This is intended, as there is no use in a player having to add up two different entries of the same class to see how many passengers of any given class are travelling: this is similar in a way to the second issue reported with multiple passengers for the same destination.
Hmm, to be honest, I dont think it matters that the player have to add up different entries of the same class to see how many passengers of a given class are travelling in one vehicle. Showing the amount of same class passengers on a per vehicle basis, I think is fine if it is not possible on a per accommodation, but it is much less overview friendly I think. Remember that we need to show both which class the passengers are traveling in as well as the class the passengers MAY be traveling in. I do plan to show the sum of alll travelers of a given class in the cargo manifest in the convoy window, so this amount should already be known. As this is the detailed convoy window, detailed information is appreciated, I would consider this to be worth showing.

I do have to rethink the design if it wont be possible. As you can see in the current convoy details window, I wanted to show the manifest in the accommodations sections, which would mean:
It saves space in the window, since I otherwise have to add a manifest section below the accommodations section as well as spacing sections to keep an overview.
It would not require duplicate information, like how many passengers a class can hold (ok, semi true, since you would have to manually add up the amounts in the accommodations), or which class the passengers are traveling on (we would have to show the class names again). It can quickly become alot of "class" names around, just look at these screenshots (the pictures are captured at different times, so the manifest is different):

combined class manifest:

I did just mock it together in msvs, and I just noticed there is a bug in the code, which makes the entries show twice. It might be a little more streamlined, like not showing a class if it is not used.

separated class manifest:

This is how I would want it to look. It works in all cases, except if two accommodations are the same.

Another thing to consider is this:
When a class is reassigned, all travelers from that class turns invincible, which is because they are shown per class, so when changing the class to something else, we thereby are not showing passengers of that old class any more.
I dont know how it is treated in the code when you change the class on the fly. Passengers obviously keep their old class, but will they get of the train at the next stop or will they keep their seat for the entire jurney?
One can think of multiple solutions to this:

Easiest solution is to remove the class manager button from the vehicle details window, so you cant reassign classes outside the depot, but that is a shame I think.
Alternatively, if we make it possible to show the manifest on a per accommodation basis, a check would be run and a text appear in the manifest that the class is reassigned but current passengers keep their class
If it wont be possible to show the manifest on a per accommodation basis, we could still check if there are some passengers that are traveling on another class than what should be available, showing both the passengers and the previously mentioned text in the manifest.

jamespetts

Quote from: Ves on August 26, 2017, 06:16:35 PM
Hmm, to be honest, I dont think it matters that the player have to add up different entries of the same class to see how many passengers of a given class are travelling in one vehicle. Showing the amount of same class passengers on a per vehicle basis, I think is fine if it is not possible on a per accommodation, but it is much less overview friendly I think. Remember that we need to show both which class the passengers are traveling in as well as the class the passengers MAY be traveling in.

Would this not adequately be achieved by showing the actual class of the passengers? Although I should note that this information would not ordinarily be available to a transport provider, of course: the difference between those who are able to pay more but choose not to do so and those who are unable to pay more is usually invisible to a business, although I note that it is customary in computer games to provide the player with more information than one would normally expect to have.

I should note that the idea always was that the default assignment of accommodation of vehicles to classes was always intended to be no more than a suggestion to the players in any event - a reasonable default that a sensible player would be most likely to choose in most situations. The idea is simply to minimise the amount of work that a player needs to do compared with, for example, having all accommodation always at class 0 by default, or having it in some indeterminate state which players would then have to customise manually before using the vehicles (and it was easier to program than the latter, too).

Therefore, showing the original, default assignment of classes to different parts of a vehicle's accommodation would not seem to be particularly useful; what use had you intended for this information, other, perhaps, than showing what pressing "reset all classes" will do?

However, am I missing something, or have you already got the original default classes shown in the first of the two screenshots below...? I must confess, I am a little unclear on what exactly you want to achieve.

QuoteI do have to rethink the design if it wont be possible. As you can see in the current convoy details window, I wanted to show the manifest in the accommodations sections, which would mean:
It saves space in the window, since I otherwise have to add a manifest section below the accommodations section as well as spacing sections to keep an overview.
It would not require duplicate information, like how many passengers a class can hold (ok, semi true, since you would have to manually add up the amounts in the accommodations), or which class the passengers are traveling on (we would have to show the class names again). It can quickly become alot of "class" names around, just look at these screenshots (the pictures are captured at different times, so the manifest is different):

combined class manifest:

I did just mock it together in msvs, and I just noticed there is a bug in the code, which makes the entries show twice. It might be a little more streamlined, like not showing a class if it is not used.

separated class manifest:

This is how I would want it to look. It works in all cases, except if two accommodations are the same.

I must confess, I am having trouble following this. Is the second screenshot what you are trying to achieve? Am I missing something, or is the only difference layout? I am afraid that I am having trouble spotting what is different in terms of the actual information in the second version.

Quote
Another thing to consider is this:
When a class is reassigned, all travelers from that class turns invincible, which is because they are shown per class, so when changing the class to something else, we thereby are not showing passengers of that old class any more.

Surely this is how it would be for a real transport business, as explained above?

QuoteI dont know how it is treated in the code when you change the class on the fly. Passengers obviously keep their old class, but will they get of the train at the next stop or will they keep their seat for the entire jurney?

The passengers will not move once they have entered a particular class in the current code. It occurs to me that this could lead to an exploit of players changing the class of accommodation just before convoys reach their stop to increase the revenue. This cannot be fixed by moving the passengers to a lower class of accommodation, as the convoy might no longer have a lower class of accommodation.

Careful consideration is necessary as to how to fix this exploit: perhaps the increasing of a class should not be able to be done when there are passengers in the accommodation and there is no lower classed accommodation to which they can move.

Quote
One can think of multiple solutions to this:

Easiest solution is to remove the class manager button from the vehicle details window, so you cant reassign classes outside the depot, but that is a shame I think.

I agree that this should be retained if possible, subject to remedying the exploit as described above. It would be most inconvenient for players not to be able to do this outside a depot.

Quote
Alternatively, if we make it possible to show the manifest on a per accommodation basis, a check would be run and a text appear in the manifest that the class is reassigned but current passengers keep their class
If it wont be possible to show the manifest on a per accommodation basis, we could still check if there are some passengers that are traveling on another class than what should be available, showing both the passengers and the previously mentioned text in the manifest.

Because we do not know whether any given passenger travelling in any given class of accommodation would have purchased a higher class ticket if he/she could have afforded to do so, I suggest treating all passengers in a given class of accommodation as being not in a position to pay a higher fare than that associated with that class for the remainder of their journey, whatever their underlying class. This is the most realistic solution, I think (passengers would buy their tickets in advance, after all) and one that is the least prone to exploits.
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 think I can see what you mean:
You mean that it might not be necessary to show the individual accommodations in the vehicle details window at all? In that case, I follow what you mean and there is indeed no point of showing passengers on a per accommodation basis.

However, just to clear somethings out as I might have been unclear:
The two screenshoots are different:
The first image was my suggestion on how to show a combined manifest below the accommodations section.
The second image was my idea of how I wanted it to look. You can see there is a manifest per accommodation, although there where no p_class[1] passengers at the time of the screenshoot. If there where, there would be a manifest below the p_class[1] entry as well.

The amount of information are the same in the two screenshoots, it is only the layout that is different. My personal view is that the first screenshoot is too cloggy, it is difficult to see what is what and relative little information takes alot of space, if you understand what I mean.
The problem with my idea, and the reason to this discussion is, I did not succeed for all circumstances, namely when the two compartments shares the same class.


But I will try and make a version where there is no information about specific accommodations of a vehicle, only which classes are held by a vehicle. I might add a note about how many compartments is in the vehicle, as I still believe this is usefull information for a player.


As to the other issue with reassigning classes on the fly, since passengers apperently keep traveling on the same class as they entered the vehicle, there would be no exploit?
My problem with it was that the passenger manifest for the compartment would be empty when reassigned, but this should not be an issue when I make the new window I think.

Ves

#11
I have a new window design which I am happy with, and I am having some real brainexcercises by trying to figure out how some of the things work (including spelling to brain excercises!)
I have another suggestion for the get_total_cargo_by_class() in vehicle_t. The previous did not produce consistent results I think, so I have looked at how it is done in the simconvoy.cc for the get_freight_info() and made some modifications.
Could you have a look and see if you think this is sensible?


uint16 vehicle_t::get_total_cargo_by_class(uint8 g_class) const
{
uint16 carried = 0;
{
for (uint8 j = 0; j < desc->get_number_of_classes(); j++)
{
if (j == g_class)
{
FOR(slist_tpl<ware_t>, ware, fracht[j])
{
if (ware.menge != 0)
{
carried += ware.menge;
}
}
}
}
}
return carried;
}


edit: added brackets {} that where missing and removed wrong comment // in the code

jamespetts

Thank you for your work on this.

Looking at the second post first, I am not sure that I understand what this code is intended to achieve: it does not have any regard to the class reassignments (despite the comment that it does have regard to that remaining in place). So, if a vehicle's class 4 accommodation had been reassigned to class 3, for example, the method above would incorrectly produce a non-zero number when the parameter g_class passed to it equalled 4. In fact, the vehicle would have no class 4 accommodation because the accommodation that was by default class 4 had been reassigned to class 3, so it should return zero in this case. That is the purpose of the line:


if(class_reassignments[i] == g_class && desc->get_capacity(i) > 0)


We need to use

class_reassignments[i]


rather than just i alone in order to match the class as reassigned correctly. Does this make sense? I wonder whether what might be a misunderstanding about how class reassignments are intended to work might have affected your position in respect of the earlier post, too?
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

#13
Just to note, however, I had misplaced a pair of brackets, which should be after the line "if (j == g_class)".

We should already know which class we want to see the cargo for. Therefore, using the class_reassignments is redundant, since that has already been done on beforehand when calling the tool. The comment was an old one which I had forgot to remove.
Since the name "get_total_cargo_by_class(g_class)" implies that we can get the amount of cargo from any class that is put in as g_class, it is also not good I think to tie it to the desc->get_capacity(i), or even just get_capacity(i) (without the "desc->") because if the class has been reassigned, the entry will show 0. That was my problem earlier, that I could not just simply ask for "give me class [2] passengers" even though there would be no class [2] compartment. With this implementation I can do that.

I was however quite puzzled when I experimented with this:
the fracht[ i ] appears not to work with the maximum possible amount of classes of the goodtype, but only with the max amount of classes for the vehicle. Therefore I am using the
desc->get_number_of_classes() in the for loop, even though i feel it should really have been the maximum number of classes for either passenger or mail, but when I use that in the for loop, it crashes when I try to call a higher class than what is in the vehicle.

In the current implementation, I noticed that there might be some water rings effect of having this change, for instance, I have problems when reassigning a p_class[0] to anything higher. It wont take any load. I guess that might be because I use the "desc->get_number_of_classes()".

Can the fracht[ i ] perhaps be modified to work on the max number of classes in general, instead of per vehicle?
If this all these changes in get_total_cargo_by_class() would create other rings in the water (which I dont know of), maybe have two different versions of it? One which is your original, and one which is my version?

jamespetts

I still think that there may be some confusion here as to how class reassignments are intended to work. I also note an error of my own in the algorithm for loading passengers, which I have just fixed, which might have accounted for at least some of the confusion. Perhaps a worked example will help. Let us imagine an aircraft with two classes: tourist class and first class. By default, tourist class is class 2 and first class is class 4. The array of capacities would be thus:

capacity(0) = 0
capacity(1) = 0
capacity(2) = 100
capacity(3) = 0
capacity(4) = 20

By default, our class reassignments array would be

class_reassignments[0]=0
class_reassignments[1]=1
class_reassignments[2]=2
class_reassignments[3]=3
class_reassignments[4]=4

Now, suppose that we want to reassign class 4 to class 3 and class 2 to class 1. Our class reassignments array would now be:

class_reassignments[0]=0
class_reassignments[1]=1
class_reassignments[2]=1
class_reassignments[3]=3
class_reassignments[4]=3

The capacities should thus be:

capacity(0) = 0
capacity(1) = 100
capacity(2) = 0
capacity(3) = 20
capacity(4) = 0

Does this make sense? Have you found that it does not, in fact, work like this, or did you not understand that it should work like this?

I should note, incidentally, that I am going on holiday to-morrow for just under a week, so I might not be able to respond in much detail until my return.
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

Thanks for the explanation! I think I understand it and it seems to make sense.
I think that also works as expected from what I have seen.

What I am looking for is this, and I will use your example:

Originally the plane have this capacity:
Capacity(0) = 0
Capacity(1) = 0
Capacity(2) = 100
Capacity(3) = 0
Capacity(4) = 20

Now the plane is filled up to 100% load into those classes. During the middle of the cruise, you decide to reassign the classes as you described.
The passengers, however, are still traveling on their original classes, and should be found like this:

Get_cargo_by_class(0) = 0
Get_cargo_by_class(1) = 0
Get_cargo_by_class(2) = 100
Get_cargo_by_class(3) = 0
Get_cargo_by_class(4) = 20

But I cannot make this work in the original implementation of Get_cargo_by_class(). Instead, it requires the class I am checking for cargo to also be a class with a capacity more than 0.
This is where my problem is at.

jamespetts

There are no variables set aside for remembering what class that any given accommodation was before the last reassignment, or whether any given passenger boarded before or after any reassignment took place. That would be extremely complex to implement and might impact performance.

Instead, if classes are re-assigned when passengers are in transit, the passengers will need to move classes if they can to match the class that they boarded. If they cannot move classes, when the revenue is calculated, the minimum of the passengers' underlying classes and the class (as reassigned) of their current accommodation should be used.

Does this make sense?
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

ah, ok then I think I have misunderstood something. I was under the impression that the passengers would keep their class even though you reassigned it by this comment

Quote from: jamespetts on August 27, 2017, 09:21:59 PM
The passengers will not move once they have entered a particular class in the current code.

If that is not the case, I am afraid that I do not dare to code anything that is beyond the GUI parts, as it would be very likely to spawn errors that I dont understand. Otherwise, do you have any suggestions as to which elements of the code I need to use to find the "hidden" passengers?

jamespetts

I may have been unclear about what happens to passengers when the class is reassigned: my apologies. As things currently stand,

(1) the revenue per passenger is based on the class of accommodation in which they are situated when they arrive at their departure point; and
(2) when the class of reaccommodation is re-assigned, no changes are made to the passengers who are travelling.

There are thus never any hidden passengers.

However, this is a problem, as this can give rise to an exploit, allowing players to increase the class during a journey, permitting players to earn more money from passengers than their class permits.

I had suggested a system in which passengers would be moved to lower class accommodation (if available) if the class increases during their journey, and that in any event, the revenue for any given passenger should never exceed that of the passenger's underlying class. This has, however, yet to be implemented.

Does this clarify anything?
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

#19
Ok, but I don't understand how it is an exploit if the passengers who are traveling keep their class if you reassign it just before the arrival. Or is it plainly what the accommodation class at arrival that decides how much money is made?

jamespetts

It is at present just the class of accommodation that determines the revenue (if I remember the code correctly, in any event).
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, now I understand! I will wait with coding further gui elements that is about the cargo hold then and perhaps continue with the class proportion for buildings etc.

jamespetts

Splendid. I am currently in Switzerland, so will not be able to do any coding until next week end.
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 am having a bit of a puzzle with the class proportions stuff for the buildings.

I have found so far get_class_proportion(i) and get_class_proportion_jobs(i), which I think are supposed to determine how likely a passenger from every class (i) is to be spawned.
Together with that I have found get_number_of_class_proportions() and get_number_of_class_proportions_jobs(), which only seems to count the amount of "proportion entries" that the building possess.
Then there is the get_class_proportions_sum() and get_class_proportions_sum_jobs(), which I dont really can lure what they do.

Now I try to put everything together in the building info window to see how it looks like. The layout for the information should be something else in the end.

The right window appears to look like expected, but the left window have some weird stuff going on. It appears as it is the get_class_proportion_jobs(i) that is off, and I noted that every single building, except the one owning the infowindow to the right, is like that, but with different random numbers.



I have used the code like this:

// class entries
char p_class[32] = "\0";
char m_class[32] = "\0";

building_desc_t const& h = *tile->get_desc();
if (h.get_class_proportions_sum() > 0)
{
buf.printf("%s: %d\n", translator::translate("class_proportions_sum"), h.get_class_proportions_sum());
}
if (h.get_class_proportions_sum_jobs() > 0)
{
buf.printf("%s: %d\n", translator::translate("class_proportions_sum_jobs"), h.get_class_proportions_sum_jobs());
}
for (int i = 0; i < h.get_number_of_class_proportions(); i++)
{
if (h.get_class_proportion(i) > 0)
{
sprintf(p_class, translator::translate("p_class[%u]"), i);
buf.printf("%s %s: %d\n", translator::translate("class_proportion"), p_class, h.get_class_proportion(i));
}
}
for (int i = 0; i < h.get_number_of_class_proportions_jobs(); i++)
{
if (h.get_class_proportion_jobs(i) > 0)
{
sprintf(p_class, translator::translate("p_class[%u]"), i);
buf.printf("%s %s: %d\n", translator::translate("class_proportion_jobs"), p_class, h.get_class_proportion_jobs(i));
}
}


There is also something called get_random_passenger_class(), but that appears to be something else.

Assuming that something is wrong with the left window that needs to be looked into (either on your side or on my) what is the function of the get_class_proportions_sum()? It shows 100 on the right info window.
Are there any else variables I should/could use to show the information?

Have a nice trip in Switzerland!

jamespetts

Thank you for your work on this. I have recently returned from Switzerland and have been spending a lot of time post-processing all the pictures that I took there, so it will take me some time to catch up with Simutrans things.

Looking firstly at the specific issue that you report, what the screenshot appears to show is a situation in which there are more than 5 classes recorded in a building, which would be an error in this pakset. However, it is not one that I can reproduce. Can I check that you are using a pakset built with a version of makeobj built with the latest version of the code? Using an out of date pakset build might cause this as I have not implemented full backwards compatibility for earlier passenger-and-mail-classes builds in all cases.
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

It appears to work now when I updated the pakset, thanks!
However, most buildings now dont have any information about classes, but that is maybe intentional?


-----
So, I was thinking about how to present the information and I think there are these ways:

Either, you present the raw numbers, in a kind of similar way as the screenshoot above shows (that is, like the right window on the picture). This would present the data in the most accurate way as possible to the player, and the player then has to deschiffer the numbers by her/him self to understand what it will mean to your company.

The other way would be that I "translate" the information into more read-friendly text. This would mean that some accuracy would be lost in the translation, and the player would have to "trust" the text that would be written. I was thinking of something like:
"Commuters from this building travels mostly on ... "
"People from this building travels equally on ... "
"People from this building travels mostly on ... and ..."
.. or if there might be some shorter ways to say it. Then I would have to make some kind of algorithm with some limits that would guide the text.

A third way could be to calculate percentages and write something like:
"Very high class: 10%"
"High class: 20%"
"Medium class: 40%"
"Low class: 25%"
"Very low class: 5%"

I am leaning most towards the second version, sacrificing accuracy to readability, and abandone the percentage, as this way would create a single scentence explaining the information. Also, it should help minimize the confusion of what the information would mean, and it would add to the immersion that everything in the game is not just numbers and calculations.
If that wont work or is not desired, I would like to go with the percentages.

jamespetts

Splendid, thank you for testing. I have not yet added class data to most buildings - you can check which buildings ought to have them by looking in the .dat files. Adding these will take some time, as careful consideration and possibly research will be needed for each building, so this might take some time.

As to your question, my preference would be for the third solution that I suggest: I suspect that players generally prefer precise numbers, and the information in the second method seems to be excessively vague (and the thresholds are likely to be arbitrary). The third would also, I imagine, be easier to code, as well as quite easy to understand.

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

I have already made some tests to see what's possible and I find one bad thing with using percentages: rounding errors. I don't know how to deal with that, other than starting to use decimals. Adding the decimals together and put in some of the entries so the sum gets 100% could maybe also work, but that would be false information...?

I was giving it some more thoughts, and I am thinking more and more that the second way is better:
Remember the discussion we had a while ago regarding the way info window?
I talked about useful information and that I think good information is both deep and shallow.
I remember back in school when having a math class. We talked about how big distance there would be between the school and the city center. Somebody suggested a ruler on the map and then he precisely calculated that with two decimals. But then the teacher said it is unnecessary information to know the distance in km with two decimals, also even with any decimals, since, first, we can't determine exactly what is the city center, and second, going there would mean traveling several km's, and then a couple of extra meters wouldn't matter really.
Same as the measurement of the distance between London and New York: The rounding/number of decimals falls under the margin of error.

Translating this to the current discussion, I think that knowing the percentage, especially with decimals, is like the distance in the above example. Since it's a computer program, there would technically be no margin of error in the sense the example above described since the computer knows everything, but the player would not be able to use this information in any calculations, as the passengers showing up at a stop is the result of potentially hundreds of buildings, each with different class settings generating passengers with different destinations, time tolerances, etc etc etc making it very difficult for the player to calculate what will be showing up at a stop. Knowing the exact percentage of a given class of a building simply becomes too detailed information imho.

You can say that I am removing further decimals from the equation, "dumbing down" the information, but still telling the player what the tendencies is in the building. Would you not consider this?

jamespetts

I do not think that we need decimals (although I do not imagine that one decimal place would do any harm, either), but players do need to know about all the classes of passengers that a building will generate and their proportion relative to one another: it is not enough simply to say that passengers "mostly" come from one class, since that tells the player nothing about the other classes from which passengers come, nor whether "mostly" means 51% or 99%. In terms of readability, a percentage seems easier to interpret quickly than text about what classes that passengers" mostly" come from.

As to rounding errors, you might use a single decimal place, or alternatively, you might simply add code to round the percentage up rather than down when the equivalent decimal would be .5 or higher, which should hopefully lead to the percentages expressed without decimals equalling 100% when added together.
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, I will do the percentages. I think I have succeded making an algorithm that crudely will add "one" for every percentage that is missing. This will mean that the information might not be truly accurate but still accurate within 1%, but it would anyway not be, as the rounding would have to be done somewhere. It should not be noticed by the player, as 1% is not very much. Doing decimals would look silly I think. The way it works is, after calculation, it checks wether the percentages adds up to 100, and if not, it will cycle through the classes, adding 1% at a time to each class, unless the class is 0%. The exact same is done if there would be a result of more than 100%. My initial checks shows that this appears to work.

May I ask, what should be shown for default? I mean when nothing is specified in the datfile. If the default would mean that it would equally distribute classes, I could display that.
Also, when an entry is 0%, should it be shown at all?

jamespetts

Splendid, thank you very much for that. I would suggest that, where the .dat files specify no classes, each class should display an equal percentage (i.e. 20% each where there are 5 classes) so that the display is consistent between buildings.
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

#31
Great! I will do that!

edit
Should be online now!

So, what information in the building view is now redundant? obviously you would still keep the population, jobs and the information currently benieth the class's part. What about the mail and passenger demand, are they redundant? How should mail be displayed by class?

Ves

I have made a new layouot for the building window without removing anything. I have only rearranged the info and made it a bit clever, for instance avoiding showing milions of entries of walking distance to stops.. It shows currently the closest six (now the closest is at top, not the furthest) and a new line will be displayed if there are even more stops. It will keep track of the furthest positioned stop and show the walking time and distance to it.

--

Going back to the class displayment in the halt window, I have finaly made a way for the passengers and mails to be sorted by classes. I have, however, done this in simhalt.cc, not in freight_list_sorter.cc as I originally wanted to. This means that it will be persistent and cannot be "sorted" to mix the classes. The reason to this, is because I have failed to see through the logic in the freight_list_sorter.cc.
Do you think it is sufficient, at least for the moment, if the passengers and mails are permanently sorted by class? Should the transit section also be sorted by class (which it currently is not), or maybe that doesnt matter..? Currently, I have left the class entries that I did make in the freight_list_sorter.cc, in case that would be needed later.

Now, going back to the vehicle class occupation, did you find a solution to the exploit?

The changes are online here: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/gui-classes

Ves

Triple post in a row!  ;D

So, finally I see the light at the end of the tunnel with the GUI for the passenger and mail classes.

What I have incorporated in the GUI:
* Class manager -> the tool to change the classes for the convoy
* Depot window -> passenger and mail classes are displayed. Also, the entire layout in the lower part is different as well as the upper right corner now displays some more detailed good info.
* Convoy details window -> Now shows loaded per class. (This is not finished, as James might change how passengers on reassigned classes behaves). Also, an upgrade notification has snuck in.
* Convoy info window -> Passengers and mails permanently sorted by accomodation.
* Halt info window -> Passengers and mails permanently sorted by class. Tranferring passengers and mail do not sort by classes.
* Building info window -> visitors and commuters percentage dependent on which class they prefer. Also manipulated the list of connected stops to show some usefull info as well as capping it if it gets too big. Sorted some other info in there as well.

TODO:
* In convoy details window, fix the displayment of passenger and mails.
* In convoy info window, assure that the passengers and mail in the convoy ALWAYS is traveling on the accomodations that is set by the player. Otherwise, GUI must change to also show passengers and mail traveling on non-existent classes.
* Consider wether the halt info window and the convoy info window should be able to be sorted differently. I would need to learn better skills to modify the gui_convoy_assembler.cc to be able to do that. If the current implementation is sufficient, thats great  ;D
* Ensure that I am not wasting memory or doing something else bad, since I am creating a bunch of for() loops with comboboxes, vectors etc (I dont know how to check if it is efficient. It works as it currently stands thoug...)
* TRANSLATIONS! 8)
* More todos?



James, could you check this to see if there are any problems?
link: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/gui-classes

jamespetts

Thank you for all your work on this. Apologies for not having had a chance to look into this yet: I have been busy outside the Simutrans universe, and on bug fixing when I do have Simutrans time. I will have a look at this when I have a chance. Thank you again.
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.