News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

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.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Ranran(retired)

#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
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.

Ranran(retired)

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...
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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.

jamespetts

I have now added support for simple consist orders (i.e., ones not involving dividing and combining) into the path explorer, which was one of the most difficult aspects of this whole project.

I should note, however, that this has not been tested yet, and is likely to need bug fixes.
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 attempted to fix the consist order UI so that I can test consist orders properly, but, after many, many hours of intensive work all of which have failed to make any progress at all, this is not something that is possible for me to do (at least, not within anything approaching a reasonable amount of time - I would anticipate it taking several months of intensive work every night, with a very large proportion of the time spent simply trying to understand how the existing code is intended to work, and that would just be to get the UI to work in a basic way as originally intended).

In the circumstances, it is likely to be difficult to progress and test this properly while there is nobody able to assist with the UI (Ranran is currently marked as "hibernating", which means, I assume, that he is taking a break from Simutrans-Extended development).

I may be able to work on depot related maintenance code and possibly some enhancements to the way that comfort works pending the resumption of UI work, but I do not anticipate being able to progress the actual consist orders work (including testing the basic consist orders or adding the dividing/combining type of consist order) without being able to set up a consist order in the UI and test it.
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

As an update to this: I note that Ranran is now marked as "on indefinite leave". This means that we are not likely to be able to progress this project (and thus make progress towards any major new features) without an alternative way of implementing the UI.

Would anyone else be interested in helping to work on the UI for this? Even a very basic UI, much simpler than Ranran was working on, would be extremely helpful, as we need a UI to be able to test what we have and to continue to add more features. If anyone is potentially interested in this, please let me know in this thread or by private message.

Incidentally, and for the avoidance of doubt, I mean no criticism of Ranran, who has done huge amounts of extremely high quality work to improve Simutrans-Extended over the years: this is just a spare time hobby for all of us, after all.
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(retired)

Quote from: Ranran on indefinite leave on April 02, 2023, 09:51:12 AMIn the work of the EX-15, I had to recreate almost the consist order UI as mentioned earlier, so I was in the middle of the work. (Maybe James's recent changes have caused many conflicts. But I don't have time to deal with it.)
In a few months, when I'm feeling better, I'll remove the Japanese comments and commit the WIP.
I have pushed the WIP for the Ex15 branch as previously announced. (It's been two weeks since I did it though.)
https://github.com/Ranran-the-JuicyPork/simutrans-exp/tree/ex15-sortable-2

This work was done until February of this year, and I cleaned up the code by removing unnecessary Japanese comments before pushing.
It's imperfect, but it won't be resumed for me in the near future unless the obstacles for me are removed. Anyone can take over the rest of the work.
It's probably easier to get basic functionality working than redesigning a text-based UI.


The thread related to ex-15 is somewhat confusing. And the consist order function is very complicated. It is difficult not only for the player but also for the person who helps the coding to grasp the actual condition of the function.
I recommend separating the consist order UI (and schedule) discussion into a separate thread. I think it will be a shortcut to complete this.





Quote from: Ranran on indefinite leave 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. Therefore it requires a lot of time...
As I mentioned in the past consist order UI had to be redesigned.

It has been 4 months since I last did these tasks and I cannot recall exactly what is missing or how far along it is.
Ideally, however, the UI should be as intuitive as possible, and in the process of testing this, please determine what is unimplemented and what is broken.

Here is just what I can recall:

The only important thing I can remember is that I think it was the improper declaration of variable definitions that caused me to initially misunderstand the function and had to redesign it.

There are currently two places in the unfinished consist order UI where alternative text is placed where we are planning to place buttons.
One of them is the label "chk_empty". I was planning to place a checkbox here to indicate whether or not this entry can be skipped, but I suspect that the flag bool empty for that purpose was declared in the wrong place.
But it may just be that I'm misunderstanding the function again.
James please check if this is correct in the vehicle_description_element. And whoever implements the UI will need to implement it properly.

"btn_goods" is a place to put a button to change the catg_index, currently not implemented.

The left and right arrows of the red X button are for swapping the order, but it was not implemented because it was difficult for me to implement a function to swap consist order vectors.
Add a function to swap the consist order vector, and implement the functionality to swap the order if the button is pressed.

-----
I'm sorry that James and I weren't active during the same time period, and that we were demotivated by a Japanese troll.
I won't be working again this year due to other priorities. But I hope this project goes well.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Ranran(retired)

I apologize for the delay in this project due to my absence.
This project must not be ruined by the disasters caused by multiple Japanese people.
I was halfway through this work. I would like to proceed with the work until I reach a good point.



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.
Now I added missing input items to the schedule UI.
Those items will be separated and added in a new tab.

The changes are in the ex15-2401 branch.

The added UI is still in the rough stages, but please let me know if it's possible to test new features.
Please let me know if there are any missing features.


One question is, can convoys be coupled with other players' convoys? Currently, other players' lines and convoys are also displayed in the selector.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Excellent, thank you very much for that. Apologies for the delay in responding: I have been especially busy in work this week.

I have tried to merge the ex15-2401 branch into my local ex15 branch, but have encountered the following errors on compiling (trying at this stage with Linux):

===> CXX dataobj/translator.cc
In file included from dataobj/../script/script.h:12,
                from dataobj/scenario.cc:31:
dataobj/../script/api_function.h: At global scope:
dataobj/../script/api_function.h:381:136: error: 'std::index_sequence' has not been declared
  381 |                static SQInteger call_function_helper(HSQUIRRELVM vm, std::function<R(A1,As...)> const& func, bool act_as_member, std::index_sequence<is...>)
      |                                                                                                                                        ^~~~~~~~~~~~~~
dataobj/../script/api_function.h:381:150: error: expected ',' or '...' before '<' token
  381 |                static SQInteger call_function_helper(HSQUIRRELVM vm, std::function<R(A1,As...)> const& func, bool act_as_member, std::index_sequence<is...>)
      |                                                                                                                                                      ^
dataobj/../script/api_function.h: In static member function 'static SQInteger script_api::call_std_function_t<R(A1, As ...)>::call_function(HSQUIRRELVM, const std::function<R(A1, As ...)>&, bool)':
dataobj/../script/api_function.h:396:83: error: 'index_sequence_for' is not a member of 'std'
  396 |                        return call_function_helper(vm, func, act_as_member, std::index_sequence_for<As...>{});
      |                                                                                  ^~~~~~~~~~~~~~~~~~
dataobj/../script/api_function.h:396:104: error: expected primary-expression before '...' token
  396 |                        return call_function_helper(vm, func, act_as_member, std::index_sequence_for<As...>{});
      |                                                                                                        ^~~
dataobj/../script/api_function.h: At global scope:
dataobj/../script/api_function.h:405:139: error: 'std::index_sequence' has not been declared
  405 |                static SQInteger call_function_helper(HSQUIRRELVM vm, std::function<void(A1,As...)> const& func, bool act_as_member, std::index_sequence<is...>)
      |                                                                                                                                          ^~~~~~~~~~~~~~
dataobj/../script/api_function.h:405:153: error: expected ',' or '...' before '<' token
  405 |                static SQInteger call_function_helper(HSQUIRRELVM vm, std::function<void(A1,As...)> const& func, bool act_as_member, std::index_sequence<is...>)
      |                                                                                                                                                        ^
dataobj/../script/api_function.h: In static member function 'static SQInteger script_api::call_std_function_t<void(A1, As ...)>::call_function(HSQUIRRELVM, const std::function<void(A1, As ...)>&, bool)':
dataobj/../script/api_function.h:419:83: error: 'index_sequence_for' is not a member of 'std'
  419 |                        return call_function_helper(vm, func, act_as_member, std::index_sequence_for<As...>{});
      |                                                                                  ^~~~~~~~~~~~~~~~~~
dataobj/../script/api_function.h:419:104: error: expected primary-expression before '...' token
  419 |                        return call_function_helper(vm, func, act_as_member, std::index_sequence_for<As...>{});
      |                                                                                                        ^~~
dataobj/scenario.cc: In member function 'bool scenario_t::open_info_win(const char*) const':
dataobj/scenario.cc:749:44: warning: unused parameter 'tab' [-Wunused-parameter]
  749 | bool scenario_t::open_info_win(const char* tab) const
      |                                ~~~~~~~~~~~~^~~
make: *** [common.mk:55: simutrans/dataobj/scenario.o] Error 1
make: *** Waiting for unfinished jobs....

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(retired)

At first glance they seem to be related to api scripts, but I haven't made any changes regarding that. CI tests don't see anything other than the same errors as the master branch. So I have no idea as to the reason for that error.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Ranran(retired)

For your information.
Ex-15 branch has been unmaintained for a while, and when I started working on it again, I encountered some build errors that needed to be fixed.

1. In my MSVC environment, finance.cc was missing include <algorithm>
https://github.com/Ranran-the-JuicyPork/simutrans-ex-fix/commit/4566838409628bb2953f6bf88e4be637c18bd2f7

2. MSVC failed to compile due to an error message that says override is marked but not overridden.
https://github.com/Ranran-the-JuicyPork/simutrans-ex-fix/commit/1e9dca9238d12a37a42610d6c2d699dc102794a5

I think recent changes may cause this sort of error depending on the environment.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Quote from: Ranran(retired) on February 11, 2024, 12:33:13 PMFor your information.
Ex-15 branch has been unmaintained for a while, and when I started working on it again, I encountered some build errors that needed to be fixed.

1. In my MSVC environment, finance.cc was missing include <algorithm>
https://github.com/Ranran-the-JuicyPork/simutrans-ex-fix/commit/4566838409628bb2953f6bf88e4be637c18bd2f7

2. MSVC failed to compile due to an error message that says override is marked but not overridden.
https://github.com/Ranran-the-JuicyPork/simutrans-ex-fix/commit/1e9dca9238d12a37a42610d6c2d699dc102794a5

I think recent changes may cause this sort of error depending on the environment.
Thank you for that. I will have to look into this when I get some time.

For reference, for the last few months (since summer 2023), I have not had much time to work on Simutrans, largely because I have been contending with major refurbishments at my house, which have been very disruptive. On top of that, I have been very busy in work, and there is a deadline to work towards on a railway modelling project at the club of which I am a member.

It is very good to see that some progress has been made on making the UI for the consist orders in the ex-15 branch work. If I can get to a point where I can get a working UI test the underlying features in this, then I can hopefully start to work on this again, first of all by working out the reason for these compile errors (and thank you, Ranran, for the assistance above). I am unlikely to be able to do the sort of major work that re-starting work on the ex-15 branch would entail before my house refurbishments are complete, however, and, even at that stage, I will probably want to see if I can fix a few bugs in the current version before turning back to the new version.

In any event, it is very good to know that one of the things that would have made progress in the ex-15 branch more challenging (i.e., me needing to learn how the UI code worked to be able to make big changes to it to allow me to test the features) may well have been overcome. Thank you very much for this contribution.
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.