Convoy operating staff cost

[Ranran]

Hi. (´・ω・｀)
First of all, I post this on a new thread as this is a new concept,
I think this is related to multiple events. This may be a bit related to the basic couple constraint as well I think.

There may be something to be said for giving some consideration to how we deal with brake carriages/vans more carefully. One thing that we need to be able to do is work out how many guards are on any given train so as to work out what the staffing cost should be for them (this is not currently done).

I think staffing cost is important in simulating transportation company's balance.
The staff I mentioned are people who are directly involved in the operation of convoys. That is, a driver and a fireman, a conductor, a doorman, a brakeman, a guardman, etc.
The reason why I think this is necessary is evident in the difference between trains and buses.
At present, I do not think that the labor cost is almost taken into consideration only with most of the power cost and a little maintenance cost.
So now buses are much more profitable than railroads. And it's not balanced.
However, there are few transport games that incorporate the concepts of comfort, class and frequency of operation, and I think that is a great specification of extended.
As you can see on the steam, there is no decent transport game made in Japan. (´・ω・｀)



Please check this.
It is the balance comparison for each waytype in the map of Ranran. Green is railway, violet is bus and blue is ship.




(´・ω・｀)鉄ヲタ息してる？


Bus companies have an extraordinary rate of return. You can earn huge profits with less investment.
The fact that I excluded the very low class passengers was only a few months ago and that has had little impact on this graph.
As railways and ships require a large amount of money to build vehicles and routes, network expansion takes time.

Buses have a very high advantage in service frequency because the transportation unit is small.
Although the speed of the bus itself is slow, it is often faster to reach the destination if passenger use the bus because there is very little waiting time.
So Simutrans-extended passengers will also like it. In that way the bus network can be very competitive.
Most risks disappeared when ignoring labor costs and congestion. It is the strongest transportation.

The long distance and large-scale transportation that railways dominate will take considerable money and time.
In addition, the benefits of the bus network are significant in that railways and ships can make such a large profit. If it were a rail-only network, it would not be as profitable, and it would take more time to recoup the investment and expand the network.

If you do not consider staffing costs, it would be better to run one railcar for 10 convoys instead of one convoy for 10 cars. Because high frequency operation reduces waiting time greatly and provides great convenience to passengers. But that is far from reality. There is a difference between the bus and the railway there.

I think it is difficult to balance these without introducing the concept of staff costs.



In the real world, one or two staff are always required to operate one bus, so staff costs increase in proportion to the number of bus vehicles.
It is possible to add driver's salary to the monthly maintenance cost of one bus or truck, but it is difficult to do it by train operation according to the current specifications.
Because one locomotive may pull two passenger cars or 15 passenger cars. Yes, railways can reduce labor costs by carrying so much at one time.

For example, when transporting coal with a dump truck, one dump truck requires one driver, but a train can transport 30, 50 freight cars at a time. (Of course, railways also need people for station and track management, but their number is not one per train)



Simutrans-Extended simulates technological changes from time to time. That is also a wonderful feature of Simutrans-Extended and pak128.Britain-Ex.
I think the same applies to the convoy operating staffing cost.

A steam locomotive needs a driver and a coal worker, so it needs two staffs. Since double heading doubles, it needs four staffs.
However, the current locomotive does not require a coal worker. And locomotives with multiple working functions do not need additional drivers even if they do double heading.
Steam locomotive staff may be able to simulate by adding the runningcost of the staff one by one.
However, multiple working can not be simulated by adding staff cost per car. This is also true for multiple combined EMUs and DMUs.

The brake man operated the brake handle when there was no automatic brake as mentioned in another thread.
In times when radio was not developed, guardman was placed in the rear surveillance.

Since the old coach did not have an automatic door, the conductor opened and closed the door.

These trailer buses required two conductors.

Before WW2 in Japan, there were three doors on one side of a large tram, and one driver and two conductor were on board.
Currently, most trams and city buses are operated by drivers only. However, there may be two crews taking a tourist bus or a long distance highway bus.

https://en.wikipedia.org/wiki/One-man_operation
In Japan, OMOs began to be used in buses around 1950, but in railways around 1980.
In the case of railways, it is often seen in a short countryside train consisting of one to two cars or in subway.

Yes, this is a railbus. The motorization has made the local railways so miserable. The prosperity of the railway has been lost.


Unmanned operation is being performed on the dedicated track. Unmanned driving will expand in the future.



Here is a magazine on the balance structure of a transportation company (in Japanese).
https://books.google.co.jp/books?id=4qQHDQAAQBAJ&pg=PA2008-IA26&lpg=PA2008-IA26&dq=&source=bl&ots=l-xwIBeYQL&sig=ACfU3U3JJnH1Dp__HtfZCBmm4vbuEXZs2A&hl=ja&sa=X&ved=2ahUKEwi26syxvcPiAhX3yYsBHeoSCZM4ChDoATAHegQICRAB#v=onepage

This image is a translation of the interesting figure in it.


The table shows that fuel costs are very low and labor costs are very high. And in busses and trams the percentage of labor costs is high.
Compared with rural railways, urban railways carry a large volume of transport, so labor costs are a smaller percentage. And small rural transport is not profitable because it is not suitable for railways.

Labor costs are changing with the age. Labor costs tend to be high in developed countries. In the old days, the labor cost might have been low but it required a lot of personnel.



Regarding the reversing algorithm:
Currently, some Britain-Ex locomotives are set up so that they can not connect to the front side of the locomotive because they do not have the Multiple working function.
I think this is not correct. This lost a lot of freedom, and eliminated the option of double heading of the locomotive.
Multiple working is not possible, but double heading should be possible. It only costs extra for the driver.

And this also affects the inversion algorithm. It will probably affect recombination as well.
If the locomotive was bidirectional, the side that can not connect anything when you shunt through the run-round loop will be back side.

Show in red the unconnected side.
It conflicts with the constraint setting. So it has to be reversed by using the turntable.


Regarding the recombination system:
It is in the recombination system that I think labor costs are particularly important.
Most of the benefits of combining and moving are lost, as labor costs are not reduced when separate EMUs move together.
If it moves separately, the service frequency will improve. It is most preferable that EMU / DMU move by the smallest unit. Especially with double lines.
For example, if the service frequency is 60 minutes/1convoy(2cars) to 30 minutes/1convoy(1car), the average waiting time will be halved. It will produce a greater average travel time savings than speeding up the vehicle.
It requires more people and raises labor costs, so it is not actively done in the real world.
In Jalapagos, there are many trains that can be run by one car.


As noted above, labor costs are a high percentage. Electricity/fuel costs are very cheap. The reduction of labor costs has a great effect.

Thank you for reading my poopy English. (´・ω・｀)らんらん ♪

[jamespetts]

Thank you for your thoughts on this topic. The point is well made.

For road vehicles and steam locomotives, the current code is sufficient to allow for staffing costs: the monthly cost is intended to simulate this. As discussed here and elsewhere, the difficulty is with railway carriages and wagons (whether powered or unpowered), where the staff cost can differ for any given carriage depending on where it is in the train and what other carriages are in the train.

What we need is a simple but effective algorithm that will allow for this difference (1) to be simulated; and (2) to be communicated clearly to the player.

As to locomotives coupling at the front despite not having multiple working, yes, a system that deals with the above issue should allow non-compatible locomotives to be double headed providing that there be a driver in each cab (and thus that the player pays for this). What the algorithm should be for this and how this should be communicated to the player are not easy questions, however.

[freddyhayward]

To echo Ranran's points, there is currently very little benefit in running longer multiple-units as opposed to shorter, more frequent multiple-units. Both arrangements have identical capacities and running costs, while the latter enjoys shorter wait times and the former requires larger stations which are more expensive and have larger transfer times.

[DrSuperGood]

To echo Ranran's points, there is currently very little benefit in running longer multiple-units as opposed to shorter, more frequent multiple-units. Both arrangements have identical capacities and running costs, while the latter enjoys shorter wait times and the former requires larger stations which are more expensive and have larger transfer times.

Longer trains produce less traffic on the rails. Especially if the same rail is shared with multiple lines. This in turn can save on signalling as well by not requiring high density signal placement.

In any case staff should be a separate computed value for each train and charged separately from monthly maintenance. This is so that economic situations such as overall relative pay rises or falls could be simulated (when compared with inflation). It also prevents vehicles monthly running costs become absolutely stupid when obsolete since currently it is multiplying the staffing pay instead of just the vehicle maintenance.

Similar to passengers there needs to be different pay "classes" for staff based on where they work. This could either be explicitly specified as 3 or 5 categories of staff, or on a per vehicle basis with an average staff pay multiplier. This is required to correctly staff aircraft, since passenger airplane pilots are well know to for receiving high salaries.

One possible and wild implementation that avoids the needs to simulate physical staff numbers might be that each vehicle element has a monthly staff cost that is separate from monthly maintenance. This staff cost can then have an efficiency multiplayer to reduce it based on how much the staff is shared with other elements.

[jamespetts]

I think that the question of staff costs being separate from monthly maintenance has been discussed before - but what other than staff costs could monthly maintenance represent, and how would one find any data about what these other costs are for different sorts of vehicles?

[DrSuperGood]

I think that the question of staff costs being separate from monthly maintenance has been discussed before - but what other than staff costs could monthly maintenance represent, and how would one find any data about what these other costs are for different sorts of vehicles?

Vehicle maintenance. Once the separate system for that is implemented then such costs are kind of deprecated so could be phased out.

[jamespetts]

Vehicle maintenance. Once the separate system for that is implemented then such costs are kind of deprecated so could be phased out.

What sort of maintenance? Most maintenance costs increase with increased use, and so are per kilometre rather than per month costs. To be able to simulate those (few) maintenance costs which do not vary at all with use, I will need detailed information about what these specific costs are for each type of vehicle. I have not found any numerical data on this so far, although there are many numerical data for per kilometre maintenance costs.

[Ranran]

@freddyhayward - Thank you for summarizing my point.
Yes, the required station tile length is also a disadvantage of long convoy in current specification.

In any case staff should be a separate computed value for each train and charged separately from monthly maintenance. This is so that economic situations such as overall relative pay rises or falls could be simulated (when compared with inflation). It also prevents vehicles monthly running costs become absolutely stupid when obsolete since currently it is multiplying the staffing pay instead of just the vehicle maintenance.

I agree.

each vehicle element has a monthly staff cost that is separate from monthly maintenance.

I do not think that the necessary number of staff always links with the owned vehicle. It is influenced by how the player operates their own vehicles. Especially on the railway.

For example, if we need one driver and one conductor on operating one convoy, the placement of staff is shown in the picture:

For example, the number of staffings per vehicle thus varies depending on the player's choice.



Furthermore, such a thing is also possible. This will happen frequently, especially with the introduction of the recombination system.
Even though this is the same vehicle as ABC, it can save a lot of staff costs by operating together.
However, there are disadvantages to the number of required station tile and the service frequency.
In the real world the decision is made according to the situation.

But with the current simutrans extended specification it will be simulated like this.

This loses the biggest advantage of EMU / DMU's double heading.

It is a feature of the railway that can be made this kind of efficiency improvement, and it is a big difference with the bus.
On the other hand, in a railway where the equipment and facility are expensive, it is difficult to make a profit by performing an operation like a bus. Mass transportation and efficiency are required.


The number of staff per staff per bus/truck is almost constant. No matter how much the network is expanded, it will not be efficient.

However, a bus company can make a profit because it has almost no costs other than garages and bus and labor costs for drivers and maintenance of buses.

This is a big difference from the railway. Yes, the articulated bus - Benz Citaro-G has been introduced also in Japan.

But it can not have as many trailers as trams and railways. (It saves labor costs but the initial implementation cost is high.)



In vehicles where the convoy formation does not change, the number of staff may have a fixed value for each vehicle. For example, buses, trucks, ships, planes. Big airplanes and ships will need a lot of staff.
Simulating the number of staff is very significant when the convoy formation is fluid, like a train.
I think that the difference between the bus and the railway shows that it is not simulated correctly at present.
Also, IMO, if this is not reproduced, the benefits of recombining EMU / DMU are very small. The advantage of saving signal facilities is a small advantage in my opinion.
There is also the trouble of setting of couple/decouple and the disadvantage of waiting for coupling at the station.
Also, stations that perform coupling/decoupling tend to be large stations, and special signals for that need to be placed. It is not always possible to save facilities. In addition, junctions of stations tend to be crowded. The risk of deadlocks will also increase.

(2) to be communicated clearly to the player.

Display the number of staff required next to running cost in the depot window or convoy window along with the staff symbol.

[DrSuperGood]

What sort of maintenance? Most maintenance costs increase with increased use, and so are per kilometre rather than per month costs. To be able to simulate those (few) maintenance costs which do not vary at all with use, I will need detailed information about what these specific costs are for each type of vehicle. I have not found any numerical data on this so far, although there are many numerical data for per kilometre maintenance costs.

I think you misunderstood. Currently in pak 128 Britain I use them to represent aging of a vehicle. Even if a vehicle is not used or used very lightly it still will suffer from aging. This means that some fraction of the value of the vehicle gets paid to combat this aging and effectively after some number of years a new vehicle will be brought. This use case is intended to be phased out when the proper vehicle maintenance system is implemented since that will handle both aging and per km maintenance costs. Without me doing this in the mean time there would be no representation for ageing.

I just thought of where monthly costs might still be used so it is not entirely deprecated. Technically vehicles still need to be cleaned, and toilets emptied e.t.c. Hence monthly costs could factor in things such keeping the vehicle clean, road worthiness tests on the vehicle and other fixed costs. However these should not vary much when a vehicle is obsolete since an old vehicle will not require more cleaning than a new one.

[Jando]

Interesting discussion, thanks! Personally I'm not sure that introducing separate staff costs is necessary (seeing the amount of work needed), I'd agree with James that the monthly maintenance figure once balanced is likely good enough. I would also like to make the point that introducing staff costs would generally have a pretty limited impact on the points Ranran made.

Bus companies have an extraordinary rate of return. You can earn huge profits with less investment. ... As railways and ships require a large amount of money to build vehicles and routes, network expansion takes time.

Buses have a very high advantage in service frequency because the transportation unit is small.
Although the speed of the bus itself is slow, it is often faster to reach the destination if passenger use the bus because there is very little waiting time.

The points above made by Ranran are true of course - but introducing a new cost factor staff does not really do much to change any of these points. Increasing monthly costs and running costs on buses has practically the same effect and these mechanisms already exist.

The advantage of road transport above trains comes simply from 3 facts:
1. In many cases roads already exist, train track needs to be built at high cost. But then I suspect that to many players building train track is a highlight of playing Simutrans. I know it is for me, that's why I largely play in the earlier years (before internal combustion) where train networks are the primary choice.
2. After internal combustion became a thing road transport beats train transport in many cases (just like it did in real life, with many secondary passenger routes and non-bulk freight no longer operated by trains). In modern times the advantage of trains is not really speed - instead it's capacity. And then speed is not much of a factor in Extended anyway, after internal combustion frequency beats speed for all but the largest maps.
3. In Simutrans we need high profit rates because we expand our network pretty frequently and network expansion needs to be paid for largely off profits, in real life networks get expanded less frequently and there are also bonds and government grants to pay for expansion.

I believe introducing a new mechanic of staff costs does not do much to change any of the above 3 points.

[Ranran]

What we need is a simple but effective algorithm that will allow for this difference (1) to be simulated;

Algorithm idea

About basic staff salary setting:
- First, set the basic value per personnel cost in simuconf.tab.
I do not know at this point whether it is better to have a monthly salary or a cost per working hour like the running cost.
But the formation of the railway is fluid as I said above. That is, disassembling convoy will increase the number of personnel but rejoining will reduce it. Therefore, when considering it as a
monthly salary, it is necessary to find the maximum required number of personnel for the entire player company.

- The salary of the personnel will need to take such settings into account as it affects the age setting.

- As Dr.SuperGood has said, the type of vehicle may have different salaries. This averages by waytype and also distinguishes between driver and others, for example.
Jobs such as coal worker (often a locomotive driver's apprentice), doorman, brakeman and service staff tend to have lower pay than drivers.
In Japan, it was often a woman who used a bus doorman.


Staff counting algorithm:
In default, 2 staff will be on board in 1 convoy - driver and conductor.

The following parameters are given to vehicle. The parameters are pseudonymous because I am not an English speaker.

"can_multiple_working=1"
This can only be set for vehicles with cab parameters. There is no distinction between parameters prev and next. EMU / DMU is recommended to set for all cab cars.
convoy requires the number of drivers as many as having a direction-oriented cab where multiple working = 0.

For example, in the case of such formations, one driver is required.
<MW|=|__|=|MW>=<MW|=|__|=|MW>=<MW|=|__|=|MW>
A set of 3 EMUs.

<MW>=<MW>=(__|=|__|=|__|=|__|=|__|=|__)
The locomotive corresponding to multiple working is double heading.


In this case two drivers are required.
<__>=<__>=(__|=|__|=|__|=|__|=|__|=|__)

<MW>=<__>=(__|=|__|=|__|=|__|=|__|=|__)


"can_auto_driving=1"
Convoy does not need drivers cost if all cabs are auto driving=1.
I think this will need to put restrictions on the depot and signal working method.
For example, unmanned driving can not receive staff. Basically I think it should be in such like cab signaling.

"can_conductorless=1"
The conductor can only be omitted if this value is set for all passenger vehicles present in convoy. However, it should be noted that such vehicles often have expensive equipment such as automatic guidance, checkout machines and rear surveillance cameras (for long formations).
Conductorless convoy may take a bit longer than usual to stop and then leave.

In particular long convoy may have multiple conductors, for which an alternative approach needs to be considered.
EDIT: There are several ways to determine the number of conductors required. (setting in simuconf.tab)
(1) Set the maximum number of seats that one conductor can take care of.
(2) Set the upper limit of passenger car length that one conductor can cover.
(*This "length" is 1 tile = 16. Because that is the length set for the vehicle.)
This is mainly for the railway, and ships and planes have different vehicle scales, so additional personnel need to be added at "additional_staff = n".


"additional_staff=n"
This is a parameter to add personnel to the vehicle as needed. This value is directly added to the number of staff in convoy.
For example, the following can be considered.
- First-class exclusive service staff
- Lots of staff on large ships and planes
- Staff working in a dining car
- Staff working in a travelling post office
- Coal worker on the steam locomotive
- A brakeman on the brakable wagon of the era without automatic braking
- Additional doorman on the large bus
- A guardman on the caboose



Postscript

If we add labor costs to your current system, we have the problem of being affected by aging expenses.
This is one of the reasons I think it is better to distinguish labor costs.
The aging cost may quadruple the running cost and the monthly maintenance cost, but it is too large for the increase in labor cost.

[Vladki]

I think that most of the staff you mention can be expressed in current monthly/maintenance for each vehicle.
- driverless vehicles are not a problem
- driver, fireman, brakeman, guard, doorman, postman; seaman (on ships); catering staff (train, planes, ships); pilot, ... They all have their dedicated vehicle.
- conductors - long trains usually have more conductors, so this could be pre-computed according to local rules as e.g. 1/4 of conductors pay for each vehicle. (This gives small advantage to short trains)
- obsolescence increase can be adjusted (balanced) in dat files to be reasonable. E.g. if 80% of monthly costs are salaries, and only 20% is real maintenance, then 2x increase of maintenance due to obsolescence would mean only 120% of the total monthly costs.
- the only problem I see are multi-headed trains where multiple engines can be controlled by one driver. And even if the engines themselvs are capable of remote control, the actual train configuration might not support it (i.e. remote control cables must run through all cars). This is similar issue to what was discussed about constraint groups (heating, coupling, door-control, engine-control, etc), that woould affect train reversal times and the capability to run backwards. But I have no idea how to deal with this. Whenever I start to think about it how to do all thet right it becomes so complex, that I think it will just make the game too complicated and less enjoyable.

And an example of joining and splitting emus is more complex. You can save on drivers thanks to remote control, but you still might need more conductors, as there might be no passage between the units.

[Ranran]

"Maintenance" should not include labor costs other than averaged maintenance staff costs.
We usually do not think that "maintenance" includes the cost of drivers and conductors. That is not explained anywhere.
The difference between the label and the truth is the cause of confusion.

- obsolescence increase can be adjusted (balanced) in dat files to be reasonable. E.g. if 80% of monthly costs are salaries, and only 20% is real maintenance, then 2x increase of maintenance due to obsolescence would mean only 120% of the total monthly costs.

It only increases incomprehension. It is very vague from the player's point of view. Confusion is also caused when other pakset authors set values. You need to do some complicated calculations for each vehicles.
Describing just the number of staff at dat is quite easy if it adds staff costs automatically depending on the rate of inflation.

could be pre-computed according to local rules as e.g. 1/4 of conductors pay for each vehicle.

This creates confusion for players and also for dat configurators. It is also vulnerable to configuration changes. Requires edits and recalculations for all vehicles when making changes.

I'm not sure that introducing separate staff costs is necessary (seeing the amount of work needed)

Yes, I don't think it is an easy task.
However, as James mentioned staffing in the brake van algorithm, I think that there may be something to be considered in the contents currently being I worked on.
As I have shown here, there is a way to place the brake vans back and forth, and there is a way to eliminate the useless brake van reorder, and it was often seen in Japan. In this case, the conductor only rides on one brake van.
However, if you add staff cost to the running cost or maintenance cost, you can not reproduce the reality and the player gets useless staff cost.

Also, as DrSuperGood says here, it may be a good time to make changes on labor costs in conjunction with the overhaul implementation.

3. In Simutrans we need high profit rates because we expand our network pretty frequently and network expansion needs to be paid for largely off profits, in real life networks get expanded less frequently and there are also bonds and government grants to pay for expansion.

Thank you, this is an interesting point of view. Certainly, since the progression of time is slow in network play, it may be preferable that the rate of return be high.
I play offline but sometimes I play network with my own pakset. Simutrans-Extended is also not exclusively online.
I think that the labor cost which seems to be included in the maintenance cost in offline play is too low, but if the labor cost is separated and it is possible to set it in simuconf, the player can adjust it by himself It will be. That is we can adjust for offline play. 

I think that such high profit margin is just hiding this issue. In other words, when pakset author took the profit margin is lower, the issue may become apparent.
As I showed in the table above, the real bus company (2007 in Japan) needs 63 labor costs to get 100 income.
On the other hand, the fuel cost is very small. The difference between the tram and the bus shows a very interesting value. Fuel costs may vary by age and country.

I think that most of the staff you mention can be expressed in current monthly/maintenance for each vehicle.

This does not simulate railway efficiency. Especially when convoy is multiplexed. (or including unnecessary drivers cab)
It's not like a train, but it's as if there are a lot of buses that can not handle multiple working. A driver ride on and drives each cab.
If the track capacity is sufficient, combining convoy will only enjoy the disadvantages.




I do not think that we can express these difference.



That is, A + B + C is changed to D.
In order to simulate this correctly, even a single vehicle (such as ships and airplanes) needs to be set up. However, if it is simultaneous work with the overhaul implementation, it will save some effort. You only need to describe the required personnel without having to perform cumbersome calculations.

I think combining convoy is reducing labor costs is a simulation of reality and can be a game technique. It enhances the need for coupling / uncoupling.
The number of freight cars that one locomotive is towing has been increased from 5 to 20. This will be a considerable cost savings. This is correctly simulating a railway.
On the other hand, I combined three EMUs into one convoy. But that doesn't reduce operating costs. This is unnatural. It does not simulate the railway.

If the difference in drivers costs is a small issue, there should not be a restriction that the locomotive can not double heading because there is no Multiple working function.
No, if staff cost is already added to maintenance cost, there is no contradiction in enabling double heading.
What is wrong is the labor cost of the locomotive with multiple working function.

- driverless vehicles are not a problem

It will be a problem if you introduce labor costs. The default is to add 2 staffs as described.
The reason for this definition is that convoy without staff is more specialized than convoy with staff.

- conductors - long trains usually have more conductors, so this could be pre-computed according to local rules as e.g. 1/4 of conductors pay for each vehicle. (This gives small advantage to short trains)

Averaging and co-locating to other values produces only ambiguity as I said above. And it does not correspond to the length properly, and the reverse phenomenon occurs that the merit that should originally be a long train can be a merit to a short train. (There is no change in the issue that want to solve)
There are several ways to determine the number of conductors required.
(1) Set the maximum number of seats that one conductor can take care of.
(2) Set the upper limit of passenger car length that one conductor can cover.
(*This "length" is 1 tile = 16. Because that is the length set for the vehicle.)
This is mainly for the railway, and ships and planes have different vehicle scales, so additional personnel need to be added at "additional_staff = n".

- driver, fireman, brakeman, guard, doorman, postman; seaman (on ships); catering staff (train, planes, ships); pilot, ... They all have their dedicated vehicle.

I saw an item about inflation in the extended implementation plan.
I think that staff cost should be separated also when implementing inflation.
Because the increase in fuel costs, labor costs and prices are different.
Labor costs are higher in developed countries. In addition, fuel costs have increased sharply relative to prices since the oil shock. Therefore, efficiency progressed rapidly.
Given the increase in inflation and labor costs, I think that they need to be set the same way to increase them in tandem.

Also, when simulating labor cost inflation, you will need to set the required number of personnel as well for the facilities owned by the company, such as stations and depot.

as there might be no passage between the units.

I do not think it is worthwhile to consider this. Because now passengers are also not moving to another vehicle through the aisle. The connection of the aisle has no meaning.
Also, vehicle should not get a comfort bonus if the vehicle is not connected to the aisle to the dining car. It is the same as that.
In Japan, there is no restriction that separate conductors are needed just because a passage is not connected.
http://kakeyama.kokuden.com/meitetsu/3100_3700.htm
It is a daily occurrence that there is only one conductor, even though the passage is not connected like this.
In the first place, there were no passages between vehicles in the late 1800s.

And even if the engines themselvs are capable of remote control, the actual train configuration might not support it (i.e. remote control cables must run through all cars).

Vehicles that can not multiple work with each other should be inherently impossible to connect themselves.
And it has nothing to do with labor costs. If the EMU / DMU has such a connection, one of the powers should be stopped as it can not coordinate.

This is similar issue to what was discussed about constraint groups (heating, coupling, door-control, engine-control, etc), that woould affect train reversal times and the capability to run backwards. But I have no idea how to deal with this. Whenever I start to think about it how to do all thet right it becomes so complex, that I think it will just make the game too complicated and less enjoyable.

Currently there are only two constraint settings for trains: loose restraints and very strict constraints. As I suggested in other threads, what we need is a loose constraint, group constraint, in between.
I think that solves many problems.
Separation of labor costs makes things more obvious and less complex from the player's point of view.
It is strange, complicated and difficult to understand that "maintenance" sometimes includes labor costs.
By displaying the staffing numbers using such a diagram, things become more obvious.



EDIT:
I realized the need to make the staff class individually definable as suggested by DrSuperGood.
That's the difference between the post man and the delivery driver.
But it may be possible to make a difference by using the former as a single conductor and the latter as a driver.

[DrSuperGood]

Pak128 Britian is currently purposely balanced in such a way that making tons of money is easy. This is for server games, specifically Bridgewater Brunel because extended is so buggy at the moment that all revenue can literally dry up for 1-2 days until bugs are fixed.

This is from personal experience. At least 3 times during the server game have there been nightly builds where critical game mechanics totally broke such as 0 passenger generation or all trains being unable to move at all. As it is these claimed several companies and sometimes required rollbacks.

[Jando]

Thank you, this is an interesting point of view. Certainly, since the progression of time is slow in network play, it may be preferable that the rate of return be high.

I also only play offline, but even then the current high profit rate is welcome too, first for expanding the overall network and then to pay for the freight network. Of course that means that - once expansion is done and all towns on the map are connected - money keeps piling up. But the second reason stays. Currently a freight network eats money because one needs a lot of infrastructure that will not produce any profit.

But I'm sure James already has ideas to deal with the finance aspect of Extended in the future, though I assume that will likely only happen after bugfixing and another balancing run through the pakset.

[jamespetts]

Thank you everyone for your thoughts, and thank you especially to Ranran for the very interesting algorithm idea. The right time to think about this is indeed in connexion with the forthcoming convoy maintenance/re-combination feature-set, to which I should be able to return when I have built my new computer.

Some preliminary considerations are needed at this stage relating to the interaction between staff costs, the planned inflation feature and the planned convoy re-combination feature. First of all, there is the somewhat technical question of at what point(s) in time that any cost relating to staff should be computed.

At present, there is simply monthly maintenance. This is intended to represent all costs that are time based rather than distance based, including staffing (although I note that Dr. Supergood has temporarily used these instead as a sort of artificial depreciation charge in the interim balance of Pak128.Britain-Ex to make up for the lack of entropy mechanics in the current version of Extended; those entropy mechanics will be introduced with the vehicle management feature-set). The monthly costs are simply deducted once per month, at the beginning of each new month. This is not a problem when the monthly cost does not vary depending on how the vehicle is used.

However, the proposals now being discussed would have the costs relating to staff vary depending on how the vehicle is used: a multiple unit might spend some time in a month working alone, and some time connected to another multiple unit. The cost representing staff for that multiple unit in any given month would differ from the cost representing staff for another of exactly the same sort of multiple unit used for the whole month alone. Simply calculating the monthly cost singularly at the end of each month will not suffice in this case, as, currently, no data are stored denoting the proportion of time that the unit is spending in different configurations. More data will need to be stored regarding this. This will need to be able to be stored with some precision to avoid rounding errors in what might be quite small figures - a tiny fraction of a SimuCent (think of what the cost of a guard on a train for one 256th of a game month in 1850 might be). Data will also need to be stored about a potentially huge number of different costs relating to staff at different points in any game month. It would not be feasible just to monetise the costs as soon as the configuration changes, as this is likely to be prone to rounding errors in situations where the configuration changes very frequently in a game month and the costs are low: imagine that a guard on a carriage of a train that splits and joins 8 times a month charges  0.015 SimuCents for each trip - because SimuCents are stored as an integer representing 1/100ths of SimuCents, the 0.005 will be rounded away for each trip, making the cost 0.01 - 50% lower than what it would be if the guard had been regarded as having been present for the same amount of time continuously. Thus, the variable storing the player's net account balance cannot be used to store these data. Additional variables - possibly several additional variables - will be needed.

There are a total of 6,401 convoys on the current Bridgewater-Brunel server, many of those with multiple vehicles. Storing one single additional 64-bit integer for each convoy (not vehicle) would take an extra ~50MB of RAM. If these were stored per vehicle, the total additional consumed could be >200MB: if four such variables had to be used, the result might be an additional memory consumption approaching 1GB for a very large game. Thus, if anyone can think of a way of storing these data that is both accurate and memory efficient, that would be extremely helpful.

The next issue is more about game balance than technical implementation. As stated above, the original idea has always been simply to use the existing monthly cost to represent the staff cost. I note the objection that the obsolescence increase would then apply to staff, which makes no sense - but the solution to that would simply be to make the obsolescence increase apply only to the per km cost and not to the per month cost. However, given the issue above regarding calculating different staff costs for different units of time of less than a month, it may be necessary to have a system for staffing costs that is separate from the general monthly cost. Quite what variables that we might need for this will require further consideration. However, that then leaves the question of what to do with the existing monthly maintenance cost. From what I understand, there are actual maintenance costs for vehicles of all sorts that are time fixed and do not depend on distance: rubber seals deteriorate at a fixed rate, paint fades based on time, not on distance, and so forth. However, the problem that I have always had with simulating this is that I have never been able to find any information anywhere at all on how to calibrate these costs. There is plenty of information on per kilometre based costs for various types of transport (road, rail, air), much of which is summarised in this thread. Given that the plan is to make the costs as close to reality as possible (at least, relative to each other and relative to the in-game income, rather than in nominal terms, since we are not simulating any specific currency), it will be a very serious problem for balancing if we do not have a way of even realistically approximating the per month maintenance (as opposed to staff) cost for each sort of vehicle if we actually use this for non-distance based maintenance rather than for staffing.

Does anyone have any idea where some useful and reliable data on this issue may be found?

The next issue is staff pay. As will be known, the plan is to have a feature that simulates inflation, and not just inflation generally, but the differential inflation of different sorts of costs and revenues, which is, historically, very important. The interesting algorithm proposed by Ranran envisages different members of staff on a vehicle being paid different amounts each. One thing that is important to know is whether it is necessary to have different rates of inflation applying to different pay grades of staff: for example, might the cost of guards increase at a faster rate than the cost of drivers at any point? This is important because, if this does not need to be simulated, it is likely to be possible to encode and store the staff costs with less data than if it is necessary.

If anyone has any historical evidence of differential inflation among pay grades for transport workers significant enough to make a noticeable difference to the overall economics of a transport operation over time, that would be extremely useful. The information that I have found (on the historical prices thread, linked above) has been fragmentary (giving salaries for particular occupations at particular points in time, or a very general cost of labour inflation index), so any economic analysis of differential staff pay over time would be very helpful. As set out, this is necessary to know before starting work on coding the feature, as whether differential inflation is necessary will affect how the data are stored.

Finally, I agree with Ranran that it is necessary to distinguish between the staffing cost of two independent multiple units and two multiple units running as a single train, so something at least approximately along the lines suggested by Ranran is likely to be necessary. Once we have given full consideration to the more fundamental questions considered here, and reached sensible conclusions, more detailed consideration can then be given to the algorithm itself, and how to integrate this into the existing work relating to vehicle maintenance, etc..

[ACarlotti]

There are a total of 6,401 convoys on the current Bridgewater-Brunel server, many of those with multiple vehicles. Storing one single additional 64-bit integer for each convoy (not vehicle) would take an extra ~50MB of RAM. If these were stored per vehicle, the total additional consumed could be >200MB: if four such variables had to be used, the result might be an additional memory consumption approaching 1GB for a very large game. Thus, if anyone can think of a way of storing these data that is both accurate and memory efficient, that would be extremely helpful.

Your computations are wrong - 64 bits for each of 6400 convoys would require approximately about 400KB of RAM, which is not worth worrying about too much.

[jamespetts]

Your computations are wrong - 64 bits for each of 6400 convoys would require approximately about 400KB of RAM, which is not worth worrying about too much.

Oops - thank you for correcting that: that is most helpful. We can therefore perhaps relax a little about memory efficiency; but we still need to consider how to store these data.

[Ranran]

The right time to think about this is indeed in connexion with the forthcoming convoy maintenance/re-combination feature-set, to which I should be able to return when I have built my new computer.

I look forward to it comes. 

However, the proposals now being discussed would have the costs relating to staff vary depending on how the vehicle is used: a multiple unit might spend some time in a month working alone, and some time connected to another multiple unit. The cost representing staff for that multiple unit in any given month would differ from the cost representing staff for another of exactly the same sort of multiple unit used for the whole month alone. Simply calculating the monthly cost singularly at the end of each month will not suffice in this case, as, currently, no data are stored denoting the proportion of time that the unit is spending in different configurations. More data will need to be stored regarding this. This will need to be able to be stored with some precision to avoid rounding errors in what might be quite small figures - a tiny fraction of a SimuCent (think of what the cost of a guard on a train for one 256th of a game month in 1850 might be). Data will also need to be stored about a potentially huge number of different costs relating to staff at different points in any game month. It would not be feasible just to monetise the costs as soon as the configuration changes, as this is likely to be prone to rounding errors in situations where the configuration changes very frequently in a game month and the costs are low: imagine that a guard on a carriage of a train that splits and joins 8 times a month charges  0.015 SimuCents for each trip - because SimuCents are stored as an integer representing 1/100ths of SimuCents, the 0.005 will be rounded away for each trip, making the cost 0.01 - 50% lower than what it would be if the guard had been regarded as having been present for the same amount of time continuously. Thus, the variable storing the player's net account balance cannot be used to store these data. Additional variables - possibly several additional variables - will be needed

Does the convoy need to have individual values for staff salary calculations?
The staff should also be at the facilities owned by the company, such as the station and the depot.
For example, there may be no staff at a small bus stop or a platform with zero capacity.
The items related to labor costs should be independent in the finance dialog to simulate real-world balance structures. It should be easier for players to understand that.

As I suggested in the last algorithm, I think it is possible to count the maximum number of the company's monthly labor staff.
The timing at which the value of the convoy staff changes is fixed.
- leaveing the depot -> increase
- enter the depot -> decrease
- stop the station for the recombination -> decrease
- leaving the station after the recombination -> increase

convoys in the depot should not be counted.
At those times, convoy declares to the container that the number of staff currently working.
The container is compared with the maximum number of months, and the maximum number is updated when the maximum number is exceeded.

The number of building staff also changes only when the building is built, when it is expanded and when it is removed.



We need to think about the relationship between staff and class.

[Matthew]

This is a random idea that might be impossible to implement or might spark some useful thinking by people who know what they're doing.

Could some of these problems by resolved by implementing staff as vehicles?

That is, a convoy would be comprised of objects in the 'convoy-objects' class, but only some would be vehicles; there would also be a new child class of 'staff convoy-objects'.

The staff would be graphically represented in the depot window alongside & in-between vehicles. The existing constraints system could then be used to implement staff requirements. So the first step in building a convoy in the steam railway depot would be selecting a driver. Only then is it possible to choose a locomotive. Just as some steam locomotives have a tender added automatically, then they would also have a fireman added automatically. Perhaps a restaurant car must be followed by a 'chef' object.

The advantages of this would be
(a) using an existing UI would make it easier for existing & new players to understand the system;
(b) modifying the existing constraints code might be easier than coding a new staff system and all the advantages of the new convoy re-combination system would become available in due course;
(c) it would be possible to implement inflation, labour force statistics, etc., by manipulating the (classes of) staff objects; (I have read that Simutrans was started as an exercise in OOP, so it seems that using classes would work with, rather than against, those principles. But maybe the code is now too Heath Robinson for this to help.)
and (d) different paksets would have different rules and at a later stage it would be possible to customize staff objects with different economic functions (choose between a cheap chef or one with a Michelin star), graphics (uniforms), etc.

The big difficulty would be the problem of on-map graphics. The staff should not be graphically represented on the map at all. I can imagine handling them as zero-length convoy-objects to the graphics code, analogous to the zero-width space in text processing. (EDIT: I suppose that the holds of ships work something like this? Surely it must be possible to have a hold without its little graphical symbol???) But I have no idea how the Simutrans graphics code works and I am aware that it is outside of James' experience too. Perhaps the Standard devs would know whether implementing this is vaguely feasible or would mean re-writing large amounts of graphics code (which is obviously not going to happen).

[Vladki]

How would this be different from the current system where staff costs are somehow included in monthly maintenance?
How would it help solving the multi head trains, where one driver can control multiple engines, or that only one conductor is needed for any length of train?

I think that for starters we could try splitting monthly maintenance (charged even for vehicles in depot) from monthly salaries (not charged in depot). And yes I know it won't solve the above mentioned problems either.
Although I think that monthly maintenance that is not related to travelled distance is negligible in comparison with per km costs and staff salaries. So we might just pretend that monthly maintenance is the staff salaries, and adjust obsolescence % accordingly.

If we want to stop paying salaries for vehicles in depot, we have to note how much was the vehicle used during the month - that is an extra counter and extra memory. How about charging the salaries per minute or some other short time interval?

[DrSuperGood]

Staff as vehicles adds pointless overhead. It is kind of as silly as how multiple holds for ships is currently implemented. For example a ship with a lot of holds needs a very long river stop to unload compared with one with 1 hold which makes absolutely no sense.

[Ranran]

If it uses staff as a vehicle, I think that it confuses the convoy formation picture.
In addition, addition and cancellation of staff (vehicles) will be done at the time of recombination, so it will create complexity and contradiction in the configuration order, reversing algorithm, etc. For example, is the staff (vehicle) considered as a vehicle with both pointed heads? Which side of one locomotive will it be connected? It may change the shape of the original vehicle.
When a two-way staff is connected behind a one-way locomotive, it is treated like a two-way vehicle.

How would this be different from the current system where staff costs are somehow included in monthly maintenance?

The current system has a big loophole.
By spending the end of the month in the depot, player save a lot of maintenance and identified labor costs.
As I have shown, the actual bus company in Japan spends 70% of its expenses on labor cost.
There is no such loophole if it is a method to count the maximum number of simultaneous workers in a month as shown in the previous post.

[DrSuperGood]

There is no such loophole if it is a method to count the maximum number of simultaneous workers in a month as shown in the previous post.

This is not really correct either. Not all transportation positions are fulltime with some of them being part time. Especially now with "0 hour" contracts being prevalent in the UK. This necessitates a distinction between positions which are fulltime, e.g. train drivers, and those that are not, e.g. delivery van driver.

[Vladki]

Raran: The current system has a big loophole.
By spending the end of the month in the depot, player save a lot of maintenance and identified labor costs

This is not true. According to graphs from online game I think that the maintenance is paid for vehicles in depot too.

[Ranran]

This is not really correct either. Not all transportation positions are fulltime with some of them being part time.

Does this assume something like mailman waiting for most of the month?
Yes, that seems to be a issue that needs to be solved. 
In this case, as in the case of recombination, I think it will be resolved if the crew leaves the convoy while the convoy is waiting for the minimum load setting or departure time.
The number of convoy workers who only occasionally move will be equalized. It will behave as if the personnel are optimally placed in the right place. The idea of reserve personnel is just to add a margin to the value of salary.

By spending the end of the month in the depot, player save a lot of maintenance and identified labor costs

This is not true. According to graphs from online game I think that the maintenance is paid for vehicles in depot too.

I think I saw a information that a big reduction in monthly maintenance costs when the convoy is in the depot, is that my misunderstanding? 

When I checked it in the game, it seems that there is no fact that monthly maintenance is reduced in the depot as Vladki says.


In any case, I think it would be better to separate the monthly maintenance cost and the labor cost, as the convoy in the depot does not need to pay the cost of the crew.

[DrSuperGood]

I think I saw a information that a big reduction in monthly maintenance costs when the convoy is in the depot, is that my misunderstanding?  When I checked it in the game, it seems that there is no fact that monthly maintenance is reduced in the depot as Vladki says.

I think it might apply if one separate the convoy into separate vehicles which are placed in storage (for reassembly) at the depot. Simply parking a convoy at a depot does not prevent the maintenance.

[Ranran]

I think it might apply if one separate the convoy into separate vehicles which are placed in storage (for reassembly) at the depot. Simply parking a convoy at a depot does not prevent the maintenance.

No, there seems to be no such fact too.
Rather the maintenance cost has doubled. (I report it as a bug to a new thread.)

[Ranran]

It should also be noted that vehicles with length = 0 will cause such dead lock in extended.

[jamespetts]

Thank you for all your thoughts on this. First of all, I do not think that having staff represented as vehicles is likely to be a workable solution for the reasons given.

Secondly, do I understand that Ranran's proposed algorithm is to have a vector of structs, with each struct containing two data, (1) a time; and (2) a new cost, and that an item would be added to the vector every time that the costs change, the total calculated at the end of the month and the vector reset after calculation? This could potentially work, but both of the variables in the struct would be 64 bits each, so each struct would be a 128 bit value. There are currently 6,263 vehicles in the Bridgewater-Brunel server, so this would add only circa 97KB, so should in principle be achievable.

I do worry potentially about rounding errors in such a situation: the algorithm would have to be implemented with great care to avoid this, I think, which might be tricky. Also, care would have to be taken to call this with the new cost at each relevant change event (including when a vehicle enters or leaves a lay-over as discussed in the various threads about the new convoy maintenance features). This strikes me as potentially making this method of implementation fragile; but I cannot see any other way of doing it (unless anyone has any better ideas?).

Can I ask whether anyone can see any particular difficulties with this system, and whether anyone can come up with a list of at least some (and preferably all) of the cost change points that it will be necessary to record?

Incidentally, what relationship between staff and class had you in mind?

[Vladki]

Would it be reasonable to simplify all that by charging the staff costs more frequently than every month. Lets say every 24 minutes (16x per month)? Then the chosen sampling interval will charge proportional staff costs according to the state of convoy - running or stored in depot (or maybe some other?)  With no need to keep track of how long it was used.

[jamespetts]

Would it be reasonable to simplify all that by charging the staff costs more frequently than every month. Lets say every 24 minutes (16x per month)? Then the chosen sampling interval will charge proportional staff costs according to the state of convoy - running or stored in depot (or maybe some other?)  With no need to keep track of how long it was used.

The trouble is that this could introduce serious anomalies if the frequency of change events interacted with the frequency of sampling so that either the higher or lower cost state were never sampled.

[Vladki]

Depends on what those states are (will be)?  At the moment it is running or stored in depot, which are both quite long term states.

[jamespetts]

Depends on what those states are (will be)?  At the moment it is running or stored in depot, which are both quite long term states.

In the future, we will need states such as laid over and different consists (as discussed) will need different staff costs (e.g. a double headed diesel train will not need drivers in both locomotives, but the locomotives will each need drivers if they should separate, etc.).

[Ranran]

Two arrays of this image have one for each player company.


For example, the initial value is

current_company_working_staffs[5]={0,0,0,0,0} max_company_staffs_this_month[5]={0,0,0,0,0}

(Variable names are made longer to avoid misunderstanding in here. Moreover, nesting of the player number is omitted.)


First of all, let's take a building example as a simple example. (If basic data structure is established, I think we can add building staff later)

The player has built a depot. The required number of staff in the depot had the following values.

staff_requirements[5]={10,20,5,1,0}

Therefore the player company will increase the number of staff of this value.

current_company_working_staffs[5]={10,20,5,1,0} max_company_staffs_this_month[5]={10,20,5,1,0}

Player has built another depot, then

current_company_working_staffs[5]={20,40,10,2,0} max_company_staffs_this_month[5]={20,40,10,2,0}

Next, player remove one depot. It will be deducted from the current value.

current_company_working_staffs[5]={10,20,5,1,0} max_company_staffs_this_month[5]={20,40,10,2,0}

The maximum value does not change.


At the end of the month pay will only be paid for this max_company_staffs_this_month and max_company_staffs_this_month will be reset.

current_company_working_staffs[5]={10,20,5,1,0} max_company_staffs_this_month[5]={10,20,5,1,0}