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.
Quote from: jamespetts on May 18, 2019, 11:56:45 AMThere 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.
(https://i.imgur.com/zJA0ilu.png)
(https://i.imgur.com/2k33thx.png)
(´・ω・｀)鉄ヲタ息してる？
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.
(http://www.city.kawasaki.jp/820/cmsfiles/contents/0000000/614/photo2-4.jpg)
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.
(https://upload.wikimedia.org/wikipedia/commons/thumb/a/a5/JRW-kiha120-ooito.jpg/280px-JRW-kiha120-ooito.jpg)
Yes, this is a railbus. The motorization has made the local railways so miserable. The prosperity of the railway has been lost.
(https://upload.wikimedia.org/wikipedia/commons/thumb/f/f4/Yurikamome7500wiki.jpg/300px-Yurikamome7500wiki.jpg)
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.
(https://i.imgur.com/iDswQpL.png)
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.
(https://i.imgur.com/fJO5rl9.png)
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. :D
(https://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/JR_West_125_series_EMU_001.JPG/320px-JR_West_125_series_EMU_001.JPG)
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. (´・ω・｀)らんらん ♪
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.
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.
Quote from: freddyhayward on July 03, 2019, 01:30:54 AMTo 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.
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?
Quote from: jamespetts on July 03, 2019, 09:14:12 AMI 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.
Quote from: DrSuperGood on July 03, 2019, 09:46:29 AM
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.
@freddyhayward - Thank you for summarizing my point. :)
Yes, the required station tile length is also a disadvantage of long convoy in current specification.
QuoteIn 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.
Quoteeach 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:
(https://i.imgur.com/FfMy3rA.png)
For example, the number of staffings per vehicle thus varies
depending on the player's choice.
(https://i.imgur.com/2tu0oGW.png)
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.
(https://i.imgur.com/gWgHUmY.png)
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.
(https://i.imgur.com/dnqFDKG.png)
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.
(https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Mercedes-Benz_O530_CITARO-G_Kanachu_Ma201_Machida_Sta_20140815.jpg/200px-Mercedes-Benz_O530_CITARO-G_Kanachu_Ma201_Machida_Sta_20140815.jpg)
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.
Quote(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.
Quote from: jamespetts on July 03, 2019, 09:50:40 AMWhat 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.
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.
Quote from: Ranran on July 02, 2019, 09:33:19 PM
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.
Quote from: jamespetts on July 02, 2019, 11:08:13 PMWhat we need is a simple but effective algorithm that will allow for this difference (1) to be simulated;
Algorithm ideaAbout 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.
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.
"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.
Quote- 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.
Quotecould 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.
QuoteI'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 (https://forum.simutrans.com/index.php/topic,18831.0.html), 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 (https://forum.simutrans.com/index.php/topic,19084.msg180747/topicseen.html#msg180747), it may be a good time to make changes on labor costs in conjunction with the overhaul implementation.
Quote3. 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.
QuoteI think that most of the staff you mention can be expressed in current monthly/maintenance for each vehicle.
(https://i.imgur.com/gWgHUmY.png)
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.
(https://i.imgur.com/FfMy3rA.png)
(https://i.imgur.com/2tu0oGW.png)
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.
Quote- 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.
Quote- 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".
Quote- 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.
Quoteas 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.
(https://i.imgur.com/CRCobq4.png)
QuoteAnd 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.
QuoteThis 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.
(https://i.imgur.com/1MdeZ37.png)
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.
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.
Quote from: Ranran on July 04, 2019, 10:06:01 AMThank 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.
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 (https://forum.simutrans.com/index.php?topic=6521). 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 (https://forum.simutrans.com/index.php?topic=6521) 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..
Quote from: jamespetts on July 06, 2019, 10:51:52 AMThere 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.
Quote from: ACarlotti on July 06, 2019, 12:41:59 PM
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.
QuoteThe 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. :) :)
QuoteHowever, 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.
(https://i.imgur.com/9PuyJjQ.png)
We need to think about the relationship between staff and class.
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 (https://en.wikipedia.org/wiki/Fireman_(steam_engine)) 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 (https://www.oxfordlearnersdictionaries.com/definition/english/heath-robinson?q=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 (https://en.wikipedia.org/wiki/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).
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?
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.
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.
QuoteHow 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.
Quote from: Ranran on July 11, 2019, 03:57:38 AMThere 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.
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.
Quote from: DrSuperGood on July 11, 2019, 05:14:51 AMThis 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. :hat:
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.
Quote from: Vladki on July 11, 2019, 06:49:43 AMBy 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.
(https://i.imgur.com/Nysuj72.png)
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.
Quote from: Ranran on July 11, 2019, 09:55:39 AMI 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.
Quote from: DrSuperGood on July 11, 2019, 01:11:26 PMI 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.)
It should also be noted that vehicles with length = 0 will cause such dead lock (https://forum.simutrans.com/index.php/topic,18496.0.html) in extended.
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?
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.
Quote from: Vladki on July 30, 2019, 09:40:08 PM
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.
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.
Quote from: Vladki on July 30, 2019, 10:36:06 PM
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.).
(https://i.imgur.com/9PuyJjQ.png)
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}
|
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.
QuoteThis 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.
QuoteFor 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.)
Quote from: Ranran on August 01, 2019, 10:43:30 AMWhen 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).
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:
(https://www.steve-banks.org/images/mystery_photos/oxford_sr_742_600_400_72.jpg) (https://www.steve-banks.org/prototype-and-traffic/83-photographs/mystery-photos/215-sr-742-and-express-at-oxford-station)
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.
Quotethe 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.
QuoteI 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.
Quotebut 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.
QuoteBut we still need a way of recording times for vehicles.
I think we are recording the travel time between stations in Times history.
QuoteThus, 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.
(https://i.imgur.com/Db3VWkV.png)
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.
Quoteit 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?
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:
/**
* 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)
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.
QuoteIt 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?
QuoteIf 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.
Quotethe 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.
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.
Thank you both for your responses.
First of all, as to layovers, I suggest looking at this (https://forum.simutrans.com/index.php/topic,17852.msg170109.html#msg170109) 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: RanranThe 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.
Given that implementation work on the schedule and related features (https://forum.simutrans.com/index.php/topic,17852.msg193643.html#msg193643) is about to recommence, some further consideration of the issues discussed here is now merited.
What I intend to do here is set out a provisional design for some elements of what has been discussed here, based in part on Ranran's suggestions, so that we can move toward refining and then implementing this design.
Staff vs. fixed maintenance costs
It is probably better to have staff cost separated from the existing fixed maintenance cost. Although nobody has been able to find any data on fixed maintenance costs that are not staff costs, it would not take much additional work to implement this separately, and, given the staff specific code set out below that will be needed for staffing costs, it is probably better to have them separate. There is nothing to stop pakset authors from simply not using the fixed vehicle maintenance.
Different staff
It is definitely necessary to have a system to simulate the different cost of different staff and the ability to have inflation affecting the cost of different staff differently. I had wondered whether Ranran's suggestion above of using classes might work for this, but this might be problematic for paksets that do not define passenger classes, or define only a few of them. It would also be too inflexible as it would not allow enough differentiations: an airline pilot is paid more than a flight engineer, who in turn is paid more than a train driver, who in turn is paid more than a 'bus driver, who in turn is paid more than a minibus or van driver, who in turn is paid more than a 'bus conductor, who in turn is paid more than a shunter. The number of classes in a pakset do not allow for this number of strata.
I therefore suggest the following system: each pakset, in a staff.tab file, will define categories of staff and their monthly salary at various points in time, using the same format as the speedbonus.tab file (thus allowing code re-use). The speedbonus.tab file looks like this:
track=1750,8,1825,10,1830,15,1835,17,1840,33,1850,40,1865,52,1880,60,1895,65,1910,67,1920,72,1930,78,1940,82,1950,84,1960,87,1970,100,1985,120,2000,150,2030,175
road=1750,8,1825,10,1830,15,1835,17,1840,33,1850,40,1865,52,1880,60,1895,65,1910,67,1920,72,1930,78,1940,82,1950,84,1960,87,1970,100,1985,120,2000,150,2030,175
monorail_track=1750,8,1825,10,1830,15,1835,17,1840,33,1850,40,1865,52,1880,60,1895,65,1910,67,1920,72,1930,78,1940,82,1950,84,1960,87,1970,100,1985,120,2000,150,2030,175
tram_track=1750,8,1825,10,1830,15,1835,17,1840,33,1850,40,1865,52,1880,60,1895,65,1910,67,1920,72,1930,78,1940,82,1950,84,1960,87,1970,100,1985,120,2000,150,2030,175
narrowgauge_track=1750,8,1825,10,1830,15,1835,17,1840,33,1850,40,1865,52,1880,60,1895,65,1910,67,1920,72,1930,78,1940,82,1950,84,1960,87,1970,100,1985,120,2000,150,2030,175
maglev_track=1750,8,1825,10,1830,15,1835,17,1840,33,1850,40,1865,52,1880,60,1895,65,1910,67,1920,72,1930,78,1940,82,1950,84,1960,87,1970,100,1985,120,2000,150,2030,175
water=1750,8,1933,13,1955,16,1972,18,2010,20,2025,25
air=1906,67,1920,72,1930,78,1940,82,1950,84,1960,87,1970,100,1985,120,2000,150,2030,175
A staff.tab could look like this:
airline_pilot=1920,150,1930,160,1950,200,1955,250,1960,275,1970,375,1980,500,1990,550,2000,600,2020,620
cabin_crew=1920,20,1930,22,1950,40,1955,45,1960,50,1970,55,1980,65,1990,70,2000,72,2020,75
train_driver=1750,10,1800,11,1820,12,1850,15,1890,17,1900,20,1910,25,1920,30,1935,32,1940,35,1950,45,1960,75,1970,90,1980,100,1990,120,2000,130,2020,150
One might then define the staff in a vehicle's .dat file as follows:
staff[airline_pilot]=2
staff[cabin_crew]=3
I am not sure how easy that it would be to implement the system of using text strings to define the individual type of staff: the only reason that text strings can be used in speedbonus.tab is that they are the names with a hard-coded association with an enum. Since this will not directly affect users, only pakset maintainers, it may be implemented simply using numbers instead of names, in a similar way to the way in which signalbox groupings are implemented. Thus, the above would instead look like this:
# ** Aircraft **
# Airline pilot
1=1920,150,1930,160,1950,200,1955,250,1960,275,1970,375,1980,500,1990,550,2000,600,2020,620
# Cabin crew
2=1920,20,1930,22,1950,40,1955,45,1960,50,1970,55,1980,65,1990,70,2000,72,2020,75
# ** Trains **
# Train driver
3=1750,10,1800,11,1820,12,1850,15,1890,17,1900,20,1910,25,1920,30,1935,32,1940,35,1950,45,1960,75,1970,90,1980,100,1990,120,2000,130,2020,150
# Airline pilot
driver[1]=2
# Cabin crew
staff[2]=3
This would then make it much easier to maintain the paksets, as there would be no need to change each individual vehicle if one wanted to change the staff cost of, for example, airline pilots, nor any need to normalise the values of staff in each individual vehicle to a standard point in time for inflation purposes when adding each entry. Instead, the inflation computation would be built into the basic system for assigning staff costs.
Variable staff operating cost, including multiple working
Ranran's original analysis of this is very helpful, and it is necessary to take into account the issues that he raises. The suggested design and the statistics for staff costs on Japanese railways, trams and 'buses as of 2007 are especially helpful.
I think that a modified version of Ranran's algorithm is the best implementation for this. I adopt Ranran's tripartide distinction between drivers, conductors and other staff. However, instead of having flags for vehicles that do or do not need these, one would simply specify, for each vehicle, how many of each is needed.
For example, a diesel locomotive might have:
# Train driver
driver[3]=1
whereas a steam locomotive might have:
# Train driver
driver[3]=1
# Fireman
driver[4]=1
In reality, multiple working requires compatible equipment. For example, two BR Class 50 locomotives can work in multiple with one another, but not with anything else. A BR Class 47, however, can work in multiple with a range of other types of locomotives (e.g. the BR Class 37) and driving trailer types (e.g. the BR Mk. 2 DBSO).
Thus, we need to be able to specify a multiple working type. This can be done simply with a numerical value thus:
multiple_working=5
(multiple_working=0 would denote no multiple working capability).
Thus, the algorithm for drivers would be simple: ignore the driver staff cost of each vehicle in the convoy which comes later (in the present orientation) than each vehicle with the same non-zero multiple working type defined which has already had its driver staff cost counted. In reality, most sensible paksets will define the train driver costs to be the same, and thus it will not matter which vehicle is first, but there needs to be some algorithm for dealing with the theoretical possibility of differing values here.
For conductors (apt to cover 'bus conductors and train guards), the algorithm could be even simpler: for each convoy, count only the conductor cost of whichever vehicle is nearest to the rear of the convoy and has a conductor cost defined. However, I note that Ranran proposes a system to provide for multiple conductors dependant on train length. I am not sure how important that this will be to simulate; but, if simulated, it is likely to need to be customised at the individual vehicle level rather than the pakset level, and then have a system for dealing with what happens when vehicles with different settings mix in the same train. It is not immediately obvious quite how this should be done.
For all other staff, the staff cost would be counted in all instances, no matter the formation of the train. This other staff parameter could be used for train guards/brakespeople in trains without continuous braking, to simulate the fact that each brake carriage on such a train would need a guard no matter the formation of the train, as each brake carriage would need somebody manually to apply the brakes when the driver gave the appropraite whistle code. They would simply be defined, e.g.:
# Buffet staff
staff[5]=2
Thus, trains or 'buses without conductors or drivers would not need a "driverless" or "conductorless" flag: they would simply be composed entirely of vehicles without any driver or conductor staff defined.
Computing time based maintenance costs
This needs to avoid both rounding errors and excessive memory consumption. The easiest way of doing this, I think, is for each player to have a vector of staff cost for each pay grade of staff, as defined in staff.tab. That vector will store data in ticks (the internal measurement of time).
Based in part on Freddy's suggestion in another thread, each time that a convoy departs from a stop or arrives at a stop, and each new month, the number of ticks since its last departure or the last month can be computed and that number of ticks, multiplied by the number of staff of each type, added to the player's vector for each different staff pay grade. At the end of the month, the number of ticks would be multiplied by the current prevailing salary for that grade of staff and then dividided by the number of ticks per month and a figure for staff cost for that player in that month would thus be computed. Rounding errors would therefore be minimised and would be incapble of being compounded, and memory usage would be minimal.
Mixed player convoys and costs
This has the potential, as can be seen from above, to become extremely complex, so I would suggest the simpler version that I set out in my last post on this topic above: each convoy willl be regarded as having an owner, which would be determined by the owner of the first powered vehicle in the convoy's non-reversed state (based, as stated above, on Railway Clearing House practice). The owner of the convoy will pay all of the staff operating cost for the whole convoy. The owner of the individual vehicles will continue to pay the running (per km) and maintenance (per month) cost for those individual vehicles.
Convoy recombination and statistics
This is complex and challenging. In one sense, it is a less critical issue, as it does not directly affect gameplay, but it has the potential to mislead players.
The simplest solution would be to erase the data and start again whenever it becomes invalidated: this would at least prevent players from being given inaccurate or misleading data.
If anyone can think of a better alternative that does not take an infeasible amount of coding effort, that would be very helpful; but, otherwise, I think that I shall have to implement the erasure system.
Catering
Ranran makes the point that catering vehicles sometimes did not have through gangways, so that a dining car on a train could only service passengers in that particular carriage. This should be dealt with by a new .dat file setting,
self_contained_catering=1
which, when set, will mean that the catering revenue and comfort boost will apply only to the individual vehicle rather than to the whole convoy.
Edit: Added catering
Regarding the multiple_working=X feature. This (if implemented) should affect also the functionality of "can_lead_from_rear" or "has_rear_cab". If the last vehicle has rear cab, but zero power, then look for a powered vehicle with the same multiple_working value. If such vehicle is not found, then it should be treated as if it does not have a rear_cab for reversal purposes. For even more realistic function - all vehicles in between them, should have the same multiple_working value - even if having no cab and no power - just to show that they have the necessary cables.
Regarding conductor costs. It would be nice to allow fractional numbers. Let's say that the railway rules say there must be one conductor for every 4 cars. So one could specify staff[train_conductor]=0.25. This value would be rounded up, so a 5-car train would have 2 conductors. This would also solve the problem of two or more multiple units connected together, where it is not possible to pass from one unit to the other, and thus each requires it's own conductor.
Quote from: Vladki on December 28, 2020, 10:16:03 AM
Regarding the multiple_working=X feature. This (if implemented) should affect also the functionality of "can_lead_from_rear" or "has_rear_cab". If the last vehicle has rear cab, but zero power, then look for a powered vehicle with the same multiple_working value. If such vehicle is not found, then it should be treated as if it does not have a rear_cab for reversal purposes. For even more realistic function - all vehicles in between them, should have the same multiple_working value - even if having no cab and no power - just to show that they have the necessary cables.
This is an interesting idea. I wonder whether this can be communicated clearly to the player? It should not be difficult in principle to write the logic for this.
Quote
Regarding conductor costs. It would be nice to allow fractional numbers. Let's say that the railway rules say there must be one conductor for every 4 cars. So one could specify staff[train_conductor]=0.25. This value would be rounded up, so a 5-car train would have 2 conductors. This would also solve the problem of two or more multiple units connected together, where it is not possible to pass from one unit to the other, and thus each requires it's own conductor.
I am still unsure about this feature, and in particular quite what the algorithm would be for this.
Quote from: jamespetts on December 28, 2020, 11:24:00 AM
This is an interesting idea. I wonder whether this can be communicated clearly to the player? It should not be difficult in principle to write the logic for this.
Perhaps similar to showing the constraints - have a "translation" for each multiple working type, and show it next to constraints:
Supported multiple working type: WTB (wire train bus)
or
Supported multiple working type: Electrostar (classes 375, 376, 378 and 387)
Quote
I am still unsure about this feature, and in particular quite what the algorithm would be for this.
Each passenger car would have staff[train_conductor]=1/x, where x is the max number of cars served by one conductor. (or the number of cars in multiple unit). Then these numbers would be summed up for all vehicles in the convoy, and rounded up to nearest integer. The result would be the number of conductors needed for that train, and used further to calculate the wages.
Quote from: Vladki on December 28, 2020, 11:44:12 AM
Perhaps similar to showing the constraints - have a "translation" for each multiple working type, and show it next to constraints:
Supported multiple working type: WTB (wire train bus)
or
Supported multiple working type: Electrostar (classes 375, 376, 378 and 387)
That could possibly work. I should be interested in Ranran's views on this.
QuoteEach passenger car would have staff[train_conductor]=1/x, where x is the max number of cars served by one conductor. (or the number of cars in multiple unit). Then these numbers would be summed up for all vehicles in the convoy, and rounded up to nearest integer. The result would be the number of conductors needed for that train, and used further to calculate the wages.
There is no existing algorithm for parsing mathematical symbols in strings to be read, so there would be a very large amount of work required to add this as opposed to a basic system involving reading only numbers.
Quote
There is no existing algorithm for parsing mathematical symbols in strings to be read, so there would be a very large amount of work required to add this as opposed to a basic system involving reading only numbers.
Of course you would not enter 1/4 but 0.25. Just the system would have to support fractional numbers for staff[...], and have the special logic if x is train_conductor, just as it would have special logic for train_driver.
Alternatively one could specify that staff[train_conductor]=x and the 1/x calculation would be done internally, but I think that would be confusing to pak designers, and lead to errors.
EDIT: maybe there would not be any need for special treatment of conductors. Any staff (except drivers) could be treated this way. (i.e sum over all vehicles using float, and round up the sum).
I do not think that the existing algorithm can even deal with floating point numbers; I think that it works only with integers, although I have not looked into this in detail.