Started by jamespetts, April 11, 2017, 02:03:56 AM
0 Members and 1 Guest are viewing this topic.
Quote from: zook2 on April 18, 2017, 03:26:39 AMCould you please elaborate these points for me:"Because at present a convoy entering or leaving a depot triggers a re-run of the path explorer, this would have to be altered so as only to run the path explorer when entering a depot for storage, not for maintenance. The path explorer would ignore depot visits for the purpose of calculating routes."I don't know what exactly the explorer does, or why that change is necessary.
Quote"Further, convoys should be able to enter a state of layover at any stop, as set by the schedule: but this would require discharging all of the passengers/mail/cargo at that stop, and have a minimum dwell time for putting the vehicle into a state of layover. During a layover, no fixed maintenance costs would be charged."I'm not sure I understand what the purpose of layovers would be, as opposed to refueling.
QuoteAlso, I think a lot would depend on how the parameters for overhauls, availability, refueling etc. are actually being set in the pak. For example, a city bus that usually takes 2-3 minutes to load/unload at each stop shouldn't take 20 minutes to refuel, or it might block the stop for that time and cause serious traffic jams and disruptions in a tight network. Alternatively, the player would have to build a large number of choose-stops (if that's the term) for stops where refueling is required. Or you'd need to make refueling non-blocking.
Quote from: jamespetts on December 10, 2017, 01:08:26 AMAs to the shipyard, the plan is to add a feature whereby it will be necessary for vehicles regularly to visit depots
Quote from: jamespetts on January 29, 2018, 09:58:03 PM(1) Create the convoy in the depot for the A > B section.
Quote(2) Create the schedule as normal for a line for the whole route.
Quote(3) Create a new convoy consisting of only the locomotive for the A > C section at a depot at B.
Quote(4) Set its schedule to a line consisting of be B depot > B.
Quote(5) Set a conditional depart flag from B depot with a trigger of, e.g. 1 for the locomotive only convoy/line.
Quote(6) Set a conditional trigger on arrival for the main convoy at B with the number 1 and the target of the line of the locomotive.
Quote(7) Set the main convoy to have both a couple and uncouple flag at B
Quote( Set the consist orders at B to comprise the train with the old locomotive detached and the new locomotive attached.
Quote(9) Add a new line from B > B depot
Quote(10) Set the uncouple target to this line with the unique entry ID for B so that the locomotive that detaches from the train goes to the depot after the train departs
Quote(11) Set a conditional depart from the depot with this schedule with a trigger number of, e.g. 2.
Quote(12) (The steps to repeat the process in reverse for replacing the locomotive for the B > A run should be able to be inferred from the above).
Quote from: Ves on January 29, 2018, 11:05:45 PMThank you for the break down! I understand somethings better now, but other things i would still like some clarifications on:The "convoy" in this sense means both the first locomotive (A <-> B) as well as the car?
QuoteSo create a schedule with these entries, as well as ticking the "reverse" tag:Stop AStop BStop CI call this schedule "Schedule 1"
QuoteMaybe it is just a mistype, but we did not want any locomotive to travel between A and C, only the car. Should I assume you mean ... consisting of only the locomotive for the B > C section ...?
QuoteOk, so a second line is created "Schedule 2"Is the "1" just a name/number for the trigger? In which case, could I theoretical name it what I want (extension request :) )?
QuoteYou say I set it from the depot entry of the schedule, so this would mean that the locomotive will in this case stay inside the depot until the trigger is released?
QuoteI call it "Trigger 1"Great, so when this convoy arrives at the station, it releases Trigger 1. That makes the locomotive in the depot wake up and continue its schedule, out from the depot.I assume the triggers are set in the schedules.
QuoteAgain, this is set in the Schedule 1?
QuoteHere is one of the big questions: How should I acces the consist orders at B? via Schedule 1, Schedule 2, clicking on a button in the info window of station B to perhaps see all consist orders to be performed on this station?I remember you talked about using the gui convoy assembler together with the consist orders, so I assume it is going to be a new window, separate from the schedule.
QuoteBut asside from that, I understand that now the original convoy we created will be altered, so the locomotive traveling A-B is detached and the locomotive traveling B-C is attached. A new convoy will be formed, which is the detached locomotive, and the already existing convoy, consisting of only the B-C locomotive, will be terminated.
QuoteSchedule 3. However, what differs this from Schedule 2? is it just the direction (towards the depot, instead of away from)?
QuoteYou might have to elaborate this a bit more.Is it in Schedule 3 we set Trigger 1? or with "unique entry ID" you mean something third?I dont understand this instruction.
QuoteSorry, but is this Schedule 3 again? Why does it need another trigger?
QuoteYou would not be able to use the reverse flag for this, as I cannot think of any sensible way of inferring what the reverse consist orders ought to be (this could get monumentally complex and extremely prone to error). Thus, when using consist orders, you would need to specify a schedule manually as ABCBThis is important, as the consist orders for the second B would be different to the consist orders for the first B, each of which would need to be specified independently.
Quote...from a button in the convoy window (perhaps to replace the existing "Replace" button)...
Quote from: Ves on January 30, 2018, 12:45:59 AMThank you, it is getting much clearer!So in order to perform this operation we need:* Three schedules* Two consist orders* Three vehicles:* - Loco 1, for which we wish this route: A->B->Depot B->B->A* - Loco 2, for which we wish this route: Depot B->B->C->B->Depot B* - Car, for which we wish this route: A->B->C->B->AThe "Schedule 1":Stop AStop B - Trigger 1 + Couple + UncoupleStop CStop B - Trigger 2 + Couple + UncoupleThe "Schedule 2":Depot B - Conditional Depart (Trigger 1)Stop BThe "Schedule 3":Stop BDepot B - Conditional Depart (Trigger 2)
Quote"Consist order 1":Detach "Loco 1" and assign to "Schedule 3"Attach "Loco 2" from "Schedule 2""Consist order 2":Detach "Loco 2" and assign to "Schedule 2"Attach "Loco 1" from "Schedule 3"
QuoteQuestions:* Dont I need to set Couple flags for Schedule 2 and 3? Or will that just happen automatically due to it already been initiated by the Couple command from "Schedule 1"?
Quote* Would it be possible to create this example "the other way round", with just two schedules? Something like:Schedule 1:Stop AStop B - Trigger 1 + UncoupleDepot B - Conditional Depart (Trigger 2)Stop B - CoupleSchedule 2:Stop CStop B - Trigger 2 + UncoupleDepot B - Conditional Depart (Trigger 1)Stop B - Couple"Consist order 1":Detach "car" from "Schedule 1" and attach to "Schedule 2""Consist order 2":Detach "car" from "Schedule 2" and attach to "Schedule 1"(I know the Schedule 2 is backwards, but since the convoys anyways travel in a circle, I kept it like that for ease of readines)
QuoteI would really hesitate to remove the "reverse" button! It is so extremely convenient, so its worth finding a replacement in this case. Perhaps, a fancy version of the Standard "copy backwads" or what it says, which would technically copy the entrances, but it would not be displayed in the schedule window other than an extra set of buttons appear, or something like that. Unticking the button would automatically delete the extra entries. Would something like that be possible?
QuoteThis is one part that I still dont understand: We are not expected to manually change the order of the consists each time? I keep getting the impression that the consist orders are tied to the convoy, but I really cannot understand how that is supposed to work with convoys forming and splitting and forming again automatically in a complex layout. Since you easily can have 1000 of different vehicles on the same lines, you would need different consist orders dependent on what train is arriving at a station and what cars that particular train is made up from. If the orders are tied to the convoys, how will the consist orders survive?What I would like is something like a "Consist order Center", where all consist orders are permanently listed, and where you can add, edit and remove orders. It would create an overview, so you can debug your network and find out why stuff might not be working.
Quote from: Ves on February 01, 2018, 08:44:14 PMOk, so you can specify multiple target_id_uncouple's?
Quote from: jamespetts on February 02, 2018, 09:25:16 AMCan you think of a practical example of where a player might need to do this which: (1) cannot be done by dropping off loose vehicles and leaving other convoys to attach to them; and (2) is likely to be encountered sufficiently frequently so as to justify the very significant amount of work and potentially performance degradation that such a change is likely to engender?
Quote from: Ves on February 03, 2018, 02:26:52 PMI cant say for sure that "this is common practice" etc, but I am very sure that if such a case is needed in the real world, that is what they do. Trains in the real world are so extremely modular, so multiple splitting at once is really not an issue in the real world.Thinking about it, my example was just a small example to illustrate the point, but the scaled up version is a big shunting yard, with lots of cars changing train, and those cannot be that uncommon in the world.If the player get the possibility to assemble/disassemble convoys outside the depot, they are most probably going to expect to be able to do this.
Quote from: jamespetts on February 03, 2018, 04:04:34 PMAs I note above, the edge case that you describe of a triple split should in principle be possible (although I might need to adjust how schedules cope with consecutive stops in the same location), but the interface will not be optimised for such cases as doing so would de-optimise the code for the commoner cases.
Quote from: ACarlotti on February 04, 2018, 04:51:33 PMThere could be a second interface, although that probably isn't strictly needed (at least if otherwise redundant consist orders are allowed).
Quote from: Ves on April 30, 2018, 07:56:02 PM1 - Curently i am finding all individual vehicles the player owns by looking through all convoys on the map, however, I suppose that is quite inefficient, but I dont know of another way. Will there be another way to gather all vehicles owned by the player eventually?
Quote4 (new) - Will there be any way to identify specific vehicles, like a unique number or desc-name combined with a number or similar?
QuoteAs to Dr. Supergood's idea, it is rare for any vehicle type to have stopped being useable entirely - even with modifications - at an exact date. Post boys could easily be replaced with slightly older boys over the legal working age (at slightly higher cost); railway carriages with manual doors could have automatic central locks fitted to the doors (at cost), and so forth. Note that the expiration date for steam locomotives on British Railways was driven by economics not any extrinsic rules forbidding the use of steam. Steam continued to be used (and is still used) on the Welshpool and Llanfair light railway, which was owned by British Rail until the late 1980s when it was privatised, and steam trains regularly ran (and still do) on the main line for enthusiasts' special trains. Also, steam locomotives were used on the outer reaches of the London Underground (not in the tunnels, I hasten to add) for three years after steam was abolished on the main lines. Thus, it would be far more realistic (and easier for players to understand) for the incentive to cease to use vehicles to be economic and to accumulate gradually rather than be an arbitrary cut-off at an exact date.
Quote from: jamespetts on May 02, 2018, 09:29:11 PMVes - can you clarify whether you intend the constraint to which you refer to be limited to describing just what can and cannot ever be coupled/uncoupled outside a depot?
Quote from: Ves on May 02, 2018, 10:59:53 PMYes, in its basic form, yes.
Quote from: jamespetts on May 03, 2018, 09:29:19 AMThank you both for your thoughts.What I was trying to establish is how the game should behave when vehicle A, which couples only to vehicle B, has "fixed_coupling_outside_depot_next=1", but vehicle B, which couples to vehicle A, does not have "fixed_coupling_outside_depot_prev=1". Have you any thoughts on that question?
Quote from: jamespetts on December 24, 2020, 11:36:22 AMMay I ask specifically why you think that triggers, broadcasters and receivers give unnecessary precision and complexity; unnecessary for precisely what? The explanation for the features is discussed in this thread (the current thread being deliberately confined to a detailed technical discussion of the implementation). As explained there, triggers are necessary to work with the layover function, which is in turn necessary to achieve balance of a realistic implementation of running costs per unit of time, which is an essential part of the ultimate goal of reality based cost and revenue balancing.
Quote from: freddyhayward on December 24, 2020, 11:46:56 AMQuoting from a more recent post, but I think it's more appropriately discussed here. I've read as much of this thread as I can in a short amount of time. I still can't find an answer to the following questions:1. Why is the layover feature necessary for balance? (this is the clearest of them all)2. What parts of layovers are most important for balance and most appropriately developed and simulated in game?3. Why are triggers necessary to simulate those parts?
Quote from: jamespetts on December 24, 2020, 11:57:45 AMThe need for the layover feature was first discussed a long time ago - one of the earlier (but not necessarily the first) discussion of it was in this thread (see the first post in particular). You will see how the ideas have evolved over time to their present form.
Quote from: freddyhayward on December 24, 2020, 12:13:19 PMThank you. It is still unclear to my why layovers in that form are necessary. I note that there were many suggestions to use a simpler form of layover, in which staff costs are decreased or suspended after a set time threshold. Again, I cannot see how a layover flag or triggers are necessary for layovers. I could see how triggers could potentially be necessary for convoy recombination, but I don't see why layovers ought to be tied to recombination.
Quote from: jamespetts on December 24, 2020, 01:55:42 PMWere the reasons not to use those specific alternatives not discussed at the time?
Quote from: freddyhayward on December 25, 2020, 06:42:01 AMI couldn't find discussion of any such reasons. I am not being deliberately obtuse — I genuinely cannot find any specific reason for not using them. My intention is not to derail years of work. I have a huge amount of spare time in the following months and wish to dedicate it towards advancing work on these changes. I can only do this if I either agree with the design or at least understand the reasons behind it. Of course, you are busy and have no obligation to explain it to me, but it would be helpful to see as I haven't found reading through multiple old threads to be sufficient.
Quote from: jamespetts on December 25, 2020, 10:37:48 AMMy apologies; I did not mean to suggest that you were being deliberately obtuse; but it is genuinely very difficult to recall all of the things that were discussed and the reasons for not selecting alternatives some time ago. Your interest in assisting with the code is very much appreciated. When I have a little more time, I will see if I can go over the old discussions in detail and the detailed descriptions of the design and try to piece together the reason that this and not an alternative was alighted upon.Also - merry Christmas!
Quote from: freddyhayward on December 24, 2020, 11:46:56 AMQuoting from a more recent post, but I think it's more appropriately discussed here. I've read as much of this thread as I can in a short amount of time. I still can't find an answer to the following questions:1. Why is the layover feature necessary for balance? (this is the clearest of them all)
Quote2. What parts of layovers are most important for balance and most appropriately developed and simulated in game?
Quote3. Why are triggers necessary to simulate those parts?
QuoteThe next thing to consider is conditionality. There are two possible sorts of conditionality that I have considered so far: conditional depart and conditional skip. I will deal first with conditional depart. The idea in this case is that, at any stop on which conditional depart is enabled, a convoy would only depart once a certain trigger condition had been met. The best way of doing this, I think, requires two data members: two bits of flags (two separate flags for different versions of the behaviour, which can be compressed into a single data member), and a further 8-bit data member with a numerical value. The flags should determine whether the convoy is set to conditional before wait or conditional after wait. In conditional before wait, the convoy would wait for the condition to be triggered, and then start waiting for the next departure slot in wait for time, or for the maximum time if wait for load with a maximum time is set. It would have no effect if wait for load without a maximum time were set. In conditional after wait, the convoy would wait for its departure slot and/or maximum time in the usual way, but then not depart until the condition in question were triggered.The triggering of conditions would not itself require data in the schedule entries for the convoy that is waiting on the condition, except for the numerical datum already identified. Instead, certain specified activities (such as a particular convoy arriving at a particular stop, or the total number of convoys on a particular line being changed so as to be greater than or less than a particular number) could trigger a method to be called in a convoy with a particular ID or all convoys of a particular line with the specific number. If a convoy is waiting for a trigger of that particular number, it will then wait until some other event calls the method in question with the correct number. However, if the event in question is a convoy arriving at another stop, it may be that sending the trigger needs to be encoded in the schedule. This would require a further boolean flag (send trigger). The numerical entry for the number of the trigger can possibly be re-used for sending (but perhaps it ought to be possible for a convoy to send a trigger and also wait for a trigger at the same stop, in which case two separate data members would be required), plus a further 16-bit data member to identify the line or convoy in question, and at least a further 1 bit of data to identify whether the number identifying the line or convoy is indeed identifying a line or a convoy. Because of their complexity, conditional depart instructions could not sensibly be taken into account in calculating the service frequency of a line for the purpose of estimating waiting times, which might therefore default to too low a figure initially until actual recorded data become available to correct this incorrect estimate.I am unsure about the utility or practicality of conditional skip. It is necessary to have something that is functionally equivalent to this for depots, although this need not have any data members as discussed above. I had wondered whether it might be useful in creating request stops, but realised that this would not work properly as a convoy would need to know at the previous stop whether to skip the next stop, so any logic for request stops would have to be separate and need not, therefore, be included in this project. I had also wondered whether it might allow a rudimentary simulation of taxis by having a whole set of road vehicles (hackney carriages as already in the pakset) waiting at a single stop for the condition of some passengers being present in a particular stop, and then skipping all stops at which passengers were not present, but I doubt that this could be made to work properly with the path explorer, and in any event, I suspect that dedicated taxi logic (which would be good to have one day, but is not a priority at present) would be better than this in any case. A conditional skip function in which the convoy will, when (and only when) departing from a stop, check whether its next stop has any goods/mail/passengers for it and skip to the next stop in the schedule if so could be implemented as part of this project if that feature without further embellishment were of any use, and I should be grateful for any feedback on that point.
QuoteThe next thing to consider is the concept of layover: a convoy that is inactive (and not incurring fixed costs). It needs to be possible to instruct a convoy to enter a layover state at a particular stop. As far as I can tell, this need be no more than a single bit of data determining whether the convoy should go into layover at that stop or not. The remainder can safely be automated: the convoy will, if requested, unload, go into layover (during which time no loading is possible) then emerge from layover automatically in time to load and then depart at whatever time that the convoy would normally depart. It may be necessary to restrict layover to stops in towns or with special facilities: the point of layover is that the staff are not being paid to look after the vehicle, so we have to assume that the staff can have some sort of break, which they cannot sensibly do if they are stranded in the middle of nowhere without any staff facilities. However, this need not be a property of the schedule entry: rather, if the layover flag is set on the wrong sort of stop, the convoy should just stop without going into layover, and give the player a warning message. The system for loading passengers/mail/goods will need to know to unload all passengers/mail/goods before a vehicle enters layover, but, again, this needs no additional data in the schedule entry. Therefore, the layover feature itself requires only 1 bit of data in the schedule entries in the form of a boolean flag.
QuoteWithout a layover feature, convoys outside depots would be assumed always to be requiring a full complement of staff and would charge the player accordingly. However, in reality, transport vehicles often spend time away from their depot when they are not in use, but are parked out of service; think of a lorry parked between turns, a train waiting in a siding between turns of duty or an aircraft at an airport some distance from its airline's home base waiting for its return journey whilst its pilots and cabin crew rest (or after one set of crew have ended their shifts and before the next crew start their shifts).The layover feature is intended to simulate this. Without being able to do this, players would not be able to deal with low frequency services without incurring a time based cost much higher than would be necessary in reality, as, in reality, the vehicle would be able to be stored out of use with the staff on other duties or having time off. This would make low frequency services potentially uneconomic if costs/revenues be balanced in a realistic way.
Quote from: Ranran on December 27, 2020, 04:11:21 AMThank you for reconfiguring the extended board. It made it easier to find the thread.https://forum.simutrans.com/index.php/topic,19081.0.html