News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Improving the convoy replacer without allowing for exploits

Started by jamespetts, January 03, 2015, 05:50:43 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

I am in the process of considering what to do about improving the convoy replacer. Many people have complained that having the convoy replace in the way that it does now can create great network disruption and be very difficult to do because of the fact that the convoys have to visit the depot to replace. Another issue is that stored but out of production vehicles cannot be used because they are not available to select in the convoy replacer window. This is not trivial to solve because if they are located in an actual depot, it is not easy to send the convoy to the right depot to collect them, especially if they are in multiple depots or in a depot entirely disconnected from the convoy's present position.

One idea that would solve both of those problems is not require convoys to return to a depot to be replaced, and simultaneously combine all of a player's depots so that any stored vehicle in any depot can be used to create a convoy in any other depot or in the replacer. Convoys would be replaced in motion (just as they are deemed to be maintained in motion), and this would work efficiently and easily with the planned overhaul system.

However, there is a potential problem: players might use the ability of vehicles, in effect, to teleport around the map as an exploit. Imagine a long freight run, from A to B, with a coal mine at A and a power station at B. Suppose that the player puts a depot at both A and B. The convoy starts at A, collects the coal, and runs to B, where the player manually sends it to a depot. The player then creates a new convoy in A using the existing (now stored) vehicles in the combined depot store, and assigns it to the coal line. The convoy has, in effect, teleported on the empty part of its run, not only avoiding the time, but also the running cost (and, now, the wear on the way) of that journey. The player could, in theory, carry on doing this for ever, though it would be very tiresome.

Can anyone think of a robust way of avoiding this exploit whilst preserving the desired features of ease of convoy replacement?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Banksie_82

Correct me if I'm wrong, but I think this exploit already exists.


One only needs to sell the convoy at Station B (without the need for a second depot) and create an entirely new one at Depot A. If the time taken from Depot A, Station A then Station B, is within the same month, there is no cost penalty as the depreciation hasn't taken effect. In any event, the depreciation is usually fairly minimal in any given month, making this exploit more than worthwhile.


But like you said, the practice would get very tiresome and not very fun.

jamespetts

Yes, I am planning on fixing this, however, by changing the sale mechanism: players would only be able to sell to other players (except for new stock that has never left the depot, which, as now, can be returned for a full refund as a sort of undo function), or sell as scrap for a very low proportion of the purchase price.

It would indeed get tiresome to do this, but the whole point of avoiding an exploit is to avoid presenting players with a dilemma of doing something tiresome for great reward or not.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Sarlock

I wouldn't worry about the potential for exploit too much - as mentioned it already exists.  It requires a lot of micromanagement to make any profits and only saves part of the running cost for the player - it doesn't increase revenues.  It doesn't really amount to much; they'd be better off investing their time on a new line than trying to squeeze another 5-10% off an existing one.

On long rail lines, the convoy replacer is really difficult to use, so I certainly would welcome an improvement to the system.

You could also just allow replacement to occur on the fly but still require the same depot mechanics as exist now for all other depot-related functions (buying, selling, etc).
Current projects: Pak128 Trees, blender graphics

killwater

I think that this is in fact a bad idea. Have you considered single player game? This is also not very realistic because in reality you can sell your vehicles to many other companies all over the world. And in this case I am afraid it would be a very rare situation in multiplayer absent built in chat.

jamespetts

Sarlock, thank you for your thoughts: that is interesting.

Quote from: killwater on January 04, 2015, 09:57:50 AM
I think that this is in fact a bad idea. Have you considered single player game? This is also not very realistic because in reality you can sell your vehicles to many other companies all over the world. And in this case I am afraid it would be a very rare situation in multiplayer absent build in chat.

As to selling vehicles, the idea is that they will remain in a for sale mode in the selling player's depot until they are sold or scrapped, and will appear in a second-hand selection window in every other player's depot until they are bought, so it would not need two players to be online at the same time or even make any effort to co-ordinate a sale.

As for a single player game, is selling (as opposed to scrapping) vehicles actually that important? A single player game represents a country with only one transport company (unless there are multiple human controlled companies), which often did have to use vehicles until worn out and then scrap them.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ves

About using it as an exploit:
Keep the depots as they already are at the moment and add a button in it to allow teleportation to a station in convoy schedule. The teleportation then looks up the distance between the depot and station and are then teleporting at say 15km/h or something. This to make it too tiresome and difficult to exploit and also reflects that trains (and trucks and boats and maglev and so on) actually can be delivered to or from a site on a truck or boat instead of driving it self.
This way you can still have physical depots with the specific vehicles inside it (which at least I like) and you can move vehicles around the map without using any infrastructure causing damage to schedules etc.
It could even be combined with a cost to move it, but that might be overkill! :-)

jamespetts

Having that sort of timing feature is extremely difficult to implement, and is also likely to be difficult clearly to explain to the player in a concise UI.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Sarlock

With respect to convoy replacement -- when this is performed, the convoy will be set to "no load" which requires it to continue on its route until all cargo has been unloaded.  Then, it will perform its replacement, which means that this step occurs at a station.  As it is now, this convoy will then travel to the depot and perform the upgrade.  If, instead, the upgrade is instantaneous, then this will occur at the station it last stopped at to unload its cargo.  From a realism perspective, this isn't that big of a deal, since we can safely make an assumption that a station has a depot in it without stretching the imagination too far.

There will still be the case where a convoy is empty when the replacement is issue and it will upgrade "on the fly" mid-station, but I don't think this is a big concern.

I know from experience with the server game that this change would be a massive help -- I've had rail lines of several hundred trains bind up irreparably when using the replacement tool and have had to do a lot of manual effort to fix it (usually force selling convoys and issuing new ones).
Current projects: Pak128 Trees, blender graphics

killwater

@ jamespetts

I do believe that selling is extremely important in single player game. You can get part of the invested capital (which haven't been depreciated yet) back when you decide to change or liquidate the line. I do it quite a lot in early game stage.
In fact in Poland vehicles are sold after some time to other transport companies and we even import like 15 years old trams from Germany which are then used for the rest of their useful life. It helps to decrease the required capital investment cost to maintain the service.

jamespetts

Quote from: killwater on January 04, 2015, 10:52:22 PM
@ jamespetts

I do believe that selling is extremely important in single player game. You can get part of the invested capital (which haven't been depreciated yet) back when you decide to change or liquidate the line. I do it quite a lot in early game stage.
In fact in Poland vehicles are sold after some time to other transport companies and we even import like 15 years old trams from Germany which are then used for the rest of their useful life. It helps to decrease the required capital investment cost to maintain the service.

Perhaps this should be optional, and disabled in multi-player games?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

killwater

I do not know much about multiplayer to be honest but if it is optional for single player than it would be perfectly fine from my point of view.

P.S. Great that you are back on developing. I must say I am really looking forward to new changes.

jamespetts

It might be a while, as there are quite a few things that need to be done, including the gargantuan effort that will be city growth.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

zook2

Avoiding the huge traffic jams when replacing 20+ trains at once would be a great help in single player. Depot-less replacing sounds fine, and a long enough fixed waiting period should discourage exploits. Let's say the replacement takes place after two game months (default time settings) or when the convoy is empty, whichever comes last.

jamespetts

Fixed waiting periods are very tricky to code and are things to be avoided if at all possible, since they require extra data to store the time, and then for the program constantly to check to see whether it is time to do something yet. In the meantime, if the game is saved, all of those data (including the time) have to be saved into the saved game. This can greatly complicate things.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Matthew

A longtime lurker would like to throw in his pennyworth.

The proposed alternatives are worse than the present system. If you need to replace a convoy, it does cause disruption but surely that reflects real life.

If you are running hundreds of convoys (as I believe that some Bridgewater-Brunel players are) then you've got to expect to invest in dozens of depots too. The micromanagement may get tedious, but that also reflects reality - big organizations often find it difficult to manage the size of their operations. This problem is balanced by the fact that you have the capital to build spare convoys to ease the replacement process, something that a smaller operation maybe can't do.

The minimum necessary change would be to permit vehicle 'teleporting' at a cost. There could be a 'Move to another depot' button in the depot interface (it would be nice if named depots could be selected from a dropdown list). This should only be available for vehicles using some kind of rail or guideway (since I presume road vehicles, ships, and aircraft don't normally have any difficulty getting to the desired depot). This would simulate the cost of having a wide load transporter move the vehicles by road. The player then has an 'interesting decision' to make: run the railways/tramway/etc. at 100% capacity and fork out for road transportation of stored vehicles, or run the rail network with some spare capacity that allows you to run empty convoys to the depot where the vehicles are needed.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

Sarlock

From experience, what happens is, even when you have depots all along the line, the convoys will finish their run and unload all cargo in their "no load" state and then proceed to a depot.  Sometimes this isn't always the next depot on the line, for whatever reason (I've watched trains choose a depot way down the line even though one is just down the track from it).  Further, when the train exits the depot after upgrading, it wants to get back to where it was previously on the line, not carry on where it currently is, and this makes it reserve a huge section of track and can completely bind the line up so that it freezes and cannot be undone except by mass deletion of many of the stuck convoys.

The system could likely be improved somewhat to address this, but I think it is a very difficult issue to tackle, as it would require the updater to determine where the best depot is on the line and how best to reintegrate the train once it returns to service.

The proposed change to instant upgrade would be far easier to code and for players to understand.
Current projects: Pak128 Trees, blender graphics

Aquin

Instant exchange at the next station doesn't sound too bad. If the new convoy has higher capacity than the old one it might even be possible to do it without complete unloading. If the new convoy is smaller than it refuses to take on load until all the cargo fits into the new convoy. You'll have to pay the running costs to and from the nearest depot for the two convoys (although they don't actually drive there).

Or if you want to actually see your trains move in and out of depots:
In the replacer-gui you can specify a last station serviced, a depot and the first station serviced.
The old convoy will - if it has cargo to beyond "last station" continue there normally.
- if it has no cargo to beyond "last station" it will not take on new cargo to beyond that station.
- when it reaches "last station" and does not completely unload, go on a final round without taking on new cargo going beyond "last station"
- when it reaches the last station and comletely unloads it moves to the specified depot.

OR: it moves on to "last station" drops all cargo there to be picked up by the new trains.

The new convoy starts at the depot, this can be immediatly  or whenever a convoy enters the depot.

jamespetts

This discussion is in many ways about a long standing issue that is quite hard to resolve in principle regarding how vehicles are to be understood in the game and how they are to work. On the one hand, there are many aspects of vehicle/convoy handling that are missing what might be considered important things from real life: trains can only run as fixed formations unless manually re-formed by a player in a depot (which is very much at odds with how trains actually worked until recently); vehicles never need to be serviced or replaced unless they are obsolete; railway signalling is very basic; reversing is handled in a very generalised way and there is no provision for turntables or anything equivalent at stations. The absence of some of these matters is significant economically. However, implementing many of these can be very complex, in part due to knock-on effects for other aspects of the game: allowing convoys to divide and combine mid route, for example, would make things extremely difficult for the routing system. Some of these can also add what some players might consider too much complexity: should a player really have to go to the trouble of manually setting up turntables at terminus stations to reverse steam trains (but if changing locomotives was permitted, what if it was faster to change to an already turned locomotive than the normal reversing time of the train?).

On the other hand, there are issues with the replacing system that is already in place: it is difficult to use, does not make proper use of stored stock, and can cause terrible disruption when it is used. An easy solution to these problems is to simplify and abstract vehicle handling by removing the requirement to visit depots for replacing, which would work neatly with the planned overhaul system in that overhauling and replacing could be treated alike. This would do away with the enormous complexity required to make the replacer work well for stored stock that might be located in a great number of depots all accross the map, some connected and some not. Such simplification introduces issues of its own, however. Should replacement/overhauling take place immediately, or only at a stop and only when the convoy is empty? For replacement, this makes sense because the replaced vehicles might have a different capacity to the current vehicles, but for overhauling this might be a bit much. Should a convoy have to wait longer at a stop than the usual (which might only be a few seconds normally) to be replaced or overhauled? If so, how long? If this is too short, it would be pointless having the extra time; but if it is too long, it would have the potential to cause much the same sort of disruption problems that the current replacer causes.

There is also the vexed question of how a simplified system would work in conjunction with future developments in operations, especially for railways, which in particular suffer from the lack of ability to change the consist of a convoy during its journey (even Railroad Tycoon had this facility, albeit it was rather simplistic). Would it not be somewhat inconsistent to have, for example, a locomotive waiting in a specific siding, and meticulously exchange for another locomotive on a train, which then goes itself to a siding to wait for another train coming in the other direction (and not necessarily on the exact same line) when actually upgrading one locomotive for another can be done by magic; or is this inconsistency more superficial than real on the basis that what we simulate operationally are vehicles' typical timetabled operations, not their maintenance and servicing, and that the locomotive change (for example) falls into the former category and the replacement into the latter? If the latter is true, would this give incentive to players to build unrealistically simplistic infrastructure in which sections of rail are isolated from others rather than joined as they are in reality, even if the join is used only for occasional working to depots? Currently, players quite frequently build tracks that only go to depots or that are only used when replacing. There is also the issue of what to do about replacing vehicles if a line were to call for (e.g.) a locomotive change at a specified point, for example, to switch between steam and electric traction. The best way to set this up would be to allow locomotives to be assigned to "pools", and to allow multiple lines to access locomotives from given pools; but how would replacing of those locomotives (and, of even greater complexity, if changing the whole of trains were permitted if the routing problem were overcome, all stock) work in conjunction with the convoy replacer model? If a player selected a convoy to replace and selected "all in line", what of the locomotives/other stock waiting in pools not assigned to a line? There is further the issue of the potential for exploits that was raised initially in this topic, and opinion seems to be divided on how real an issue that this is.

Although some of these issues, especially in the latter paragraph, might seem somewhat far away from a current Simutrans game, it is important to address them at this stage because features being implemented now need to be compatible with features that it is planned to implement in the future, and, at present, it is rather difficult to see how that will be achieved in this context.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Rollmaterial

For the replacement with legacy vehicles issue I have an idea: assign a depot to a schedule or line. When a convoy's schedule or line has an assigned depot, the replacement GUI would show all vehicles stored or available in that depot. It could also be able to calculate and display whether there are enough vehicles to replace all convoys of the line when using the "replace all in line" function.

jamespetts

That is an interesting idea to which I shall give some consideration. This will have to be considered in conjunction with the matters discussed in this thread, which are currently high on my list of priorities.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

zook2

Slightly off-topic, but would it be possible to name depots? I'm frequently cycling through a dozen train depots - sometimes looking for some obsolete cars or locos - and it always takes a moment to realize which one I'm looking at and where it is.

jamespetts

Quote from: zook2 on October 29, 2015, 10:08:15 PM
Slightly off-topic, but would it be possible to name depots? I'm frequently cycling through a dozen train depots - sometimes looking for some obsolete cars or locos - and it always takes a moment to realize which one I'm looking at and where it is.

This has been discussed for Standard and is possible in principle, but the issue, as always, is that there is only me working on this and that I have a very long list of other projects that currently take a higher priority than this (which would be somewhat fiddly to implement). The best chance of this being done any time soon is if it were to be implemented in Standard (and I might then extend it to signal boxes).
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

DrSuperGood

You model all depots as a pool from a high level however each retains what convoys are stored in it. Replacement and stock management is then done at a high level looking at the pool instead of individual depots. There is a time requirement and cost associated to moving convoy pieces from one depot to another and then to replace a running train.

The high level convoy pool is in charge of convoy resource management. It will move convoy pieces to appropriate depots where they are required. Fundamentally movement time is based on the depot to depot distance divided by some age dependent time factor (faster as time advances, stops at about 100 km/h which is what can be achieved loading train pieces onto a truck today) and some time constant representing preparation time (1-2 minutes, something small). A cost is associated with this movement which is nominal compared with ordering new (should always be cheaper to move existing around than to order a new one).

A special case can be added for when source depot is connected to destination depot. In this case the distance used is the path distance from source to destination and the speed used is the convoy maximum speed. There still is a constant time penalty representing preparation time and the speed could have a penalty representing that running at max speed is not always possible. The cost again should be nominal and orders of magnitude cheaper than ordering new (possibly even cheaper than not connected to encourage connecting). All air depots with a runway are considered connected and use this way. Like wise if ships are connected via ocean and can path over ocean then they are connected this way. This is useful for rapidly moving high speed convoys such as planes, high speed trains or cars which would move faster than the default relocation speed.

Replacing trains is done by first gathering the needed convoy components at depots along the line (cheapest to get to depots used when moving components, makes sure enough components arrive to fully replace a whole number of convoys). After enough components are gathered to replace a convoy then a convoy will be replaced automatically and instantly upon arriving at the closest stop on its schedule to that particular depot. Replacement occurs before loading occurs and the first loading (loading at stop it was replaced) always assumes worst loading delay representing passengers being transferred. Additionally there is a minor financial penalty for this replacement equivalent to the new convoy running 5 KM of distance and the old convoy running 5 KM of distance (fixed amount, not related to actual depot distance) representing some hidden movement of convoys around in order to be at the platform. After replacement the old convoy arrives at the depot the components were sourced from and can be further processed from there by the convoy pool management system (eg sold, moved to another depot).

This does not stop abuse however it certainly limits the benefits you can get from it. The movement delay means no teleporting (although maybe faster or slower than actual return). The movement cost means no free distance (although possibly still cheaper or maybe more expensive). Sure you might be able to make a little more money this way but the amount is so trivial you will probably make more by planning a better route.

This system would also open up future possibilities for convoy management. One could be ordering convoys from a manufacture (takes time, incurs minor movement cost) which means that new convoys have to be phased in over time at the rate they can be manufactured (possibly an entire new mechanic, maybe just some global settings based on economic state of the map). Another could be the ability to transfer convoy components between companies where instead of another player ordering a new one (expensive) they could get a second hand disused one from another company (costs current resale value plus delivery). With such systems you could order 20 new trains to replace existing stock and then sell off the old stock cheap to new players (better deal than buying new) or if you ordered too many then sell off the new stock to other players (who may also want to upgrade) at trivial loss.

jamespetts

We have, I think, two competing and interesting models suggested of how to do this, both of which are potentially workable in theory: either Rollermaterial's suggestion of each line being assigned a home depot (convoys already have a home depot, although this concept is only used in a limited way currently) and having replacement, overhauling and upgrading based on that system, or Dr. Supergood's more abstract model as described above.

Both have advantages and disadvantages, I think. Rollermaterial's suggestion ("the home depot model" hereinafter) has the advantage of being easy to understand in principle and realistic in practice. Dr. Supergood's suggestion ("the abstract model" hereinafter) has the advantage that co-ordination and management of complex networks might be more efficient for more experienced players.

The home depot model has the disadvantage that it might be tricky for players to co-ordinate vehicles between multiple depots, and it might be harder in a long-running multi-player game where players log on for a short while then leave their network running unattended for a much longer time for a player to co-ordinate stock movements. The abstract model has the disadvantage that it needs quite a lot of rather complex and not very transparent mechanisms (extra costs for moving things, vehicles being regarded as being in transit without actually being in transit, and having a time delay while travelling from one depot to another) for preventing abuse that might be difficult to calibrate and difficult to explain to players just by using the GUI.

I am currently leaning towards the home depot model at this stage because of the latterly mentioned problems with the abstract model, although I think that furhter consideration will be required. One thing that Dr. Supergood suggests that I had long been planning in any event was a secondhand market in vehicles, and, whilst this can be accommodated in the home depot model, it may be a little tricky for players to use in that context because it will be necessary to distinguish in some way between vehicles already in the convoys' home depots and vehicles available to be purchased from other players (and if this is to be done in a two stage process, it would then make it difficult for players to set and forget a replacement cycle as is highly desirable in the large multiplayer games for which Experimental is primarily intended).

Any additional thoughts on this important topic would be most welcome.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Aquin

The home depot is an easy to understand concept, for better identification depots should get a name like 'Town Type Depot Number', which would be 'London Train Depot 1' or 'Berlin Truck Depot 12'.
- When setting up a new line from a depot this depot is preselected as home depot.
- Home depot will have a place in the schedule, although in normal operation the convoi doesn't care about it. Only in case of replacing this comes into play. If the convoi has no goods loaded beyond home depot it will not take on any goods to beyond home depot and enters home depot as soon as scheduled, otherwise it will run a further round and enters restricted loading mode after passing home depot. 
- Home depot will be changeable, is a line has no home depot a warning should be posted, and convoi replacer disabled.

- There should be an option for "get vehicles from other depots". In the available vehicle list there could be two numbers like 1(5) This would mean 1 locally available and 5 globally. Getting the globally available vehicles to the depot should come at a price (running cost for closest link? more if using different mode of transport, even more if no connection exists), but if it is cheaper to buy new vehicles then vehicles are not moved.

- The 'on the fly' exchange could be an option at extra cost, like [running cost to+from station] + [5% of price of new vehicles] so you could avoid the trouble of having extra vehicles on a high density line.
- Home depot could be used for things like explicit maintenance.


DrSuperGood

Quote- Home depot could be used for things like explicit maintenance.
One cannot do that because of the economy simulation. There is no real day and night model which rules out time slots for trains to go to depots and be maintained. A single depot will not be enough for a line which takes several months to loop around.

jamespetts

Thank you both for your thoughts. One complexity about assigning home depots in the first place is that it is possible to create a line from the line management window, in which case there will be no obvious easily available candidate home depot, so some consideration will have to be given to what to do in that case if the home depot model be chosen.

As for explicit maintenance, this is something that I am considering implementing: indeed, it is of some importance economically, as different types of vehicles need different amounts of time being maintained (usually referred to as an availability percentage). What I had planned to do was to allow players considerable flexibility in when to maintain vehicles by not requiring maintenance to be at fixed intervals, but rather simply having an availability percentage and having a (very long: e.g. one year) maximum maintenance interval to prevent players never maintaining their vehicles at all. On the availability percentage point, the time that vehicles spend in a depot being maintained would be proportionate to the time that they have spent outside a depot since their last maintenance and the availability percentage. For example, if a convoy had an availability of 90% and had spent 10 game hours outside a depot since it was last maintained, it would have to be in the depot for 1 game hour being maintained before being able to be released again; but if it had spent only 5 hours out of the depot since last being maintained, it would need to be maintained for only 30 minutes.

Together with the planned greater flexibility of schedules (allowing convoy re-combination and the addition and subtraction of convoys for a line on the fly), this should allow sufficient flexibility for players easily to schedule regular maintenance notwithstanding the constancy of the demand. (In reality, of course, there are some situations, such as merry-go-round freight traffic or very long haul air or shipping traffic, where there is constant demand day and night, yet these vehicles also have to be maintained).
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

DrSuperGood

Quote
As for explicit maintenance, this is something that I am considering implementing: indeed, it is of some importance economically, as different types of vehicles need different amounts of time being maintained (usually referred to as an availability percentage). What I had planned to do was to allow players considerable flexibility in when to maintain vehicles by not requiring maintenance to be at fixed intervals, but rather simply having an availability percentage and having a (very long: e.g. one year) maximum maintenance interval to prevent players never maintaining their vehicles at all. On the availability percentage point, the time that vehicles spend in a depot being maintained would be proportionate to the time that they have spent outside a depot since their last maintenance and the availability percentage. For example, if a convoy had an availability of 90% and had spent 10 game hours outside a depot since it was last maintained, it would have to be in the depot for 1 game hour being maintained before being able to be released again; but if it had spent only 5 hours out of the depot since last being maintained, it would need to be maintained for only 30 minutes
As soon as you have any sort of "has to go to depot to be maintained" you will have a lot of usability problems. In real life trains are sent to depots generally out of service hours so there is no traffic on the lines. Simutrans does not have such down time so any sort of physically going to depot will disrupt line traffic massively. When they leave the depot the convoys will have to be re-spaced which causes all kinds of congestion problems. Especially when starting a large line you will also get huge waves of convoys wanting to be maintained.

Spenk009

Quote from: Aquin on October 30, 2015, 09:06:59 PM
- Home depot will have a place in the schedule, ...
Why would one place a depot somewhere/elsewhere in schedule? If this is to make replacement stops more convenient, convoys are empty on replacing (and goods not reloaded into the replaced vehicles) and therefore bound to where they unload fully. Especially with passenger lines you may not have a guarantee as to which point in the schedule is the point where the vehicle is empty and ready to be replaced. As of now, the system generally allows passengers to get to their destination without being told to disembark on a waypoint on some tracks in between stations.

1. Could a mechanic be created that allowed goods/pax to board a convoy under the "no load" command if there are others on board that are travelling to a destination before the convoy is empty?
2. Could one add a copy function from a specific convoy in the replacer? (Using the convoy id and applying the setup to the convoy in the replacer)

Quote from: Aquin on October 30, 2015, 09:06:59 PM
- There should be an option for "get vehicles from other depots". In the available vehicle list there could be two numbers like 1(5) This would mean 1 locally available and 5 globally. Getting the globally available vehicles to the depot should come at a price (running cost for closest link? more if using different mode of transport, even more if no connection exists), but if it is cheaper to buy new vehicles then vehicles are not moved.

This is pretty good, sending vehicles across the map is a hassle. Especially when moving slower vehicles on congested networks.




Have a look at Cities In Motion (2?), where lines are centered around depots. This is due to the core mechanic of the game being management of maintainance/stocks and set schedules according to day & night cycles. The concept of pooling is also handled there, where vehicles on lines are chosen according to what vehicles are available and what vehicle is wanted.

Aquin

Quote from: Spenk009 on October 31, 2015, 05:59:23 PM
Why would one place a depot somewhere/elsewhere in schedule? If this is to make replacement stops more convenient, convoys are empty on replacing (and goods not reloaded into the replaced vehicles) and therefore bound to where they unload fully. Especially with passenger lines you may not have a guarantee as to which point in the schedule is the point where the vehicle is empty and ready to be replaced. As of now, the system generally allows passengers to get to their destination without being told to disembark on a waypoint on some tracks in between stations.

1. Could a mechanic be created that allowed goods/pax to board a convoy under the "no load" command if there are others on board that are travelling to a destination before the convoy is empty?
That's what I suggested as well, and then it makes perfect sense to know where the depot is along the line, so you can load as much as possible before, and minimize the amount of way the convoi runs completely empty.
The other thing with an explicit point in the schedule convois will not try to take "shortcuts" that will mess up other lines, or end up in the wrong depot. Which would be bad if you just want to update the engine or replace some cars.

You should get more money if you sell your convoi from a depot, then if you just make it dissapear when empty with the "withdraw all" button.

On the options of what to replace I would like to have:
- this convoi only
- all of this type on this line
- all of this type on any line
- all on this line
For the last option it would be nice to be directly able to access the replacer from the line management, the other options could be greyed out if you don't have a convoi selected.

You should have more control over what happens with the withdrawn convois that are not reused right away.
- stay in the depot
- sell outdated
- sell all