Schedule features: technical discussion

[jamespetts]

One thing that I am noticing at present with the schedule dialogue is that some of the options are not being saved, in particular, bt_pickup_only, bt_setdown_only, bt_discharge_payload, lay_over, force_range_stop and ignore_choose_on_arrival. The wait_for_trigger and broadcast_trigger_on_arrival work, but the symbols do not update until the schedule window has been closed and re-opened.

It is difficult to write the logic for the other features without being able to test them, which is difficult without these buttons working, so it would be helpful if you could look into this. Thank you.

[jamespetts]

Excellent, thank you for that. I can confirm that the time display and translations are now fixed. As to the speed limit, this is better, but it seems as though the button is inverted: the speed limit number entry field should be enabled when "enable_speed_limit" is checked and disabled when it is not, but the opposite seems to be the case at present. Other than this, however, this is a definite improvement in design.

I think that Ves had indeed intended to work on what he called a "vehicle manager". I cannot recall precisely how far that he had got with this, but it was not finished (and could not have been, I think, until more progress had been made with the substantive code on this branch than had been made at the time). I cannot remember where this was discussed, but there were forum posts about this, I think. It was planned to have been quite a sophisticated feature, if I recall correctly, not strictly required for the new features in the 15.x branch, but good to have.

As to the consist orders feature, I think that Ves had originally planned to work on this, too, but it was separate from the "vehicle manager" feature. The consist orders feature has been discussed extensively in this thread, although I cannot recall how much discussion specific to the UI that there has been.

As to the livery bug, I will have to look at that. It is probably better for bug reports about the 15.x branch to be put in the "major projects" board rather than the bug reports board until the 15.x branch has been integrated into the master branch.

Thank you for letting me know what was intended by "compartments": this is helpful. I shall consider how best to describe this in English when producing the English translation texts for this part of the UI. It would be helpful to have a list somewhere of the texts that need English translations so that I can be sure that I do not miss any.

In the meantime, I have been working on the replace feature. I have added a new datum to the replace_data_t as follows:

Code Select Expand

enum replacement_time
{
immediate, // Set by the player to replace as soon as the player closes the replace window
on_replenish, // Set by the player to replace as soon as the convoy reaches its next replenishment stop
on_maintenance, // Set by the player to replace as soon as the convoy next visits the depot for maintenance
on_overhaul, // Set by the player to replace as soon as the convoy next visits the depot for an overhaul
manual, // Set by the player to replace only when next manually sent to the depot
automatic // Set by the code to replace forthwith once one of the above conditions should have been fulfilled.
};

...

// When the replacement should take place.
 uint8 replace_at = immediate;

The code comments document what each of the options does. I have implemented replacement on overhaul, on maintenance, on being sent manually to the depot and immediately (the latter of which is the same behaviour as the current master branch), but have yet to implement the on replenish replacement. However, as I cannot easily set these values, I have not been able to test my code yet. It would therefore help me if you could implement these in the UI to allow me to test this. I note that you are working on an updated replacer UI at present.

Do you think that we need any more replace data to deal with the interaction between replacement, overhauls and maintenance?

[jamespetts]

Thank you for that analysis, both as to the issue with respect to saving the schedule flags and also the reversing. I will have to look into those more closely in due course; the schedule saving issue once I have finished inflation and the reversing issue once I start to implement the convoy re-combination features in substance.

However, I think that it will be necessary to have the consist order UI (not the more sophisticated vehicle manager UI that Ves was planning) working at least in a basic state before I can start work on the code for convoy re-combination.

Can I check - is the 2207-overhaul-of-replace-dialog intended to be merged into the 15.x branch?

[jamespetts]

I suspect that the current code is not recognizing as intended after discharge_payload(65536).

Code Select Expand

bool is_flag_set(schedule_entry_flag flag) const { return flag & flags; }I think the related behavior was broken because the expression was wrong.

I have spent some time looking into this. I have tested specifically the is_flag_set() code, and this appears to work. Have a look at my testing code at line 1491 of schedule_gui.cc. Using lay_over as the test datum, setting lay_over here works correctly and TEST_set returns true. The flags value of the relevant schedule entry is correctly set to 2.

However, when the schedule window is closed and re-opened again, the value becomes corrupted. Instead of being 2, it is 1 (which is the flag for wait for time). Setting lay_over again correctly sets the value to 3, and, again, TEST_set evaluates to true. Closing and opening the schedule window, once again the flags value is reset to 1. It seems that something is overwriting the flags value when the schedule window is closed and/or opened. This is not code that I have written, so I am not sure where to look to find where this is happening.

[jamespetts]

Excellent, thank you for that - I will test this fix when I get a chance.

The first thing I got stuck in was that I had no idea how to add, edit or remove constist_order_t.

Do you mean how to edit the code itself or how to edit the data in consist_order_t? If the latter, I may not have added getters and setters yet; that will need to be my next job if this is so that you can get on with this. I had written the consist_order_t code so long ago that I have forgotten quite how far that I had got with it: my apologies. Do clarify which of the two meanings that you intend so that I know whether I need to work on getters and setters for consist_order_t. Thank you.

[jamespetts]

The latter.
It means adding a new empty constist_order_t (and editing or deleting it) to the schedule entry. I think it's the same as adding a new line/convoy to the world. I don't see anything like the definition of tool.

Thank you for clarifying - that is helpful. I will look into this when I next get a chance to work on the code.

[PJMack]

About seven years ago, I downloaded and rewrote a patch for simutrans standard where full vehicles would skip over destinations with nothing to unload and empty vehicles would skip over destinations where there was no potential for picking up goods (set by setting the minimum loading to not zero, a hack but I did not understand the GUI code at the time).  This resulted in being able to create distribution centers where a train would drop goods off at each distribution hub where trucks waiting at that hub would load.  The trucks would then proceed directly to the destinations of the loaded goods to drop them off, then return directly to the hub to pick up or wait for more goods.  Unfortunately, my record keeping abilities from that time were rather lacking and have been unable to find and properly credit the makers of the original patch, however I put some of the code below that I believe I wrote most of but may contain a few lines from "farhrplan_opt.patch".  Although I doubt it will end up back into simutrans or simutrans-extended, I would like to see the new scheduling features allow for such distribution methodologies, as they would not be uncommon for the real world.

Code Select Expand

void convoi_t::advance(){
    //code from fahrplan_opt.patch

    // Advance schedule
    if(loading_level == 0 || loading_level == 100 || get_no_load() || get_withdraw()){
        uint8 this_stop = fpl->get_aktuell();
        bool stop_here;

        do{
            stop_here = false;
            fpl->advance();

            if(is_waypoint(fpl->eintrag[fpl->get_aktuell()].pos)){
                stop_here = true;
                break;
            }
            if(loading_level==0){
                if(fpl->get_current_eintrag().ladegrad>=1)
                    stop_here = true;
            }else{
                for(unsigned i = 0; i<anz_vehikel && !stop_here; i++){
                    vehikel_t* v = fahr[i];
                    if (! v->get_fracht().empty()){
                        FOR(slist_tpl<ware_t>,ware,v->get_fracht()){
                            halthandle_t end_halt = ware.get_ziel();
                            halthandle_t this_halt = haltestelle_t::get_halt(fpl->eintrag[fpl->get_aktuell()].pos,besitzer_p);
                            if(end_halt == this_halt){
                                stop_here = true;
                                break;
                            }
                        }
                    }
                }
            }
        }while(!stop_here && fpl->get_aktuell() != this_stop);
        if(fpl->get_aktuell() == this_stop){
            fpl->advance();
        }
    }else{
        fpl->advance();
    }
}


On a separate note, I have given inflation and balancing of prices some thought and I would recommend that each cost (one-time, monthly, or per km) be stored in an array containing a breakdown of costs by unit.  Element zero would be the cost in simucents (for legacy purposes), and the remainder being up to the pakset designer, for example: British pounds, man-hours train driver, man-hours cook, man-hours mason, gallons oil, tons of coal, chords lumber, cubic yards dirt moved, etc.  The pakset would have a list of conversion rates from those units to simucents for various years, which would be interpolated and placed into an array at the start of each month.  Any accounting would then only need to multiply each element in the cost array by each element in the monthly conversion array and total all elements.

[jamespetts]

I have attempted to merge the latest changes from the master branch into the ex-15 branch, but this has failed as there are some very major merge conflicts. These appear mostly to relate to the UI, code with which I am unfamiliar, so I am not able to solve these conflicts, as I do not know the intention of much of the conflicted code.

Ranran, would you be able to look into the UI related merge conflicts? What I was hoping to do was to add the tool definitions for the consist orders so that you can start work on the UI for this, and also look into the error that you reported relating to vehicle data relating to inflation, but I cannot do that while these merge conflicts remain.

[jamespetts]

I believe the conflict has been resolved. But as previously reported it already had some problems with boot so haven't tested this.

Thank you for this. I believe that I have now fixed the crash on loading relating to inflation data - thank you for spotting this.

[jamespetts]

The latter.
It means adding a new empty constist_order_t (and editing or deleting it) to the schedule entry. I think it's the same as adding a new line/convoy to the world. I don't see anything like the definition of tool.

I have spent a little time looking into this. This is in fact already incorporated into the tool_change_line_t. This will copy the schedule and transmit it over the network. Consist orders are just data contained in the schedule, and there is specific code for copying and transmitting the consist order specific data using the ssprintf_schedule() and sscanf_schedule().

Thus, the UI just needs to create and populate the consist orders attached to a particular schedule, and then use the existing tool_change_line_t to transmit this over the network: the code should already be there for that.

I hope that this helps - please let me know if anything is unclear or if you think that anything is still missing.

[jamespetts]

Creating the consist order does not require a network tool, since it can be created locally on a client and then transmitted once it is applied to a schedule. I believe that consist orders are only available on schedules that belong to a line.

Were you referring to network tools or did you mean to refer to some other sort of tool? So far as I can see, all that the UI need to do is to call a constructor of the consist_order_t object, allow the user to modify data in that object and then use the line tool as described to commit it to a line (over the network if applicable).

Does this assist?

Did you need the get and set methods written?

[jamespetts]

I wanted to look into this this afternoon, but, unfortunately, once I merged the master branch into the ex-15 branch, the game consistently crashes on startup when reading a pakset (specifically, when registering a wayobj_desc). It does this irrespective of whether it is reading a 14.x or 15.x pakset. I am not sure which particular set of changes caused this, but I suspect that it is linked to some of the merging from Standard, as none of the other recent changes on the master branch affect loading paksets. Incorporating your Ex-15-2211 changes did not alter this situation.

I am not going to be able to progress with this until this issue has been solved.

[jamespetts]

I think that I have found and applied a fix for the above, although I am not sure that this deals with the underlying problem. Nevertheless, the game does now appear to work.

[jamespetts]

I have now had a chance to look at the schedule UI. First of all, I have added some English translation texts for them. I will deal with the remaining matters in an enumerated list below.

Schedule UI

• The overall layout is much better than the existing schedule window in 14.x.
• The display does not seem to update properly when enabling/disabling a speed limit: I need to make some other change (e.g. modifying the wait for trigger) for this to update.
• The symbol for "ignore choose signal on arrival" is confusing, as a lower case "i" in a circle usually means "information" - this may need a different symbol (perhaps a junction signal with a cross through it?)
• The "modify_convoy" button is so wide that there is no padding between it and the right hand edge of the window.

I attempted to review the consist order UI, but unfortunately, this crashes on opening. The issue appears to be related to trying to write -1 to an unsigned integer, which integer is used as the index of a vector; the unsigned integer underflows to a very high number, which is then out of bounds for the vector.

This also exposes another problem on the ex-15 branch - the fatal error dialogue seems to have stopped working. Instead of showing the fatal error dialogue when trying to read an array beyond bounds, the game simply freezes.

[jamespetts]

Excellent, thank you for that. Some further feedback follows.

Schedule UI

• The tooltip for the speed limit would work better attached to the "enable speed limit" button rather than the speed limit number input, I think.
• It would be better for the "Speed limit:" text to be grey if "enable speed limit" has not been set.
• There needs to be a space between "Speed limit:" and the decrement button for the speed limit adjustment button.
• The "Modify consist" button now has a better width.
• Modifying the speed limit still does not update the schedule display on the left of the window until something else has changed.
• I have modified reference to "convoy" to "consist" - I should be grateful if all future references to "convoy" could be changed to "consist", as I intend to make this consistent throughout the UI from version 15.x onwards ("convoy" has always been a confusing and inaccurate name).
• We 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.

Consist order UI

• I have similarly modified "convoy" to "consist".
• The box for the vehicle picker has no padding at the lower and left-hand edges.
• The current behaviour seems to be in the vehicle picker to include nothing other than locomotives in the list until a filter has been selected. This is likely to be confusing for players. I suggest including everything unless a filter be selected.
• The vehicles displayed in the add vehicles box seem to exclude many items that should not be excluded. For example, in the Pak128.Britain-Ex demo game, creating a new consist order for a railway schedule will show only the LMS 8F locomotive and tender with no type of goods selected. In fact, there are many other types of locomotives available.
• The detail display to the right for vehicles in the vehicle picker looks very good and is easy to understand.
• It would be helpful if the vehicle picker could automatically prevent invalid combinations in the same way as the depot window does.
• 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
• It would be helpful if the consist order window could include a simple one line explanation somewhere for what players are supposed to be doing, something like, "Select the vehicles that you want to make up this consist at this stop and onwards on this schedule".
• It would be helpful if the consist order window would automatically start with the consist that is already on the line (and, if there is more than one type, the most common type on that line, or, if none are more common than others, the first in order) to make it clearer to the player what is to be done and to reduce workload.

As to this:

But I didn't understand how to commit it using with network tool.
I'm not familiar with the schedule edit code and you said tool_change_line_t but the tangle of schedule tools and line tools sank my ship.
Any help with this would be appreciated. 

The basic idea is that the consist order is just another datum in the schedule: you create the consist order on the stack (i.e., as a local variable, not using the "new" command) and then just assign (copy) the consist order object to the inthashtable representing the consist order for the particular entry in the schedule to which it relates. Then, you commit the changes to the schedule in the same way as you would commit a simpler change (e.g., adding or removing an entry).

If, after the above explanation, you are still having difficulty, what I think would be the easiest is if you add a place in the UI code where the consist order should be committed to the schedule, let me know where that is, and I will see if I can code the actual committing to the schedule part. Would this be workable?

Thank you for your work on this: it is much appreciated.

[jamespetts]

Thank you for this. Can you commit your work so far so that I can work from there?

[jamespetts]

I pushed a testing commit.

Thank you for this. I think that I have managed to fix the issue with the schedule changes not committing - can you test this to check that this is working? If that is working, is there anything else that I need to do before you can continue work on the consist order dialogue?

I will reply to your other questions when I have a little more time.

[ceeac]

Regarding the issues with consist_order_t, there is this piece of code in consist_order_t.h:

Code Select Expand

consist_order_element_t& get_order(uint32 element_number)
{
if (element_number > orders.get_count()) { return consist_order_element_t(); }
return orders[element_number];
}
which is invalid:

Code Select Expand

bauer/../tpl/../dataobj/../dataobj/consist_order_t.h:237:53: error: non-const lvalue reference to type 'consist_order_element_t' cannot bind to a temporary of type 'consist_order_element_t'
                if (element_number > orders.get_count()) { return consist_order_element_t(); }
                                                                  ^~~~~~~~~~~~~~~~~~~~~~~~~


[jamespetts]

Ranran - thank you for that. I am having some trouble merging your ex15-2211 branch, however, in that I get the following merge error in simwin.h:

Code Select Expand

<<<<<<< HEAD
+ magic_script_error,
  =======
+ magic_consist_order_rdwr_dummy, // only used to load/save
  >>>>>>> 3b326559462272a0585b8ab91afeafa50c644460


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

[jamespetts]

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.

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

[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!

[jamespetts]

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.

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.

[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!

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

[jamespetts]

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.

[jamespetts]

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.

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.

[jamespetts]

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

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

[jamespetts]

Code Select Expand

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.

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:

Code Select Expand

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:

Code Select Expand

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

[jamespetts]

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

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.

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

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

Code Select Expand

/*
* 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.

[jamespetts]

I have now implemented the pick up only, set down only and discharge payload options in the schedule.

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