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.

[C] Ranran

Thank you for your report. I think I fixed them.


Editing the schedule will not corrupt the data, but opening the consist order dialog and editing anything will prevent the save from loading.
Editing the consist order and committing it to the schedule_t seems to break the second and subsequent vehicle descriptions.
Also, if you change the entry and re-edit the consist order without closing the schedule dialog, the second and subsequent vehicles will not be acquired correctly. Temporary recording also doesn't seem to work correctly.
char vehicle_name[512];
file->rdwr_str(vehicle_name, 512);
const vehicle_desc_t* desc = vehicle_builder_t::get_info(vehicle_name);
if(desc == nullptr)
{
desc = vehicle_builder_t::get_info(translator::compatibility_name(vehicle_name));
}
vehicle_description.specific_vehicle = desc;

According to the error when saving and loading, an error occurs at this point.
vehicle_desc_t may not be written or read correctly.

[C] Ranran

#211
Quote from: jamespetts on November 06, 2022, 12:24:02 PMWe are missing a UI for the target_id_condition_trigger, target_id_couple, target_id_uncouple and target_unique_entry_uncople data. These data are intended to be used for schedule bifurcation and concatenation.
Quote from: Ves on March 18, 2018, 01:17:19 AMThe couple and uncouple commands along with the specific line and convoy target id trigger I have not touched upon yet, I had an idea that some of this either was done automatically by the GUI, alternatively if it is needed, the commands could live in the modify convoy window, to have more overview there. Or do you think otherwise?

What more functions exists in this manner that would fit well into the schedule window?

Github: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/consist-order-gui
The target_id things seem to have been mentioned a bit earlier, but there doesn't seem to be a detailed explanation of how this works.
Also, Ves didn't do the work of implementing these into the UI as mentioned above, which is why it was overlooked.
What helps implement this is the relationship between those parameters and wait_for_trigger and broadcast_trigger_on_arrival.


Quote6. It would be helpful if the vehicle picker could automatically prevent invalid combinations in the same way as the depot window does.
Added as an option. Enabled by default.

    /*
    * If this is set to true, the vehicle slot is empty.
    * This means that it is permissible for the convoy as
    * assembled by this consist order to have no vehicle
    * in this slot.
    */
    bool empty = true;
I'm wondering if the consist order connectable status display (like the depot dialog) will be rendered difficult by this feature. For example, it usually shows the connectivity of adjacent cars, but it doesn't make sense if the next car is skipped.



Quote7. It would be helpful if the vehicle picker could show whole consist data (e.g., maximum speed, power, weight, etc). for the consist as modified
Previous versions did not implement editor. An editor has been added to the third tab. Did you mean something like this?


EDIT:
Issue: gui_numberinput_t can only handle up to sint32, so UINT32MAX in vehicle description input cannot be handled correctly

jamespetts

I have spent some time investigating the issue relating to the transmission of consist order data and have fixed a number of issues relating to this. I have not tested this fully yet, but the functionality appears to be working in at least some basic tests now.

It would be helpful if you could do some testing on this to see if I have missed anything. Thank you.
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.

[C] Ranran

Quote from: jamespetts on November 20, 2022, 04:55:14 PMIt would be helpful if you could do some testing on this to see if I have missed anything.
If you edit the consistent order of multiple entries, only the first one will be restored after closing the schedule dialog. So save not working properly.

jamespetts

Quote from: Ranran(Hibernating) on December 07, 2022, 11:00:07 AMIf you edit the consistent order of multiple entries, only the first one will be restored after closing the schedule dialog. So save not working properly.
Excellent - thank you for testing that. I believe that I have now fixed this - I should be grateful if you could re-test. (Apologies for being slow with this: I have been exceptionally busy at work in the last few months and then I was ill last week, so I have had limited time for Simutrans lately).
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.

jamespetts

I have been looking at the interface a little more to-day, although I do not have a great amount of time at present. There do seem to be some anomalies in some places. Attempting to delete a consist order entry results in a crash from consist_order_t::get_order() being called on UINT32_MAX_VALUE rather than a valid entry number.

Rules seem not to persist: committing a rule, closing the consist order (but not the schedule) window, re-opening the consist order window for that schedule entry then editing the rule shows the rule to be blank even if data had been added before committing it. I believe that this is a UI issue rather than a data structure issue, since, before closing the schedule window, the consist orders are not committed to their final data structure.

After adding a new consist order, the "append", "insert" and "overwrite" options in the consist order menu seem to repeat, so that there are two of each of those options rather than one of each.

For some reason, the "max brake force" option is always selected whereas the other options are (correctly) not selected. Selecting one of the other options gives incorrect default values for the maximum, i.e., 0 instead of the maximum possible value.

The spacing between each line of the rules is different if editing a rule set than if creating it anew (I am not sure whether this was intended, though?).

At this stage, I have not had a chance to test the "copy consist" tab, as I am not entirely clear on how this is intended to work.

In any event, thank you very much for your work on this so far: it is much appreciated. Very best wishes of the festive season!
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.

[C] Ranran

Quote from: jamespetts on December 24, 2022, 12:02:39 PMRules seem not to persist: committing a rule, closing the consist order (but not the schedule) window, re-opening the consist order window for that schedule entry then editing the rule shows the rule to be blank even if data had been added before committing it. I believe that this is a UI issue rather than a data structure issue, since, before closing the schedule window, the consist orders are not committed to their final data structure.
Quote from: Ranran(Hibernating) on November 09, 2022, 05:49:37 PMIssue: gui_numberinput_t can only handle up to sint32, so UINT32MAX in vehicle description input cannot be handled correctly
As already mentioned, input can only handle up to sint32 and cannot handle uint32 correctly. I've tried to work around this a bit with no success.
Therefore, its implementation has not progressed.

jamespetts

Quote from: Ranran(Hibernating) on December 24, 2022, 01:17:49 PMAs already mentioned, input can only handle up to sint32 and cannot handle uint32 correctly. I've tried to work around this a bit with no success.
Therefore, its implementation has not progressed.
Ahh, I see; I had forgotten that.

Given that we are very unlikely to need such high values, may I suggest progressing for the time being on the basis that you can just truncate all the inputs to a maximum of SINT32_MAX_VALUE? I suggest putting a comment in the code to make clear that you are doing 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.

[C] Ranran

Quote from: jamespetts on December 23, 2022, 10:44:21 PMI believe that I have now fixed this - I should be grateful if you could re-test. (Apologies for being slow with this: I have been exceptionally busy at work in the last few months and then I was ill last week, so I have had limited time for Simutrans lately).
it can't register multiple consist_order.
Some consist order contents are not saved. Perhaps only the last one will be registered.

Register multiple consist_orders using e.g. New order
It will persist until you close the schedule dialog.
When the schedule dialog is closed and reopened, the vehicle that was registered as #1 has been reset and is in an empty order.

jamespetts

Ahh, thank you for this. I was testing with single instances of orders at multiple schedule entries, and that has been fixed. This I will have to look into when I get back from my Christmas holidays.

In the meantime, merry Christmas!
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.

[C] Ranran

QuoteAt this stage, I have not had a chance to test the "copy consist" tab, as I am not entirely clear on how this is intended to work.
I believe copy consist is the simplest way to set order.
This copies the existing convoy order as is.
Therefore, the player can select an existing convoy, or build a convoy in the depot and select it.
You can narrow down what you want to copy by using filters. The simple operation will be easy for players, especially beginners, to understand. So I put this on the first tab.
For example, a convoy belonging to the line, a convoy using a station registered with the line.
Of course, you can also add or remove vehicles from the copied order.
Anyway, if this simple registration method is completed, I believe that we can start implementing the recombination function.
Planned additions on this tab will copy the requirements with the convoy spec as the minimum requirement if the limit_to_same_vehicle option is checked and copied. That is, it is not limited to specific vehicles. You can edit the rule after copying it if necessary.

Quote from: jamespetts on November 06, 2022, 12:24:02 PM5. Modifying the speed limit still does not update the schedule display on the left of the window until something else has changed.
I believe this issue has been fixed.


As a known bug consist_order_gui does not restore the open state correctly after autosaving. Even if you operate the restored dialog, you cannot operate it correctly. This can be difficult to resolve.

Another bug can corrupt the layout of schedule entries, making them not clickable.

jamespetts

I am now looking into this again. Thank you again for your work on this. There seem to be some issues with this at present.

First of all, there is a reproducible crash relating to UI code. Here is a save file for a reproduction case. Steps to reproduce:
  • Open the saved game
  • Open the line management window
  • Edit line
  • Modify consist at this stop at Benridge Marsh Railway Station
  • Add the GWR 517 class from "pick vehicles"
  • Add the GWR autotrailer
  • On the autotrailer, press the left-hand arrow to re-orient it.
  • We get a crash in line 108 of vector_tpl.h, called from line 35 of consist_order_t.cc

Another issue occurs when attempting to delete the default order (no. 1) created when first opening the modify consist at this stop (as at item 4 in the reproduction case above), which is an assertion failure triggered by line 241 of consist_order_t.h.

Another issue occurs when, from step 4, selecting the "vehicle rules" tab and selecting "reset", which causes the Visual Studio address sanitiser to show a use of deallocated memory at line 227 of gui_container.cc.

The "hide incompatible vehicles" checkbox appears to have no effect: even when unchecked, vehicles incompatible with the current convoy in the line (again, see the above saved game) are not available to be selected in the "pick vehicles" tab. This does prevent meaningful use of the consist orders.

In the copy consist and pick vehicles tabs, the text next to "Sort by:" is stuck at "dummy sort combobox"; there is no way of changing 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.

jamespetts

#222
I should note that it is quite difficult to test and correct the issue with multiple consist orders while the issues in the preceding post remain outstanding, as it is currently quite difficult to interact with consist orders generally.

Edit: I am not able really to investigate the issue with multiple instances of consist_order saving when the window is closed as I am not at present even able to store values consistently before closing the window: when I select one and go back to edit it with the consist order window still open (using rules here as I cannot pick vehicles for the reason set out in the preceding post), the values that I have selected when I press "commit" have been erased when I create a new consist order, then return to the original consist order and select "edit". I believe that this is an issue with the UI code rather than the back-end code, as I believe that the back-end code is only activated when the schedule window is closed. If you believe that the position is different, however, please do let me know, and I can investigate this further.

I should note that, at the moment, these are the things that I need to do to make progress towards implementing the consist order feature, which is the current priority: this will be the most difficult part of ex-15 development, and completing this will be one of the most important Simutrans-Extended coding milestones for many years. I am keen to make serious progress on this feature this year, as all other major features (and fundamental balancing) are waiting for this feature in order to be implemented before work can start.
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.

jamespetts

Quote from: [C] Ranran on December 24, 2022, 07:00:31 PMit can't register multiple consist_order.
Some consist order contents are not saved. Perhaps only the last one will be registered.

Register multiple consist_orders using e.g. New order
It will persist until you close the schedule dialog.
When the schedule dialog is closed and reopened, the vehicle that was registered as #1 has been reset and is in an empty order.


I have managed to set up a testing scenario for this reported issue. Having reminded myself in more detail of the code, what I can see is that it is not intended to be possible to have more than one consist order per schedule entry.

Consist orders are stored in a hashtable in the schedule. They key to the hashtable is the entry id and the value is the consist order object. Thus, it is not possible to have more than one consist order per schedule entry.

Apologies for not having remembered this when you first made the report: because these features are so complex and it has been so long since I worked on them last that I do not recall all the details.

The UI for having multiple consist orders per schedule entry will need to be removed - apologies if this has involved any wasted work.
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.

jamespetts

Quote from: [C] Ranran on November 06, 2022, 03:45:11 PMThese changes are complete.

Indeed these parameters seem to exist in the code, but I searched the forums and didn't find any explanation for this.
I'm not exactly sure how to set what.
For example what does target_id refer to? schedule? line? How then does the player obtain it? For example, select from a list. Or do we have to type the ID number directly into the text box?

Picking up on this, I see that I had omitted to answer your question on this topic: my apologies. I am working through issues in relation to this feature set at present, as I am beginning work on implementation of this. The intention of these data members was first discussed in detail in this post in this thread. Some additional detail is discussed in the later parts of this post. Some clarification is given here.

To answer your question more directly: the target_id refers to a line - preferably, players would simply pick the line in question from a list (ideally filtered, but this is not necessary in the first instance). The line in question is either the line that this consist is going to be joined to (target_id_couple) or the line that this consist is going to be assigned to when it has uncoupled from something else (target_id_uncouple). target_unique_entry_uncouple is the unique schedule entry at which the uncoupling will take place. target_id_condition_trigger is the id of the line that will trigger the condition.

Edit: A clarification: correction regarding the above: the coupling and uncoupling targets can be lines or individual convoys, depending on how the couple_target_is_line_or_cnv and uncouple_target_is_line_or_cnv flags are set. Likewise, the conditional trigger id can either be a line or convoy depending on how the cond_trigger_is_line_or_cnv flag is set.
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.

jamespetts

I have now implemented the basic components of the layover feature on the ex-15 branch. The next phase is to implement the most basic type of consist recombination, which is the type that does not use any of the flags, but is triggered when a convoy arrives at a stop and has a consist order set without any flags. This type of consist recombination will use vehicles at the same stop in a laid over state, which is why it was necessary to implement the layover feature first.
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.

[C] Ranran

Quote from: jamespetts on January 21, 2023, 09:08:33 PMI have managed to set up a testing scenario for this reported issue. Having reminded myself in more detail of the code, what I can see is that it is not intended to be possible to have more than one consist order per schedule entry.

Consist orders are stored in a hashtable in the schedule. They key to the hashtable is the entry id and the value is the consist order object. Thus, it is not possible to have more than one consist order per schedule entry.

Apologies for not having remembered this when you first made the report: because these features are so complex and it has been so long since I worked on them last that I do not recall all the details.

The UI for having multiple consist orders per schedule entry will need to be removed - apologies if this has involved any wasted work.
vector_tpl<consist_order_element_t> orders;Why can consist_order_t have multiple consist_order_element_t?
Anyway, it looks like the UI needs to be redesigned.
This has stuck me in that task as I don't know how to handle this.

jamespetts

Quote from: [C] Ranran on January 23, 2023, 11:41:28 AMvector_tpl<consist_order_element_t> orders;Why can consist_order_t have multiple consist_order_element_t?
Anyway, it looks like the UI needs to be redesigned.
This has stuck me in that task as I don't know how to handle this.

My apologies: I think that there may have been some confusion regarding the difference between a consist order and a consist order element.

A consist order element is a single vehicle slot in a consist order. So, for example, if you want your consist to have one locomotive of type X and three carriages of type N, your consist order will have four consist order elements: one specifying X and three specifying N.

While each consist order can have multiple elements, each schedule entry can have only one consist order. The current UI attempts to put multiple consist orders into a single schedule entry, which will not work because the data structures only allow for one.

In terms of the UI design, I think that we can remove the "new order" and "delete order" buttons and the list of different consist orders without replacement. The window should be for the one and only consist order for the schedule entry in question. The remaining part does not, so far as I can make out, need a radical redesign, but there are some issues to address as set out above.

Please let me know if you are stuck on any other element of the UI design for this or any of the other schedule related features and we can discuss what would be the best implementation in this thread.


More generally, I have now added a feature, as discussed earlier on this thread, to the effect that layovers can only happen at stops with layover facilities. Layover facilities can be set in a station extension building by adding the following line to the extension building's .dat file:

layover_enable=1

I have also done the same thing for replenishment stops, but I have not written the code to implement this in the game yet:

replenish_enable=1

In terms of the UI for this, I have made it so that a layover cannot be set in a schedule for a stop that lacks layover facilities and given an explanation of this fact to the player in the schedule UI, but we will need UI for: (1) showing players which extensions have layover facilities at the time of building; (2) showing which already built stations have layover facilities; and (3) giving a warning to a player when a convoy tries to lay over at a stop without facilities (e.g., because they were present when the schedule was set but have since been removed).
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.

[C] Ranran

Quote from: jamespetts on January 24, 2023, 12:41:55 AMIn terms of the UI design, I think that we can remove the "new order" and "delete order" buttons and the list of different consist orders without replacement. The window should be for the one and only consist order for the schedule entry in question. The remaining part does not, so far as I can make out, need a radical redesign, but there are some issues to address as set out above.
Just fixing the layout didn't make sense.
Unfortunately this is a complex UI and I know it was badly designed and will have to be reworked from scratch. Incorrect handling of consist order data structures. Therefore it requires a lot of time...

jamespetts

Quote from: [C] Ranran on January 24, 2023, 12:12:50 PMJust fixing the layout didn't make sense.
Unfortunately this is a complex UI and I know it was badly designed and will have to be reworked from scratch. Incorrect handling of consist order data structures. Therefore it requires a lot of time...

I will leave it to your discretion in that case as to whether to undertake a more fundamental redesign. The interface as it stands has been enough for me to start work on part of the consist re-combination feature (as described above, using laid over convoys), so there will be a little time before the new version of the UI is required.

I realise, incidentally, that it is much harder to create a UI for features that have not been written yet than it is to create a UI for an existing feature. Please let me know if anything is unclear about how this set of features is intended to function so as to make the UI design/implementation task easier.

Thank you very much for your work on this so far; 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.

jamespetts

My apologies: it seems that I have made an error. It has been such a long time since I wrote the original consist order code that I had not recalled how it was intended to work.

Working on some code relating to this now, I realise that there is a further element to the hierarchy of parts of consist orders that I had not previously recalled.

Each consist order can have one or more consist order elements. However, each consist order element can in turn have more than one vehicle description. The way that this is intended to work is that each consist order element is intended to be effectively a vehicle slot for the consist as re-assembled after the processing of the order. Each vehicle description element, in turn, is intended to be an alternative type of vehicle (whether specified directly by type or by a ruleset) that will fill the slot.

So, the intention is not to have multiple alternative consist orders for the whole consist, but rather multiple alternative vehicle descriptions for each slot (consist order element).

I hope that this makes sense, and apologies for the incorrect description in the earlier post. I will need to do some further work to correct some code that does not fully recognise this intended structure.
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.

[C] Ranran

Quote from: jamespetts on January 25, 2023, 01:29:50 AMEach consist order can have one or more consist order elements. However, each consist order element can in turn have more than one vehicle description. The way that this is intended to work is that each consist order element is intended to be effectively a vehicle slot for the consist as re-assembled after the processing of the order. Each vehicle description element, in turn, is intended to be an alternative type of vehicle (whether specified directly by type or by a ruleset) that will fill the slot.

So, the intention is not to have multiple alternative consist orders for the whole consist, but rather multiple alternative vehicle descriptions for each slot (consist order element)

Quote from: [C] Ranran on January 24, 2023, 12:12:50 PMUnfortunately this is a complex UI and I know it was badly designed and will have to be reworked from scratch. Incorrect handling of consist order data structures.
What I said in my previous post meant the consist order UI needed to deal with it.

jamespetts

I have been spending some time working on this over the last few days, and have committed the results to the ex-15 branch. The basic code for consist orders is now implemented (albeit the dividing/joining code is not yet fully implemented; some elements of the joining code have been implemented; the simple type of consist order in which a consist will take vehicles from laid over consists waiting at the same stop is what is implemented so far) and what I have tested of it so far is working. I have successfully separated a locomotive from a rake of carriages, left the carriages at the station in its own newly created consist, set to be laid over, and had the locomotive continue to the next station.

The UI issues mean that I have not yet been able to test this fully yet, although they have had the benefit of allowing me to test some significant edge cases and adapt the code to deal with those edge cases (e.g., a specified consist containing no powered vehicles, a specified consist containing only one vehicle when the previous consist contained 7, etc.).

One thing that I have realised during this implementation process is that it may well not be feasible to implement the priority rules. The data structure for these is below to remind us of what was intended for them.

/*
* These rules define which of available
* vehicles are to be preferred, and do
* not affect what vehicles will be selected
* if <=1 vehicles matching the above rules
* are available
*
* The order of the priorities can be customised
* by changing the position of each of the preferences
* in the array. The default order is that in which
* the elements are arranged above.
*
* + Where the vehicle is a goods carrying vehicle: otherwise, this is ignored
*
* NOTE: This feature is currently unimplemented. This seems to conflict with the
* priority order of vehicle description elements in the consist order elements.
* It is hard to imagine how this might be implemented.
* Query whether this should be removed.
*/

enum rule_flag
{
prefer_high_capacity = (1u << 0),
prefer_high_power = (1u << 1),
prefer_high_tractive_effort = (1u << 2),
prefer_high_brake_force = (1u << 3),
prefer_high_speed = (1u << 4),
prefer_high_running_cost = (1u << 5),
prefer_high_fixed_cost = (1u << 6),
prefer_high_fuel_consumption = (1u << 7),
prefer_high_driver_numbers = (1u << 8),
prefer_high_staff_hundredths = (1u << 9),
prefer_low_capacity = (1u << 10),
prefer_low_power = (1u << 11),
prefer_low_tractive_effort = (1u << 12),
prefer_low_brake_force = (1u << 13),
prefer_low_speed = (1u << 14),
prefer_low_running_cost = (1u << 15),
prefer_low_fixed_cost = (1u << 16),
prefer_low_fuel_consumption = (1u << 17),
prefer_low_driver_numbers = (1u << 18),
prefer_low_staff_hundredths = (1u << 19)
};

static const uint8 max_rule_flags = 20u;

uint32 rule_flags[max_rule_flags]
{ prefer_high_capacity,
prefer_high_power,
prefer_high_tractive_effort,
prefer_high_speed,
prefer_high_running_cost,
prefer_high_fixed_cost,
prefer_high_fuel_consumption,
prefer_high_driver_numbers,
prefer_high_staff_hundredths,
prefer_low_capacity,
prefer_low_power,
prefer_low_tractive_effort,
prefer_low_speed,
prefer_low_running_cost,
prefer_low_fixed_cost,
prefer_low_fuel_consumption,
prefer_low_driver_numbers,
prefer_low_staff_hundredths
};

The difficulty at present is that this clashes with the current priority system, which is to treat each vehicle description in each consist order element as being ranked in order of priority. This was complex enough to implement in code, but I cannot at present see any way of making a large number of priority rules work. I will leave the data structures in for the present in case either I come up with a sensible way of doing this, or anyone else would like to implement this in the future.

For the present, therefore, we do not need a UI for priority rules.

One other small feature that I have added is the ability to mothball vehicles. This is partly implemented in that the simulation aspect of this is implemented (but not tested), but the UI aspect is not yet implemented, meaning that it has not been possible to test this. The idea is that vehicles that are mothballed cease to incur the monthly fixed maintenance cost, but it costs 1 month's worth of fixed maintenance cost to mothball a vehicle and a further 1 month's worth of fixed maintenance cost to unmothball it. The intention is that it should only be possible to mothball vehicles in a depot and that are not part of a convoy/consist, albeit this needs to be enforced via the UI.

I have also added a simuconf.tab setting for the time taken to shunt vehicles in accordance with a consist order, being the shunting_time_seconds setting. The default is 60 seconds, but Pak128.Britain-Ex is set to 120 seconds, to match the non-turntable hauled reverse timing.

The next step is to see whether I can effect a temporary fix of the UI so that I can test a wider range of consist order operations, including the main goal of the initial stage of work on this feature, which is to effect a locomotive change.
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.

jamespetts

I have now implemented the pick up only, set down only and discharge payload options in the schedule.
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.

jamespetts

Working on consist orders, I have now dealt with the fact that convoys can come to be reversed, which is capable of causing problems with consist order matching. I have now dealt with this issue by creating a shadow copy of the convoy and de-reversing it for the purposes of re-assembly before re-reversing it again afterwards.

This has the consequence that the consist order UI must always assume that the consist will be in the forwards direction, and, when copying a consist, must de-reverse it if it is reversed.
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.