The International Simutrans Forum

 

Author Topic: Balance discussion: cost (maintenance, convoy re-combination and others)  (Read 8696 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
One of the major tasks that lies ahead is altering the vehicle/convoy cost model to take into account the need for regular maintenance and overhauls, as well as time spent in maintenance. It is also necessary, in order to make full use of fixed costs, to allow for a convoy to be in a state of lay-over, in which it is static, with no passengers/goods on board, in which it is not incurring any fixed costs (e.g. because there is no driver in the cab, as it is awaiting its next turn of duty).

Another task that will need to be done at some point is allowing convoy re-combination: for example, allowing locomotive changes on railway trains. This is particularly important for railways, for which the ability to change locomotives in service was very important throughout most of their history (although has become much less important in recent years).

That latter task in particular is likely to be extremely complex to implement (more complex than signalling, and signalling took well over a year to complete and there are still a number of bugs even now that need to be resolved).

I had planned to undertake both of these things at the same time so that, for example, a locomotive could be separated from its carriages to be maintained/refuelled. However, given that the game is really only suitable for sandbox play until balancing occurs and that the convoy recombination task is likely to be gargantuan, I have wondered recently whether it would be sensible to split the two projects. That requires a maintenance/overhaul/availability system that will work properly without convoy recombination but that can readily be adapted to work with it.

I have devised the following system, which I will set out in outline below. I should be grateful for any considered feedback on this scheme.

All vehicles would have an availability percentage. This would denote the time that those vehicles are not spending being maintained. There would be two options (settable in simuconf.tab) as to how to handle this: (1) the simple option, more suited to sandbox play; and (2) the realistic option, more suited to economic play. In the simple option, the vehicle's capital cost would be multiplied by one divided by the availability percentage. So, for example, a vehicle with an availability of 75% would cost 25% more to purchase in the simple model. This would be intended to simulate the cost of having to buy extra vehicles of the same type to cover the period that the vehicle in question is being (notionally) maintained. The actual maintenance would not be simulated directly. This would be the default option for loading existing saved games.

The realistic option would not adjust the purchase price, but would instead mandate that every schedule have a depot of a suitable type for that convoy as an entry. A schedule without a depot would not be valid. Each depot entry in a schedule would have parameters determining (1) the frequency of the visit (i.e., how many times would the convoy pass the depot before visiting); and (2) whether the visit is for maintenance or whether the vehicle is to go to the depot for storage (the current default behaviour). Depending on the length of the route and the vehicle's availability percentage, there would be a minimum limit on the frequency of depot visits in the schedule.

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.

The maintenance time in the depot would then be based on the availability percentage and the time since the vehicle last visited a depot. For example, if the vehicle had last visited the depot exactly an hour ago and its availability percentage were 75%, the vehicle would spend 1/4 of an hour being maintained before becoming available again. This time would be based on the vehicle in the convoy with the lowest availability percentage. (It will thus be seen that convoy re-combination would allow players to make more efficient use of their resources in the case of trains).

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.

As vehicles accumulate distance since they were first bought, their per kilometre cost would increase based on settings in their .dat files. It would be possible to reset this increased cost by overhauling the vehicle. This would be done on a visit to the depot. There would come a point in time (defined in kilometres since purchase or last overhaul, except for aircraft, where it would be defined in number of takeoffs) where the vehicle would have to have an overhaul in order to continue running at all. This would be set in the vehicle's .dat file, as would the cost of an overhaul. By default, vehicles would be overhauled at the point in time when it is compulsory to do so, but players should be able to set a convoy (or a whole line) to overhaul early on their next depot visit. The default cost of overhaul in the absence of being specified in the .dat file would probably be something like 1/5th of the purchase cost (although I should be interested in any data).

The vehicle replacer would continue to work largely as it does now, except that the replacement would occur on the next scheduled depot visit rather than ad hoc as at present.

Until convoy re-combination can be implemented, it will be assumed that all vehicles can refuel/replenish without visiting the depot or discharging their cargo. However, this should now take a minimum amount of time. This would be implemented as follows: when the schedule is created/amended, a set of range stops will be calculated. These are the stops on the schedule (ignoring the depot and any waypoints) where the vehicle needs to refuel/replenish. For example, suppose that a vehicle with a range of 100km had 10 scheduled stops, each 30km apart: it would have to make one range stop every 100km, so stops 4 (after 90km, the next stop being 120km) and 8 (after 180km, the next being 210km) would be range stops, where the convoy would wait longer than at other stops. It could continue to load/unload whilst replenishing, so this would just increase the minimum loading time, and might not affect at all the loading time for vehicles, such as ships and aircraft, that take a long time to load. This would not alter the convoy's state. The range stops should be marked on the schedule.

I should be grateful for people's views on these ideas, which are aimed at expediting the balancing of the game, which has been seriously delayed to date.

Offline zook2

  • *
  • Posts: 321
With current depot building and maintenance costs, having a depot for every line, or most lines, would be prohibitively expensive. So we'd have to separate maintenance docks from shipyards, for example.

Also, if I understand your concept correctly, working out complex schedules for rail lines would become moot, as any maintenance/refueling stop would easily upturn the entire schedule.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
One would not have to have a depot for every line: a number of lines could share a single depot.

As to schedules, I will have to give some consideration as to how players might control what happens to convoys when they leave depots after having been sent there automatically, but the aim should be to allow players to allow for depot visits in their schedules, for example, by having extra convoys or having a sufficiently long lay-over at one end of the trip that a depot visit can be accommodated there should one be needed. Giving players control of what happens to a convoy on leaving a depot (whether it leaves the depot straight away or waits for a particular point in time, and whether it goes into lay-over, etc., for example) should help to make this possible.

Offline AndrewTraviss

  • *
  • Posts: 14
  • Languages: EN
Cities in Motion uses a system similar to this, and it mandates that all lines must originate from a depot, which is probably the simplest and most intuitive rule; the vehicles on a line will initially emerge from a depot, after all.

Rather than having to micromanage the maintenance frequency, perhaps having two settings on the line itself would suffice:
- minimum km of wear before vehicle maintenance
- number of vehicles in simultaneous operation on the line

Vehicles beyond the configured number would enter the depot and receive any needed maintenance, remaining at the depot even if all maintenance is completed. Once a vehicle that is actively operating the line reaches the wear threshold, it would plan to drop what it is carrying at the stop before the depot and check in for maintenance. The vehicle with the least remaining maintenance in the depot would be dispatched to the same stop to pick up the passengers/goods that were dropped and continue the route.

This allows the player to balance quality of service vs maintenance costs through a relatively simple mechanism that clearly relates to the vehicle statistics available to them.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
From on top of my head, I would think it was better to implement the recombination of vehicles first as that somehow seems more fundamental. But i trust that you make the right decision! :-)

I'm all for controlled automation! That is, I want ultimately to be able build a line with all the small details I want, and then it works like that until I change it (or become bankrupt). If there are problems, I want to be properly notified what is the problem so I can take care of it.

Doing the decision on a per line basis sounds nice, especially if the convoy recombination also will work on a per line basis. Having all the controls the same place is very handy!
However, it would also be nice to have the possibility to make these decisions directly to a vehicle, without taking it away from its schedule. Say you have a line with some different vehicles in that have quite different needs, it would be very convenient to have only one schedule but be able to say that these five convoys can travel two times back and forth, but these five can only travel one time back and forth.

All this makes me wish that the depot is not a single tile building that the trains disappears into. How cool would it be if the "depot" where actual tracks so you could see and click on the trains being in there.
This would also make players build depots at more strategic and thought out locations, due to its possible size, rather than everywhere you might need a depot. Big depot can serve many vehicles, but small ones could only serve a few at a time.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you both very much for your input: that is very helpful.

Andrew - those are interesting ideas, and could work well (although, given the way that schedules work in Simutrans, it would not be any different in practice to mandate that a route starts from a depot than that it includes a depot somewhere, and the latter would be more flexible; but creating a new schedule might start with the current depot (set to a maintenance visit) as the default, perhaps). You have devised, I think, quite a good way of simplifying the interaction with this in a workable way (and I remember that this aspect of things worked quite well in Cities in Motion 2, despite that game's other flaws). There may well be something to be said for Ves's idea, however, of also allowing players to alter the minimum distance before maintenance setting on a per convoy basis given that a line might well have different types of vehicles running on it. (Someone a while ago had an interesting idea about groupings of similar lines with slight differences between them that could all be edited together as if they were one line, and even volunteered to code it, but then sadly disappeared; this would have helped here, I think).

We might also, until the implementation of convoy re-combination, use depot stays as the way of achieving lay-overs (i.e., periods of time when convoys are at rest and not incurring fixed maintenance costs), and leave the idea of lay-overs out of depots (which realistically would only be likely to be used for trains in any event) until the implementation of convoy re-combination.

As to convoy re-combination, the reason to put this behind the maintenance features is that the maintenance features are essential before balancing work can begin, whereas the convoy re-combination features are not, and there really is only half a game without economic balance: all that one can really do is play a sort of sandbox game. Convoy re-combination will be a particularly challenging task: just look back at how much work that the signalling has involved, and the enormous number of subtle and tricky bugs each of which take many hours to find and fix: the convoy re-combination I estimate will be similar, but on a considerably larger scale, and touching a greater number of fundamental parts of the game.

As to multi-tile depots, that would be a good thing to have, but it would involve again very considerable and fundamental changes to the way that depots work, especially for spawning new vehicles, which would take a lot of work to implement and would not at this stage of Simutrans-Extended's development justify that time which could be spent on preparing the game for balancing. In economic terms, the cost of depots can encourage players to have no more than a realistic number of them, and it would be relatively easy to put a limit on the number of convoys that a depot can maintain at once, having the large/small distinction without a difference in the physical size.

Offline A.Badger

  • *
  • Posts: 54
  • Languages: EN
openttd has depot maintenance and it's a bit of a pain because it adds a requirement into scheduling that doesn't match up with either factory and passenger generation or time to traverse a route.

In my openttd play-style, mitigating the pain is usually a matter of scheduling one (or more because route length sometimes exceeds how often a train needs to be maintained) or more depot stops as part of the route.  There is not a maintenance cost so too frequent maintenance does not have a detrimental effect on profits.  Time taken to maintain is basically the same as the train making any other stop so the primary consideration is just to place the depots in a convenient location along the tracks (usually near stations at either end of a linear route or at every single station).  Depots are not expensive to buy or maintain (I'm not sure if openttd even has maintenance fees for depots.... track and signals dominate the costs) so I often end up with a depot at every station and intermediate ones on very long routes.

One thing that is lacking in openttd is drive-through depots.  station layout can be optimized for through-put by having trains enter one side and leave the other but depots only have one entry and exit so there's always a portion of track that is bidirectional.

Another way that openttd makes this (and other scheduling where there may be a mismatch between travel time and readiness to depart) is having conditions within scheduling.  "If train is within 10% of refit time, go to depot, else skip to the next schedule entry".  (In non-depot related scheduling, it can also be used for cargo handling and other decision making "If Train has X% cargo, then go to station else skip to schedule entry #") The interface would need to be more complex with each component having separate refit needs but having conditionals probably becomes even more necessary for automation as well.

trying to think of other ways in which separate maintenance schedules for each component affects game play, in the real world, if a train pulled into a depot and only the locomotive needed to be maintained, wouldn't the depot just perform maintenance on the locomotive?  it seems like they'd either ignore the cars it is attached to or unhitch the locomotive from the cars inside the depot, service the locomotive, and then reattach the locomotive and send the convoy back out.  Seems like modelling that would be a time saver and ease automation as well.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you for your feedback. I hope to find a system of depot visit maintenance that does not make it impossible or excessively difficult for players to have sensible schedules; what do you think of Andrew's idea as posted above?

I should note that there is no plan to have a specific cost associated with visiting depots: maintenance will be based on the number of kilometres travelled.

Conditional schedules are an interesting idea, but are likely to be tricky to implement and even trickier to make easily understandable to the user. If anyone would like to have a go at implementing these in Simutrans-Extended, I should be likely to incorporate such a patch if it worked reasonably well.

I am a little unclear about the last paragraph, in particular how you imagine that this would actually work in the game. Can you elaborate?

Offline A.Badger

  • *
  • Posts: 54
  • Languages: EN
Ah, nevermind my last paragraph.  I see that I misread your plans on how full convoys being maintained should operate.  Your plan when there's a lack of automated convoy recombination seems to match with what I was thinking.

Conditional schedules aren't very tricky to make a gui for.  OpenTTD is quite easy to use.  They aren't great to maintain, though... For a programmer, it's a partial return to spaghetti code (If condition goto schedule entry X.  [the else is always to fall through to the next entry]).  The impact is made slightly better because the gotos are linked to an entry's id, not their visible number: when adding more entries, the gotos automatically update to continue pointing to the correct entry.

Coding of conditionals may not be too hard but depends on what assumptions the code already makes.  Basically, when a train leaves a station, it looks at the next entry in the schedule.  If it's a condition, it needs to evaluate the condition to decide where to go next.  So if the code already makes the information available that you want to allow conditions to address, things are easy.  If not, then there's some restructuring to do.  There may also  be work needed if the schedule's data structure is not flexible enough to hold entries for conditions in addition to entries for locations.

I'm trying to figure out the differences between your initial idea and Andrew's idea... If I understand what you were thinking, I may like yours better.  It sounds like with your idea, you can have a single depot anywhere on a route.  When the train passes the depot, if some number based on the availability percentage has been exceeded, then the train would need to go into maintenance otherwise it could continue on (the user could also set the train to maintain every time it passes the depot or some number in between if they wish).

One other thing... I realize reading this idea over again that overhaul is different from maintenance.  Instead of having running cost increase with time between overhauls, would it make more sense for availability percentage to go down (which would influence costs because it would increase the amount of time in which a train is out-of-service)? It feels like as a vehicle accumulates more miles, the parts wear and there's more need for repair (which would fall under maintenance) rather than a decrease in fuel economy or salaries paid to the staff manning the vehicles.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you very much for your feedback: that is most helpful.

The trouble with the code in Simutrans is that it is not very modular: accessing the schedule is done in lots of different places all over the code at a fairly low level (in terms of the structure of the schedule); for example, the code that determines the service frequency to estimate the waiting time before actual waiting time data are available, the code to check whether a particular line calls at a particular stop for the purposes of routing, the code to check whether the next stop is within range all (separately) access the schedule's basic data directly in order to work. There is no definitive list of which things do this in the code, so it is hard to tell whether any change to the schedule code would be violating an implicit assumption somewhere.

Moreover, there is code which allows the schedule to be traversed forwards or backwards (to allow for automatic reversing of schedules), and, again, at present, there are different bits of this code that do essentially the same thing in different places for different functions, so any addition of conditional schedules would have to take account of this (both by actually checking the schedule's direction and by anticipating that the schedule may be traversed in either direction).

I am afraid that, over the years that I have been working on Simutrans-Extended and extending the code from Simutrans, I have copied the coding style from the Simutrans-Standard (often as it was some years ago before improvement), and copied in many places some of the weaknesses in the coding style from that original codebase (which were probably rather less serious weaknesses when that code was simpler in any event).

It would certainly be possible to implement conditional schedules, but I suspect that this would involve quite a lot of re-writing the schedule code to make it more modular. If anyone would like to do this, it would be a very helpful thing.

Edit: I realise that I replied only to the part relating to the scheduling code: my apologies.

My original idea was to have a specific depot on the schedule: having a specific depot in a schedule is already possible, but the vehicle will stay in the depot and the depot entry will be deleted from the schedule when the vehicle enters it. The idea of having an abstract call for a vehicle to visit any depot (is this what you meant?) would be more difficult to implement in the code, as it would be more different from the current schedule code, and would potentially add a whole layer of unpredictability for the player. The idea would be not for the availability percentage to determine when the vehicles need to go to the depots, but rather how long that they spend there when they do: the idea would be for the timing of going to the depots to be based on a fixed (and somewhat generous) distance interval.

In relation to an increase of running costs as against a reduction in the availability percentage as vehicles grow older, I suspect that the more realistic thing would be to have both (as more mechanics' time would be needed to maintain the vehicles as they got older, and likewise more spare parts and materials), but I wonder whether altering the availability percentage in this way would upset schedules in a way that would require constant attention by players in order to optimise, which in turn would make semi-unattended play (as in large, long network games) non-viable? If you can think of a way around this, however, I should be most interested.

Offline zook2

  • *
  • Posts: 321
Could 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.

"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.

Also, 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.
« Last Edit: April 18, 2017, 03:41:04 AM by zook2 »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Could 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.

The path explorer is the code, written by Knightly some time ago, which calculates the route that all passengers, mail and goods take to get from any stop to any stop. This is quite computationally intensive, so it is set to be run only when necessary. At present, a convoy entering a depot triggers the path explorer being re-run because it suggests that something has changed in the way in which the schedules are arranged. This will have to be altered when this new system is implemented.

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.

The concept of a layover is a state in which a convoy is dormant and accrues no fixed maintenance cost because it is not being attended by staff (e.g. a 'bus parked in the garage, etc.). When fixed maintenance costs are fully implemented in the pakset, it will be important to be able to have layover states in order to allow convoys/vehicles to remain dormant for periods without attracting considerable cost. There will have to be some restrictions on the layover state to prevent exploits (such as layovers at every stop for the duration of loading): a layover requiring no passengers/mail/goods be on the vehicle or being loaded should probably suffice for most purposes, although a delay for entering and leaving layover might also be necessary.

Quote
Also, 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.

Refuelling I imagine would take closer to 5 minutes for road vehicles, and there is a long-term plan to make all road vehicles non-blocking when they are stopped.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #12 on: April 18, 2017, 01:38:48 PM »
This is a really interesting topic, and I'm looking forward to see it in the game!
Am I making the right assumption that there are three levels of this:
Range = the max distance before the vehicle needs replenishing/fueling
Maintenance (distance) = the max distance before a minor maintenance must occur, i.e. Clean the vehicle, refill oil, check brakes, fill air in tires etc
Overhaul (distance) = the max distance before a major overhaul must occur, i.e. Replace engine, rust removal etc.

I too would think that having conditions is very (VERY) handy with a thing like this.
I wrote earlier that it would be nice to have on a per schedule basis, but I'm more and more convinced that a dedicated "vehicle maintenance window", a standalone window not bound to any vehicle, is the best way to go. Let me explain:

In the real world, (I assume) the vehicles are grouped more together on a per type basis than a per schedule basis. If the train to London and the train to Liverpool are copies of each other, the individual cars and loco of the London train would likely have more in common with their twin in the Liverpool train than with the other types of cars running in their own train in respect of maintenance needs. This will be especially true if vehicle recombination allows for physical sharing of cars between the two lines.

The vehicle maintenance window would be brought up by a button in the schedule, vehicle window, schedule window and maybe also from the menu bar and would look the following:
On the top, similar tabs as on the schedule window to select different means of transportation, including "all".
Below that, four fields of lists next to each other, the first being "groups", second being "schedules", third being "vehicle models" and fourth being "individual vehicles".
All these four fields would start with "all" so all individual vehicles can be made visible in the right most window.

The "groups" are groups of vehicle models/schedules/individual vehicles that the player can put together to ease modifying. Say you have a big bunch of kind of similar vehicles but they might be just a little different but not enough to justify individual maintenance schedules, you can put them in the same groups. If it is easier to put entire schedules in the same groups then that should be possible too.

The "schedules" field would show all the schedules that you are currently operating (if not filtered away by "groups").

The "vehicle models" are all different kinds of vehicles that you currently own (if not filtered by "groups" and "schedules"). It is not the actual vehicles but it groups together all vehicles of the same kind.

The last "individual vehicles" are the actual vehicles that you own. If the three previous fields shows "all" then all your vehicles will be shown in the last box.

All below settings are stored at the individual vehicles and the above sorting method is just to select the specific vehicles. Now that you can select precisely which vehicles to make corrections to, this should go underneath. If multiple vehicles are selected, the max/min displays the worst case:

* Display availability percentage
* Display range
* Display vehicle maximum travel distance/time before maintenance need (from vehicle dat.file)
* Set maximum travel distance before maintenance
* Display max years or distance to overhaul
* Set overhaul frequency (years or distance)
* set minimum km of wear before maintenance
* Display minimum maintenance duration from vehicle dat.file)
* display the age of the vehicle, if more than one, display the range (i.e. 4-9 years old)
* display the different costs associated with maintenance if more than one type of vehicle is selected, show both the worst case of the selection as well as the sum.
* Set wether the vehicle should "overhaul" to original condition or to an upgraded version if available.
* Specify which depots (if not any) that might be used to perform maintenance and overhaul.
* Set maintenance grouping
* possibly some more info/settings as well

When changing settings for a group of vehicles (i.e. a schedule with different vehicles), the vehicles should keep their settings that have been changed individually and only change the settings which are collectively set.

In the schedule it self, the range stops are calculated automatically but should be modifiable so I can change if I want another stop to be a range stop. Also I specify at which point/points in schedule where it should check if any of the vehicles operating the schedule needs to do any maintenance or overhauls. If, at the maintenance check, it finds that the entire convoy can make it to the next "maintenance check" it should proceed.
Also, being able to have several depots along the route to be able to perform the maintenance and overhauls would allow for some really long routes (one end of the map to the other).


Btw, the layover's, are they supposed to be performed in the depot or on a station?
Anyway, since that is a schedule thing and not a maintenance thing, it should belong to the schedule window.

Also, maybe consider the possibility to add conditional good loading, ie only load books at this stop, or only unloading at this stop in Y direction.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you for the feedback.

The idea behind the specific outline that I gave in the opening post is to simplify the idea enough that it is a reasonable task to implement within a reasonable time given the very limited coding resources currently available to us. Additional features, such as conditional schedules and convoy recombination, are things that might be added later if and when they are practical - but it should be possible to get the game to balance without having to do all that work, and it is important to get the game to balance sooner rather than later, as, without proper balance, it really is only half a game. Once the game is balanced, hopefully it will attract considerably more players, some fraction of whom may in time themselves contribute content and code, so there is a definite strategy to proceeding in this way.

As to the vehicle manager window, this seems as though it would be a good idea in principle, albeit rather a lot of work to code; but if you and/or Andrew are able to do this, then it would certainly be a welcome addition. I wonder whether vehicle replacement could be linked to this display in some way, too?

As to layovers, the current plan is for these to occur in depots only until convoy re-combination is implemented.

As to conditional goods loading, that is an interesting idea, albeit quite distinct from this topic.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
The conditional good loading suggestion was just in case the schedule window anyway was about to be recoded. Then that could at have been thought of and perhaps prepared.

I will see what I can accomplish! :)

Offline Bear789

  • *
  • Posts: 129
Re: Small ships and range
« Reply #15 on: December 10, 2017, 11:00:18 AM »
As to the shipyard, the plan is to add a feature whereby it will be necessary for vehicles regularly to visit depots

It's slightly off topic, but I'm really unsure about this bit. One of the reasons why I prefer Simutrans over OpenTTD is that it doesn't have the silly breakdowns, maintenance is abstracted as a cost. This is a good thing in a time scale in which a month passes in merely a few minutes. Breakdowns and maintenance/repair visits to the depots (even if low mainteinance does not cause breackdowns) in this time scale cause an amount of disruption to the normal operations that is massive compared to the real life conterpart, and is therefore highly unrealistic.

It's the trite and mildly frustrating issue of simulation games making rather mundane stuff tricky and harder than they should be because of the discepancy between the in-game time scale and the interactions time scale. Like in The Sims, where you have to either wake up at dawn or choose between peeing, showering or having breakfast because each of these things takes a whole hour; or a village of a dozen people in The Settlers needing an army of butchers or risk starvation every time the man goes to have a beer at the pub. Or indeed a gridlock that lasts half a year in TTD when a single vehicle breaks down. All these things require either abstraction (like the way it's currently handled in Simutrans), or a more realistic and slower time scale, plus tools to set up replacement vehicles/services, plus passengers/goods AI smart enough to figure that out (which seems rather hard to implement).
« Last Edit: December 10, 2017, 11:26:08 AM by Bear789 »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #16 on: December 10, 2017, 01:12:56 PM »
Bear - I have moved this post into the thread that discusses the feature on which you are commenting, as it is better to be here than to go off-topic in the post specifically about the range of small sailing ships.

I do suggest that you read the above discussion on this feature to understand in some detail how it is intended to work: it is very specifically intending to take account of the timescale (that is, the short timescale, measured in hours rather than months) with some precision and to use the timings as an important part of the simulation of realism.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #17 on: January 22, 2018, 11:39:07 PM »
The time has now come to move towards implementing this. I infer that Andrew Traviss has unfortunately not had time to do this, so I will have to start work on this myself (although any contribution from Andrew to this or any other feature would still be welcome).

The initial focus, it seems to me, needs to be on precisely how these features would impact scheduling, and a discussion of that (in some techincal detail) can be found here.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #18 on: January 28, 2018, 05:29:08 PM »
Work has started on this set of associated features in the vehicle-management branch on Github.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #19 on: January 29, 2018, 05:03:27 PM »
Hi James,
I will continue in this thread, so the other doesn’t get too long with mixed content and me shooting arrows in the mist.

Could you elaborate step by step, how do you imagine the player should create a schedule, create convoys, create the hash-tables, and then send the convoy out on the network?

In other words, what actions and decisions must the player take and do in order to get it working?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #20 on: January 29, 2018, 09:33:21 PM »
That is not entirely straightforward, as many of the steps are to be optional depending on what a player wants to do and how the player wants to do it. At minimum, a player would create a schedule in the same way as at present, but have a depot in the schedule with a conditional skip command which would not skip (causing the vehicle to enter the depot) whenever the vehicle needed maintaining (quite what counts as the vehicle needing maintaining I have yet to devise).

The hasthables to which you refer are to be the internal storage system for the planed convoy re-combination data, and any convoy re-combination would be optional.

If you wanted more specific information, perhaps you could let me know what specific that a player might do for which you want a step by step outline?

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #21 on: January 29, 2018, 09:41:18 PM »
Ok, I will try to be more specific! :)
What would the steps for the player be to setup the following:

Stop A ==== Stop B ==== Stop C

One locomotive serves the line: Stop A <-> Stop B
Another locomotive serves the line: Stop B <-> Stop C
We want one car to travel all the way from Stop A to Stop C, and subsequently back again.

We do not consider overhaul or anything more advanced than the above.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #22 on: January 29, 2018, 09:58:03 PM »
The steps need not necessarily be followed in this exact order.

(1) Create the convoy in the depot for the A > B section.
(2) Create the schedule as normal for a line for the whole route.
(3) Create a new convoy consisting of only the locomotive for the A > C section at a depot at B.
(4) Set its schedule to a line consisting of be B depot > B.
(5) Set a conditional depart flag from B depot with a trigger of, e.g. 1 for the locomotive only convoy/line.
(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.
(7) Set the main convoy to have both a couple and uncouple flag at B
(8) Set the consist orders at B to comprise the train with the old locomotive detached and the new locomotive attached.
(9) Add a new line from B > B depot
(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
(11) Set a conditional depart from the depot with this schedule with a trigger number of, e.g. 2.
(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).

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #23 on: January 29, 2018, 11:05:45 PM »
Thank you for the break down! I understand somethings better now, but other things i would still like some clarifications on:

(1) Create the convoy in the depot for the A > B section.
The "convoy" in this sense means both the first locomotive (A <-> B) as well as the car?

Quote
(2) Create the schedule as normal for a line for the whole route.
So create a schedule with these entries, as well as ticking the "reverse" tag:
Stop A
Stop B
Stop C

I call this schedule "Schedule 1"

Quote
(3) Create a new convoy consisting of only the locomotive for the A > C section at a depot at B.
Maybe 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 ...?

Quote
(4) Set its schedule to a line consisting of be B depot > B.
Ok, so a second line is created "Schedule 2"

Quote
(5) Set a conditional depart flag from B depot with a trigger of, e.g. 1 for the locomotive only convoy/line.
Is the "1" just a name/number for the trigger? In which case, could I theoretical name it what I want (extension request :) )?
You 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?
I call it "Trigger 1"

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

Quote
(7) Set the main convoy to have both a couple and uncouple flag at B
Again, this is set in the Schedule 1?

Quote
(8) Set the consist orders at B to comprise the train with the old locomotive detached and the new locomotive attached.
Here 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.

But 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.

Quote
(9) Add a new line from B > B depot
Schedule 3. However, what differs this from Schedule 2? is it just the direction (towards the depot, instead of away from)?

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
You 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.

Quote
(11) Set a conditional depart from the depot with this schedule with a trigger number of, e.g. 2.
Sorry, but is this Schedule 3 again? Why does it need another trigger?

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).
Great!  ;D

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #24 on: January 29, 2018, 11:29:46 PM »
Thank 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?

Yes, indeed, the whole train in its A > B journey.

Quote
So create a schedule with these entries, as well as ticking the "reverse" tag:
Stop A
Stop B
Stop C

I call this schedule "Schedule 1"

You 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
A
B
C
B

This 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
Maybe 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 ...?

Yes, my apologies: this was a typing error. I intended B > C section.

Quote
Ok, 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 :) )?

The 1 is the trigger number: this can be in the range 0 - 15. This needs to be a number as bitfields are used. In theory, this could be represented by a name in the UI - but this would have to be saved somewhere, and that would take a lot of data just for saving these names. A trigger number in the range 0 - 15 is not inherently hard to understand.

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

Yes, with the conditional depart flag.

Quote
I 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.

Yes, indeed.

Quote
Again, this is set in the Schedule 1?

If by "schedule 1", you mean the schedule of the first convoy described, then yes.

Quote
Here 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.

I had not finalised a UI design, as I thought that it might be better to leave that to your discretion if you were doing the UI coding. There are various possibilities for this: one might access it from a button in the schedule window, or from a button in the convoy window (perhaps to replace the existing "Replace" button). The actual dialogue itself I imagine as being similar to the GUI convoy assembler dialogue, with graphics showing the final consist, and silhouetted graphics of a vehicle representing more abstract rules, the silhouetted graphic representing a currently available vehicle that matches all of the rules (currently available as in either available to buy or already in the player's fleet).

Quote
But 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.

Yes, indeed.

Quote
Schedule 3. However, what differs this from Schedule 2? is it just the direction (towards the depot, instead of away from)?

This schedule would have a different trigger condition for departing from the depot than the other locomotive's schedule: it would be triggered to depart from the depot in the second instance of the main convoy arriving at stop B, whereas the other convoy would be triggered to depart on the first such instance.

Quote
You 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.

By instruction no. 10, I meant that the next stop in what you call schedule 3 is the depot, so that the detached locomotive heads to the depot after uncoupling.

Quote
Sorry, but is this Schedule 3 again? Why does it need another trigger?

Yes: as explained above, this A>B>depot>B>A locomotive needs to be triggered to leave the depot when the train enters B heading towards A, whereas the B>C>B>depot locomotive needs to be triggered to leave the depot when the train enters B heading towards C.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #25 on: January 30, 2018, 12:45:59 AM »
Thank 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->A

The "Schedule 1":
Stop A
Stop B - Trigger 1 + Couple + Uncouple
Stop C
Stop B - Trigger 2 + Couple + Uncouple


The "Schedule 2":
Depot B - Conditional Depart (Trigger 1)
Stop B


The "Schedule 3":
Stop B
Depot B - Conditional Depart (Trigger 2)



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


Questions:

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

* Would it be possible to create this example "the other way round", with just two schedules? Something like:
Schedule 1:
Stop A
Stop B - Trigger 1 + Uncoupe
Depot B - Conditional Depart (Trigger 2)
Stop B - Couple


Schedule 2:
Stop C
Stop B - Trigger 2 + Uncouple
Depot 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)


Quote
You 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
A
B
C
B

This 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.
I 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?

Quote
...from a button in the convoy window (perhaps to replace the existing "Replace" button)...
This 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.



Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #26 on: January 30, 2018, 11:17:42 AM »
Thank 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->A

The "Schedule 1":
Stop A
Stop B - Trigger 1 + Couple + Uncouple
Stop C
Stop B - Trigger 2 + Couple + Uncouple


The "Schedule 2":
Depot B - Conditional Depart (Trigger 1)
Stop B


The "Schedule 3":
Stop B
Depot B - Conditional Depart (Trigger 2)


This is correct so far.

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"

This is not how consist orders would work: they would not specify what vehicles are to be attached and detached: rather, they would specify the end-state of the convoy after all coupling/uncoupling, and what attaching/detaching, if any, needs to be done to reach that end state would be calculated automatically.

For example, suppose that we use the following symbols to have the following meanings:

L1: Locomotive no. 1
L2: Locomotive no. 2
Cb: Brake carriage
C: Non-brake carriage.

The train leaving A would have the following formation:

L1-Cb-C-C-C-Cb

The train leaving B would need to have the following formation:

L2-Cb-C-C-C-Cb

Thus, the consist order at B (heading towards C) would be:

L2-Cb-C-C-C-Cb

Each of the slots between the hyphens could be taken by a list of alternative vehicles, and/or a set of rules about what vehicles may or may not form part of the end-state convoy.

There would be no "attach" or "detach" data in a consist order.

Quote
Questions:

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

Yes, I think that you would need to set the couple flag in schedules 2 and 3 as well.

Quote
* Would it be possible to create this example "the other way round", with just two schedules? Something like:
Schedule 1:
Stop A
Stop B - Trigger 1 + Uncouple
Depot B - Conditional Depart (Trigger 2)
Stop B - Couple


Schedule 2:
Stop C
Stop B - Trigger 2 + Uncouple
Depot 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)

I repeat what I wrote above about how consist orders are to work.

As to the remainder, something like this might work, but you would still need to specify at stop B that the carriages are to couple with a locomotive of schedule 2, or else the passengers on the train would have no way of knowing that the train continues to C, and would all get off at B (and the path explorer likewise would not treat this as a direct connexion between A and C).

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

The idea is not to remove the "reverse" button; but it would only be able to be used when the schedule flags need to be the same for each stop in both directions (as each entry has only one set of flags; in this case, we need different flags at stop B on the outward than the return route). This should still allow the "reverse" button to be used in most cases of simple schedules (including 'bus schedules, for which it is especially useful).

Quote
This 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.

Remember that where the button is in the UI is very different from where the actual data are stored. The idea is that consist orders are stored in both lines and convoys. In this case, there would be lines for schedules 1, 2 and 3, and so the consist orders would be retained in the lines. One might also want to add a consist order button somewhere in the line management window. Also, you may recall that, even without lines, setting an uncouple target convoy ID causes the schedule of that convoy to be copied to the uncoupled portion of the convoy. This should probably also include, not just the schedule, but the consist orders of the target convoy.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #27 on: February 01, 2018, 04:13:26 PM »
Ok, so the consist order only tells in which combination the convoy will be leaving the station. Where exactly do you then state what lines the detached vehicles should join? In the schedule entry for that particular stop?
In which case, can you enter multiple targets for a single schedule entry, so many cars can be detached and go to different lines?

I was thinking, now that ACarlotti has come around, perhaps he or she would like to participate in the creation of the GUI? :)

Offline ACarlotti

  • *
  • Posts: 483
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #28 on: February 01, 2018, 08:08:15 PM »
Probably not 'creation' as such for now, but I'll quite happily take your ideas/code and throw some suggestions/fixes/improvements at them.

At present I'm primarily intending to fix existing bugs (including those that I discover while reading the code), or make other minor improvements, and in doing so learn more about the codebase. Then maybe at some point in the future I'll start creating new stuff. But I suppose it largely depends where I end up on a random walk through the codebase.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #29 on: February 01, 2018, 08:23:58 PM »
Ves - to answer your question, the detached vehicles will either be loose vehicles if no target line or convoy be specified, or will be formed into a new convoy with the schedule or line of the line or convoy specified in the target_id_uncouple data member in the schedule entry corresponding to the relevant consist orders if this be a valid non-zero value.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #30 on: February 01, 2018, 08:44:14 PM »
Ok, so you can specify multiple target_id_uncouple's?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #31 on: February 01, 2018, 09:18:17 PM »
Ok, so you can specify multiple target_id_uncouple's?

No, as there is only the one variable. I do not think it practical to have a vector in a schedule_entry_t object, and in any event, specifying which vehicles would be assigned to which convoys/lines would hugely increase the complexity.

The better thing to do would be to have the first stop on the new schedule one which itself has an uncouple command, and so one, so that one can effectively cascade the commands.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #32 on: February 02, 2018, 01:36:28 AM »
Hmm, ok but will this not be overly complex for players? So the convoy dropping of multiple cars should assign one schedule to all those cars, a schedule where the first entry is the same stop as where it is currently located and which also has a drop command, which states “this” many cars are to be dropped of into a new convoy and have another schedule, again with “this” stop as their first entry, and with another couple command etc. That could potentially be a lot of “ghost schedules”, since you might very well be in the situation that the different cars are to be picked up by other lines, which can just have a couple command at that particular station, rendering all these schedules to just take the consist apart with a feeling of “work around” for the player. I’m sorry, but I don’t think that is less confusing than having, say an array of target schedules per schedule entry, or some other means where the player can specify directly what should happen to particular vehicles. And then we are not even talking about the complexity and micromanagement it requires just for the player to maintain all these potential ghost lines. Imagine having to alter the consist orders of 10 lines, just because it is the “last” line in the row that needs some alteration. 

Are you sure there is not a more flexible way?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #33 on: February 02, 2018, 09:25:16 AM »
Can 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?

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #34 on: February 02, 2018, 11:41:11 AM »
Can 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?

But, Im really puzzled now. Are you saying that it is indeed possible to do this setup:

Lines:
Stop X ==== Stop Y

Stop Y ==== Stop A
Stop Y ==== Stop B
Stop Y ==== Stop C

You want this train to travel between Stop X and Stop Y:
L1-C1-C2-C3

At stop Y you want to disconnect all cars and attach one new locomotor to each:
L2-C1
L3-C2
L4-C3

If the schedule of the line traveling between Stop X and Stop Y can only specify one target schedule/line at Y, how can this be done?
Remember that there are good in the cars, so they need to go to the correct stops.

The only way I can think of is if you specify the same stop multiple times in the schedule, and specify a different line target to each entry, but that too seems to be walking across the river for water...

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #35 on: February 03, 2018, 12:15:24 AM »
For that sort of arrangement you would need to cascade as described; but is this common? When I was designing the convoy re-combination system, I had in mind four paradigm cases that the system had to be able to deal with:

(1) a locomotive hauled train changing locomotives;
(2) a pair of multiple units dividing/combining en route (dividing in one direction and re-combining in the other);
(3) a pick-up goods train; and
(4) a locomotive hauled train dropping off carriages at a stop and those carriages then being taken on to a different destination by a different locomotive (and then re-combining again on the return journey).

I sought to design the simplest system possible that would successfully do all of those things. The case that you describe (multiple splitting at once) is not one of the paradigm cases that I had in mind because I am not aware of any significant real life examples of this. It is likely still to be possible, but, as an edge case, the interface is not likely to be optimised to make this particular case achievable in as few steps as possible, as this would in turn de-optimise the implementation for the paradigm cases.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #36 on: February 03, 2018, 02:26:52 PM »
I 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.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #37 on: February 03, 2018, 04:04:34 PM »
I 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.

The idea is not to simulate shunting directly (i.e., require the player to set up the trackwork and orders to attach and detach specific vehicles in a specific order and be able to keep track fully of the fantastically complex logistics of doing so), but to simulate the result of shunting at a more abstract level: trains join together at a station and automatically (allowing for a lapse of time) re-arrange themselves into the correct order. Thus, there is no need to simulate shunting yards, as such: there might be sidings to be simulated, but in those cases, there would be no need to keep the loads on vehicles in those cases.

As 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.

Offline ACarlotti

  • *
  • Posts: 483
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #38 on: February 03, 2018, 11:52:20 PM »
As 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.

If I recall correctly (although it was some ago that I checked the data), timetabled 3-way splits/joins currently occur on the UK rail network in just two contexts:
1. The Highland Sleeper has a 3-way split/merge at Edinburgh, with smaller locomotives and additional seated carriages to the north replacing a single large electric locomotive to the south. (http://www.realtimetrains.co.uk/search/advanced/EDB/2018/02/13/1200-1159?stp=WVS&show=all&order=wtt&toc=CS and http://www.scot-rail.co.uk/page/Caledonian+Sleepers have details, although the former doesn't detail all the shunting movements. Note that platforms 1 and 2 are the opposite ends of 20 and 19, with a crossover in the middle, and the electric locomotive stays at Edinburgh during the day.)
2. Empty coaching stock movments at the beginning of the day sometimes involve multiple DMUs or EMUs running into a station, before becoming up to 4 different services. (And the reverse at night.)

Returning to Simutans, I think the best way to try implementing something like 1. in Simutrans is to allow mulitple consecutive stops at the same location. It's then just a case of working through each separate split/join event sequentially, rather than being a big mess of 4 incoming convoys all recombining to 4 outgoing convoys simultaneously. (2. is not relevant to Simutrans since we don't simulate day/night or peak/off-peak.)

Changing the way consecutive stops at the same location are handled would be useful anyway. At the moment attempting to change a schedule of the form a>A>B>C>c>C>B>A to the form a>A>B>C>D>d>D>C>B>A by deleting c first also deletes one of the Cs, which is particularly annoying if that C had settings that you wanted to retain. (In this case a,c,and d are waypoints to allow simulating a bus stand.)


I've been thinking about how you could set up running freight trains that pick up and drop wagons enroute, and have two ideas here:
Idea 1:
Allow attaching tags to vehicles, which can be set and read in consist orders. So you when you pick up vehicles from an industry and ship them to the mainline, you can set a tag to indicate where they should go, which can be read by subsequent consist orders to ensure the correct routing later on. In its most basic form, such tagging would be invisible to the path explorer, but would be used to ensure that the correct amount of vehicles go to each downstream destination, and perhaps also to minimise the amount of cross-loading of goods when coupling/uncoupling (which might be able to reduce the loading time at that location). However, this idea struggles with multiple flows originating a the same station, and I'm not sure how you'd fix that.

Idea 2:
Add the option to specify that particular vehicles should only load goods for one destination (which maybe could be a building/industry, a destination station, or transfer station), and then allow a consist order to specify which wagons to include according to which of the two schedules is next on the intended journey of the first item of freight in the vehicle.

In both cases, there could be a difference in the coupling time depending on whether any goods need to be moved to another vehicle (or the platform if there is insufficient capacity, or everything can just be left where it is.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #39 on: February 04, 2018, 11:38:01 AM »
Thank you for your thoughts on this: that is much appreciated.

I agree regarding the multiple consecutive stops: I will have to modify the code to allow for this without deleting (I think that this should be fairly straightforward, as I think that there is code somewhere that specifically exists to perform this deletion).

As to the vehicle tagging: how had you thought of setting these in consist orders? Since consist orders are to consist of the state of the consist after any re-combination operations, this would not easily allow for tagging of vehicles already in a convoy (especially in respect of those vehicles that form part of a convoy when initially assembled in the depot). Had you imagined that the vehicles would be tagged by portion of the train, or separately for each individual destination that might be served?

Offline ACarlotti

  • *
  • Posts: 483
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #40 on: February 04, 2018, 02:16:59 PM »
What I had been imagining with tags is a way of being able to define a consist by both the vehicles in it and by what tags those vehicles should already have. The idea occurred to me while I was thinking about the possibility of getting specific vehicles to go to specific places by choosing different types of vehicles to go on different routes.
As an analogy, you could consider it as allowing vehicles to be painted different colours, and rather than a consist order saying for a particular vehicle "I want a bulk goods hopper", it could say "I want a blue bulk goods hopper", or event "I want a blue bulk goods hopper, which I'm then going to repaint in pink in the new convoy".

The idea of tags would be that you could, in a somewhat clumsy fashion, say that "these vehicles ought to be carrying goods to go onto these routes when the convoy divides". A more intelligent, but I think still feasible approach, is to actually allow the consist to be determined based upon where the goods in each vehicle want to go to. This would require either a per-convoy or per-vehicle setting to say "only load stuff for the same destination within each vehicle".

So in terms of code (loosely), I think this (by which I mean the non-tags idea) would require:
1. A change to the vehicle loading code to enable restricting goods to have matching transfer points if the vehicle. Whether to apply this restriction could be determined by a boolean stored in the vehicle (or possibly in the convoy). (This could be implemented separately before any of the following, and could also be useful in combination with conditional skips.)
2. The ability to specify in a consist order that certain extra types vehicles will be taken if the first good they are carrying has a next transfer point that is best reached via the associated schedule.
3. An addition to the decoupling code to be able to determine which portion of the convoy provides the best (or at leat some) route to a particular transfer point.
4. (Optionally) The ability to automatically set a vehicles boolean flag for loading only to a single destination. The most sensible place to do this would appear to be in a consist order.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #41 on: February 04, 2018, 03:49:30 PM »
This is certainly an interesting idea - but, to take your colour metaphor - how would players say "I want this open wagon to be blue" when "this open wagon" is part of the convoy as as originally assembled at a depot? Would you imagine a second interface for this beyond the consist orders?

Offline ACarlotti

  • *
  • Posts: 483
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #42 on: February 04, 2018, 04:51:33 PM »
There could be a second interface, although that probably isn't strictly needed (at least if otherwise redundant consist orders are allowed).

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #43 on: February 06, 2018, 12:28:01 AM »
There could be a second interface, although that probably isn't strictly needed (at least if otherwise redundant consist orders are allowed).

Thank you for the clarification, and apologies for not having reverted earlier on this, as I wanted to think about this carefully.

I can see that there might be some benefit to this idea. Had you imagined this as a bitfield of flags that could be set to change in consist orders or set initially in the depot/convoy details window? This is how I am currently imagining that such a feature might work: there would be the aforementioned 16-bit bitfield per vehicle. By default, these bitfields would be set to 0. The consist orders would also have an additional 16-bit variable for each vehicle consisting of that vehicle's bitfield. This would also be zero by default. If all bits set in the consist order's vehicle slot are also set in the vehicle's bitfield, then the vehicle would be considered suitable to be used, otherwise it would not.

I am not quite sure how to represent this in the UI to the player (16 checkboxes seems as though it would be very awkward design) - Ves, have you any thoughts about this? Does anyone have any thoughts on how this suggested implementation would affect usability for the player?

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #44 on: February 06, 2018, 10:44:53 PM »
I’m trying to wrap my head around the new additions by ACarlotti:
Is the idea to add some kind of filters for the player to set when they create the consist order?
Would it for instance work like if you have a huge network, and then a region further away, you could mark each vehicle with, say color blue, and do that for all vehicles going to this region, and then the lines actually traveling to the region would in their consist order have just something like “all blue cars” without the need to go too much into detail?

In other word, a “vehicle grouping”?

Would a vehicle be able to hold more than one “color”?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #45 on: February 06, 2018, 10:50:19 PM »
From what I understand, ACarlotti's suggestion is for the tags to be an additional restriction on which vehicles may be coupled to a convoy as a result of a consist order. It would not be possible for the tags alone to define this, as, for the reasons given above, it is necessary for the type of goods carried to be deterministically set for each vehicle in each set of consist orders.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #46 on: February 08, 2018, 12:52:37 AM »
I should note that I have begun to implement the data structures for consist orders, and I should be grateful for feedback before proceeding further on that specific part of the code.

This is discussed more fully in the technical discussion thread.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
I have begun the work on doing the vehicle management window, as that seemed more straight forward, both conceptually and technically, than the consist order window. Hopefully I will also learn some new GUI techniques that I can use in the consist order window later. The "vehicle manager" window does now exist on a local branch and it currently only do two things: lists the vehicles you own, and lists all vehicles available to you (I know, i promised to code that YEARS ago  https://forum.simutrans.com/index.php/topic,13654.msg135690.html#msg135690. Well here it is.... ;) ) in two separate lists, and all sorted with tabs by waytype, like in the "schedule manager".
The plan with the window is to make it easier for the player to "manage" the vehicles, to get an overview of what vehicles the player owns and perform actions across multiple vehicles by tabs benieth the lists, featuring stuff like "information", "payload", "maintenance/upgrade" or whatever names for the tabs is suitable. Also, I would like to be able to sort, especially the left hand list, by different parameters etc.
Im still in the proces of making the two lists "speak" with the window (it is apperently not as straight forward as one might think) so when a vehicle is selected, the window knows what vehicle is in fact selected, and wether it should unselect the previously selected vehicle etc.

I have some questions:
1 - 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?
2 - I am puzzled as to what to do with multiple unit vehicles, that is vehicles that will never decouple outside a depot. Preferably I would list them together as a entry in the left list, however, I dont know currently a solid way to distinguish between a multiple unit vehicle that never decouples, and a vehicle with constraints, but which do decouple. I imagine that you anyway need to adress this, so the player cannot unrealistically couple and decouple vehicles that ought not to be, for instance via some datfile parameters? something like:
fixed_coupling_outside_depot_next=1
fixed_coupling_outside_depot_prev=1

3 - Are there any specific features that you (as in both James and anyone else) would like to see in this window (if possible), or any suggestions to improvements I could do in the window?
4 (new) - Will there be any way to identify specific vehicles, like a unique number or desc-name combined with a number or similar?

Lastly some screenshoots of the work in progress window: Note that the entries on the left list autoresize according to the picture, so they dont overlap, which Im quite proud to have achieved. I consider removing the pictures on the right hand side, to allow for some text instead, and because the picture will be visible on the left hand side (and also elsewhere I plan to) anyway. Also, you are supposed to click on a vehicle in the left hand list, to make it show up in the right and list, but currently it shows all vehicles you own for that waytype (remember the "speaking to window" issue I wroter earlier?).




On a side note: Scrolling through the lists really makes one appreciate the fantastic quality on all of the vehicles in Pak.Britain, and in such quantities! 1659 rail vehicles, to name a few  :o
Well done Pak.Britain(-ex) creators and maintainers!  :thumbsup:

edit:
Added question nr 4
« Last Edit: April 30, 2018, 08:12:23 PM by Ves »

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2732
  • Languages: EN
A thought occurred to me the other day. When this feature is added one should probably give some vehicles an absolute maximum end of life date, after which the vehicles are automatically sold or confined to depot forever. This is to represent that some vehicles are no longer legally allowed to be operated for safety or other reasons.

For example the boy riding a pony delivering mail eventually has to stop due to child labour laws preventing one from exploiting child labour in later years. Another example is in the distant future, eg 2040, all fossil fuel powered vehicles can no longer operate due to strict emission laws. A final example would be that all steam trains have to be pulled from lines and replaced with either electric or diesel by a certain date, as happened with British Railways.

Offline ACarlotti

  • *
  • Posts: 483
1 - 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?
I'd say the most important consideration when writing code for the gui (apart from correctness) is that it be as readable as possible. Players will only have a small number of gui windows open at one time, so it seems unlikely that generating gui elements such as this will take up a significant proportion of the overall processor time. Of course, if it does turn out that the current implementation significantly slows the game (though only for the player using that gui), then it would be time to look at optimising for speed or memory at the expense of a little readability.

It would probably be sensible to place a method to list all vehicles used by a player in a sensible place (player_t seems appropriate), where it will be easier to reuse the functionality elsewhere or modify the algorithm used.

Quote
4 (new) - Will there be any way to identify specific vehicles, like a unique number or desc-name combined with a number or similar?
Are you looking for something similar to the internal ids used for convoys?

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
DrSupergood, that looks interesting,  but I highly doubt James will do that, since he probably will want it to not be economical feasible instead, forcing the player to change the old vehicles.

However a variant of your suggestion: the player could determine that at a specific year/month in the future that (s)he wants a replacement, or retirement, of a particular vehicle should start.
James?


ACarlotti, thanks!
You probably have a point that no more windows usually would be open if this window is open, I just was wishing for a more “obvious” solution than how I have done it. Also currently, I realize, I have missed the vehicles you own, but which has not become part of any convoys, but only lives as single vehicles in the depot vehicle selector. Putting it at vehicle_t is probably a good thing, it is, however, nothing I dare do.

Yes, I had envisioned In my head that the individual vehicles would get some kind of ID number to help tell them apart.
If the ID starts at 0 (or some other player set value) for each vehicle type, it would perhaps be easier to memorize the vehicles, as it would come somewhat close to how the real life litera numbers where composed.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Ves - thank you very much for your work on this: it is most appreciated.

My apologies that I have not had more time to work on the vehicle management features of late: my Simutrans time has been taken by a large number of bug reports from the online game relating to time interval signalling. In short, the reason that there have been so many issues is that there were a few specific use cases that had not been tested that unexpectedly did not work with the current code and required significant additional logic to make work, but, because of the enormous complexity of the signalling system, that extra logic now requires extensive and intensive debugging. When most of the bug reports use the server game as a reproduction case, the size of that game makes running it in the debugger so slow that it takes 5-20 times longer to diagnose each bug than would be the case with a reproduction case in a smaller map. I have also recently taken up railway modelling, which is taking some of the time that I might otherwise spend on Simutrans-Extended.

Turning to your questions, I will answer them in sequence.

1. There is no better way of doing this so far as I can make out. Indeed, this is the way in which things are done in convoi_frame.cc (although the convoys owned by a particular player are cached there so that the world's list of convoys only needs to be read once for every time that the window is opened). As A. Carlotti states, however, this aspect of things is not performance critical.

2. I do not think that this distinction is entirely practical, as there is no fixed concept of such convoys in the game. In reality, multiple units on railways were sometimes uncoupled and coupled outside depots in ways that are not now considered normal. There were some trains that were semi-permanently coupled together with bar couplers or the like (and still are: think of modern multi-vehicle trams, for instance), but there are no data for distinguishing these from vehicles that have normal couplings but are rarely uncoupled from anything else. One distinction that you might consider is a vehicle that has exactly one constraint requiring coupling to another vehicle which also has exactly one constraint requiring coupling to the first vehicle: such pairs of vehicles would thus only ever be coupled to each other. However, this will produce many false negatives: even many steam locomotives share tenders with other locomotives, for example. Adding extra data just for UI handling in this way would be a huge task for Pak128.Britain-Ex given the number of rail vehicles. If anyone can think of anything ingenious for this, however, this might well be worth considering.

3. It would be very useful to have cost statistics (including for cost based features planned but not yet added, as discussed in this thread) and some way of comparing different vehicles in different ways. One might have, perhaps, a system for predicting future upkeep cost if present trends continue (taking into account future wear, etc.), although I appreciate  that this will be difficult to code for without the code for the underlying feature being written, so it may be better simply to prepare for this feature being added in the future.

4. Vehicles do not have the same handle system that convoys and stops have. Thus, whilst it would be easy to add a system for stops that works in the same way as it does for convoys because the basic code for this is already present, just missing in the UI (presumably, because it was not thought useful), there is no code anywhere dealing with automatic numbering of vehicles, and adding this would be quite an undertaking. Internally, they are distinguished simply by pointer addresses, which are non-stable in that they vary between load/save cycles and between different computers in a network game (although remain consistent outside a load/save cycle on any given computer). In reality, vehicles did have numbers: road vehicles and aircraft have registration numbers and rail vehicles have rail company internal numbers. In theory, it would be possible to provide for automatic numbering on creation based on a numbering scheme predefined in the .dat files (which would have to allow for letters as well as numbers to permit, e.g., registration numbers); but this would get very complex and require a huge amount of work. Much easier would be to identify vehicles of the same type by date of purchase and convoy membership. Vehicles that are identical in both of those respects may not need much distinguishing.

As 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.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Thanks for your response, and no worries, Simutrans doesnt run anywhere :P Best luck in your model railroading, I used to do that but have no space for it currently  ::(

1) Ok, I will keep this for the moment then!

2) I was thinking about if there where some clever way to find it by looking at the constriants, but as you write there will be false positives and negatives everywhere. I was also thinking if there where any way to identify a "tender", so they could be displayed in a clever way.
I do think that this is something that really is worth considering. You have many vehicles, which in real life would be considered one vehicle, but the technical limitations in Simutrans makes it into two vehicles. For instance you have multiled busses, or trains running on "jacobs"-type boogies (two cars share one boogie), and also the additional cargo- and passenger holds for many of the vehicles in pak.britain. I dont think you want the player to be able to rearrange that on the fly?
On the question to where to draw the line, I would think that it is the pakset maintainer that decides what is considered "easy" separations to do at a platform and what is not. You could combine it with a "separation_time", where the pakset creator can estimate how long time it takes to separate a vehicle from the next and previous.
The subject of constraint groups has been brought up many times before, and that could be a quite elegant solution.
However, getting around without having to edit all those vehicle datfiles I also struggle to figure out...

3) Indeed! A tab with charts could be very usefull! I would like to be able to do predict future costs and dates, that is a good idea!

4) Ok, I do get the point that one could question the need for a separate vehiclename, as it would mostly only be for the GUI anyway. I will then not plan for it in the lists.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
In relation to no. 2: one of the issues is that there are not really hard boundaries. Vehicles (in the Simutrans sense) that would be treated as separate vehicles for accounting purposes, for instance, might not be uncoupleable at stations (consider as in the example of a train made up of quite separate carriages coupled with bar couplings). However, a vehicle such as an articulated 'bus would be treated for all purposes as a single vehicle in reality, whereas in Simutrans, it is treated as two vehicles. Thus, there is no universal way of defining multiple vehicles as an inseparable unit that makes sense for all purposes.

Had you imagined a need for a way of distinguishing which vehicles can and cannot be uncoupled out of depots for the purposes of the convoy re-combination? This might possibly be necessary, but this would not be quite the same thing as you had in mind.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2732
  • Languages: EN
Quote
As 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.
One cannot really bring in "enthusiasts' special trains" into the argument as they are a special case where the attraction is the vehicle/train itself rather than where it is going. People come from all over the world to have a ride on the GWR 4900 Class 5972 Olton Hall aka "Hogwarts Express" due to its  appearance in the Harry Potter film series.

These are unique pieces, something currently not simulated in Simutrans Extended and unlikely to be so for a long time for complexity. Further more many of them have had extensive modification to comply with modern safety requirements. Often the combined cost of restoration and modification far exceeds the cost of a brand new and better equivalent. As such technically there is a hard cut off date because beyond that the cost of keeping a fleet of them serviceable exceeds the cost of buying a fleet of replacements and hence they might as well be automatically replaced.

When British Rail anti-steam policy was in full effect they did not allow any steam engines on most of the main lines. This was a huge problem for some of the enthusiasts who brought up their favourite trains from being scrapped as they could not run them in the UK as there were no suitable track stretches to run them properly. This is why many trains ended up being sent to countries like the United States of America where they were still allowed on the tracks. This has obviously changed, with Network Rail permitting steam trains on tracks as long as they fit all their requirements which many can do.

Anyway another idea to tie in with wear and other mechanics for vehicles. Some vehicles should also be given a finite life expectancy before they cannot be used and must be replaced. This is because maintenance and overhauls are not sufficient to prolong the safe use of the vehicle. Generally the vehicle would be renewed with itself, but if not available one would have to renew it with a like equivalent.

This is realistic and would apply for the following.
  • Horses: Horses have a finite life expectency. They eventually die of old age, and often start to under perform long before then. One cannot fix such a horse, and rather has to out right replace them. Horses are technically an asset of the company.
  • Boats: Boat hulls have a finite life expectency. After this is exceeded the hull runs a risk of catostrophic failure so the ship is no longer safe to use. Although less common with todays hull designs, this was especially the case for Clipper type ships which had under a 30 year working life before hull fatigue became a problem. Since most of a boat is the hull it effectivly means ordering a new boat for a replacement. Old wood ships had near no scrappage value due to how common and degraded the wood was, but metal hulled ships retain a significant scrap metal value.
  • Winged aircraft: The airframes have a finite life expectancy due to fatigue. Once the airframe is at end of life it is not safe to fly the aircraft anymore and a completly new airframe is needed. Airframes are so complex and precise that only aviation manufacturers can make replacements, which effectivly means buying a new plane. Planes are unique in that scraped aircraft retain comparitivly a lot of value since changeable components like engines might still have considerable working life remaining so can be resold at high value as spare parts.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Yes indeed I had imagined that it would not, for instance, be possible to swap the backend of an articulated bus with another! Imagine an articulated bus drives to a stop, decouples the backend, connect another and then continue. Altough it might look funny with lots of backends waiting around, it illustrates something that should not be possible. People would be reporting that as a bug.

Also in this multiple unit era, which for some part is heavily built around hard constrained consists, but whith easy coupling between consists. It would only add to the immersion and gameplay depth if the player has to take into account that (s)he cannot separate the units outside the depot.

No, you are right that there is no universal way to define what vehicles are considered inseparatable, that is why I believe it is best if the designer of the pakset steps in and define what vehicles can separate, and what not.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
There is a fundamental difference between the lifetime of a specific vehicle and the lifetime of a type of vehicle. As discussed here and elsewhere, it is certainly intended to simulate the lifetime of particular vehicles by making the cost of an overhaul the cost of replacing the vehicle entirely (especially in the case of horses). In some cases, this may require a variable overhaul cost where subsequent overhauls cost more than earlier overhauls. However, the lifetime of particular vehicles (aside from biological vehicles, for which a special case will have to be made in the code because of the inherent nature of biological organisms being different from mechanical vehicles), the lifetime of vehicles will be based on usage, not time elapsed (and lifetime being based on time elapsed since purchase is in any event different from lifetime being determined at a specific date not related to the date of purchase).

Lifetime of types of vehicles is a different matter entirely, and is what I was addressing in the previous post. There are virtually no examples of an entire type of vehicle, even with suitable modifications, being prohibited entirely after a certain date. Even if a few such examples could be found, they would be so rare as not to justify the extra effort in coding this feature just for them.

In relation to steam locomotives, the point that I was making was simply that there was no prohibition on steam locomotives on the ground of safety: they were discontinued in service because they were found to be uneconomic as labour costs rose. That underlying incentive will be simulated. It is otiose (and unrealistic) to impose an additional artificial constraint founded, not in economics, but in the calendar date for the usability of any type of vehicle.



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

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Ves - 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?

Yes, in its basic form, yes.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Yes, in its basic form, yes.


I can see that that may well have merit. One thing that should be considered, however, is what should happen when (1) one of the two vehicles has this datum specified and the other does not; and (2) both of these vehicles have this datum specified. Not being clear about this at the outset, I imagine, will lead to much confusion later.

Had you any thoughts about how this should work?

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Well, it should, in its simplest form, be quite straight forward:

If we implement two new datfile parameters:
fixed_coupling_outside_depot_next=1
fixed_coupling_outside_depot_prev=1


... then, if a vehicle has this parameter, it can never decouple outside the depot, no matter what the other vehicle has. The existing constraint mechanics would work as usual and determine what vehicles can be around this vehicles.

Whatever calls are being made for a vehicle with this parameter, would in effect be a call for all vehicles which are currently bounded together.
So, to illustrate with an example:

Vehicle "A", "B" and "C" are being in layoff state at some station. Then comes convoy "X" and wants to connect vehicle "B". This would result in both  "A", "B" and "C" are connected, and in that specific order, if not reversed.
Where to put them in the new convoy to make sense is another question, but that is something we anyway will have to deal with in some way.

This would of corse only apply in cases where it would otherwise violate the rule never to separate them. For instance it should still be possible to change the classes of only one of the vehicles, and their info window would still be just like any other info window.

Offline Ranran jp

  • *
  • Posts: 484
  • Languages: ja
I played Simutrans-Extended for a couple of days. I am having a lot of fun. I am looking forward to this feature.

BTW, "fixed_coupling_outside_depot_[hoge]" is not "constraint[hoge] do not have the parameter none or any"?

I mean, normally multiple unit's intermediate car does not have the constraint parameter "none".
It may have more than one constraint, but in such cases, they will recombine in the depot.

Only the driver's side of the lead car has "none".
There is no problem even if they separate them outside the depot.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank 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?

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Thank 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?

In this case, I would think that the restriction should in fact be enforced, and it should be ignored that vehicle B doesn’t have the parameter.

The effect would be that once vehicle B gets attached to vehicle A, it can never detach again, if not done in the depot.

I would also think that if the “fixed_coupling_outside_depot_next=1” is specified, but no more vehicles are attached in the depot, this end would in effect become “un-attachable” outside the depot.

Reasoning:
The parameter should symbolize that “this vehicle wont work properly, due to realistic limitations, simutrans technical limitations, or pakset artistic, graphic or design decisions, if this end of the vehicle can be rearranged outside the depot.”


Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you - that is very helpful. I will look into implementing this when I get a moment, although I should note that this may be a while, as bugs are still being reported at a rate faster than I can fix them.

Offline tubanonymous

  • *
  • Posts: 27
A few brief thoughts on the topic

1) Any sort of shunting feature would be awesome

2) I've read the thread, but having a hard time imagining what the end result looks like. Say I want to move 5 passenger carriages from one loco to another at a given station. Does the first train stop in the station, then drive to the nearest depot to reassemble; and then the second train also stops at the station before reassembling the 5 carriages inside the depot? Or do the trains pull into the station, and the carriages just pop up in the proper position after a given amount of time, like with reversing?

3) Would it be useful to create a locomotive type with the blender image of any given passenger or freight carriage, and set the power factor to 0? The cars that are shunted are in themselves their own convoy, and are assigned an order to attach to another train? The problem with this is that locomotives cannot come after carriages in simutrans. Something I always found odd...

4) Is their some aspect of the simutrans code that would require shunting to involve use of the depot?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18750
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
To answer your questions: the exact mechanism of how this is to work has developed over time to an extent, which may be why you are having trouble visualising it. However, the current plan is for convoy re-combination to occur at stations rather than in depots. I am afraid that I do not really understand the third question. As to the fourth question, the current plan is for vehicles to have to visit depots periodically for maintenance and overhauls.