News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

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

#175
QuoteThe "modify_convoy" button does not work, but I infer that this is because this interface has not been designed yet - I presume that this is for consist orders? I cannot comment on the completeness of what you have implemented here without seeing the implementation of the modify_convoy dialogue.
QuoteAs 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.
I think the vehicle manager is an independent entity.

https://forum.simutrans.com/index.php/topic,18113.msg184276.html#msg184276
And as far as I can tell from this thread, there's little mention of the UI, and Ves seems to have been working on something, but I couldn't find such code in his repository.
Therefore, if we want to implement this, we have to start the implementation of this UI from a blank slate. I think this will be a tremendous task.
First of all, as ves hinted at, there is currently no optimal vehicle pick component to achieve this.

Secondly, what we may have overlooked is that the consistent order must take into account the reversing state of the vehicle. vehicle_desc_t alone does not have a field to set the reverse state.
I'm not sure, but since OPRP is based on standard, I suspect that convoys with opposite orientations will not bind to each other. But with extended, that happens.
For example, when you open the replace frame of a convoy that is reverse-cruising in the replace frame of the current master branch, the connections you see are completely corrupted.
However, regarding this problem, I think that I fixed this in the overhaul branch of the replace dialog by the method via vehicle_t. This is just to change the order back and always change the same order when the convoy is reversed.
In the recombination system, however, we have to go one step further and maintain, understand and manage the reversing state.
It should be noted that if the vehicle is reversed, the coupling constraint will also be reversed.
Double-headed electric locomotives may not care about orientation. In other words, it may be oriented freely.
Players have to know that and set up the configuration, and the system and UI have to deal with it, which is feared to be very complicated.

Thirdly, as previously discussed with ACarlotti, coupling constraint originally had to consider the reversal state, but now it does not consider which side to connect with.
For example, the rear of the locomotive requires a tender, but if the tender is reversed, it will be judged to be in a good connection.

Fourthly, if the recombination system causes the convoy's configuration to change independently of the convoy's reverse state, the reversing process must also be revisited.
That is, currently the vehicle can be in the reverse state only when the convoy is in the revese state. This condition no longer holds.
For example, when a convoy that is not in the reverse state of all vehicles is moving forward, a convoy in the opposite direction may be added at the station. As such, convoy is not in the reverse state, but there is a possibility that vehicles in the reverse state will be mixed. Therefore, it is necessary to review the process of changing direction.

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

#177
Quote from: jamespetts on July 10, 2022, 02:36:09 PMCan I check - is the 2207-overhaul-of-replace-dialog intended to be merged into the 15.x branch?
It is intended to be merged in the master and 15.0. But note that 2207-overhaul-of-replace-dialog is an old branch.
The latest branch is 2207-overhaul-of-depot-dialog-v3.
It's a large update of the basic and important dialogs with lots of changes, and I think it needs to be thoroughly tested, so I think it needs to be thoroughly tested on the master branch.
Also, without this change, updating the depot/replace dialog for 15.0 (adding many parameters) would be difficult.
The current old style depot dialog is a bit broken at this point as some ppl reported. I'm not sure if this is a conflict with the old code and it's difficult to fix.
Anyway, the update of depot dialog and replace dialog is almost completed, so basic test is possible.

EDIT:
Unfortunately, there seems to be a processing error somewhere in depot code.

jamespetts

Quote from: Ranran on July 06, 2022, 02:22:55 PMI suspect that the current code is not recognizing as intended after discharge_payload(65536).


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

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

Follow Simutrans-Extended on Facebook.

Ranran

Quote from: jamespetts on July 10, 2022, 11:54:01 PMI have spent some time looking into this. I have tested specifically the is_flag_set() code, and this appears to work.
I fixed it last week. The #174 post was intended to report that. It is possible that the correct English could not be written.

Ranran

Quote from: jamespetts on July 10, 2022, 11:54:01 PMUsing 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.
And I believe now I have fixed it.

Ranran

Quote from: Ranran on July 09, 2022, 08:43:53 AMwe have to start the implementation of this UI from a blank slate. I think this will be a tremendous task.
Quote from: jamespetts on July 10, 2022, 02:36:09 PMHowever, 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.
The first thing I got stuck in was that I had no idea how to add, edit or remove constist_order_t.

jamespetts

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

Quote from: Ranran on July 11, 2022, 04:08:52 PMThe 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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ranran

Quote from: jamespetts on July 11, 2022, 04:12:22 PMDo 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.
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.

jamespetts

Quote from: Ranran on July 11, 2022, 04:17:43 PMThe 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.
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

Incorporating the update of the master branch seems to cause problems in obtaining vehicle data regarding inflation and prevents the game from launching.

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.

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.