Started by [C] Ranran, July 02, 2019, 09:33:19 PM
0 Members and 2 Guests are viewing this topic.
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).
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.
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?
Quote from: DrSuperGood on July 03, 2019, 09:46:29 AMVehicle maintenance. Once the separate system for that is implemented then such costs are kind of deprecated so could be phased out.
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.
Quoteeach vehicle element has a monthly staff cost that is separate from monthly maintenance.
Quote(2) to be communicated clearly to the player.
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.
Quote from: Ranran on July 02, 2019, 09:33:19 PMBus 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.
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;
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.
Quotecould be pre-computed according to local rules as e.g. 1/4 of conductors pay for each vehicle.
QuoteI'm not sure that introducing separate staff costs is necessary (seeing the amount of work needed)
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.
QuoteI think that most of the staff you mention can be expressed in current monthly/maintenance for each vehicle.
Quote- driverless vehicles are not a problem
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)
Quote- driver, fireman, brakeman, guard, doorman, postman; seaman (on ships); catering staff (train, planes, ships); pilot, ... They all have their dedicated vehicle.
Quoteas there might be no passage between the units.
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).
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.
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.
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.
Quote from: ACarlotti on July 06, 2019, 12:41:59 PMYour 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.
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.
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
QuoteHow would this be different from the current system where staff costs are somehow included in monthly maintenance?
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.
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.
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 costsThis is not true. According to graphs from online game I think that the maintenance is paid for vehicles in depot too.
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.
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.
Quote from: Vladki on July 30, 2019, 09:40:08 PMWould 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, 10:36:06 PMDepends on what those states are (will be)? At the moment it is running or stored in depot, which are both quite long term states.