Started by jamespetts, April 11, 2017, 02:03:56 AM
0 Members and 1 Guest are viewing this topic.
Quote from: jamespetts on December 24, 2020, 01:55:42 PMWere the reasons not to use those specific alternatives not discussed at the time?
Quote from: freddyhayward on December 25, 2020, 06:42:01 AMI 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.
Quote from: jamespetts on December 25, 2020, 10:37:48 AMMy 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!
Quote from: freddyhayward on December 24, 2020, 11:46:56 AMQuoting 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)
Quote2. What parts of layovers are most important for balance and most appropriately developed and simulated in game?
Quote3. Why are triggers necessary to simulate those parts?
QuoteThe 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.
QuoteThe 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.
QuoteWithout 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.
Quote from: Ranran on December 27, 2020, 04:11:21 AMThank you for reconfiguring the extended board. It made it easier to find the thread.https://forum.simutrans.com/index.php/topic,19081.0.html