News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Schedule features: technical discussion

Started by jamespetts, January 22, 2018, 11:15:36 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

freddyhayward

Quote from: Ranran on December 24, 2020, 02:03:18 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.

Ranran

#106
Quote from: freddyhayward on December 24, 2020, 02:25:40 AMI 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.

freddyhayward

Quote from: Ranran on December 24, 2020, 02:33:29 AMDo 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.

jamespetts

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.

Quote from: freddyhayward on December 24, 2020, 01:45:32 AM
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.

Quote from: Ranran on December 24, 2020, 02:03:18 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.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sirius

#109
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)

jamespetts

Quote from: Freahk 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)

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

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

#111
The freddy fix can load 14.x but crashes in demo.sve.

EDIT:

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.

freddyhayward

Quote from: Ranran on December 25, 2020, 10:36:46 AMI 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.

Ranran

uint16 max_brake_force = UINT32_MAX_VALUE;
I noticed a compiler warning of consist_order_t.h.

jamespetts

Quote from: Ranran on December 25, 2020, 04:08:46 PM
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

freddyhayward

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.

jamespetts

Quote from: freddyhayward 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.


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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

freddyhayward

#117
Quote from: jamespetts on December 26, 2020, 12:04:18 PMImagine, 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.

Quote from: jamespetts on December 26, 2020, 12:04:18 PM
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:
Quote from: jamespetts on December 26, 2020, 12:04:18 PMEdit: 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:
Quote from: jamespetts on February 08, 2018, 12:50:17 AMAs 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.

jamespetts

Quote from: freddyhayward on December 26, 2020, 12:32:03 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.

QuoteIf 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.

QuoteThese 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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sirius

Quote from: jamespetts on December 26, 2020, 02:14:17 PMYes, 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.

Quote from: jamespetts on December 26, 2020, 02:14:17 PMAnother 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.

Quote from: jamespetts on December 26, 2020, 02:14:17 PMThe 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?

freddyhayward

Quote from: jamespetts on December 26, 2020, 02:14:17 PM
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.

freddyhayward

Quote from: Freahk on December 27, 2020, 04:21:03 AMWhen "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...

Vladki

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...)

jamespetts

#123
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

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.

jamespetts

Quote from: Ranran 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?

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

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. (´・ω・`)

jamespetts

That looks very good!

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

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

#128
Quote from: jamespetts on December 28, 2020, 04:37:20 PMAs 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.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

Quote from: jamespetts on December 29, 2020, 05:49:15 PMa 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?

Quoteit 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.

freddyhayward

Quote from: Ranran on December 30, 2020, 12:34:59 AMtriggers 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.

jamespetts

Quote from: Ranran on December 30, 2020, 12:34:59 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.

QuoteWhat color is desirable for force range stop?

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

QuoteLayover symbol that imitates the sleep state

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

QuoteHourglass symbol indicating that the waiting time is set at the station

This is a good symbol for this.

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

This seems sensible.

QuoteThe 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?

QuoteThe 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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

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?

freddyhayward

Quote from: Ranran on January 02, 2021, 01:15:18 PMI'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.

Ranran

Quote from: freddyhayward on January 02, 2021, 01:22:44 PMDischarge 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.

Ranran

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.

freddyhayward

Quote from: Ranran on January 02, 2021, 01:46:49 PMWhat 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.

freddyhayward

Quote from: Ranran on January 04, 2021, 06:23:04 AMHowever, 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".

Ranran

#139
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.

QuoteYou 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.