Started by ACarlotti, February 12, 2018, 09:46:18 PM
0 Members and 1 Guest are viewing this topic.
Quote from: jamespetts on February 12, 2018, 11:01:55 PMA little background on the path explorer might assist (and my apologies if you already know this or have inferred this)....I hope that the above is helpful in your understanding of this important part of the code.
QuoteReturning to your proposal, I find this very interesting. Just one or two questions, if I may, to make sure that I have understood what you suggest. Firstly, do I understand correctly that what you propose would, so far as the internal workings of the path explorer is concerned, be very similar algorithmically in the case of a dividing/combining convoy to passengers/mail/goods alighting at the stop where the split/combine takes place and boarding again after the split/combine? If so, this is a very interesting idea, and I can see that this could readily be more efficient if it can be made to work than what I had imagined.
QuoteSecondly, as to preventing coupling before uncoupling, how had you imagined this working in cases where players specify multiple consecutive stops at the same halt (which is currently not possible because the schedule editing algorithm will automatically delete the second stop, but which may need to be added as part of my current works)?
QuoteThirdly, I note the reference to the possibility of not needing strictly to specify the type of cargo to be carried on each specific vehicle in the consist order. If your system could achieve this flexibility without cost, that would certainly be an advantage. As you probably know, I am currently working on the data structures for the schedule features, including the convoy re-combination. Do you think that that it would be better to remove the data member that specifies this in anticipation of this feature?
QuoteFinally, more generally, are there any other aspects of the data structures for consist orders that you think would need or benefit from adapting in order to fit your planned implementation of the interface between the path explorer and convoy re-combination? I should like to get the data structures written first so that the work on the user interface and multiple aspects of the logic that rely on those data structures can continue in parallel.
Quote from: ACarlotti on February 13, 2018, 12:01:37 AMI was aware of most of this (having encountered serveral of the relevant threads during an unrelated search of the forum). However, this is a helpful summary of the history. It also suggests that there may be room to optimise the path explorer to better incorporate the more recent changes (e.g. incorporating 5 passenger classes shouldn't need 5 times as much computation).
QuoteThat is indeed what I mean. I think I read a comment on an old thread indicating that per-connection waiting time was not implemented due to some combination of more storage requirements and more time to accummulate sufficient data; this proposal is effectively to add per-connection waiting time in a limited number of cases.
QuoteI have not yet considered how this would be implemented, but it seems to be largely a UI problem. One possibility could to automatically reorder entries when closing the schedule window.This restriction came to mind after spending a few days wondering how to deal with the issues of vehicles transferring between convoys multiple times at a single stop; the best way to deal with that seems to be to just disallow it.
QuoteIf this is a data member to enforce this *regardless* of what a player specifies in a consist order, then I think it should be removed. (If it's removal will make it impossible or much harder to specify vehicles by cargo type, then that's another matter, but I don't think that's what you mean.)An analogy to existing systems can also be made here - suppose you have a line which has separate passenger and mail convoys with one station set to wait for a full load. But mail never arrives at that station, so the mail convoys get stuck and never follow the full line schedule. I don't see any substantial difference in how routing should behave regarding that situation, and how it should behave regarding optional vehicles in consist orders.
QuoteI cannot think of any others right now, although I do not remember all the details of what has been written so far. However, I still support the idea (mentioned elsewhere) of being able to route (some) vehicles in a consist according to their contents, along with a flag (per vehicle, or maybe convoy or schedule entry) to indicate that vehicles should only carry loads sharing a common destination or transfer station. This received little comment when I mentioned it before, but perhaps your view of it changes in light of the above?
Quote from: jamespetts on February 13, 2018, 01:25:41 AMThis is definitely interesting - if this were possible more widely, it would be possible more realistically to simulate the logistical consequences of having larger stations, allowing passengers/mail/goods to transfer more quickly between arrival and departure points that are closer inside the station than farther away - although this may introduce more complexities than are manageable.
QuoteI did add data structures for the tags. Did I comment explicitly on routing by contents? I recall thinking that it was not practical, but that may have been in the light of my planned implementation of the path explorer interaction, and so this may need reconsideration if your implementation removes those practical limits. Can you elaborate a little on how this feature would work? Suppose that we have a passenger line with a schedule as follows:A > B > C > D > E > F > G > H [SPLIT]First part after split J > K > L > M > NSecond part after split W > V > X > Y > ZPresumably, when passengers board at A, any vehicle is suitable for travelling to B, C, D, E, F, G or H. Then, one set of vehicles is also suitable for J, K, L, M and N and another set for W, V, X, Y and Z. So, passengers need to know when boarding a vehicle whether (1) it matters what portion of the train that they are in; and (2), if it matters, whether they are in the right portion of the train. Does your suggestion here mean that, if some passengers bound for N got on one carriage at A, no passengers for any destination/transfer other than N could board that same carriage, even if they were bound for B, C, D... K, L, M and could thus travel in the same carriage without difficulty? If so, this would be problematic in operation and would probably not be workable. If you mean something else, can you elaborate a little on what that something else might be?
Quote from: ACarlotti on February 13, 2018, 04:46:49 PMI can't presently see how that would work, as with choose signals it is possible for specific convoys to arrive or depart from anywhere in a station. More realistic transfer times may be possble, however, so this is something I will try to keep in mind.
QuoteTo clarify, I imagine routing according to contents being used solely for freight, and not for passengers. So when loading freight wagons, you ensure that the entire contents of a wagon is going to the same transfer point (being on one of the possible schedules for vehicles in a given convoy). Then at the uncoupling point, the portion that the vehicle ends up in is determined according to its contents. So this is taking the approach of "load it up, and then work out which way it's going when it reaches the divide point", and matches how small amounts of freight are typically moved by rail.An alternative approach, which would be more realistic for passengers, is "work out which way it will go, and then load up accordingly". It is not yet clear to me whether such an approach is feasible for an entire journey, but it should be possible to work out which schedule each vehicle will end up until the first uncouple order following a future coupling order. With uncoupling always preceding coupling at a given stop, this is likely to allow accurate prediction for most realistic schedules (at least in the absence of routing by contents).In both these cases unloading and reloading goods at the dividing point is always available as a last resort, if things go wrong or the loads are unbalanced. A simpler algorithm would apply a fudge of shuffling stuff internally, or defaulting to unloading/reloading; however I think it is feasible and helpful to avoid those fudges where we can. I suppose the main complication in the above is what happens the "route by loading" and "load by routing" schemes collide; I shall have to consider this further.
Quote from: jamespetts on February 13, 2018, 01:25:41 AMQuoteI have not yet considered how this would be implemented, but it seems to be largely a UI problem. One possibility could to automatically reorder entries when closing the schedule window.This restriction came to mind after spending a few days wondering how to deal with the issues of vehicles transferring between convoys multiple times at a single stop; the best way to deal with that seems to be to just disallow it.Yes, I see. Ves - if you are reading this thread, have you any views on the UI aspect of this?