The International Simutrans Forum

 

Author Topic: Convoy operating staff cost  (Read 30157 times)

0 Members and 1 Guest are viewing this topic.

Offline ACarlotti

  • *
  • Posts: 478
Re: Convoy operating staff cost
« Reply #35 on: July 31, 2019, 05:28:37 PM »
Ranran: This suggestion completely ignores the fact that staff don't work 24/7. They have a limited amount of working time, and within this working time they will usually have shorter breaks. For a large company this might average out to about the right value (due to the current number of staff not varying as much proportionately), but for a company just starting out it could have a massive impact. For example, consider a company that uses a single truck to deliver goods from a producer to a consumer, where the truck remains idle three quarters of the time. If you charge for staff according to the maximum usage, then you miss the fact that you only need one hired member of staff to drive this vehicle (ignoring sickness/holiday cover), not four.

Offline Ranran jp

  • *
  • Posts: 481
  • Languages: ja
Re: Convoy operating staff cost
« Reply #36 on: August 01, 2019, 10:43:30 AM »
Quote
This suggestion completely ignores the fact that staff don't work 24/7.
It should be noted that there is no real time change in simutrans.
There is no difference between rush-hour and off-peak and midnight, and convoy (worker) always works.
The actual number of staff involved can adjust the salary.
We consider 18 hours as a two-shift work system and double the required personnel for convoy staff.
Assuming a 2 day break out of 7 days, multiply the required staffs (salary) by 7/5.
Also, the lowest class staff may be able to lower their salary because they are not full time.


Quote
For a large company this might average out to about the right value (due to the current number of staff not varying as much proportionately), but for a company just starting out it could have a massive impact.
Even in the real world, small companies often use human resources inefficiently.

Imagine a rural line that runs two convoys in the morning rush and the evening rush.
When averaged it may be taken as one convoy going back and forth, but in reality it is not.
That is, two drivers and two conductors are needed.
Convoy is not working at off-peak hours, but they will be working differently.
Because they also have a life, there will be no one who applies for the job if company do not pay proper salary.
And it should also be noted that players have the option of leaving them free.
Fuel cost will increase if you increase flights because they are free. So the company may choose to spare them more than that.

And as company gets bigger, this kind of error gets smaller rather than larger.

On the other hand, setting all convoys to depart at the beginning of the month may require the most staffs... (´・ω・`)
Yeah, this may be a bad idea.  ::'(
I thought that seeing the number of employees could be an indicator of the size of a company, a reference for improving management. :)




When paying a salary by the running cost method, the correct salary can not be calculated because this depends on the moving tile and not on the working time.

Is it better way to pay the staff salary for the travel time between stations for each station at the same time the convoy get the fare?
(I think it is currently calculating the traveling time between stations.)

Offline ACarlotti

  • *
  • Posts: 478
Re: Convoy operating staff cost
« Reply #37 on: August 01, 2019, 10:59:56 AM »
When paying a salary by the running cost method, the correct salary can not be calculated because this depends on the moving tile and not on the working time.

Is it better way to pay the staff salary for the travel time between stations for each station at the same time the convoy get the fare?
(I think it is currently calculating the traveling time between stations.)
I think it would be sensible to charge for the time spent travelling, plus a proportion of time spent waiting at stations (beyond which we can perhaps assume that the workers are taking a scheduled break, or there is a gap between shifts, or the workers are switching to a different convoy).

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18721
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Convoy operating staff cost
« Reply #38 on: August 03, 2019, 11:16:40 AM »
There are some complex issues raised here. First of all, for vehicles, the plan is to use the layover function in the vehicle maintenance feature-set to simulate times when those vehicles/convoys do not need staff. This requires, as noted above, quite precise time calculation of when these vehicles do and do not require staff. If we only sample the number of staff that they are using once a month, then all the changes between a laid over state and a non-laid over state within that month would be ignored (imagine sampling a 60hz frequency cycle once a second).

Buildings are another matter again. Currently, buildings simply have a single flat monthly cost, which takes into account the average total costs of that building, including the staff who work there regularly, services (coal/electricity/gas/water/telephone) and building maintenance (which is mostly also staff cost, but non-regular staff). Rent is not accounted for as the player is assumed to own the land (and charged accordingly in the construction costs). This is workable for buildings, since they are fixed and do not time slice their staff in the way that vehicles need to be able to do (with the layover feature). If one were to change the way in which the costs for buildings work so that one specifies a number of staff, however, one would then have to calculate the cost for that staff differently to the way in which one would calculate the cost for staff for a vehicle with exactly the same data, as, as A. Carlotti points out, staff do not work all day and all night. One might, however, imagine shift workers and calibrate the numbers on the basis of the average number of staff needed to operate the building at any given time; but would we then need to add a layover concept for a building? I suspect not given that we do not yet have any regular cycles of varying demand with time, so we might be able to use the simple system for buildings.

But we still need a way of recording times for vehicles. One additional complexity that has come to mind is this: in the planned future system, when convoy re-combination is introduced, it will be possible for one convoy to have vehicles from multiple different players, as in this real life example from Oxford in 1939:



Thus, storing the staff cost in the convoy will not work. It either needs to be stored per vehicle, or alternatively stored per player in the way that way maintenance is stored. The latter may have much to recommend it so long as only single threaded parts of the code will ever need to change this.

Offline Ranran jp

  • *
  • Posts: 481
  • Languages: ja
Re: Convoy operating staff cost
« Reply #39 on: August 04, 2019, 09:59:12 AM »
Quote
the plan is to use the layover function in the vehicle maintenance feature-set to simulate times when those vehicles/convoys do not need staff. This requires, as noted above, quite precise time calculation of when these vehicles do and do not require staff.
Staff should be working while convoy travels between stations.
The travel time between stations is currently recorded (as can be seen in the Times history dialog).
The time until the convoy leaves the station when it arrives at the station is calculated.
If convoy goes directly to the next station, the staff will continue to work.
So, player pays the salary by adding the calculated loading time to the travel time between stations.
That way, every time convoy arrives at a station or depot, it pays a salary for the staff according to the uptime.

If the schedule is set to "wait for time" or "minimum load", the crew can rest for the time waiting at the station.

In the case of reversing, it will fall into several patterns.
1) If the convoy only changes the direction of travel, as in EMU, the crew can rest until the departure time. In many cases, they will be chnaged to another staffs. Therefore, the salary of the staff is not paid while the convoy stops at the station.
2) If the convoy needs shunting, the driver has to work in the meantime. The staff for the passenger service will be able to take a break.


Some staff may be optional if there is no load in "no load" mode. There is a problem in how to distinguish it. A conductor may be unnecessary, but a brake man seems to be necessary.


Quote
I think it would be sensible to charge for the time spent travelling, plus a proportion of time spent waiting at stations (beyond which we can perhaps assume that the workers are taking a scheduled break, or there is a gap between shifts, or the workers are switching to a different convoy).
I think that the staff waiting time suggested by ACarltti may be simulated by adding a certain margin to the salary.
For example, assume that two hours out of nine hours of restraint are spent at such time.
In the real world, the train driver does not drive the train for eight hours out of eight working hours. Usually about half. Therefore, the number of staff required may be large.
But truck drivers will drive a lot of their working hours.
I think that part can be dealt with by setting a high salary (class). For example, class higher than the bus driver.
This may differ from country to country, and to some extent it would be adjustable by class settings.

I think that the relationship between class and salary can be set as the pakset creator thinks.
Quote
but would we then need to add a layover concept for a building? I suspect not given that we do not yet have any regular cycles of varying demand with time, so we might be able to use the simple system for buildings.
Yes, I think the building is good with a simple salary calculation method. The lowest class is considered part-timer, and lower working hours are set as low salary.
It would also be useful to display worker information in the station (detail) information as suggested in another thread.



Quote
But we still need a way of recording times for vehicles.
I think we are recording the travel time between stations in Times history.



Quote
Thus, storing the staff cost in the convoy will not work. It either needs to be stored per vehicle, or alternatively stored per player in the way that way maintenance is stored. The latter may have much to recommend it so long as only single threaded parts of the code will ever need to change this.
I think this applies to many other things.
The charts that convoy currently has, these data are almost meaningless for convoy with variable formations.

The resolution of the problem James pointed out seems to have to be done together with these.
However, dividing the data that convoy currently has into individual vehicles will consume more memory.


Quote
it will be possible for one convoy to have vehicles from multiple different players
This issue is not limited to the staff cost issue.
After two train with locomotives join, only one locomotive is often used. That is, one locomotive is left behind.
If the owner of the locomotive is different from the owner of the coach, the owner of the locomotive will pay much of the operating cost of the convoy.
However, on the other hand, because the locomotive does not carry anything, will it not earn any income?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18721
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Convoy operating staff cost
« Reply #40 on: August 04, 2019, 10:38:06 AM »
This raises a large number of highly complex issues.

First of all, I do not think that the idea of assuming that staff only work when a vehicle is in motion (or when a vehicle is in motion plus a fixed margin) is workable. It is likely significantly to underestimate staff times. Even if there is a fixed margin, whenever a vehicle comes to a stop for slightly longer than that margin, the staff would be assumed to be having an unpaid break for a very short fragment of time. In reality, times between shifts are never tiny fragments of time. Also, if a vehicle is unattended by staff, one cannot have passengers aboard the vehicle, and shunting operations cannot take place. This is why the layover concept was described; can I check whether you (and A. Carlotti, as well as any other contributors to this discussion) have read about and understood the layover concept in the other thread regarding schedule features? It is of some importance in this discussion.

As to convoy metrics, this is an interesting point that I had not considered fully, especially the GUI aspect. In terms of actually charging the player running cost, the current code for that is this:

Code: [Select]
/**
 * convoi add their running cost for travelling one tile
 * @author Hj. Malthaner
 */
void convoi_t::add_running_cost(sint64 cost, const weg_t *weg)
{
jahresgewinn += cost;

if(weg && weg->get_owner() != get_owner() && weg->get_owner() != NULL && (!welt->get_settings().get_toll_free_public_roads() || (weg->get_waytype() != road_wt || weg->get_player_nr() != 1)))
{
// running on non-public way costs toll (since running costs are positive => invert)
sint32 toll = -(cost * welt->get_settings().get_way_toll_runningcost_percentage()) / 100l;
if(welt->get_settings().get_way_toll_waycost_percentage())
{
if(weg->is_electrified() && needs_electrification())
{
// toll for using electricity
grund_t *gr = welt->lookup(weg->get_pos());
for(  int i=1;  i<gr->get_top();  i++  ) {
obj_t *d=gr->obj_bei(i);
if(  wayobj_t const* const wo = obj_cast<wayobj_t>(d)  )  {
if(  wo->get_waytype()==weg->get_waytype()  ) {
toll += (wo->get_desc()->get_maintenance()*welt->get_settings().get_way_toll_waycost_percentage())/100l;
break;
}
}
}
}
// now add normal way toll be maintenance
toll += (weg->get_desc()->get_maintenance() * welt->get_settings().get_way_toll_waycost_percentage()) / 100l;
}
weg->get_owner()->book_toll_received( toll, get_schedule()->get_waytype() );
get_owner()->book_toll_paid(         -toll, get_schedule()->get_waytype() );
// book( -toll, CONVOI_WAYTOLL);
book( -toll, CONVOI_PROFIT);
}

get_owner()->book_running_costs( cost, get_schedule()->get_waytype());
book( cost, CONVOI_OPERATIONS );
book( cost, CONVOI_PROFIT );
}

This code is called once per tile. We have a concept of the convoy itself having an owner, which is used for the way toll. This will need to continue, and this is in any event how real railways worked: the company controlling the train was traditionally considered to be the company which owned the locomotive hauling the train. Thus, whichever player owns the first powered vehicle in the convoy in its non-reversed direction should be considered to be the owner of the convoy. This then would determine whether a way toll should be paid.

As to the actual running costs, this method is called as follows from this code in convoi_t::increment_odometer(uint32 steps)

Code: [Select]
sint32 running_cost = 0;
bool must_add = false;
for(uint8 i= 0; i < vehicle_count; i++)
{
const vehicle_t& v = *vehicle[i];
if (v.get_pos() != pos)
{
if (must_add)
{
add_running_cost(running_cost, weg);
}
pos = v.get_pos();
weg = v.get_weg();
running_cost = 0;
}
must_add = true;
running_cost -= v.get_desc()->get_running_cost(welt);
}

if (waytype == air_wt)
{
// Halve the running cost if we are circling or taxiing.
air_vehicle_t* aircraft = (air_vehicle_t*)front();
if (!aircraft->is_using_full_power())
{
running_cost /= 2;
}
}

if (must_add)
{
add_running_cost(running_cost, weg);
}
}

We would therefore need to create a system in which we pass a vector to add_running_cost of cost values per player, and these are booked accordingly. The most complex issue, however, is how to deal with the statistics and GUI. If anyone has any thoughts on how to deal with this, this would be much appreciated, as this is a potentially very complex issue.

Offline Ranran jp

  • *
  • Posts: 481
  • Languages: ja
Re: Convoy operating staff cost
« Reply #41 on: August 04, 2019, 02:17:36 PM »
Quote
It is likely significantly to underestimate staff times. Even if there is a fixed margin, whenever a vehicle comes to a stop for slightly longer than that margin, the staff would be assumed to be having an unpaid break for a very short fragment of time
The idea I described in the previous post shows two cases where convoy's stop time may or may not be added to working time.

1) loading time (If stop time at the station = loading time, staff will be considered as working continuously)
2) Of the reversing times, the time spent on shunting. - *
During the above time, the convoy staff will continue to work even if convoy is stopped. (At the time of shunting it only looks like it is stopped.)
The stop time is currently calculated when convoy stops at the station. Therefore, add that time to the inter-station travel time.
The time they are loading and unloading passengers at the station they are still on the train and will continue to work and their salary will definitely be paid.
Is your "overlay" different from this?


Quote
If the schedule is set to "wait for time" or "minimum load", the crew can rest for the time waiting at the station
If the time staffs have to work these way has not been decided, they will be released.
The staff will work continuously rather than fragmented, except in these case and in the case where EMU changes direction at the terminal station.
However, pay will be made every time convoy arrive at the station or depot.

(If the schedule changes, is it correct to be liquidated immediately?)
(And will waypoint be considered as a station?)

The margin is an addition to that (traveling time + loading time + shunting time).
Therefore, the margin will not be shorter than the stop time (which the staff may need to continue).
In the case of Japanese railways, the time when the crew is on the moving vehicle is about half of the working time.
In other words, it requires twice as many people as the train is moving.
Replace this with double salary. (This is the content that is properly adjusted by each pakset.)


*The head shunting needs one driver (per locomotive group), but the three-part shunting seems to require two drivers (e.g. move brake van to rear), but I think that distinction is possible.
Other necessary staff are often thought to be staff working at the station, but it may not be simulated correctly in the current specification.
Because the station does not judge whether the head shunting is possible or not. Even if that station doesn't have a shunting loop, you can do head shunting. We also do not need to build a turntable to turn the locomotive. That is, the cost of necessary facility is ignored.
I think that there are many contradictions of this kind today and will continue to do so. So I think that's not a big issue.


Quote
the company controlling the train was traditionally considered to be the company which owned the locomotive hauling the train. Thus, whichever player owns the first powered vehicle in the convoy in its non-reversed direction should be considered to be the owner of the convoy. This then would determine whether a way toll should be paid.
If the convoy includes other owner's vehicles, I think paying the rental fee for the vehicle is the correct behavior.
The track owner and the rental vehicle owner may be different. Payment of tolls will not help.
In the Japanese example, it is customary to equalize the number of vehicles or the total distance traveled to offset the rental charges as much as possible.
However, it is necessary to set an appropriate vehicle rental fee because it is considered that many cases will occur in the game.
« Last Edit: August 04, 2019, 02:49:18 PM by Ranran »

Offline Ves

  • Devotee
  • *
  • Posts: 1675
  • Languages: EN, SV, DK
Re: Convoy operating staff cost
« Reply #42 on: August 09, 2019, 11:47:39 PM »
Hi all! Hope you had a good summer so far! :)
I was sitting and thinking about this and came up with this strategy. Im not sure if you talked about this approach before and I dont know how resource demanding it might be.

I was thinking that for each class of employers there is a value. These values fills up and down automatically by the player vehicles and buildings. For instance, when a vehicle goes out of layover into normal operation, it checks the vehicle_desc for what classes the employers are and then add the appropriate amount of employers to the respective class value,
When a vehicle goes into layover, it subtrakts the amount of employers it holds from the class values.
If all goes well, those values should never go below 0!

Now the tricky part which might be too consuming:
In simuconf.tab there should be a setting called employer_salaries_per_month. This value is a fractal of a month and should be as high as possible for better accuracy, but could be set to a lower value for better performance or pakset design. As far as I can think of, the highest value possible would be the number of ticks per month.

How it would work then is that whenever the time specified above has passed, the game looks at the current number of employes in the different working classes and then pay their salary. The formula would look like this:
monthly_salary_class[ X ] / employer_salaries_per_month * number_of_employes_class_[ X ]
.. and that would be done for each class of employers.


As to determine wether a vehicle needs an employe or not to run is more complex and it migh be quite difficult to get it fail proof. I have not yet thought out a princip that I think would work fail proof, but it should be possible I think.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18721
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Convoy operating staff cost
« Reply #43 on: August 10, 2019, 04:03:30 PM »
Thank you both for your responses.

First of all, as to layovers, I suggest looking at this topic, which discusses them. This should give a clear description of what is intended.

Secondly, there is some merit to Ves's idea (which is very similar to the way in which infrastructure maintenance works, and I believe similar to what I suggest above), but it would make keeping track of metrics for convoys and lines very difficult. It also has the potential to be fragile in the sense that any place in the code where these data are added or not added incorrectly would lead to the number being incorrect for an extended period of time, and each error would compound the existing incorrect state; moreover, there are many different places where these data would have to be adjusted, and there is no easy way of making sure that nothing that requires adjustment can happen without this adjustment taking place, so it will be extremely easy to miss the line of code calling for an adjustment in one of the many dozens of places where it will need to be added (and it will be even harder to make sure that this be not missed when the code is modified). If we can think of some way of adding an abstraction layer so that there is some automatic link between the types of things that require adjustment of this figure and the actual code calling for the adjustment, that would make the code far more robust, but I cannot immediately think of such a mechanism that is compatible with the Simutrans codebase.

As Ves has correctly identified, sampling time is the real complexity with this. The only way of doing it that would not cause errors is to compute the staff cost every time that staff costs are added or subtracted (and probably also at the ends of months): any less frequent sampling would inevitably lose data and produce inaccurate results, and any more frequent calculation would have no benefit. This would not be too computationally intensive, as it would require only a few arithmetical operations and would require only a total of six 64-bit integers per player (one for each class of staff, if this sort of class be used, plus one representing the time when the calculation was last performed). However, where things get extremely complex is the interaction between this and rounding errors: if the recalculation occurs too frequently, the values may well be low enough to be a fraction of a simucent, which would then be truncated; but if there are tens of thousands of truncations per month, it is theoretically possible to truncate tens of thousands of fractions of simucents, which might add up to hundreds or thousands of simucents per month.

The only lossless way of doing this of which I can think is to record actual start and end points using the 64-bit integer representing current game time. It should be possible to do this per player rather than per convoy, and then compute the charges on the basis of this once per month: this would then ensure that any precision loss is a once a month event (and therefore trivial in amount) and not affected by the number of actual changes of staff requirements per player per month. This would take more memory than the more basic system suggested by Ves, requiring a 64-bit integer to be stored per player once every change. Assuming that each of 14 players has 1,000 convoys each (by way of comparison, there are circa 6,000 convoys on the current Bridgewater-Brunel server), and that each of those convoys change configuration on average 100 times per month, this would require 100 x 1,000 x 14 x 8 bytes of memory by the end of the month, being 1,814 bytes (just over 1 megabyte), which is not very significant in the grand scheme of things, and that is assuming a server even more heavily developed than the current Bridgewater-Brunel server.

As to Ranran's suggestions, one or two questions of clarification.

Quote from:
Ranran
The idea I described in the previous post shows two cases where convoy's stop time may or may not be added to working time.

1) loading time (If stop time at the station = loading time, staff will be considered as working continuously)
2) Of the reversing times, the time spent on shunting. - *
During the above time, the convoy staff will continue to work even if convoy is stopped. (At the time of shunting it only looks like it is stopped.)
The stop time is currently calculated when convoy stops at the station. Therefore, add that time to the inter-station travel time.
The time they are loading and unloading passengers at the station they are still on the train and will continue to work and their salary will definitely be paid.

Imagine that a train arrives at a station at 0:00. Its loading time is 0:15, but its schedule requires it to wait until 0:30. Assuming no shunting, would the staff be paid for the time between 0:15 and 0:30 in this situation in your proposed algorithm?

More generally, do I understand correctly that your proposed algorithm is one which, at the most fundamental level, computes staff time just spent in fixed blocks rather than assessing a monthly cost and then working out a fraction of that cost based on when the staff would be working?

So, for instance, to simplify what I imagine your algorithm might be for the sake of illustration, suppose that we have a train travelling between points A and B. Its dwell time at point A is 0:30, its travel time between points A and B is 1:00 and its dwell time at point B is 0:30; one could simply at 0:30 of staff time on departing point A, 1:00 of staff time on arriving at point B, and 0:30 of staff time on departing point B. Is this, at a very simple level, the sort of thing that you had in mind? This is potentially workable, but has a possible issue with precision loss: if we have a 'bus travelling from point A to point B, and the dwell time at point A is 0:00:10 and the journey time between points A and B is 0:00:45, then we could well end up needing to add a staff cost that is signifciantly less than 0.01 SimuCents (the currency being stored in a 64-bit integer representing 0.01 SimuCents). This would lead to 0 staff cost being recorded for that convoy at all.

Forgive me if this is not what you had in mind and I have misunderstood your proposed algorithm: perhaps you could clarify if that is so?

Quote
If the convoy includes other owner's vehicles, I think paying the rental fee for the vehicle is the correct behavior.
The track owner and the rental vehicle owner may be different. Payment of tolls will not help.
In the Japanese example, it is customary to equalize the number of vehicles or the total distance traveled to offset the rental charges as much as possible.
However, it is necessary to set an appropriate vehicle rental fee because it is considered that many cases will occur in the game.

My apologies: I have not fully understood this. It would help if you could explain what you imagine should happen in each of the following examples.

Suppose that the toll is 10 SimuCents per km. What would you imagine the toll to player A to be for the following convoys travelling over player A's ways:

(1) a train with a locomotive owned by player A, 2 carriages owned by player A and 2 carriages owned by player B;
(2) a train with a locomotive owned by player A and 4 carriages owned by player B;
(3) a train with a locomotive owned by player B, 2 carriages owned by player A and 2 carriages owned by player B; and
(4) a train with a locomotive owned by player B and 4 carriages owned by player A.

Remember, the current toll system in Extended is based on a proportion of the revenue generated (which is based on how the Railway Clearing House worked), so it would also help to understand how you imagine this system interacting with your suggestions as to the toll.

For reference, what is currently planned is for the player which owns the convoy to take all the revenue for the journey but to have to pay all the variable maintenance costs and be liable in full for the tolls to other players (including if that other player owns some or most of the revenue earning vehicles, e.g. passenger carriages, in that convoy). No payment to other players for the use of their vehicles is envisaged (as in Railway Clearing House practice). This would incentivise players to send though trains onto other players' networks, but to change locomotives near the boundaries of the networks - exactly as tended to happen in reality.