Topic: Better Depots

[Fabio]

Do we really need depots?
They have nothing to do with real world depots (where vehicles are serviced time and again) and additionally AI makes no use of them.
They serve only as a gateway for vehicles to enter the map.

We could have instead a virtual depot for each vehicle type. Depot button would open the virtual depot dialog. Vehicles could enter the map at their first stop and leave it at their next stop when sent to depot.

This would be much less confusing for new players and would allow new commands like cloning a running vehicle (see also the line orders thread).

[X]

What about electrified tracks? Other than that, sounds good to me.

[Fabio]

Well, the control on electrification could be moved to schedule/line level.
When assigning a schedule/line to an electric vehicle, just check if the route (or at least the first/selected stop) is electrified.

[kierongreen]

On the other hand the existing depots mean that players have to think about running actual networks rather than isolated lines - weighing up the cost and maintenance of depots compared to connecting road and rail links.

[greenling]

Depot s are usefull they safe money by the parking of trains.

[Ters]

On the other hand the existing depots mean that players have to think about running actual networks rather than isolated lines - weighing up the cost and maintenance of depots compared to connecting road and rail links.

I always construct a depot at most stations anyway.

Depot s are usefull they safe money by the parking of trains.

This is what I mostly use them for. While one could also park trains in virtual depots, that means teleporting vehicles around become a more natural way of reassigning a parked trains elsewhere, whereas I now drive them from depot to depot.

[Fabio]

While something would be lost, I usually associate depots operations to boring and unpleasant micro management.

Even teleporting could be accepted if it frees the player and give him more time to actually dedicate to strategic planning rather than sending a vehicle to depot.
Virtual depots could also be coupled with new nice features like a second hand market: sold vehicles would be moved to public player depot. Every time you buy a vehicle, it would look up in public depot for the cheapest resale available (+5/10% few for public player, but capped at new vehicle price) and only if none available it would buy a brand new vehicle. This would especially be useful for start-ups in online games. Vehicles present in second hand market would be shown (their number) in different color as now it shows vehicles already in depot.

[Ters]

What some find boring and unpleasant, others love. Second hand market can be implemented with depots as they are.

[Fabio]

Also cloning a running vehicle?

What I would like to get is whether, pleasant or unpleasant, you would consider manual depot operations (e.g. Giving order to transfer a vehicle between 2 physical depots) micro management or not.

[greenling]

Second hand vehicles are heavy to get.

[Ters]

The hardest part for me when I want to add another train to an existing line is figuring out what to name it, since I name trains after the line and a running number within that line. That trains don't materialise out of thin air is one of two(?) reasons I play Simutrans and not Railroad Tycoon 2/3. (Though depots have a unrealistically large capacity.)

[Fabio]

A few ideas for existing physical depots:

- auto electrify till first intersection if the intersection itself is electrified (would be huge help for noobs)

- common store room, i.e. cars bought but not assembled in consists, shared among depots, as well as second hand market for disassembled cars (in order: use own car, buy from market, buy new)

- Order to transfer a consist to a different depot (e.g. in schedule drop box a last line "Transfer to another depot", if you select it a dialog appears where you can select the destination depot.

[ӔO]

I think it would be somewhat better, as far as game play is concerned, to have just one "virtual depot" screen. All the "physical depots" that the player builds is just for the vehicle to warp out of.

This way, you can click on any depot on the map, build what you want, assign it a line and send it on its way, without having to worry about if the ways between depot and schedule are connected or not.


To that end, it might be useful if depot window showed what else is running on the same line, but I think that would make for one crowded and large depot/schedule window.

[Vonjo]

I'm sorry, may be a little bit off-topic...
I'd like to also have a depot list. It is similar to the list of station, city, goods, label, and factory, which have been available in Simutrans.

[Fabio]

AEO's proposition of virtual depot with physical gateways is brilliant. It would combine the best of both systems. I strongly support it, together with auto electrification from gateway till next junction if the junction is also electrified.

[Ters]

Though I dislike such suggestions: I suggest an option so I'm can force myself to think about logistics, which is what the game is about for me.

[prissi]

For ships, finding out which depot would get you to your target could mean a two minute break in simutrans on large maps and bad locations ...

[isidoro]

I like depots as a physical place where trains appear/disappear, but remain unless sold.  I would give them even more importance than they have now: for instance, as a place in a schedule where trains can change consists.

I think UI can be improved dealing with depots, but I don't like the idea of trains appearing and disappearing from nowhere or vehicles shared among them.

I think operations that now require a convoy to be sent to depot should be reduced to a minimum.  For instance, a duplication of a running convoy could be possible with present depots if a clipboard is implemented.  You open the convoy window, hit copy.  Open the depot and hit paste as many times as you want.  If paste is not possible, make the button be grayed.

[Ters]

I think operations that now require a convoy to be sent to depot should be reduced to a minimum.  For instance, a duplication of a running convoy could be possible with present depots if a clipboard is implemented.  You open the convoy window, hit copy.  Open the depot and hit paste as many times as you want.  If paste is not possible, make the button be grayed.

Now that's an idea I like! Too bad it's too late for me to try and code it the weekend that just ended.

[ӔO]

^ Alternatively, how about duplicating the convoy from depot window only?

1. open convoy window, check number. e.g. (631) Train
2. open depot window, select number "(631) Train" from "New convoy" drop down list
3. press "copy convoy" and convoy will be duplicated at depot.

May or may not want the convoy that's not in the depot greyed out, with text yellowed out, if it's not in the depot.
This would also match the "New convoy" field to line selection field, where currently only one has a drop down menu, while the other relies on arrows.

For ships, finding out which depot would get you to your target could mean a two minute break in simutrans on large maps and bad locations ...

ah, that's a shame.

Would it as bad with the new pathfinding algorithm?

[Sarlock]

I've always seen train depots as a one tile representation of a large switching and maintenance yard and try to restrict the use of too many of them to challenge myself to introduce new trains to the network by requiring the train to travel through an existing section of a different network in order to get to its final destination.  I've used that as a proof of the worth of my switching system.  That said, it would be extremely useful to be able to clone/copy an existing train using copy/paste and produce a second copy of that train in the depot without having to recall that train (or any other vehicle) to the depot first.

[sdog]

I very strongly support the initial suggestion!

No physical depots, trains starting at the active waypoint/station in their schedule.

This saves the player a lot of micro management, and it is absolutely consistent with the abstraction we are playing at (e.g. No servicing or tanking either). It also is consistent with the static lines pardigma: A line set up and running should not easily break. However trains comming and going to depots very often cause congestion and deadlocks, since trains suddenly take routes the player hasn't anticipated.

The only drawback is small, as mentioned above, small insular train networks, and service to small isolated bodies of water would be much cheaper.

AEO's sollution would help but is, as prissi pointed out, complicated by having to find the nearest shipyard to a stop.

A more complicated sollution could be to introduce the network id concept of powerlines, to identify the number of un-connected networks and charge the player based on the number. User example:
The player has boats on two lakes, three isolated train networks and cars on 5 islands.
At the finances dialogue she will be charged 10 times $ 1000 depot upkeep. (a mouseover tooltip would explain the costs)

[Sarlock]

In the case of a large jam of trains it would be nice to be able to remove the trains to a virtual depot and reposition them back on to the line.  It becomes a logistical nightmare trying to get 8 jammed trains back in to a depot to sort the mess out.

[Spacethingy]

+1 to depot naming.

Re. scrubbing depots completely and making vehicles just appear, I wouldn't like that. I want to play a transport simulator, not a model railway game. I'd actually go one further and disallow selling vehicles unless they're in a depot.

I do like the depot-sharing ideas, although, maybe warping across to a different virtual depot "exit" should be tariffed to keep things realistic.

Sort-of-related-idea: could that virtual depot idea be expanded a little to include Ro-ro ferries/An-225's/Intermodal stuff? On entering a carrier vehicle, the convoy would enter a "transit" virtual depot, be charged, wait until the carrier reached its destination, then respawn at the carrier's destination?

[Igorlizr]

Please, to avoid topic derail, further discussion about "Names for Depots" will continue here: http://forum.simutrans.com/index.php?topic=5876.0

Topic split.

[jamespetts]

- common store room, i.e. cars bought but not assembled in consists, shared among depots, as well as second hand market for disassembled cars (in order: use own car, buy from market, buy new)

Something very like this is planned for Experimental.

[greenling]

Hello Jamespetts

Something very like this is planned for Experimental.

That what you want to build it not simpel that it very heavy.
Here in germany gives in Moment only BR 295 and 298 from the DBAG to buy.

[uhennig]

I would like to have better looking and bigger tram depots and train depots.
Let me post a picture to show my idea.



Currently I'm using busstops for tram stations.



Maybe somthing like this:

[Ters]

I'm not sure we're finished discussing the removal of depots altogether.

[uhennig]

I think that's not a good idea. Simutrans is a simulator of real life and a depot is the company office and  the factory work room of trains, trams and buses.
Removing depots is like removing stations.

[Fabio]

There were several ideas on the table.
As it is now, depots are short of meaningless.
I would see well changing them to share disassembled parts, but maybe also correlate the max number of vehicles of a given type with the number of depots the player built on the map (or depot extensions as in your proposition).

[Ters]

I think that's not a good idea. Simutrans is a simulator of real life and a depot is the company office and  the factory work room of trains, trams and buses.
Removing depots is like removing stations.

That depends on playing style, of which there seems to be as many as there are players. Some would hardly need graphics at all, just a finance window, a list of stations and a list of lines, while others put care into every single tree like some model railroad builder without any care for the money.

[uhennig]

I'm sure the developer will find a new good solution.
If I have some traffic jams I send the vehicle back to the depot and I don't want to miss this feature.

[sdog]

Having vehicle commisioning independent of depots, would allow much more eyecandy for depots. The game still could require the player to have a depot. Just don't buy vehicles in them.

If you think about it, buying vehicles in depot is as arbitrary as buying them at a station, or just by pressing a button. We don't do maintenance in depots either. Its just a convention introduced in Transport Tycoon (TT) two decades ago we still stick to. I suspect for people never having played TT or openTTD it's not obvious at all.

@uhennig
there would still be a way to store vehicles, as in the depot. Just not having them drive to the depot.

However don't worry, i bet this will certainly not changed. In the end the german forum would tip the balance. And i can already imagine the outrage of the people there if this was suggested (i'm not reading it very frequently though).

[greenling]

Sorry sdog in tt and openttd gives no teleporting of vehicles.
There must the player let´s drives the vehicles from on depot to the another depot.

[isidoro]

Sometimes people complain that sending a train to a depot messes all their beautifully built network up.  But other people find placing the suitable depots and thinking up the network an interesting task: trying to achieve that no matter where or when you send a train to a depot, things work flawlessly.

[Ters]

I just want a vehicle to have a position at any given time, and that that position only changes according to the vehicle's top speed. That two vehicles can't occupy the same position might be a nice addition, as it would make stockpiling of vehicles more costly. The main problem as I see it is how to make such a change compatible with existing games.

[Fabio]

I just merged the two threads, so more brainstorming in one place

[wlindley]

How about changing the behaviour of depots in schedules?  Currently, sending a convoy to depot as part of a schedule sends it there, a dialog pops up "Train 1 has entered a depot" and it stays there.  Suppose we changed depot orders to regard some flag (in the manner of Minimim load, max wait for load) that permitted entering the depot, then leaving after a short time to simulate maintenance. 

That would be prototypical for trains, which in real life would terminate at a station, roll away from the station to be cleaned and serviced, and then return to start their next journey.

In the game, we could replace the current "obsolete" logic (which penalizes using old equipment) with a counter (months since last service) so  convoys not receiving regular service would become more expensive, but still functional. 

Together with this, permit the player to purchase obsolete equipment (after the "retire" date) with a cost increased by the number of years out-of-date.  You want to build a 1840s engine in 1940? No problem, we have the blueprints, sir, but it's going to cost you a pretty penny and it won't have much perfomance, but if that's what you want, yes sir!  And if you don't give it lots of maintenance, it's really going to set you back! 

[jamespetts]

I would see well changing them to share disassembled parts, but maybe also correlate the max number of vehicles of a given type with the number of depots the player built on the map (or depot extensions as in your proposition).

As I think that I mentioned, the first is planned for Experimental. The second I have considered in the past, but shelved when the idea proved controversial in favour of other projects, the suggestion being that the same economic job could be done more efficiently using vehicles' fixed costs (which are now in Standard, too). I wonder whether this matter needs considering again? A similar consideration can be given to giving functionality to headquarters - either by having the headquarters level limit the number of depots built, or by having the headquarters level determine how many useful statistics/data about one's transport network that one can access.

[greenling]

Hello wlindley

How about changing the behaviour of depots in schedules?  Currently, sending a convoy to depot as part of a schedule sends it there, a dialog pops up "Train 1 has entered a depot" and it stays there.  Suppose we changed depot orders to regard some flag (in the manner of Minimim load, max wait for load) that permitted entering the depot, then leaving after a short time to simulate maintenance. 

That would be prototypical for trains, which in real life would terminate at a station, roll away from the station to be cleaned and serviced, and then return to start their next journey.

In the game, we could replace the current "obsolete" logic (which penalizes using old equipment) with a counter (months since last service) so  convoys not receiving regular service would become more expensive, but still functional. 

Together with this, permit the player to purchase obsolete equipment (after the "retire" date) with a cost increased by the number of years out-of-date.  You want to build a 1840s engine in 1940? No problem, we have the blueprints, sir, but it's going to cost you a pretty penny and it won't have much perfomance, but if that's what you want, yes sir!  And if you don't give it lots of maintenance, it's really going to set you back! 

I think that your ideas more in Simutrans exp usefull it than in simutrans standart.

[INJMVO]

There is a thread to make the depots multi-tile maybe this will give them more eye candy and more function:
http://forum.simutrans.com/index.php?action=post;topic=5126.50;last_msg=73752