The International Simutrans Forum

 

Author Topic: Schedule features: technical discussion  (Read 17382 times)

0 Members and 2 Guests are viewing this topic.

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #105 on: December 24, 2020, 02:25:40 AM »
I updated this to a new GUI code style to repair the broken schedule UI layout. (The lower station list is not yet in the new GUI code style) And I changed some layouts.

 I would appreciate it if you could give your opinion on this.
As a replacement for the broken layout, it's fine. In general, I would like to see clearer separation between line options and schedule_entry options.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #106 on: December 24, 2020, 02:33:29 AM »
I would like to see clearer separation between line options and schedule_entry options.
Do you have any specific suggestions?
One change I've made is that the convoy schedule now shows the convoy name in the title bar.

EDIT:
 :done: Changed to display line name in the title bar on the line schedule gui.
« Last Edit: December 24, 2020, 07:17:38 AM by Ranran »

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #107 on: December 24, 2020, 07:26:06 AM »
Do you have any specific suggestions?
I do have suggestions. I don't know whether they effectively communicate the point. One or more of:
1. Use a separator
2. Move them to different parts of the window
3. Move line settings outside of the schedule editor into a tab in the line manager.
4. label the different sections: "line or schedule settings" and "stop/order/entry settings"
5. move the buttons onto the entries themselves. this is probably a bad idea.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #108 on: December 24, 2020, 11:36:22 AM »
Thank you very much all for your contributions to this. I will not be working on this until I get home in the new year, when I can review all of the very helpful work that has been done so far, but I do encourage anyone who wishes to continue working on this to do so.

Freahk is probably right about the use of vehicle-management-new being "ungitish" (which is a rather splendid neologism). I had not remembered the tag feature when I created the new branch. That would probably have been a better approach.

Having briefly read the prior discussion on this thread and parts of the code, the design seems extremely ambitious and complicated. I worry that it will take a near-infinite amount of time to be brought into a usable, let alone user-friendly state. Especially suspect is the idea of triggers, broadcasters and receivers. These seem to offer unnecessarily high levels of precision and complexity. I don't currently have an alternative design, but I hope that through further discussion here, either one can be developed or the current design sufficiently explained and justified.

May I ask specifically why you think that triggers, broadcasters and receivers give unnecessary precision and complexity; unnecessary for precisely what? The explanation for the features is discussed in this thread (the current thread being deliberately confined to a detailed technical discussion of the implementation). As explained there, triggers are necessary to work with the layover function, which is in turn necessary to achieve balance of a realistic implementation of running costs per unit of time, which is an essential part of the ultimate goal of reality based cost and revenue balancing.

The in progress implementation in the vehicle-management-new branch has had many years of very detailed thought put into its design, and any change would require consideration of all of the potentially vast number of implications of that change vis a vis the achievement of the purposes originally intended by that design implementation of which is already underway. Since the only alternative is to abandon the idea of ever making the game balance in a realistic way, only a fully detailed alternative design that fulfils the functions of the existing design at least as thoroughly could be a reason to do anything other than progress with this design.

I updated this to a new GUI code style to repair the broken schedule UI layout. (The lower station list is not yet in the new GUI code style) And I changed some layouts.

 I would appreciate it if you could give your opinion on this.

That looks good so far - thank you for your work on this. I agree with Freddy that it would be useful to have some sort of separation for the consist order part of this display, which might be as simple as a separator, although an alternative possibility would be a tab or similar. Some work may be needed on the relationship between "wait for time" and "wait for trigger" to make clear to the player what happens if both are selected, although I cannot immediately remember what, if anything, I had planned so far in that regard at this stage.

One thing that may need considering at some point is whether Ves's vehicle manager UI can be revived. I had not merged this into vehicle-management-new as, being a UI feature, it seems likely to clash with the new UI system. When vehicle maintenance becomes more involved, a vehicle manager system is likely to be worthwhile, but I am not sure to what extent that Ves's code will integrate into the new UI system.

In any event, thank you all for your work/comments on this: it is much appreciated.

Offline Freahk

  • Devotee
  • *
  • Posts: 1435
  • Languages: DE, EN
Re: Schedule features: technical discussion
« Reply #109 on: December 24, 2020, 12:28:20 PM »
When working on schedules anyways, might you consider to adjust the behavior of "wait for load" plus "wait for time", so a train waiting for both will depart when both are fullfilled?
That means first wait until the min load is exceeded, then depart at the next scheduled slot.

Imho that makes much more sense than current behavior, which is "depart when either of these is fullfilled".
Especially in case of cargo trains this would be very useful as you can wait for load but at the same time ensure that the train departs in a time slot that won't slow down other trains on the line, which imho is the whole idea of scheduled departures.
If you just need a functionality to ensure a minimum service is provided no matter te actual demans, you should use the maximum waiting time (which should ignore the wait for load, but also depart at the next available slot)
« Last Edit: December 24, 2020, 01:36:26 PM by Freahk »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #110 on: December 24, 2020, 02:01:31 PM »
When working on schedules anyways, might you consider to adjust the behavior of "wait for load" plus "wait for time", so a train waiting for both will depart when both are fullfilled?
That means first wait until the min load is exceeded, then depart at the next scheduled slot.

Imho that makes much more sense than current behavior, which is "depart when either of these is fullfilled".
Especially in case of cargo trains this would be very useful as you can wait for load but at the same time ensure that the train departs in a time slot that won't slow down other trains on the line, which imho is the whole idea of scheduled departures.
If you just need a functionality to ensure a minimum service is provided no matter te actual demans, you should use the maximum waiting time (which should ignore the wait for load, but also depart at the next available slot)

I suspect that this may be straightforward to implement - I shall have to look into this when the appropriate time arrives.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #111 on: December 25, 2020, 10:36:46 AM »
The freddy fix can load 14.x but crashes in demo.sve.

EDIT:
Code: [Select]
DBG_MESSAGE("convoi_t::rdwr","rdwr vehicle: %s",v->get_desc()->get_name());
I found that commenting out line 4226 of simconvoi.cc makes it possible to read it.
« Last Edit: December 25, 2020, 10:47:53 AM by Ranran »

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #112 on: December 25, 2020, 10:52:58 AM »
I found that commenting out line 4226 of simconvoi.cc makes it possible to read it.
Sorry, none of those debug lines needed to be in there... they can probably all be removed.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #113 on: December 25, 2020, 04:08:46 PM »
Code: [Select]
uint16 max_brake_force = UINT32_MAX_VALUE;I noticed a compiler warning of consist_order_t.h.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #114 on: December 25, 2020, 06:33:02 PM »
Code: [Select]
uint16 max_brake_force = UINT32_MAX_VALUE;I noticed a compiler warning of consist_order_t.h.

This definitely looks like an error - I will have to look into this when I get home to check which size of variable is intended here.

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #115 on: December 26, 2020, 12:43:22 AM »
I have spent a short time working on an alternative implementation design for layovers. I believe that this design is simpler than the current planned design, and I have attempted to ensure that it retains that design's core goals.

Staffing costs for ALL convoys are charged per unit of time as follows:
   * at the end of each month while driving, AND at arrival at ALL stops, the smallest of:
      - the time since the convoy's last departure OR
      - the time since the start of this month
   * at the end of each month at stops WITHOUT layover facilities AND at departure from stops WITHOUT layover facilities, the smallest of:
      - the time since the convoy's arrival at this stop OR
      - the time since the start of this month
   * at departure from stops WITH layover facilities, the smallest of:
      - the time since the convoy's arrival at this stop OR
      - the convoy's layover time threshold determined by any number of factors, potentially including game settings, pakset-specified values, default values, time spent loading, etc...

Design Implications:
   * There is no layover state for convoys
   * There is no layover setting for schedule entries
   * Staffing costs during layovers are zero

Potential issues and responses for this design:
   * Players would not have control over when the convoys enter and exit layover in this system:
      - Players would always receive the greatest possible cost savings for minimal effort in this system.
   * Staffing costs should be reduced or potentially reduced rather than zero, therefore this system saves players too much:
      - Players would still have to pay for the maintenance costs of layover facilities.
      - Additionally, this system could be modified to include reduced costs quite easily.
   * Players would not be able to check whether a convoy is in a layover state in this system:
      - Players should associate long waiting times with staffing cost savings in general, and therefore assume that any convoy waiting for long periods of time is probably in a layover state.
   * Layovers should not be in effect while vehicles have cargo onboard, therefore this system saves players more than they should and/or is unrealistic:
      - This system could be easily modified to apply regular non-layover charges while the convoy has cargo onboard. This could be coupled with 'unload all' and 'no load' schedule entry flags which would be very useful in their own right.
      - Additionally, a convoy's layover time threshold could be altered as part of its calculation when being charged to include the implicit costs of managing the cargo during the layover, generalising loading, unloading, storage, etc.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #116 on: December 26, 2020, 12:04:18 PM »
I have spent a short time working on an alternative implementation design for layovers. I believe that this design is simpler than the current planned design, and I have attempted to ensure that it retains that design's core goals.

Staffing costs for ALL convoys are charged per unit of time as follows:
   * at the end of each month while driving, AND at arrival at ALL stops, the smallest of:
      - the time since the convoy's last departure OR
      - the time since the start of this month
   * at the end of each month at stops WITHOUT layover facilities AND at departure from stops WITHOUT layover facilities, the smallest of:
      - the time since the convoy's arrival at this stop OR
      - the time since the start of this month
   * at departure from stops WITH layover facilities, the smallest of:
      - the time since the convoy's arrival at this stop OR
      - the convoy's layover time threshold determined by any number of factors, potentially including game settings, pakset-specified values, default values, time spent loading, etc...

Design Implications:
   * There is no layover state for convoys
   * There is no layover setting for schedule entries
   * Staffing costs during layovers are zero

Potential issues and responses for this design:
   * Players would not have control over when the convoys enter and exit layover in this system:
      - Players would always receive the greatest possible cost savings for minimal effort in this system.
   * Staffing costs should be reduced or potentially reduced rather than zero, therefore this system saves players too much:
      - Players would still have to pay for the maintenance costs of layover facilities.
      - Additionally, this system could be modified to include reduced costs quite easily.
   * Players would not be able to check whether a convoy is in a layover state in this system:
      - Players should associate long waiting times with staffing cost savings in general, and therefore assume that any convoy waiting for long periods of time is probably in a layover state.
   * Layovers should not be in effect while vehicles have cargo onboard, therefore this system saves players more than they should and/or is unrealistic:
      - This system could be easily modified to apply regular non-layover charges while the convoy has cargo onboard. This could be coupled with 'unload all' and 'no load' schedule entry flags which would be very useful in their own right.
      - Additionally, a convoy's layover time threshold could be altered as part of its calculation when being charged to include the implicit costs of managing the cargo during the layover, generalising loading, unloading, storage, etc.


Thank you for your detailed suggestions: this is very helpful. If I understand correctly, what you suggest is a sort of implicit layover. This is an interesting idea, but one possible problem relates to rounding errors for convoys that have low fixed costs and stop regularly.

Imagine, for example, a minibus that stops 10 times per game month and with a fixed cost of 1.29c. At each of its stops (assuming even spacing), it would charge a fixed cost of 1.29c / 10, which would, in integer arithmetic, produce 0.12c. 0.12c * 10 = 1.20c, reducing the fixed cost by 0.09c/month compared to an otherwise identical convoy with only 1 stop per game month. With 100 stops, the cost would potentially be truncated further to 1.00c.

We may also want to consider whether we need the concept of "layover facilities" and, if so, how to interpret it; do we need different facilities for different types of convoys (consider an airport with an associated 'bus stop, for example; layover facilities for the 'buses should not, if layover facilities are a thing at all, necessarily mean layover facilities for the aircraft, too). What exactly did you intend "layover facilities" to simulate?

Edit: One more significant issue occurs to me: the path explorer. One of the specifications for the layover feature is that the path explorer should not route passenger/mail/goods past a layover point. This is, I think, the reason that it was considered necessary explicitly to state the layover in the first place: the path explorer needs to know where layovers will occur at the time that it runs in order to determine whether to treat the stop in question as a terminating point or not.

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #117 on: December 26, 2020, 12:32:03 PM »
Imagine, for example, a minibus that stops 10 times per game month and with a fixed cost of 1.29c. At each of its stops (assuming even spacing), it would charge a fixed cost of 1.29c / 10, which would, in integer arithmetic, produce 0.12c. 0.12c * 10 = 1.20c, reducing the fixed cost by 0.09c/month compared to an otherwise identical convoy with only 1 stop per game month. With 100 stops, the cost would potentially be truncated further to 1.00c.
Thanks, I had not considered this issue. The timing points I suggested could instead be used to accumulate time spent with an active staff (that is, not in layover), which could then be charged at the end of each month.

We may also want to consider whether we need the concept of "layover facilities" and, if so, how to interpret it; do we need different facilities for different types of convoys (consider an airport with an associated 'bus stop, for example; layover facilities for the 'buses should not, if layover facilities are a thing at all, necessarily mean layover facilities for the aircraft, too). What exactly did you intend "layover facilities" to simulate?
I deliberately did not consider the actual implementation of layover facilities - I assumed that they were already planned because they were mentioned in prior discussion. As far as my suggestion is concerned, the actual presence or implementation of facilities is not very important as it would only require checking whether a given stop has appropriate facilities for a given convoy (or no check at all if it is decided not to implement them). As an independent discussion, I have not given much thought to the issue but would probably be in favour of generic facilities applicable to all convoy types since layovers as I understand them are primarily concerned with staffing costs.

EDIT:
Edit: One more significant issue occurs to me: the path explorer. One of the specifications for the layover feature is that the path explorer should not route passenger/mail/goods past a layover point. This is, I think, the reason that it was considered necessary explicitly to state the layover in the first place: the path explorer needs to know where layovers will occur at the time that it runs in order to determine whether to treat the stop in question as a terminating point or not.
If it is decided that all goods must be unloaded at layovers (which would be the only reason not to route past them), then convoys carrying goods would record non-layover time at those stops. Adding 'load only', 'unload only' and 'unload all' flags would give players more control over routing behaviour in many situations besides layovers. These were suggested and rejected earlier:
As to W. Lindley's suggestion - thank you for suggesting that, but having to increase the size of the flags to 32-bit to accommodate the extra 3 flags for reversing would actually take more space than it would take as it stands; and the minimum loading has already been co-opted for some depot specific flags
I think that these are worthwhile features and it would be worth exploring to either find the space within the flagset by removing or consolidating other flags, expanding to 32 bits, or rearranging categories of flags into a few 8-bit sets.
« Last Edit: December 26, 2020, 12:56:49 PM by freddyhayward »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #118 on: December 26, 2020, 02:14:17 PM »
Thanks, I had not considered this issue. The timing points I suggested could instead be used to accumulate time spent with an active staff (that is, not in layover), which could then be charged at the end of each month.

Yes, that would probably be the way to do it - any suggestions for a data structure for this? The implementation of the data structures is what needs to be done at the earliest stages of this project.

I should note that one important refinement to the semi-automatic implicit layovers that you suggest would be to require a substantial lead-in time for a layover, and only record any time without staffing costs if the stop duration is longer than a fixed time to represent the need for the lead-in time, a lead-out time and a reasonable amount of time between the two. One might have a minimum_layover_time= setting in simuconf.tab for this.

Another important anti-exploit mechanism is to ensure that a vehicle cannot load in a laid over state. This then requires considerable complexity to allow players to keep a vehicle in a laid over state for a time until it is ready to load (or else one would get either an exploit or a deadlock when using the wait for % load feature).

Quote
I deliberately did not consider the actual implementation of layover facilities - I assumed that they were already planned because they were mentioned in prior discussion. As far as my suggestion is concerned, the actual presence or implementation of facilities is not very important as it would only require checking whether a given stop has appropriate facilities for a given convoy (or no check at all if it is decided not to implement them). As an independent discussion, I have not given much thought to the issue but would probably be in favour of generic facilities applicable to all convoy types since layovers as I understand them are primarily concerned with staffing costs.

I cannot immediately recall whether layover specific facilities were mentioned (as distinct from refuelling facilities). Whether to require these and, if so, what to require, is a potentially complex question that needs careful consideration. However, it requires early consideration, since, as noted above, data structures come first in the implementation phase.

Quote
If it is decided that all goods must be unloaded at layovers (which would be the only reason not to route past them), then convoys carrying goods would record non-layover time at those stops. Adding 'load only', 'unload only' and 'unload all' flags would give players more control over routing behaviour in many situations besides layovers.

With the semi-automated implicit layover system that you suggest, one could simply use the existing "layover" flag as an "unload all" flag, which would have very similar functionality to the layover flag as originally proposed, save that the actual entry to and exit of layover states would only arise when the relevant conditions have been fulfilled rather than whenever this flag has been set.

Quote
These were suggested and rejected earlier: I think that these are worthwhile features and it would be worth exploring to either find the space within the flagset by removing or consolidating other flags, expanding to 32 bits, or rearranging categories of flags into a few 8-bit sets.

What was suggested was:

Quote
Also, why not change Reverse from an 8-bit field to a bit flag as well?

If there are bits left, "Receive only" and "Unload only" would be quite nice; used along with the conditional-skip, a stop would be skipped if the convoi were already full (receive only, conditional skip) or already empty (unload only, conditionally skip).

The original objection to this still holds; may I ask why these features justify increasing the per schedule memory consumption?

Offline Freahk

  • Devotee
  • *
  • Posts: 1435
  • Languages: DE, EN
Re: Schedule features: technical discussion
« Reply #119 on: December 27, 2020, 04:21:03 AM »
Yes, that would probably be the way to do it - any suggestions for a data structure for this? The implementation of the data structures is what needs to be done at the earliest stages of this project.
Did I misunderstand the suggestion?
The needed "datastructure" sounds like a simple int to me. Instead of paying the cost instantly, we add the time spent to the counter, at the end of each month, pay the costs according the accumulated time, done.

Another important anti-exploit mechanism is to ensure that a vehicle cannot load in a laid over state.
When "wait for load" is used, do not load any goods in layover state, unless loading all the available goods will exceed the defined "wait for load" value.
Sounds like a rather simple implementational thing to me, not a big conceptual issue.

The original objection to this still holds; may I ask why these features justify increasing the per schedule memory consumption?
How much additional memory consumption are we talking about?
I'd expect that memory to be rather negligible.

Assuming an impresively huge map with 10k vehicles and each route to contain 100 stops(which is much more than even on BB), we get an impressive 1 million affected entries, growing each of these by 16 bits (2 bytes) results in an impressive 2mb of additional data.
Do we really need to argue about the justication of 2mb?

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #120 on: December 27, 2020, 05:14:48 AM »
The original objection to this still holds; may I ask why these features justify increasing the per schedule memory consumption?
The cost of doubling the flag size from 16 bits to 32 bits is extremely low. bridgewater-brunel currently has 5000 convoys. If  each convoy had its own unique schedule with 20 stops, that would add at most an additional 0.2MB of memory usage to the existing ~9-10GB. It would provide the space to trivially add another 13 flags in the future without needing to change the data structure again. Such flags could include orders for request stops, waiting for transferring cargo, and using the end of the platform.
Further, there are a number of situations where one or more of "no load", "no unload", and "unload all" would be use:
1. Forcing local passengers to use local services between nearby stops on a long-distance line by setting "no unload" on the down trip and "no load" on the up trip for those stops.
2. Preventing freight transfers from occurring at delivery destinations by setting "no load" at the destination stop.
3. Preventing freight from routing from one hub to another via a low-capacity delivery service (and instead use high-capacity services) that stops at both hubs to pick up cargo.
4. Preventing cargo from loading too early onto a delivery service that serves one hub multiple times per round trip and multiple destinations once per round trip by setting "unload all" either at all the destination stops or all the hub stops.

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #121 on: December 27, 2020, 05:19:19 AM »
When "wait for load" is used, do not load any goods in layover state, unless loading all the available goods will exceed the defined "wait for load" value.
Sounds like a rather simple implementational thing to me, not a big conceptual issue.
This would be a slightly more difficult in my system that does not have an explicit layover state. Applying this to all situations (which would be necessary in my suggestion) might cause overcrowding at stops which could in turn cause deadlocks where goods will not appear in stops because the stop is overcrowded because the convoy won't pick up the goods. This is actually quite a significant problem with my suggestion...

Offline Vladki

  • Devotee
  • *
  • Posts: 3705
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Schedule features: technical discussion
« Reply #122 on: December 27, 2020, 10:51:38 AM »
Speaking about the layovers and loading. The reality for goods trains is that the train loading is often  done by different people that the train crew. So the train crew can have a rest during loading, or even the engine detached and dispatched on another trip. Also goods trains are usually loaded sequentially (car by car), not in parallel like passengers who board themselves.

About the flags for conditional skips. What I had long time in mind is "skip the stop if no cargo for that stop is loaded". This is good for a truck supplying several small shops. Similar option "skip the stop if no cargo is waiting there to be loaded" would be nice for pickups from several farms. (however that assumes some sort of telecommunication is available - phone, telegraph, pigeons...)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #123 on: December 27, 2020, 12:19:34 PM »
Thank you for your thoughts in relation to this, especially the memory calculations: that is helpful. As a reminder, the current design of the schedule boolean flags and associated data members is as follows:

Boolean flags:

(1) wait for time;
(2) lay over;
(3) ignore choose sign;
(4) force range stop;
(5) conditional depart before wait;
(6) conditional depart after wait;
(7) conditional skip;
(8) send trigger;
(9) conditional trigger is for line/convoy;
(10) clear stored triggers on departure;
(11) trigger one only;
(12) couple;
(13) uncouple;
(14) target for link couple is line/convoy;
(15) target for link uncouple is line/convoy; and
(16) target schedule direction (whether reversed) for link uncouple.

Data members:

(0) flags, as above (16-bit);
(1) unique entry ID (16-bit);
(2) condition bitfield (16-bit);
(3) target convoy/line ID (condition trigger) (16-bit);
(4) target convoy/line ID (link/uncouple) (16-bit);
(5) target convoy/line ID (link/uncouple) (16-bit);  and
(6) target unique entry ID for link uncouple (16-bit).

The suggested revised design, I believe, would be the following, (edit with changes shown in orange).

Boolean flags:

(1) wait for time;
(2) lay over;
(3) ignore choose sign;
(4) force range stop;
(5) conditional depart before wait;
(6) conditional depart after wait;
(7) conditional skip;
(8) send trigger;
(9) conditional trigger is for line/convoy;
(10) clear stored triggers on departure;
(11) trigger one only;
(12) couple;
(13) uncouple;
(14) target for link couple is line/convoy;
(15) target for link uncouple is line/convoy;
(16) target schedule direction (whether reversed) for link uncouple;
(17) discharge payload;
(18) set down only;
(19) pick up only;
(20) unused;
(21) unused;
(22) unused;
(23) unused;
(24) unused;
(25) unused;
(26) unused;
(27) unused;
(28) unused;
(29) unused;
(30) unused;
(31) unused; and
(32) unused.


Data members:

(0) flags, as above (32-bit);
(1) unique entry ID (16-bit);
(2) condition bitfield (16-bit);
(3) target convoy/line ID (condition trigger) (16-bit);
(4) target convoy/line ID (link/uncouple) (16-bit);
(5) target convoy/line ID (link/uncouple) (16-bit); 
(6) target unique entry ID for link uncouple (16-bit); and
(7) maximum speed (32-bit).

Note that I have used the term "discharge payload" in place of "unload all" used above and likewise "pick up only" in place of "no unload" and "set down only" in place of "no load", the latter two being standard terminology in the 'bus industry in the UK.

I can see that we do need an explicit layover given what Freddy has explained regarding deadlocks with wait for load. We may wonder whether we need to require the payload to be discharged for a layover for mail and goods, but we will need this to be done for passengers. However, this then gives rise to the complex question of how to deal with this in convoys with both passengers and other sorts of cargo. We probably cannot rely on the "discharge payload" flag for these purposes, as this would be set per schedule, so would have to make this implicit for passengers when the layover flag is set, and have logic in the path explorer specifically for this case.

As to the discussion of the computation of staff costs, Ranran has reminded me of this thread, which discusses the issue in considerably more depth and on which it is probably better to continue that aspect of the discussion.

Edit:  I have modified the above to show the changes in orange. I have also added a maximum speed parameter as discussed here. This is intended to have the effect of limiting the convoy to the set speed (which would be set by the player in km/h but converted to internal speed steps for storage) when its next schedule entry has the speed defined. Setting this to zero would disable the limit, and be the default value.
« Last Edit: December 27, 2020, 02:16:53 PM by jamespetts »

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #124 on: December 28, 2020, 05:09:58 AM »
Questions related to UI design work:
(1) Are wait_for_trigger and broadcast_trigger_on_arrival exclusive?
In other words, is it possible that [->1] [1->] are displayed at the same time?


(2) Can lay_over be considered like a superordinate of wait_for_time?
What triggers convoy to return from lay_over? If it's time, I think it's considered higher than wait_for_time.
Can we make it a lay_over even if the convoy is waiting for another convoy to join?
My intention is that if [LO] contains [*], it doesn't make sense to display both at the same time.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #125 on: December 28, 2020, 11:19:35 AM »
Questions related to UI design work:
(1) Are wait_for_trigger and broadcast_trigger_on_arrival exclusive?
In other words, is it possible that [->1] [1->] are displayed at the same time?

No, these should not be exclusive: it should be possible for a convoy to broadcast one trigger on arrival and then await another.

Quote
(2) Can lay_over be considered like a superordinate of wait_for_time?
What triggers convoy to return from lay_over? If it's time, I think it's considered higher than wait_for_time.
Can we make it a lay_over even if the convoy is waiting for another convoy to join?
My intention is that if [LO] contains [*], it doesn't make sense to display both at the same time.

Not necessarily: a layover might work with a condition rather than a time, so the order might be for the convoy to go into layover until a condition has been fulfilled. A return from layover might be caused either by a time or a trigger.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #126 on: December 28, 2020, 04:19:21 PM »
Thank you for your answer.
I tried to design the schedule UI to be more graphical and intuitive to understand.





There is still no clear vision for wait_for_trigger and broadcast_trigger_on_arrival. (´・ω・`)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #127 on: December 28, 2020, 04:37:20 PM »
That looks very good!

As to a clear vision for the triggers - do you need more information from me in this regard?

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #128 on: December 29, 2020, 03:42:48 PM »
As to a clear vision for the triggers - do you need more information from me in this regard?

Here is the new design. Do you think this is a reasonable design?


vehicle-management-new branch bug:
- There is a problem reading saves prior to ver.15. (After removing debug code.)
All convoys do not belong to the route.

- There is something wrong with the schedule operation.
As soon as you fast forward demo.save, some trains will wait forever.

- Editing the schedule removes all reversing marks ([<<]). (Maybe if you check the added items)

EDIT:
The convoy that waits forever seems to be when the bidirectional convoy reversing at the end point.
« Last Edit: January 02, 2021, 01:03:41 PM by Ranran »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #129 on: December 29, 2020, 05:49:15 PM »
Thank you for this analysis. First of all, as to the graphic, this looks good, but it would help if you could explain the new symbols. Also, a question about the fuel indicator: does this denote a forced range stop or any range stop? It would probably be better if the symbol denoted any range stop, perhaps with a different colour for a forced range stop.

In relation to debugging - I will have to look into that when I get home; thank you for reporting this.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #130 on: December 30, 2020, 12:34:59 AM »
a question about the fuel indicator: does this denote a forced range stop or any range stop? It would probably be better if the symbol denoted any range stop, perhaps with a different colour for a forced range stop.
When is any range stop used? Or is it a plan? Is there such a parameter somewhere?
What color is desirable for force range stop?

Quote
it would help if you could explain the new symbols.
Layover symbol that imitates the sleep state
Hourglass symbol indicating that the waiting time is set at the station
Brown pile indicating that loadind limit is set. The load limit percentage is displayed as a yellow bar.
The color of the line indicates the color of the player
Double line indicates round-trip route. round-trip will show a reverse mark at the end of the schedule. If not, a dashed line will be displayed to indicate that you will return to [1].
A dashed line is displayed for the route to the depot as well.
The station number display is a player-colored square in the case of a depot.
waypoint is an unnumbered circle.
The station has a white background with a square with rounded edges in the color of the station owner.
ignore choose means that the arrival coordinates are fixed, the text color of the coordinates changes to blue, and the information symbol is displayed next to it.
triggers match the increase / decrease colors that can be set in the theme. Therefore, in the above example, the separation is orange, which indicates a minus, and the addition is a turquoise color, which indicates an increase.

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #131 on: December 30, 2020, 01:00:47 AM »
triggers match the increase / decrease colors that can be set in the theme. Therefore, in the above example, the separation is orange, which indicates a minus, and the addition is a turquoise color, which indicates an increase.
If send and receive  are already indicated by the triangle direction and color, the '+' and '-' indicators are probably redundant. They might also be confusing, since '+3' indicates trigger no. 3 rather than 3 triggers.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #132 on: December 30, 2020, 10:35:06 AM »
When is any range stop used? Or is it a plan? Is there such a parameter somewhere?

The logic for this is not written yet, but all the parameters are present. The logic will be that convoys will have to make a range stop every time that the distance to the next stop would exceed the distance specified in the last range parameter since the last range stop or last leaving the depot. For example, if a convoy had a range of 100km, and stops at 40km apart, the first stop after leaving the depot would be 40km from the last range stop or depot visit. The second stop would be 80km away, so the first stop would not need to be a range stop. The third stop, however, would be 140km away from the last depot visit or range stop, so the second stop would need to be a range stop. The third stop would then be 40km from the last range stop; the fourth stop would thus be 80km from the last range stop, so the third stop would not need to be a range stop, and so forth.

Quote
What color is desirable for force range stop?

I would suggest black for an automatic range stop and dark red for a forced range stop.

Quote
Layover symbol that imitates the sleep state

Is that the three quarters circle with the "zzz"? If so, that looks good.

Quote
Hourglass symbol indicating that the waiting time is set at the station

This is a good symbol for this.

Quote
Brown pile indicating that loadind limit is set. The load limit percentage is displayed as a yellow bar.

This seems sensible.

Quote
The color of the line indicates the color of the player

That looks good, although you might want to test all the colours to make sure that nothing clashes with e.g. the highlight colour.

Quote
Double line indicates round-trip route. round-trip will show a reverse mark at the end of the schedule. If not, a dashed line will be displayed to indicate that you will return to [1].
A dashed line is displayed for the route to the depot as well.

That is a nice idea. I wonder whether, instead of the green arrow symbol, it might be clearer to join the two lines in a loop after the first and last stops?

Quote
The station number display is a player-colored square in the case of a depot.

I cannot see an example of this in the displays above; but I wonder whether there might be a clearer way of designating a depot than a square; perhaps a square with an oversized triangle on top of it representing a gabled roof to depict a depot building?

Quote
waypoint is an unnumbered circle.

The station has a white background with a square with rounded edges in the color of the station owner.

That looks good. One thing that might be even better - although not a high priority - is a graphical difference between stops at which only convoys of this line (or only this convoy, if it does not belong to a line) stop and stops at which other lines/lineless convoys stop. This is common on maps of metro networks around the world. One might use a circle with a number to represent a non-interchange stop and a square with a number to represent an interchange stop. The waypoint might either remain as a circle without a number, or switch to a thick perpendicular bisecting line.

Quote
ignore choose means that the arrival coordinates are fixed, the text color of the coordinates changes to blue, and the information symbol is displayed next to it.

I am not sure that this is the clearest way of representing this, as this looks as though it is giving general information - I wonder whether a set of diverging arrows with a red cross through it may be more suitable?

Quote
triggers match the increase / decrease colors that can be set in the theme. Therefore, in the above example, the separation is orange, which indicates a minus, and the addition is a turquoise color, which indicates an increase.

This looks sensible, and I agree with Freddy's suggestion for making this clearer, especially the latter part.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #133 on: January 02, 2021, 01:15:18 PM »
I'm thinking about how to distinguish between symbol designs. So I have a question.
Is the discharge payload intended to make the convoy out of service until the next stop?
Does that mean it's exclusive with minimum load setting and pickup only? It seems pointless at first glance to unload all passengers and reload them. Is it possible?

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #134 on: January 02, 2021, 01:22:44 PM »
I'm thinking about how to distinguish between symbol designs. So I have a question.
Is the discharge payload intended to make the convoy out of service until the next stop?
Does that mean it's exclusive with minimum load setting and pickup only? It seems pointless at first glance to unload all passengers and reload them. Is it possible?
Discharge payload does not need to make convoys out of service. If a convoy discharges payload and allows loading, it will first load the cargo already waiting at the stop.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #135 on: January 02, 2021, 01:46:49 PM »
Discharge payload does not need to make convoys out of service. If a convoy discharges payload and allows loading, it will first load the cargo already waiting at the stop.
What are the benefits of being able to do that?
So what makes it different from being able to set pickup only and setdown only at the same time?
Unloading something that does not need to be disembarked will add to the disembarkation time.
If you want to unload everything once during the layover, you only need to include it in the layover, eliminating the unnecessary operations and confusing things mentioned above.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #136 on: January 04, 2021, 06:23:04 AM »
From observation
convoy will automatically return to depot on a regular basis.
However, convoy spams "convoy has entered a depot" every time it returns to the depot on a schedule, which can be annoying. I think this should be changed.

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #137 on: January 04, 2021, 06:29:40 AM »
What are the benefits of being able to do that?
So what makes it different from being able to set pickup only and setdown only at the same time?
Unloading something that does not need to be disembarked will add to the disembarkation time.
If you want to unload everything once during the layover, you only need to include it in the layover, eliminating the unnecessary operations and confusing things mentioned above.
You may not want there to be any cargo onboard, for example. Maybe you want the convoy empty before going over a weight restricted bridge. Maybe you don't capacity to be filled longer than is absolutely necessary. Goods and passengers will often make questionable decisions that harm operation. I will draw and link an example soon.

Online freddyhayward

  • Devotee
  • *
  • Posts: 645
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #138 on: January 04, 2021, 06:31:44 AM »
However, convoy spams "convoy has entered a depot" every time it returns to the depot on a schedule, which can be annoying. I think this should be changed.
I agree, same with "too long for next stop".

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #139 on: January 04, 2021, 01:33:51 PM »
Note that I'm not saying that feature isn't needed. Rather, I think the feature is a necessary feature.
I just asked about exclusivity with another option.

Quote
You may not want there to be any cargo onboard, for example. Maybe you want the convoy empty before going over a weight restricted bridge. Maybe you don't capacity to be filled longer than is absolutely necessary.
I don't think it can achieve this situation correctly, even if it allows the exclusive option I asked.

If I remember correctly, I think I talked a few months ago at the London Bridge is falling down thread, I talked about piece goods carriages that can't cross the bridge in 1750's.
We can't set the maximum amount of cargo as we really do, so we can't cross the bridge and have to make a detour.
It is not enough to discharge.
If the upper limit cannot be set, it will be unloaded and then loaded with maximum load before departure. Because you can currently set the minimum load capacity, not the maximum load capacity.
I only want to load 8t on a 10t carriage, but when I set the "minimum load:" option to 8t, if 10t of cargo is waiting at the station, it will load 10t.
So allowing multiple options like I asked doesn't make any sense here. There is no point in discharging and then reloading. Rather, it only imposes wasted processing and loading time.
Therefore, the only reliable way to cross the bridge is to cross the bridge with an empty horse, but that is not the goal to achieve.
If you can set an upper limit on the amount of cargo, you only need to automatically unload the surplus, so you do not need to check the discharge option at the same time.
I mean It is useless to discharge all cargo at that case. But discharge is useful if you want to be out of service.

Again, I asked if it is necessary to allow minimum load and discharge at the same time.
It may be useful to have a upper load limit setting option, but keep in mind that there are two types of weights limited by the way: the total weight of the convoy and the axle load. And it should be noted that the weight of the luggage convoy is also different. It may not be possible to respond correctly with% or the weight of the cargo.
« Last Edit: January 04, 2021, 01:44:03 PM by Ranran »