Topic: Feature suggestions

[KneeOn]

Hello,


I have had three thoughts on possible future features. I will preface this with saying I am not a programmer and these are suggestions to prompt discussion/debate/ideas rather than anything else. There are three specific things I've had thoughts on. I can't find a specific feature request/idea thread where they are discussed so i'm posting here - sorry if this isn't the right place but its the best one I can find.


1. Depots


Currently depots that are the "home depot" for hundreds of carriages are a short 2 track spur and 1 tile building. Theoretically I could have one depot to service the entire fleet of trains for a 2048x2048 map. This is plainly unrealistic. On Standard, which has a much more 'gamey' ambition that is fine however Extended it seems like an outlier. I have an idea for better depots made of two smaller changes. One applies solely to multi-tile vehicles i.e. maglev, narrow gauge, tram and train. The other applies to all tiles. Both would tie in with planned maintenance visits


The first part involves creating a new way-object type for depot-stations. The practical implication is that a multi-tile vehicle cannot attend a depot for planned depot visits if that depot is shorter than the vehicles actual length. For example (using Carls pak64 train types) I have a 8 car class 377 which takes 6 tiles from memory. The train has completed its nth journey, is in town B and now requires a depot visit (or however this is calculated). The closest depot is Town B depot and it is a small 4 tile depot which is suitable for servicing the 313 trains which also run out of Town B however it cannot accept the 377 class trains because it is too small.


From here the feature kicks in. There are one of two implementations I have thought of. Firstly, an absolute rule that units cannot attend depots which aren't long enough and must travel to town A which does have an 8 tile depot long enough to service. This would be more challenging for route planning but perhaps less realistic for multiple units - the 8 car 377 is actually formed of 2 4 car units which can split and run independently.


The other, less challenging to a point but more realistic is to have a shunter/split either actually shown or simulated. For example the 377 8 cars cannot fit in to the 4 tile depot however two 4 cars can. The time in the depot is therefore doubled because a maximum of 1 unit wholly fits in. This could be shown either with the other unit waiting in the sidings or simply simulated. I prefer to have sidings be used, I think that better reflects cost and realism. Smaller changes and future planning could be used to make this implementation work better. If I had a 4 tile depot and wanted to run a train which takes 5 tiles, I could make the small extension and add another siding. As long as the unit fits in wholly we don't need to split it. 


The benefits of this would be:
1. The cost of running a depot would no longer be static based on a single tile and two tiles of track. The cost would be reflected across way maintenance and depot tile maintenance, which can be scaled. A depot which has to service the 377s in the above example would cost more because of the extra tiles or increased costs with the use of sidings and the amount of time a vehicle is out of revenue service. Short term hit on cost would reduce time out of revenue service - a clear cost/benefit but capital may be limited or even dependant on the route being up and running. A depot expansion may then be required down the line.


2 Planning a new route will require a more realistic thought process. Lets say you have made your first mainline route running out of Town A East station. The depot is just oustide Town A East along the route to Town B. To the south east of Town A is Town C with a new monument and there are towns along the way you want to link. The station could be expanded with a new junction to allow through running from the depot to this new line, it could have a diversion at a junction beyond Town A and out or a new depot for a new unit could be considered. The financials of the new junction cost vs the new depot vs diverting the route to miss out a town but use the same junction and depot would be an interesting balance to strike and consider. Similar to the above - short term capital vs long term gain.


3. Upgrades and cascading units to other lines may require more thought. If you have an old steam engine fleet and you're upgrading your line to use newer diesel units you can choose to sell the trains. You might sell to other players (when that feature is implemented). You might, instead, wish to cascade the unit to another route which is still running first generation steam units and need to be upgraded asap. One vital consideration would then be finding the right depot of the right size.  If you only have the one depot, a route must be considered between their new line and the old depot as it is the last of its type. You could make a new route which in turn could develop, over time, in to its own fully fledged line with its own units to increase capacity around a town, provide a diversion or new journey or be used as freight diversion to keep passenger rail clear. That would be far more realistic and natural growth, similar to how lines develop in reality with spurs turning in to junctions.


In short, depots must be long enough to accept a unit for maintenance, perhaps with a cost in time spent out of revenue service being the trade off for having depots which are too short to simulate splitting units made up of multiple units or having to use a shunter unit.


The second part is depot platform numbers.


This works with every vehicle type. Simply put, a depot type will be able to service X number of vehicles on each platform/tile across. For multi-tile vehicles this is the exact same mechanism as a station - 1 train per platform. If 4 trains need maintenance at the same time, there must be 4 free depot platforms else they must wait their turn. Short term capital cost could prevent unnecessary time spent out of revenue service. These may block the running line so depot sidings could be used to store units waiting for maintenance.


For planes, boats and road vehicle it could be slightly different. Planes might be 1 in 1 out per tile per hanger/depot because of their size but buses will perhaps be able to fit 3 trucks in at any one time, boats 1 or 2 perhaps.  That would be down to pak-set maintainers to strike that right balance according to their needs.


The benefit of the two ideas is that it promotes realism, longer term thinking, operational knowledge of your routes but doesn't' have to penalise more casual players who can take the financial hit of having an extra road or two and for their depots so they don't return to games with huge chains of trains waiting to go in to a depot and no money left. This could be a configurable option similar to way-weight-restrictions in simuconf for those who don't want this aspect of micromanagement.


2. Way and way-obj maintenance

This idea is similar to the above. Simple tiles which facilitate the track/road/wayobj/air port/dock teams which go around and make sure signals, lights, gates, signs and ways are properly maintained. The cost of way maintenance would be more realistic. A small depot of track maintainers may look after a specific line of route with a set radius from their hub. Larger hubs would be able to look after more track with the largest able to cover a pure geographical area rather than a single line of route. Forward planning by placing these with vehicle depot teams could provide a small bonus to speed for maintenance on those vehicles and extra radius/efficiency in maintaining tracks because of the shared equipment. This simulates 'strategic partnerships' in the UK between TOCS and Network Rail who work together to ensure service standards are met across their two areas of responsibility.


Again, perhaps there are two branches and a third is being planned. Do you remove the local hub depots looking after the two branches and instead build a large hub to cover that geographical area? There would be costs associated to setting that up but you'd potentially save by streamlining your maintenance and therefore the feature adds realism. I appreciate there may be arguments against this that we already simulate these teams discreetly in the pure cost of upkeep for ways already. I think this feature would better reflect decision making made by companies when making new routes and making their business as efficient as possible. Consider these the signal boxes of the way-maintenance.


3. Station Capacity and radius


Currently station radius is set at X and that's that. That isn't realistic and there may be a way to approach this. Bus stops are often much more local than international train stations. My local station growing up was a tiny halt, where as the cities main station has long distance services and a much bigger catchment.


The idea is this, station_radius becomes a maximum, so no station can be more than x tiles. Each station has a rounded base figure of x/y to give its platform only station radius. For example if my maximum radius is 8 tiles, and my station has a divisor of 8 giving a base radius of 1 tile per platform, there are two platforms it means its actual radius is 2 tiles. I build a new junction at this station to serve a branch line and this station is now more important so I build a ticket office, which adds a radius of 2.


Fast services now need to call there because the station is growing, so I add another 2 tiles and it has become a radius of 4. A further large concourse is built which would add a radius factor of 3, so now I have 7 tiles. Lastly, I need 2 new terminating platforms for two new branches I'm building because this is now a major station. That would be a radius of 9 (2 for the first platforms, 2 for the old ticket office, 3 for the new large concourse and now 2 for new terminating platforms). However the maximum is 8 tiles so no additions will expand the radius. However each platform/extension has a capacity increase also so if I needed to i'd still have to expand my station. Change the various passenger based things for freight related additions - a good example being perhaps a crane, liquid storage and storage yard adding radius because instead of each factory in a town having its own stops we now have the cargo terminal which is able to serve the entire industrial area.


Each waytype could have its own radius maximum perhaps- airports clearly would require some sort of transport to get to rather than having a large radius that would cover regions and their reach is naturally expanded by the players feeding routes.


As i've said, i'm not a programmer - they're not requests or anything other than things for others to consider. I've considered the high level extended principles and tried to make these ideas work within that while still addressing the problems so I hope they help rather than hinder the ongoing development of Extended!

[Vladki]

Hello,

1. Forcing depots to occupy more tiles will surely add on realism. But the tracks already occupy quite a lot of space. Each track is 1 tile wide (125 m). Even if considering the building scale, it would be 20-30 m (depends on pakset), that is still enough space for 4-6 tracks. So I take the fact that depots have a special universe (like discworld's unseen university library), as a compensation for the excessive width of tracks.

There was a discussion regarding splitting and recombining trains, where it was noted that it would be necessary to distinguish "permanent" coupling of units that cannot be uncoupled in normal operation. If that is implemented it would apply to depot visits in the same way. Either being somehow automatic, or forcing players to make exact schedule, where to split, and wait for the depot to be free, etc. Considering a locomotive hauled train that is too long to be serviced at once, and forcing it to shunt with cars, I would rather spend the money and have depots of the same length as platforms. That would be too much micromanagement for me. This game is about transport simulation, not about shunting trains on the station.

Going for more realism:
- there would have to be some ultra cheap or even free type of platform (or parking lot) for storing surplus rolling stock, and the possibility to make one stop schedule to send the vehicles there.
- road transport - first I'd like to see two buses/trucks to be able to load side by side on dead end loading bay. Then of course depot could behave similarly to be consistent.
- air transport - if considering the 125m scale, even the Jumbo Jet or Ruslan will fit.
- water transport - we have the same problem with ports - any number of ships of any size can load on 1-tile port. Having realistic ports is imho higher priority that realistic shipyard, but probably extremely complicated to implement

2. I just don't see any added game value from these "maintenance centers". I usually do not even build company headquarters But hey this could be a way to make some use of them - first build headquarters, and that will allow you to build ways and stations in some radius. Upgrading will increase the radius, or there could be an option to build secondary headquarters. It could be nice addition and easy to implement. But otherwise the costs of maintenance of should be included in the objects themselves. Headquarters should be to simulate the overhead of running big company.

3. I think the current station coverage mode works well. In real world there is nothing that prevents you from walking 1 km (8 tiles) to a tram stop. (Which in your example would have only 2 tiles radius). It is the total journey time that makes the decision if people will walk to a distant stop or not. Just as in real life: I have a bus stop 200 m from home, with 20 minutes interval. Then a tram stop 1 km from home with 5 minutes interval. So if I do not catch a bus, I walk to tram. Consider a train stop in countryside - in practice it has coverage of several km, because local transport would be uneconomical, so all passengers have to walk there. Also the willingness of people to walk has changed during time. I think that the current coverage of 16 tiles (2 km) is there just to reduce computation intensity, by not considering journeys that would be too long anyway.

[KneeOn]

Hey! I'm glad there's so many discussion points, there might be nothing from this but it's always good to consider new ideas and see where improvements can be made or where things work really well and actually don't need further development!


Going in turn:


I did not consider the scale and width of depots. Perhaps depot stations not having unlimited universe space, but being more than 1:1, but more like 1:5, letting a depot which would take up many tiles still have to be long enough but not wide enough would solve that problem. I think that strikes the balance between having realistic looking depots and mathematically realistic sized depots.


The shunt would have to be automated. I'm no programmer but I envisage it working something like

Code: [Select]

"train sent to depot -> does depot fit? -> if yes then train enters depot -> if no, is there a free shunter? -> if no then wait for shunter -> if yes powered unit enters depot with as many cars that fit -> shunter attaches to remaining units -> is there space in the depot -> if no shunter consist waits -> if yes shunter enters depot -> servicing happens -> shunter leaves to sidings in reverse -> shunter splits from cars, goes back to depot to sleep -> power unit and cars leave in reverse to siding -> reattaches to remainder cars -> resume"

That would be a way to graphically represent a split/join.


Alternatively

Code: [Select]

is train able to fit in depot? -> if yes service if no-> service time is multiplied by the number of splits required to fit in to depot -> train leaves depot

That would address the issues with servicing and capacity graphically vs mathematically and eliminate any micromanagement - it would let you do your longer depots and have a reason economically to do so without penalising those who play in a more casual manner.


I agree, sidings are cheap. Sidings would be useful to reduce station sizes anyway as a place to wait for their slot perhaps, which is realistic and would hopefully stop stations being 8 tiles wide, rather only needing to be 6/4 tiles wide with sidings running along the tracks just outside the station. They are cheap with a nominal cost because sidings are only metal steps to train doors, walk ways and the tracks which already have an associated cost.


Considering the other transport - agreed on road transport priorities.
Air transport - one in one out would be acceptable in my mind, with one tile per jumbo jet for maintenance being both mathematically right and graphically appropriate.
Water transport - I don't know how you'd address that. I'd guess adding length paramater would mean as many spare slots next to each other, equal to the length required - that could be applied to shipyards?


Maintenance centres - I really, really like that idea of yours. You define your 'patch' by the number of regional offices/head offices as a special building type. As time goes on, bigger offices with bigger a radius become available which consolidates having to have a lot of offices, reducing costs to reflect the reduction in required labour. Within your radius that office/offices govern maintenance. You may have loads of track km in the radius, so a second office may be required to meet staffing requirements and keep tracks going. This would be an extra layer of micromanagement to make sure you have enough staff in the area but you wouldn't be dispatching them - only considering if you need to build more logistical support?


Stations - my example uses easy to round numbers, the actual numbers and scale would depend entirely on the pakset scale. My consideration is what benefit is there in having a suburban or metro network if your central station and only one or two outer stations can cover the entire city when in reality that would require a bus or tram network?


That said, i'm not well versed on the route finding algorithm and if walking all 16 tiles is possible but is not realistic and therefore discounted by the game as a viable route then perhaps the problem isn't there to be fixed at all, as there is purpose to urban networks to make sure those who want to travel but would have to walk 128 tiles be able to make their journeys.


If mutli-modal travel is used however perhaps that will need re-addressing - for example if you've got one main station which you can drive to in an acceptable time even though realistically you'd take a local trip first how would the game simulate the realistic journey? I live a 20 minute walk/5 minute drive from my local station, or a 15 minute drive and hours (maybe more?) walk from the central station where there are more destinations. The train journey takes 8 minutes so if I walk that's 28 minutes to get to central station.


If i were going out and my journey involved going via the central station, i'd be taking a train to central - probably by walking or cycling - rather than driving in to central and paying for parking etc. Unfortunately I don't have answers to that question! I can only point to London where if you lived in south London and wanted to go north you'd absolutely take public transport even if it took a bit longer because parking at each of the Termini is so strictly limited. Could having parking as part of station desirability for private/public transport mixed journeys solve that issue and therefore remove the need for this entire discussion? Scale would be a problem there, perhaps with car-parks having more spaces than their square meterage would actually represent.


Thank you for your points, specifically you've opened my eyes to how we all play differently. I go exclusively for what looks right rather than what the simulation will do right, and like the challenge of making a perfectly represented network. Others want scale and accuracy and I did not consider that when thinking of these ideas!

[Freahk]

1. About Depots, if we really want them to be more realistic we should consider graphics scale, not economical scale but the shunting should be implied.
That means, we can safely assume that a single tile has space for 4-6 tracks in parallel, each 30m in length. A single tile depot can hold 120-180m of trains, no matter if they are assembled or not.
If a train is too long for a depot, we might add a time penalty for each split we have to do.
If someone was bored, we could also simmulate it by moving the train part by part into the dpot, but that's purely an eye-candy thing and should not require any player action!

Once we differ in between types of coupling, we might re-think the time penalty and differ in betwen (faster) automatic coupling like scharfenberg couples, slower coupling like screw couplers, even slower couplings like semi-fixed coupled multiple units and very slow (or even imposible) uncoupling like trains using jakobs bogies.
Anyways, the latter would be quite consequent with said splitting and recombination feature but definitely low on priority list just to get enetring depots simmulated more realistically...

- there would have to be some ultra cheap or even free type of platform (or parking lot) for storing surplus rolling stock, and the possibility to make one stop schedule to send the vehicles there.

I also kind of like that idea but there is the 30m-wide-track-isssue again. Imho "compressing" trains in depots according to graphics scale should be preferred, although the latter would look better.

Having realistic ports is imho higher priority that realistic shipyard, but probably extremely complicated to implement

Might be more complicated for river/canal ports but for the real docks it should not be too complicated to let ships occupy a tile and add an implicit choose signal to such harbors, just as it's done for airplane Aprons.

2. About maintainance
I'll keep it short: Too much micro management for a feature that imho does not add-up a lot.

However, I kind of like Vladkis idea. Especially in multiplayer, that would add-up a lot to gameplay and realism imho.
Especially in early years, companies started in a rather small area and from there expand across the world.
Co-operating with other companies in other areas will become mandatory if the cost of such headquarters is properly balanced.
It does not have the disadvantage of fixed terretorial gameplay where the owner of a terretory will decide what is allowed there and what's not.

3. About Stations
I don't think a train station per-se has a larger catchment area than a bus stop. It's moreover the service of that station and surrounding stations that decide the actual ctachment area and that works quite well currently.

For a few years, I lived in a large town with an even larger countryside within city borders.
I lived on a former farm in that countryside. The two closest (city) bus stop being 3km far away, the next rail stop being 5km far away.
I didn't have a car, so I went to one of them by bike or on foot. We simmulate inhabitants that don't have a car in simutrans either, so the current bus stop catchment area would be even too small! But it's fine for computational reasons. Such stops won't attract many people anyway.
Further note that the willingness to travel long distances to the next stop drastically changed with time.
In the early years of industrialisation, a footwalk to work of 10km was quite common for a lot of people.

Another example is taken from the town where I currently live.
I have four bus stops in a range of 200m-550m
Usually, I walk to the 500m far-away bus stop because it has the best service. Some other people, especially elderly ones prefer the closer stops.

Around the main station, I frequently see passengers enetring the bus for only one stop, because it's faster than walking 750m (it's an express line)

I never walked to the main station, although it's just 4km far-away from my home, thus less than the bu stop I was walking to on the countryside.

That said, some railway stations might have quite huge "catchment areas", wherease others might not directly attract people far-away, because there are faster alternatives.
On the other hand, bu stops can also have a quite huge catchment area.
The current journey time based approach handles this behavior quite well!

if we want to increase realism in pasenger routes, there are some things we could do but reducing catchment areas of bus stops is definitely not one of them.

[KneeOn]

Shunting being implied is now something I think strikes a balance between the meters per tile issue stopping huge depots which dominate the map, and having some sort of realism to the depots. Time penalty I think also works better than the original idea I had - eye candy bits would be nice to see however. I agree, this is all dependant on automation of splitting and having a shunter unit that does this autonomously from player action. I don't want this to become Simsig!


Coupling types isn't something I even considered and would be an extra layer of realism to the time penalty but would servicing be train-dependant rather than pakset dependant? So that feature could easily be built in to a datfile as couplingtime=x and servicetime=y and if you have to de-couple the train to service, you'd have total depottime = servicetime*numberofsplits + couplingtime*(numberofsplits*2) - the *2 is to allow for recoupling and as you've said, the splitting and re-coupling feature would have to come first for that to be implemented.


So the total equation would be:
depotlength/trainlength=x - note that might need to be the other way around, but this would be the figure that determines how many times the
if x>1, then
depottime=servicetime*numberofsplits + couplingtime*(numberofsplits*2)


What do you think about putting a limit on magic universe space (as Vladki nicely put it) so that you'd only need 2 depot platforms to service the trains - but there must be a spare slot for that to happen?


I still genuinely believe sidings have a place in simutrans. In order to run an effective timetable there must (IMHO) be stabling space or platforms far in excess of what is reasonable in terms of size if you're running a regular service from a terminus station. By having real sized sidings as a station/depot tile (either works to be honest, depot type would be useful if you were graphically simulating the entry/exit to a depot and needed a place to turn/shunt/display this to keep running lines clear).


The issue goes to the core of simutrans scale, simply that things are not square and we have to work in squares and can't have multiple vehicles in the same square generally. Solutions such as the one Vladki has prompted - multiple trains in depot stations with some sort of limit to help with realism and planning - covers this.


Maintenance is to add a feature which gives a further layer of decision making and realism but I absolutely endorse Vladki's suggestion because it solves the issue of why we would place a HQ aside for playing in the spirit of the game.


I'd suggest that we don't let HQ's become something that can allow a monopoly, like you said - perhaps rather than deny rights to others you can only build if the area you're building is covered by an office you own and multiple players can be given rights to build in that radius so long as each has an office or, to go closely with revenue sharing which is planned, an agreement is in place. This could be an office by office basis where on multiplayer games you can click the office and toggle if each player can build in that area using your office infrastructure rather than have to build their own.


That would further foster cooperation and competition - perhaps as a company becomes too big and is running lucrative routes you decide to revoke their usage forcing them to build a HQ but if their service is so critical and making so much money they will move to build their own?


Stations: it appears I don't understand route finding well enough to have commented! I thought people would walk to the stop with the most direct service and therefore metro/bus/suburban services wouldn't be used appropriately. I appear to be wrong and actually the routefinding, based on what you've said, satisfies this fine.

[Freahk]

What do you think about putting a limit on magic universe space (as Vladki nicely put it) so that you'd only need 2 depot platforms to service the trains - but there must be a spare slot for that to happen?

As mentioned, a train should occupy space in a depot. A depot of two tiles length has a capacity of 120m-180m of trains. That's for examply 4-6 60m short trains.
A single Eurostar E300 in its real-world setup (394m) would at least require a 4-3 tile long depot.

The tiled nature of simutrans in combination with the current graphics scale is indeed an issue, especially in built-up areas but I don't think we can easily change this in a graphically consistent way.
The only way I see to (properly) achieve this is by generally allowing multiple lanes of the same waytype on the same ground but that would be a very major overhaul of the whole way and vehicle logic and even beyond. we don't even have tools to put stuff on parts of a ground. We cannot even click on a specific object on a ground.

I'd suggest that we don't let HQ's become something that can allow a monopoly, like you said

I didn't say that.
If an HQ has a coverage in which you can build, you are encouraged to co-operate with other companies that have already covered an area, because expanding the own coverage to that area might be quite expensive.
If he is not willing to build or share infrastructure you need, you can still expand, but it will be more expensive than co-operating.
If that cost is balanced properly, likely with non-linear coverage scaling, where the scaling factor decreases with time, this might add up quite interessting considerations to the gameplay.

[Vladki]

Road & Rail Depots: we do not have any splitting/recombination yet. What could be easy to implement and also easy to understand for players would be this:
1. modify depots so that they can be more like station - several tiles long, and several tracks wide. This would be IMHO the most complicated part. Multi-tile depot would behave as one (like station).
2. length of depot defines how long trains can be assembled there - in the same way as how long platform you need for given train.
3. width of depot defines how many trains you can assemble. Station tracks should be 5m apart. This tram depot is 60 m wide and has 15 tracks (4m per track): https://mapy.cz/s/kotonalupo  So I would be in favor of 7 tracks per tile.
4. total length of vehicles stored (assembled or not) must not exceed the length x width of depot.
5. Any shunting, splitting, etc is hidden within the depot by assembling and disassembling the convoy. Train must be fully assembled in depot. The only shunting in stations is reversal of trains.
6. Depot space checking should be optional.

Air depots: there is no length specified for airplanes, so default (half tile) is assumed. If the above rules would apply, it would be 2x7=14 planes in one hangar. We do not have any way to distinguish small cessna from jubo jet.
Ship depots: length is known, but even the biggest ships have length <= 16 (1 tile). This is not realistic, but we have at least something. Width can be assumed according to canal constraints, but that is pakset specific.
Therefore for air and ship depots, I would recommend a configurable option how many vehicles can fit on one tile, with a possible dat option for vehicles telling how many "slots = m^2" it occupies. The task to play tetris to actually fit them in place would be done by the depot staff and hidden to player.

On second thought, players usually do not store too much idle vehicles (because of monthly costs, which should imho be reduced for vehicles in depot). So a 1 tile for everything except trains, and one track depot of appropriate length for trains would be enough. So there is no direct need to implement multi track depots.

Headquartes/maintenance: I would try to keep it simple. No exclusivity or sharing with players. But more similar to signalboxes - maximum range how far you can build, and perhaps maximum length of roads/tracks, or maximum number of stops (stop tiles), that can be maintained from those headquarters. Maybe even maximum number of vehicles/convoys/lines... If you want more, upgrade HQ, or build a branch office.

Stop coverage. I agree with freahk

if we want to increase realism in pasenger routes, there are some things we could do but reducing catchment areas of bus stops is definitely not one of them.

I did not verify how the path finding works, but in theory, it should do it quite realistically. We do not have multi modal transport (no P+R) yet. So the options are:
- whole journey in private car (including horse cart)
- whole journey on foot. There are some plans to allow really long distance walks. I'm not sure how exactly it works now, if the walk has to be within catchment area of one stop or how...
- walk + public transport + walk. The journey is limited by total journey time. So if walking to main station is faster, than using local transport, people will walk, even if there is some stop on their way. Current station coverage allows for 30-40 minute walks.

In first post you wrote about not allowing people to walk to airport. That's not real. Older airport were closer to city centers, and easily reachable on foot. The barrier are the motorways leading to airports, not the airports themselvs. So it should be more a property of road, if walking over it is allowed or not. Currently people can even swim to get to their station

[KneeOn]

I didn't say that.
If an HQ has a coverage in which you can build, you are encouraged to co-operate with other companies that have already covered an area, because expanding the own coverage to that area might be quite expensive.
If he is not willing to build or share infrastructure you need, you can still expand, but it will be more expensive than co-operating.
If that cost is balanced properly, likely with non-linear coverage scaling, where the scaling factor decreases with time, this might add up quite interessting considerations to the gameplay.

I've taken that to mean no one player can have an absolute monopoly on any part of a map - even thought it may be expensive I could build my own HQ/regional office in the same town as you and obtain the right to build there even if you have too. To check: building your own HQ's or offices in an area, regardless of who else has built a HQ/office covering that area, would allow you to build on that part of the map - but you cannot exclude competition from anywhere you are running a service however it would make sense for sharing to be cheaper for you if you can get an agreement with another player than having to set up the office infrastructure in that part of the world.

Sorry, I see what you mean. I meant I agree with you that HQ's should not allow monopolies rather than you suggested monopolies - I wasn't very clear! (second edit, I don't seem able to say I agree with what you've said without writing out the opposite!)

Vladki, I agree with the six implementation parameters you've listed. I think that meets the balance between my all singing, all dancing idea that, ultimately, adds not a lot in its suggested form and removing the issue of depots that are not realistic. Thank you for your input on these ideas - there has been a lot which I didn't consider!


Air depots I also agree with - i'm not an expert on air travel and as i'm sure you can tell I tend to play Simutrans with a rail/tram and partial bus focus!


Ship depots likewise, I don't tend to use them much. In fact I don't tend to do freight, certainly historically. It is only recently I've come back to playing it and developing my own pakset, prompting these thoughts.


It sounds like we are all agreed with the way HQ's work - sharing etc should be handled by the future revenue sharing and current things but not by adding another layer of confusion and complexity when there are other plans afoot which handle that well. At least there is room for a HQ function now!


Stop coverage - the idea clearly is rooted in flawed logic and understanding of pathfinding. If really long walks are allowed, I don't know how that would make the 16 tile catchment area make the game to oplay - there is at least a suggestion if it comes a problem, which is better future planning than most UK railway companies!


I used to live near a major international airport and could indeed walk to it if I really wanted! Most people don't however


My only disagreement is the need for multi-tile depots/train idling. If you look at the largest depots, they tend to have roads which, using a scale of 7 roads per tile, would require 2-5 tiles width. I think there is a usage for multi-tile depots (even if it's only 2 tiles wide) when it comes to major fleet upgrades, larger TMDs which service many lines of route (Sulhurst, Wimbledon, Clapham all come to mind) but if the tile behaviour comes from stations, it won't really matter because flexibility to simulate a graphically accurate if not entirely balanced network is still there, while those who play games with less 'freeplay' and more accuracy economically won't have to make that extra expenditure.


I do think idling trains may result in smaller stations. If we go back to the inherent (but I think ultimately acceptable) issues of scale in Simutrans, a single tile per platform is well over what is required. Multi-vehicle behaviour is probably not going to happen, which isn't a bad thing to my mind. But if you don't want a station that is 2km long, then using sidings along the main approach for trains to wait before their next slot on high-intensity urban areas may still be useful. Similarly freight yards include many roads which are used solely for stabling trains before their next dispatch is required. This is already implemented by using stations which are not compatible with the vehicle type (freight trains in empty passenger platforms, or vice versa), or by using stations with no good type such as the japanese pak64 depot pack - their discussion now is redundant. The ideas presented by the pair of you mean that they won't be required in another form because all shunting is hidden.

[Vladki]

Sidings - in pak128.britain we have platforms with 0 capacity. Not for free, but cheap. So it is a possibility. I don't know if it is worth trying to do anything extra - distinguishing true stations from these sidings. Anyway, my playing approach is to schedule so that the waiting times are minimal, and thus trains do not occupy the station very long anyway. I have never felt an urge to make such "lunchbreak" siding to get a train out of the way, and let it idle. The best way is to send it on return journey ASAP.

[Freahk]

Edit: I just posted this two posts behind.

3. width of depot defines how many trains you can assemble. Station tracks should be 5m apart. This tram depot is 60 m wide and has 15 tracks (4m per track): https://mapy.cz/s/kotonalupo  So I would be in favor of 7 tracks per tile.

I don't think we should discuss the exact number of parallel tracks that a depot can have in 30m here.
That greatly depends on many factors and is something the pakset should care about, either using a simuconf value or a dat parameter.

Air depots: there is no length specified for airplanes, so default (half tile) is assumed. If the above rules would apply, it would be 2x7=14 planes in one hangar. We do not have any way to distinguish small cessna from jubo jet.

Well introducing a dat parameter for their size (representing width*length) should not be an issue. Same goes for ships.

On second thought, players usually do not store too much idle vehicles (because of monthly costs, which should imho be reduced for vehicles in depot). So a 1 tile for everything except trains, and one track depot of appropriate length for trains would be enough. So there is no direct need to implement multi track depots.

As you said, maintainance in depots should definitely be reduced a lot.
If I recognise correct, vehicles will lose wealth over time anyway. If you don't use these vehicles, they effectively cost you something as their worth decreases.

In the first place, I see the depot space feature with maintainance/overhauls in mind. In that case it might make a difference how many trains a depot can handle and you will likely want to store additional trains in the depot as a replacement for trains in maintainance.
With splitting and recombining in mind, we might even consider dmanding fixed-coupled sections of a train to fit on a single platform, which will require us to build quite long depots to assemble quite long trains.
Maintaining trains that don't fit on a single platform will take longer as they need to be shunted in and out.

In first post you wrote about not allowing people to walk to airport.

Skipped that when I read it first. That would indeed be an unrealistic, artificial restriction. Düsseldorf Airport, for example is quite close to the city. I don't see why people from Unterrath or Lichtenbroich districts should not walk ~2km to the airport, apart from the fact that using the bus will be faster. There even is a footpath.
So if there was no public transport service from these districts to the airport, some people would simply walk to th airport, instead of not traveling at all.

So if walking to main station is faster, than using local transport, people will walk, even if there is some stop on their way

That's correct and many people will behave like this. However, that's one of the possible improvements I was talking about. Some people, especially elder ones might prefer the bus even if doing so will take a little longer, simply because they cannot walk quite well anymore.
So something like a randomised per-passenger maximum walking distance might be applied when searching for start and destination stops.

[KneeOn]

Yeah, there are certainly capacity zero stations in pak64 as addons which work. I think there are different approaches, I personally don't like stations which are 16 tiles long but often my service levels are quite large at some stations - I like having an intense service at regular intervals and find setting aside some space for turn around times works better in maintaining that although I appreciate I could off-set my interval times and choose not to.


Given the way we have discussed depots and the fantastic ideas of better implementing them having distinct sidings as a type would be redundant since the splitting/coupling etc would be hidden from player view within the depot.


I had just seen your 4th point in more detail, I hadn't considered making all trains stored no greater than the area of available track - just the length.


I don't know how many people do 10 station tile long freight services but I suppose if you want to do that, the associated costs in running trains that long would be reflected in the length of your depots.


I'd be interstested in Jamespetts and Keirongreens view on this discussion about what is possible.


Freahk - you raise a good point about depots. Scales change even by game - Carl has done two different scales for different maps using largely the same pakset and I sometimes want to simulate the finer details of the city (which is why i'm doing the project with pak64.uk - for the scale that pak.64, pixel drawn buildings let a single developer create) and other times I want to do really long distance maps or even a mix of the two in a region. My scale needs to reflect that and changes depending on what i'm doing. By having a depot specific limit I can use what depot would suit that map.

[Vladki]

So something like a randomised per-passenger maximum walking distance might be applied when searching for start and destination stops.

Either that or randomised walking speed, which will in turn affect the overall travel time.

[jamespetts]

Thank you for your thoughts.

I should note that adding features to Simutrans-Extended is usually an extremely time consuming task, partly because of the inherent complexity of the simulation and partly because of the quite old-fashioned coding style (the codebase dates from the 1990s), which makes it inherently less maintainable than more modern codebases; thus, changing something like depot size would involve not just adding basic game logic, but disentangling scores of undocumented assumptions about how depots work scattered across a huge amount of code from graphics to vehicle movement in an unpredictable way, working out exactly what they do and how they do it now, and then finding a way of making that work with new systems without, in turn, breaking the complex, subtle and undocumented relationship between those parts of the code and all the other parts of the code with which they, in turn, interact. (To give an example of this: attempts to increase the maximum number of players have failed because of an extremely complex and impeneterable relationship between the precise current maximum number of players, player colours, special colours and a hard-coded set of colours).

Because coding resources are very limited and making significant changes are extremely intensive in those resources, significant feature changes that are not critical to game balance in the short or medium term, especially those, such as relating to the size of depots, which interact with a particularly large number of existing basic systems in the game and would be hard to change, are not likely to be implemented for many, many years unless somebody other than me who is able to modify the code, test the modifications thoroughly and make it work well is able and willing to treat this as a higher priority than all other possible things on which that person could work, even if in principle and all other things being equal such a feature might be desirable.

In principle, it would be sensible to have depots have to take as much space as stations: it really makes little sense that the two have different rules for how much space that each should have to take. However, this is a feature likely to be vastly time-consuming and is unlikely to be a priority for my own work for the foreseeable future.

As to placing track maintenance facilities, I do not think that this suggested feature would work well with the paradigm of Simutrans-Extended, as it is likely to require the player to do too much work of the sort that does not involve any meaningful or interesting strategic decisions. There will almost always be a dominant strategy of how to place such maintenance depots, so the only effect of requiring it would be to force players to go through a specific sequence of actions. This is unlikely to enhance the gameplay experience.

As to coverage radii, there is already a feature intended to make these less binary than at first they appear: walking time. Passengers take into account the walking time to all of the stations within range of their origin and destination when deciding which route to take, and take the fastest route, where fastest includes the walking time. This therefore simulates the real effect of distance from transport stops without introducing arbitrary distinctions. Indeed, the only reason to have a catchment radius at all is so as not to take excessive computational resources: ideally, every station and stop would be theoretically reachable from anywhere on foot (unless an impenetrable barrier, such as the sea, were in between), and total travel time would be the only determiner.

[KneeOn]

Hi James,


I've followed Extendeds development for a few years and I know it's a very complicated beast. I know you have plans that would take years to add in and that's excluding the bug fixes, network desyncs and the higher priority features. I saw the recent work to implement up to 121.0 standard features and how adding those patches proved at times difficult. There is certainly no expectation that you'd be dropping everything to add this.


During this conversation on my own suggestions there have been things which I hadn't considered and it was nice to see and hear other peoples thoughts about gameplay in general and the differences we have.


A better feature suggestion was made to include 'offices'. The HQ currently does nothing apart from cost money and by having a new class of building which lets you build in a certain area acting as a regional office may give strategic decisions such as cost/benefit of expanding your network in to a new area while accurately simulating the decisions a real company would make.


That wouldn't be to everyones taste, and that's before you mentioned having a 'dominant strategy'. I also forgot just how wildly, wildly different strategies can be while all working. I play a few simulator games, Cities Skylines and Football Manager in particular. FM is a good example of 'dominant strategy' where my scouting/training decisions are based on what generally works. High potential, young and cheap players are obviously the better ones to sign compared to signing older, declining and expensive players as a general strategy. To that mind, even the office feature is unlikely to be able to avoid having a clear 'best practice/dominant strategy' and might not suit Simutrans as a whole but there are better people than I to consider that, not least of all you and the others involved in actually developing a game rather than me, who only plays and creates pakfiles.


I wasn't aware how good the route finding algorithm was at making sure in dense urban environments sims will use the bus/tram/subway network just as much as the faster mainline services.

[jamespetts]

I do want to do something functional with the headquarters at some point, as it is silly to have it as something that one can buy that has no purpose. Ideally, it would simulate the overhead costs of running transport companies, but the complexity is how to incentivise players to build a headquarters and also the correct level of headquarters. One possibility is requiring headquarters to build more than a certain number of depots (perhaps 1 depot without headquarters, a higher number for a level 1 headquarters and so on), but it would be important to calibrate this carefully, and it is difficult to know whether this would be possible. This will have to be considered after full balancing, I think.

[Vladki]

And how about as suggested before - headqurters would have a range (similar to singalbox) - and you could not build anything (except branch headquarters) outside of this range. That should be easy to understand, and perhaps not complicated to implement.

[Freahk]

I agree with Vladki.
I'd especially prefer this over the Depot solution, because that would simply lead to ppl trying to build a s few depots as possible and likely city transport would suffer as there are usually much more road depots built than railway depots or  shipyards.
E.g. on stephenson-siemens, I maintain roughly 4 "mainline" railway depots. With that headquarter regulations, I'd only maintain one or two.
Ahead of that, I maintain an uncountable number of road depots, tram depots and a few tube depots, usually one per town, apart from a few towns that are very close to another.
I'd simply destruct most of these and rebuild them when I need them... every 50 years or something like that.


With the coverage suggestion, we will need to consider how to allow companies to potentially cover the whole map, and how to handle different map sizes.

[Vladki]

With the coverage suggestion, we will need to consider how to allow companies to potentially cover the whole map, and how to handle different map sizes.

Highest level HQ could have infinite range, or just allow more headquarters per company - so you can build smaller branch headquarters - that would be especially needed on bridgewater brunel for overseas transport.

[Freahk]

Infinite range does not sound like a good idea with different map sizes in mind. On some maps the second largest level might already cover huge parts of the map, whilst on other maps it might be only a very small part, thus proper cost balancing would be not generally be possible.

Multiple headquarters was what I thought about either.
Headquarter ranges might need to be configurable, as it's a huge difference if you cover e.g. a radius of 10km of a very densely settled map or 10km of a sparsely settled map i.e. on some maps headquarters might become unaffordable, whilst on others the cost would be negligible.

[Vladki]

Then further limits (again similar to signalboxes' limit on number of controlled signals) can be applied:
- number of vehicles / convoys (that could be a function of depot - how many vehicles it can service, although we do not simulate that in detail)
- number of buildings / stations
- total length of ways

[jamespetts]

The geographical range idea is interesting, but may I ask what real world thing that it is simulating such that the headquarters costs can be balanced with reference to real world figures for transport company overhead costs?

[Vladki]

To see the overhead structure of Czech Railways:

http://www.ceskedrahy.cz/en/skupina-cd/organizacni-slozky/generalni-reditelstvi/-13009/
http://www.ceskedrahy.cz/en/skupina-cd/organizacni-slozky/organizacni-jednotky/-13011/

And the HQ building itself:
https://zeleznicar.cd.cz/assets/zeleznicar/hlavni-zpravy/struktura712.jpg
https://zdopravy.cz/wp-content/uploads/2019/04/mdcr-990x461.jpg
(That building is the ministry of transport, so the railway HQ use only part of it)

Unfortunately I don't know how much all the people in that building are paid...

[Freahk]

https://upload.wikimedia.org/wikipedia/commons/9/94/16199_dbtower_duhanic.jpg
"Bahntower" in Berlin, the Headquarter of Deutsche Bahn concern.
That headquarter does cost the Deutsche Bahn 500 millions per year and is only one of many administrative centrals of the concern, although it's the "main" HQ.

[jamespetts]

Thank you - what I was really after was some information on what real world dynamic would be simulated by an actual limit on the geographical distance from the headquarters that one can build; if this is not simulating something real, but is intended as a proxy for something else, then it would be better to simulate the something else more directly so as not to produce anomalies.

[Freahk]

Well usually such huge concerns have a main headquarter and are sibdivided in many more Subsidiaries, where many of them got their own, more local headquarter.
Deutsche Bahn is subdivided in very many Subsidiary including, but not limited to infrastructure, long distance travel, Regional subsidaries in each State of Germany, and many more within and outside of Germany, like DB cargo and arriva.

[jamespetts]

Well usually such huge concerns have a main headquarter and are sibdivided in many more Subsidiaries, where many of them got their own, more local headquarter.
Deutsche Bahn is subdivided in very many Subsidiary including, but not limited to infrastructure, long distance travel, Regional subsidaries in each State of Germany, and many more within and outside of Germany, like DB cargo and arriva.

This does not equate to a system in which geographical spread in and of itself necessitates more provision of office buildings such that it is not possible to expand geographically without building more or larger office buildings.

[Freahk]

So what do you suggest instead?

I don't think they had all these headquartes spread around just for fun. I'd expect it's simply not (efficiently) posible to operate the whole concern just from the DB tower in Berlin.

Sure, in the real-world there are no hard borders where you suddenly cannot build because it's out of headquarter range, but it becomes hard to operate such a huge transport company without any local offices at some point and even if you don't have local offices, you will need more offices somewhere to operate the company as it grows.

So there clearly is a relation of companies size and the need for headquarters/offices.
The real-world suggests that it's clearly advantageous to have local branch HQs, instead a central mega HQ.

Not sure if headquarter coverage is the best measure for companies size, although it's one that can easily be understood by players and is rather esily implemented.
Maybe counting players (weightened) objects instead is a more preciese model of company size. That needed very much balancing work, however.

[jamespetts]

So what do you suggest instead?
I don't think they had all these headquartes spread around just for fun. I'd expect it's simply not (efficiently) posible to operate the whole concern just from the DB tower in Berlin.

As indicated, the original suggestion was to scale the number of headquarters required with the number of depots, although it is possible that this might itself lead to anomalies.

Ultimately, what is desired is a system in which the actual number of things that need to be administered can be estimated in a realistically proportionate way relative to the actual networks that players have such that administration cost scales with the overall level of transport activity engaged in by the player. Geographical area does not really do this as the overall number of things to be administered does not relate to geographical area except very indirectly and contingently, and this relationship is likely to be broken as soon as there is an incentive to do so (as players will find intensive compact transport networks more profitable than low density spread-out networks for reasons which do not simulate anything real).

[Vladki]

As indicated, the original suggestion was to scale the number of headquarters required with the number of depots, although it is possible that this might itself lead to anomalies.

If anything is bound to the number of depots, than depots themselves would have to be somehow limited. Now you can serve the whole map with one depot of each type if the network is well connected. So there would have to be some limit on how many convoys can be built / operated / serviced by each depot, to enforce building more depots if the company grows.

[Freahk]

What you said about the area approach does also apply to the depot approach, in an even worse way.
As pointed out already, the number of depots does not at all relate to the maintained network.
Depots are not really required to run a huge network. If I was about to ptimise for the number of depots, I could easily use a single rail depot to serve my whole mainline network, instead of I believe, 4 depots currently.

If you really want to measure the network size in a more-or-less realistic way using depots, those will need to be simulated in a much more extended way, that actually requires fairly nearby depots to exist and adds a (maintainance) capacity to depots, otherwise networks built around a central point will still only need a single depot to maintain the whole network.

If you really wanted to measure the network of players, you might weighten each object a player has build by its administrative requirement and sum this up.
Balancing this out properly, without favoring any specific mean of transport in general nor favoring compact, dense networks will be very hard in this case.

[jamespetts]

I should note that the forthcoming and long planned changes to vehicle maintenance will do more or less precisely what is suggested: vehicles will have to visit depots for maintenance periodically and will only be able to deal with a certain number of vehicles at once. This should, therefore, deal with the issues described.