Balance discussion: cost (maintenance, convoy re-combination and others)

[freddyhayward]

Were the reasons not to use those specific alternatives not discussed at the time?

I couldn't find discussion of any such reasons. I am not being deliberately obtuse — I genuinely cannot find any specific reason for not using them. My intention is not to derail years of work. I have a huge amount of spare time in the following months and wish to dedicate it towards advancing work on these changes. I can only do this if I either agree with the design or at least understand the reasons behind it. Of course, you are busy and have no obligation to explain it to me, but it would be helpful to see  as I haven't found reading through multiple old threads to be sufficient.

[jamespetts]

I couldn't find discussion of any such reasons. I am not being deliberately obtuse — I genuinely cannot find any specific reason for not using them. My intention is not to derail years of work. I have a huge amount of spare time in the following months and wish to dedicate it towards advancing work on these changes. I can only do this if I either agree with the design or at least understand the reasons behind it. Of course, you are busy and have no obligation to explain it to me, but it would be helpful to see  as I haven't found reading through multiple old threads to be sufficient.

My apologies; I did not mean to suggest that you were being deliberately obtuse; but it is genuinely very difficult to recall all of the things that were discussed and the reasons for not selecting alternatives some time ago. Your interest in assisting with the code is very much appreciated.

When I have a little more time, I will see if I can go over the old discussions in detail and the detailed descriptions of the design and try to piece together the reason that this and not an alternative was alighted upon.

Also - merry Christmas!

[freddyhayward]

My apologies; I did not mean to suggest that you were being deliberately obtuse; but it is genuinely very difficult to recall all of the things that were discussed and the reasons for not selecting alternatives some time ago. Your interest in assisting with the code is very much appreciated.

When I have a little more time, I will see if I can go over the old discussions in detail and the detailed descriptions of the design and try to piece together the reason that this and not an alternative was alighted upon.

Also - merry Christmas!

Thank you, and Merry Christmas!

[jamespetts]

Quoting from a more recent post, but I think it's more appropriately discussed here. I've read as much of this thread as I can in a short amount of time. I still can't find an answer to the following questions:
1. Why is the layover feature necessary for balance? (this is the clearest of them all)

Without a layover feature, convoys outside depots would be assumed always to be requiring a full complement of staff and would charge the player accordingly. However, in reality, transport vehicles often spend time away from their depot when they are not in use, but are parked out of service; think of a lorry parked between turns, a train waiting in a siding between turns of duty or an aircraft at an airport some distance from its airline's home base waiting for its return journey whilst its pilots and cabin crew rest (or after one set of crew have ended their shifts and before the next crew start their shifts).

The layover feature is intended to simulate this. Without being able to do this, players would not be able to deal with low frequency services without incurring a time based cost much higher than would be necessary in reality, as, in reality, the vehicle would be able to be stored out of use with the staff on other duties or having time off. This would make low frequency services potentially uneconomic if costs/revenues be balanced in a realistic way.

2. What parts of layovers are most important for balance and most appropriately developed and simulated in game?

It is necessary to simulate both the fact of vehicles being in a state in which they accumulate either no or very little in the way of fixed costs, and the fact that, when in that state, they cannot operate (which includes loading, unloading and accommodating passengers). This latter requirement, in turn, requires players to be able to have control over when vehicles are put into layover and for how long as there may be cases where vehicles need to be available for use for an extended period, whereas, in other cases, vehicles will be more efficiently laid over.

3. Why are triggers necessary to simulate those parts?

The purpose of the triggers is not specifically connected to layovers; if it were only layovers being implemented, it may be that it would not be necessary to implement triggers at all, although a very extensive review would be necessary to check this.

The main purposes of the triggers are to allow convoy re-combination to work, as well as allow co-ordination of vehicle departures and maintenance. Here is the overview of the intended function of the triggers:

The next thing to consider is conditionality. There are two possible sorts of conditionality that I have considered so far: conditional depart and conditional skip. I will deal first with conditional depart. The idea in this case is that, at any stop on which conditional depart is enabled, a convoy would only depart once a certain trigger condition had been met. The best way of doing this, I think, requires two data members: two bits of flags (two separate flags for different versions of the behaviour, which can be compressed into a single data member), and a further 8-bit data member with a numerical value. The flags should determine whether the convoy is set to conditional before wait or conditional after wait. In conditional before wait, the convoy would wait for the condition to be triggered, and then start waiting for the next departure slot in wait for time, or for the maximum time if wait for load with a maximum time is set. It would have no effect if wait for load without a maximum time were set. In conditional after wait, the convoy would wait for its departure slot and/or maximum time in the usual way, but then not depart until the condition in question were triggered.

The triggering of conditions would not itself require data in the schedule entries for the convoy that is waiting on the condition, except for the numerical datum already identified. Instead, certain specified activities (such as a particular convoy arriving at a particular stop, or the total number of convoys on a particular line being changed so as to be greater than or less than a particular number) could trigger a method to be called in a convoy with a particular ID or all convoys of a particular line with the specific number. If a convoy is waiting for a trigger of that particular number, it will then wait until some other event calls the method in question with the correct number. However, if the event in question is a convoy arriving at another stop, it may be that sending the trigger needs to be encoded in the schedule. This would require a further boolean flag (send trigger). The numerical entry for the number of the trigger can possibly be re-used for sending (but perhaps it ought to be possible for a convoy to send a trigger and also wait for a trigger at the same stop, in which case two separate data members would be required), plus a further 16-bit data member to identify the line or convoy in question, and at least a further 1 bit of data to identify whether the number identifying the line or convoy is indeed identifying a line or a convoy.

Because of their complexity, conditional depart instructions could not sensibly be taken into account in calculating the service frequency of a line for the purpose of estimating waiting times, which might therefore default to too low a figure initially until actual recorded data become available to correct this incorrect estimate.

I am unsure about the utility or practicality of conditional skip. It is necessary to have something that is functionally equivalent to this for depots, although this need not have any data members as discussed above. I had wondered whether it might be useful in creating request stops, but realised that this would not work properly as a convoy would need to know at the previous stop whether to skip the next stop, so any logic for request stops would have to be separate and need not, therefore, be included in this project. I had also wondered whether it might allow a rudimentary simulation of taxis by having a whole set of road vehicles (hackney carriages as already in the pakset) waiting at a single stop for the condition of some passengers being present in a particular stop, and then skipping all stops at which passengers were not present, but I doubt that this could be made to work properly with the path explorer, and in any event, I suspect that dedicated taxi logic (which would be good to have one day, but is not a priority at present) would be better than this in any case. A conditional skip function in which the convoy will, when (and only when) departing from a stop, check whether its next stop has any goods/mail/passengers for it and skip to the next stop in the schedule if so could be implemented as part of this project if that feature without further embellishment were of any use, and I should be grateful for any feedback on that point.

The layover specific functionality of the schedule feature-set is explained thus:

The next thing to consider is the concept of layover: a convoy that is inactive (and not incurring fixed costs). It needs to be possible to instruct a convoy to enter a layover state at a particular stop. As far as I can tell, this need be no more than a single bit of data determining whether the convoy should go into layover at that stop or not. The remainder can safely be automated: the convoy will, if requested, unload, go into layover (during which time no loading is possible) then emerge from layover automatically in time to load and then depart at whatever time that the convoy would normally depart. It may be necessary to restrict layover to stops in towns or with special facilities: the point of layover is that the staff are not being paid to look after the vehicle, so we have to assume that the staff can have some sort of break, which they cannot sensibly do if they are stranded in the middle of nowhere without any staff facilities. However, this need not be a property of the schedule entry: rather, if the layover flag is set on the wrong sort of stop, the convoy should just stop without going into layover, and give the player a warning message. The system for loading passengers/mail/goods will need to know to unload all passengers/mail/goods before a vehicle enters layover, but, again, this needs no additional data in the schedule entry. Therefore, the layover feature itself requires only 1 bit of data in the schedule entries in the form of a boolean flag.

I hope that this assists?

[Ranran(retired)]

Without a layover feature, convoys outside depots would be assumed always to be requiring a full complement of staff and would charge the player accordingly. However, in reality, transport vehicles often spend time away from their depot when they are not in use, but are parked out of service; think of a lorry parked between turns, a train waiting in a siding between turns of duty or an aircraft at an airport some distance from its airline's home base waiting for its return journey whilst its pilots and cabin crew rest (or after one set of crew have ended their shifts and before the next crew start their shifts).

The layover feature is intended to simulate this. Without being able to do this, players would not be able to deal with low frequency services without incurring a time based cost much higher than would be necessary in reality, as, in reality, the vehicle would be able to be stored out of use with the staff on other duties or having time off. This would make low frequency services potentially uneconomic if costs/revenues be balanced in a realistic way.

Did you see any improvement in the balance between labor costs and the economy as I suggested in several threads? Do you have any ideas?
I don't think we got a clear answer in that thread.

What I mean is that the layover alone does not simulate the labor cost correctly.

For example, two EMUs merge at a station and turn into one convoy. In the real world, even if convoy is fused, driver will never be fused.
However, with the current specifications, it costs as if driving by two people. This is because labor costs are not independent. This means that the staff is integrated with the vehicle.
In other words, one cab always has one or more staff members attached to it.
The layover only costs nothing when the vehicle is sleeping. Vehicle maintenance costs and staff costs are not equal.
This does not simulate economic balance in the real world.

Without it, it is difficult to get the right economic balance, which is exacerbated by the coupling function of convoy.
Unlike the real world, there are few advantages to merging convoy, so you will enjoy many disadvantages.
Because in the real world, merging convoys can lead to significant cost savings, but there is no such specification.
Forcing players to waste time due to merging, convoy waits and consumes wasted time for coupling, which reduces the frequency of operation and reduces service.
In the real world, it may be possible to complete the coupling work and start the train with a waiting time of about 5 minutes, but on the simutrans time scale, it may be easy to wait for half a month to complete the coupling work.
It only has the advantage of saving line capacity. On the other hand, it may interfere with the area around the station for a long time.
If the waiting time for merging vehicles exceeds the transfer time, there is no advantage to having a direct route. It is smarter to prepare both vehicles according to the transporting demand and divide the line.

[jamespetts]

Ranran - I believe that there has been discussion of a plan to have a certain element of the fixed cost dependant on certain parameters (e.g. only have one vehicle in a train with the "guard" fixed cost), but I cannot now recall where that was discussed or how much detail that the planning for this feature had reached. I agree that something along these lines is necessary (in addition to layover).

[Ranran(retired)]

Thank you for reconfiguring the extended board. It made it easier to find the thread.

https://forum.simutrans.com/index.php/topic,19081.0.html

[jamespetts]

Thank you for reconfiguring the extended board. It made it easier to find the thread.

https://forum.simutrans.com/index.php/topic,19081.0.html

Excellent - it was intended to help to make threads easier to find.

[Matthew]

I noticed on GitHub, and reading back through the Technical Discussion thread, that James and Ranran have begun to implement staff as a commodity. It seems that the plan is that a convoy will require staff 'points' and maintenance charges will be adjusted accordingly. For example, a locomotive might require 2.0 staff points and a restaurant might require 3.0 staff points, so the convoy requires 5.0 staff points. It is a clever solution.

This treats all staff as a fungible commodity. But staff are not fungible. Why would we do this with staff when we don't do this with vehicles? We could just say that a convoy requires 5.0 locomotive points, as though the 1830s 'Rocket' and the 2020s Shinkansen were interchangeable. But we want to make the interesting decision whether to use 'Rocket' or a  Shinkansen set. And there are many interesting decisions to be made about transport staff.

So I think it would be better if staff were modelled as objects rather than points.

(I know this is a change from the original design, which is why I have posted in this thread rather than technical discussion. But this thread is five years old now, which seems a reasonable amount of time for re-opening a debate).

I think the clearest way to explain my vision is this mock-up of the Depot Window:



The exact examples and values there are not important, but I hope you can see beyond the bad graphics to imagine the possibilities.

You can see that we now have two classes of convoy objects: vehicles and staff. And we can now use the full power of object-oriented programming to model staff. Just as we distinguish between locomotives and passenger carriages, we can distinguish between drivers and 'conductors' (to use Ranran's term). And within the driver class, we can distinguish subclasses with different properties: electric-qualified drivers, steam-qualified drivers, secondmen, and firemen/stokers. These were some examples that immediately came to mind, and over time we would no doubt think of more properties to model.

For example, players could choose to staff the restaurant car with a fully-trained chef or just someone serving packaged sandwiches or bento boxes, depending on what catering and comfort level they wanted.

Using objects also makes it easier to implement other features later on. This is especially important for the planned inflation feature, since the relative wages of different types of staff have changed over time. You could change the 'salary' (maintenance) cost of all objects in the drivers class each year, for example. I don't think the 'staff points' system could do anything like this.

Adding more of a human element might also attract a wider range of players and contributors to the game. I have no particular interest in transport uniforms, for example, but there are certainly people out there who would enjoy painting staff in different clothes.

Of course, all these aspects could not be implemented at once. For now, a single class of Staff objects would do everything that the 'staff points' system can. But it would leave the door open to other classes in the future.

I know that James and Ranran are doing the hard work of implementing these changes and it's easy for players to make suggestions. I wish you (and other participants) the very best of luck in this project however you decide to implement it.