Hi James and everyone,
I have been thinking and thinking over and over again how to best make the new "consist order" (in lack of a better name) window, and I think I am a little stuck in the thought process. I troubble foresee how the window should look like, what buttons are needed, what layout is best to use etc.
What I in my mind had thought should be possible to do in the new window:
* Select specifically what vehicles, by some vehicle ID or similar, that should be detached, or attempted to be attached.
* Select what type of vehicle, by vehicle name, that should be detached, or attempted to be attached.
* Select what properties a vehicle should posses, or not posses, that should be detached, or attempted to be attached.
- This will include such things like:
- - by cargo
- - by weight
- - by speed
- - etcetc
* Select "the most something" from the vehicles available, for instance, the fastest one, or the lightest one.
James suggested, and I also find that a good idea, to use the "convoy-assembler", which is the GUI that the depot and the replacer window use. One could create new consist order window, and basicly poulate it with the convoy-assembler, and you would already have all the same possibilities to select vehicles into a convoy, as you would in a depot.
However, we need more functions out of it than just to select types of vehicles:
* An overview of what the old convoy(s) looks like (What if there are different types of convoys?)
* An overview of what the reassembled convoy will look like. (basicly exists already, however, might need to be altered to show properly)
* "Wildcard" vehicles: We dont necessary know what specific cars we want to drop of or attach, but we need to represent them somehow.
* Change/ignore/lock the order of the vehicles (does it matter?)?
* Modify the field of selectable vehicles to vehicles you own across all convoys
* If needed, some ability to select a specific vehicle you own by its ID (select type of vehicle -> select vehicle ID from combobox)
Selecting wildcard-vehicles based upon certain properties, like wheight, can be done either inside the convoy-assembler or directly in the window. Preferably inside the assembler, since one dont know what that functionally could be used for in the future, but also it might be easier to program.
I imagine it is done by selecting a "wildcard" vehicle, and then specify the properties using comboboxes. To keep it simple, as few comboboxes should be used as possible, but since there is two ways of defining the properties of wildcard vehicles ("max X tonnes", or "as light as possible") there needs to be two separate sections that both works in parallel (etc "max X tonnes AND as fast as possible").
Then the question with the amount of vehicles. If you have a convoy to be equipped with *a lot* of coal cars, it might be very overwhealming and excessive to have to press the wildcard-vehicle billions of times, as well as specify the parameters each times. Therefore some sort of "copy" function, or a place where you can write how many cars you want. This could be usefull also in the depot window, when you have excessive amounts of cars. In addition, one could consider the display of the convoys:
* If you want to display it as they currently are displayed in the depot window, all vehicles lined up after each other, or
* If you would want each vehicle lined up once, and then the amount of those cars currently in the assembly.
What do you think?
I gave the consist order window a heavy thaught the other day, and I think I came up with a solution how to initiate the consist order window. The problem I have had is how the window should be identifyed, ie what it should be tied to. The two "reassign classes" windows are tied to either the windows of the convoy or the schedule, and the vehicle manager is tied directly to the player, just like line management and economics, so all those where "easy". The consist_order_t, not really being tied to anything (what I can see) but rather a loose new element, had me puzzled with this.
I have copied the code from the signal.cc "show_info()" and as for now just renamed it properly but nothing else. Am I making the correct assumption that "consist_order_t" can be used in this way (similar to how simconvoy etc are handled)? Am I also correct in my assumption that there will be one instance of "consist_order_t" for every entry in every schedule?
What I would like to do is this:
void consist_order_t::show_info()
{
create_win(new consist_order_info(self), w_info, magic_consist_order_info + self.get_id());
}
The way I anticipate you would identify the consist order, and hence get the GUI for it, is to have something like this:
schedule->entries[schedule->get_current_stop()].get_consist_order_t::show_info();
... in the schedule dialog.
Do you think this would work?
Thank you for your continuing work on this, and my apologies that I had not got around to replying to your first post: your GUI thoughts relating to this major development project are most welcome.
I have not yet had time to review this in detail, and it may be a little while before I get to things relating to the maintenance/re-combination project; I am trying to complete a number of relatively lightweight but high impact changes and bug fixes first (including incorporating others' changes that are complete or nearly complete, such as Ranran's GUI enhancements), set up the Bridgewater-Brunel server to be workable again (starting a new game if necessary; but only once the things that need to be dealt with at map generation are complete), and then return to this.
It will be easier for me to think about the complex but important issues relating to the re-combination/maintenance project all at the same time, so please bear with me whilst I deal with the shorter term things first. Your ongoing work on this is much appreciated.
In the meantime, anyone else is welcome to give input as to the implementation of this, which would be helpful to both me and (no doubt) Ves.
I don't think I understand this much,
Simply put
(1st car) Electric Locomotive
(2nd car) open waggon for bulk good
...
(10th car) open waggon for bulk good
(last car) brake van
If such conditions are set by the player, a convoy configuration is automatically created, is my understanding correct?
Also we can add further conditions such as maximum speed and axle load, right?
Ranran - this new UI is intended to work with the features discussed here (https://forum.simutrans.com/index.php/topic,17852.0.html); that is an ongoing project which has been dormant for some time, but which I am hoping to re-start this year.
Thanks for commenting! I know you have a lot of fixes going on, so no worries! This is a long term project indeed.
I have implemented it as written in my post, and it appears to work, that means only that it is compiling without any errors.
Eventually you (or perhaps I can do it) will create functions like create_consist_order() and get_consist_order() and then it will be obvious wether this way of defining the GUI will work.
I must say that slot of time has passed since my OP in this thread, and I think I have a relative clear vision for how the GUI should be done.
But one question is bugging me though:
Which method should be used for picking vehicles? The GUI convoy assembler (aka the depot window), or the way you pick vehicles in the vehicle manager?
Perhaps I am blinded after working so much with the vehicle manager, but I find that way of picking vehicles somewhat easier than in the depot window. Mostly, I think it is because there are texts, including the name, alongside each entry, so you don't have to hover with the mouse.
Gui convoy assembler, on the other hand, is more suited for landscape windows, just like the depot-, replace- and consist order windows are.
Granted, it is the sort- and display by fields that makes it easy, and those could just be added to the gui convoy assembler. But you would still miss the text for each entry.
Any views on the matter?
Ranran, there is a (somewhat heavy read :o) thread where the entire feature is heavily discussed. But pretty much yes, that is sort of how it works, although you need to buy the vehicles first etc. Find and read that thread if you have interest! :D
Thank you for your work on this. If you could implement the code to link the GUI to the data structures, that would be very helpful, as that would then leave me to focus on the relationship between the data structures and the actual simulation and the simulation-relevant algorithms relating to the data structures.
As to the best GUI profile here, I have not yet had a chance to test the vehicle manager so cannot comment at this stage; what are the views of those who have had a chance to test this?
Yes, I will aim to prepare as much as possible!
However, I would ask you to implement the basic "create consist order" routine first. I suppose that it is a pretty standard routine, that just creates and deletes instances of consist_order_t's. Partly so you get it the way you want it, but mostly because I dont feel happy creating such a fundamental part of the code.
When that is coded, I can link it to the "consist orders" button in the schedule window and access the consist orders and its GUI through that.
I know that you have your hands full, but if you ever want to code something different than bug-fixes for an evening, then I would really appreciate this! ^-^
I have a question.
One of the current vehicle pick methods in the Consist Order UI I am working on is intended to select vehicles from player owned vehicles, but is it possible for convoy-recombination to mix vehicles from other players? If so this increases complexity in all aspects. Rejection of join vehicle for each player, Paying fares, fairness of which vehicle passengers choose, charts, UI display, etc.
I pushed a mockup of the Consist Order UI to my ex15-ui branch.
As I mentioned a few days ago, it looks like it's missing the function to add and edit orders, so it's just a paper mache now.
Many dummy labels are still placed.
But it's somewhat possible to imagine how this dialog works, and at this point you may be able to give some advice as to whether this meets the required functionality.
Any advice on this would be very helpful as I may not know exactly about this feature.
I thought there were three patterns for how to set the order element.
The first is to select a specific vehicle; the second is to select a convoy and copy its order; the third is to set a wildcard instead of a unique vehicle.
The first two have two tabs placed for that purpose in the current mockup; the third has nothing implemented yet. If the first one works, this feature can be tested and its implementation takes precedence.
The method of copying convoy has a problem with vehicle reversing, as pointed out a few days ago.
As I pointed out when implementing the Vehicle color bar, this bar lacks some information about vehicle connectivity. A debug display for this is currently in place.
The vehicle spec table in this dialog displays these parameters based on the rule flags below. (However, capacity is still a dummy)
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_low_capacity = (1u << 7),
prefer_low_power = (1u << 8),
prefer_low_tractive_effort = (1u << 9),
prefer_low_brake_force = (1u << 10),
prefer_low_speed = (1u << 11),
prefer_low_running_cost = (1u << 12),
prefer_low_fixed_cost = (1u << 13)
};
In my opinion, the axle load limit often makes player mad in extended. Therefore, it would be nice for the player to specify the maximum axle load.
Locomotives are very heavy, so in Japan there are locomotive types with different axle loads, and the suitable one was selected and used.
EDIT:
uint32 min_range = 0;
uint32 max_range = UINT32_MAX_VALUE;
uint32 max_weight = UINT32_MAX_VALUE;
uint32 min_weight = 0;
uint32 max_axle_load = UINT32_MAX_VALUE;
uint32 min_axle_load = 0;
Are some rule flags missing?