News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Ideas on range management

Started by Zeno, March 04, 2013, 06:00:04 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Zeno

I've been reading a little bit around, and I found lots of interesting ideas, but one of them makes me feel particulary expectant. I've dreamed a lot of times with the idea of vehicle's range, not only for airplanes, but also for diesel/steam locos, or even road vehicles (although these ones would be really clever to manage).

That was discussed in this thread[url], and seems to be a difficult thing, so I'll think loud some ideas with the aim that someday they may help.
Quote from: jamespetts on August 03, 2012, 12:33:17 PM
I have considered range; however, it is a tricky issue. It would apply not just to aircraft, but rail and road vehicles, too, as well as ships, and, indeed, almost any non-electrified vehicle. The trouble is that it is not an easy thing to communicate to a player: whilst actually stating the range in the depot/replacer window is easy enough, players actually being able to work out whether any route will be in range of suitable vehicles before planning it is not an easy task. I suspect that people would find this feature a bit too awkward and fiddly.

It could be a bit awkward, I agree, but maybe it would be possible to make it playable.
My first idea has been: I think that scheduled vehicles would not be a problem, as shedule is a single-vehicle thing and doesn't look like a huge problem; line management could be harder, because many vehicles can be involved, thus I thought "what about considering a range=longest-distance-between-stops concept and sticking it somehow to the line? If such thing was possible, when modifying a line it could be verified and limited to the minimum range of all vehicles in line, and when assinging a vehicle to the line its range could be verified with the line's range. That would help managing ranges by forbidding assigning lines to vehicles that don't have the required range, and also modifying a line by adding a stop that would mean a range bigger than the smallest of the vehicles currently in the line.

Later on, if the required range for a line is kwown, one could think of adding a filter to the depot window, mostly useful when upgrading vehicles.

wlindley

Refueling would be a wonderful assignment for the somewhat redundant Depots, no?

Zeno

Well, that could be a further step to add. That would give some sense to having a "depot network", which I guess is quite common...

jamespetts

A problem with this is: how do we calculate the distance between stops, and when do we recalculate it? Suppose that the schedule does not change, but somebody amends the road network and it now takes longer to get from A to B. How do we know when to recalculate the range? How do we explain to the player what has happened? What about a multi-player game when this happens and the player is offline - what happens to the convoys in the meantime?
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.

Zeno

I didn't thought about that, mostly because I didn't consider the *real* route, but the Manhattan distance between stops; it's not 100% realistic, but it's a good approach.
Another option would be charging a penalty fee for out-of-range routes; that would partially solve the re-routing and the multiplayer problems.

jamespetts

Hmm - using the distance between stops would produce odd results where the route distance is tortuous (and would be unintuitive to players), and charging extra for being out of range seems to me to make little economic sense, and does not really solve the issue of absent players, since players may find themselves in financial difficulties as a result of this.

The ideas are appreciated, incidentally; but, sadly, I don't think that this particular idea will work.
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.

Zeno

I agree the distance would be rather unintuitive, but I don't agree with your charging logic, even I don't like the idea of charging either. Absent players will be in financial difficulties by other reasons much before a range charging was applied, specially in experimental.

About the other questions you made before, I'm sorry I'm not familiar with ST code at all, but isn't the route to the next stop calculated for every trip? Would be too resource consuming calculating that distance at same time? About explaining the player... well, a message could do the job 8) "Route was modified; vehicle out of range!". Anyway, the multiplayer problem is much tougher...

Vladki

I think that range limits are most interesting for planes, and there the manhattan distance is fine. For the other vehicles I think it is not that critical. Buses, Trucks and Trains can travel a few hundred km with full tank, and they usually stop more often than that, or at least they pass through some station. For planes the range calculation is crucial. For trucks, trains and boats we could skip the range calculation, and slow down the vehicle if it runs out of fuel. Something like that was in RT. Steam engines could run out of water, and then they slowed down dramatically. So either slow down, or extra charge - buying fuel on the road...

jamespetts

Range was particularly important for steam trains, as Valdki suggests, as well as for aircraft. It is of more limited importance to other forms of transport, but, even so, there are diesel locomotives on railways with extended fuel tanks compared to others in the same class especially for longer trips, so this not an issue confined entirely to steam and aircraft. It is probably particularly relevant to steamships, too, however, as well as long distance road transport (I don't think that a 'bus from 1950 could travel 500km without stopping, for example). As for going slowly - I don't think that that makes any sense: a steam locomotive cannot move at all if it is out of water, so it should not set off unless it knows that the next stop is within range.

Zeno is right, in fact, that the routes are calculated at each stop, so this would not in principle add any further computational load. The routes would have to be calculated in advance, too, though so that a player setting up a schedule in the first place would know whether things are within range.
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.

Junna

Quote from: jamespetts on March 04, 2013, 10:48:33 PM
Range was particularly important for steam trains, as Valdki suggests, as well as for aircraft. It is of more limited importance to other forms of transport, but, even so, there are diesel locomotives on railways with extended fuel tanks compared to others in the same class especially for longer trips, so this not an issue confined entirely to steam and aircraft. It is probably particularly relevant to steamships, too, however, as well as long distance road transport (I don't think that a 'bus from 1950 could travel 500km without stopping, for example). As for going slowly - I don't think that that makes any sense: a steam locomotive cannot move at all if it is out of water, so it should not set off unless it knows that the next stop is within range.

Zeno is right, in fact, that the routes are calculated at each stop, so this would not in principle add any further computational load. The routes would have to be calculated in advance, too, though so that a player setting up a schedule in the first place would know whether things are within range.

But the demand created by the addition of these sort of simulation would be quite considerable - water-towers, water troughs/coal depots for steam use (would be amusing if this would consume produced coal too - though I don't think this should be a requirement, but something that would be possibly simulated in a more basic manner; railways were after all one if not the largest single consumer of coal for a long time). Maintenance depots for diesels with refuelling points (would help then if done after shunting/switching carriages and so on had been implemented, then, I guess), so on. Petrol stations as possible refuelling points for road vehicles? Worth thinking about.

ӔO

I think, a simple way of doing this, although it gives poor feedback to the user, would be to charge extra for distance overages.
Since the game records odometer, if a vehicle runs over x km between stops, the vehicle can be fined some extra money for a fuel refill.

Otherwise, I can see this requiring an adjustable measuring tool overlay.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Zeno

The use of refuelling points would make things a lot more complex, I think, because it would mean to make mandatory the inclusion of depots in the vehicle's schedule, and the distance to calculate would be the whole route beetween two depot visits. It would be incredibly realistic, but at the moment I understand this can't be even considered...

About planes and ships, its easy. Maybe it could be enabled only for those? With road vehicles and particulary with trains it's a tricky matter; I keep thinking the fee is a good idea, although it's not very realistic, but it's just a way of keeping the player away of building schedules overcoming the rule. Anyway, even in multiplayer, the chance of such a huge track/road modification to make the fee considerable enough would be pretty small, don't you think? In that case it could be a variable fee, not painful if the vehicle runs a couple of km more than its range, harder if the distance raises...

Quote from: jamespetts on March 04, 2013, 10:48:33 PM
The routes would have to be calculated in advance, too, though so that a player setting up a schedule in the first place would know whether things are within range.
That means in the line design window I guess... Every time a new stop is added/removed, the route(s) where that stop is involved should be recalculated to give the proper message if requirements aren't met. Am I right?

ӔO

Actually, there already is a code limitation to ship route ranges.

On the server game, if you setup a really long ship line, ships won't be able to find routes
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Vladki

Refuelling: depot is not the right place as we will lose cargo/passengers, and steam trains used to get water with passengers on board. The same applies for buses. So I think refueling should be done during stop in station. For simplicity any station could refuel, or for advanced players a special extension would be needed - coal, water, diesel, jetfuel, food for horses...

jamespetts

Vladki's point is valid, and this is the only way of doing it to make it workable - the trouble is that this is likely to overcomplicate things rather.
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.

isidoro

Stations should be the natural refueling places.

Regarding what happens if the next station is not in range, a more consistent way of indicating it would be a message on the vehicle saying Next stop not in range.  That would be similar to the No route message.  The vehicle should be stopped and the message shown until the problem is solved.

No change to the line schedule dialog is needed and this would not include problems of a different sort than the present No route message, whether in single or multiplayer...

jamespetts

Players would need to know in advance which vehicles are suitable for which lines/schedules, rather than only find out when it is too late.
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.

ӔO

I can see there being some issues when reconfiguring a working line.

But if the line is not in service, how about a tool that checks line statistics? It only needs to give back min/max distances between stops and maximum weight over the line.

Presumably, if the tool copied the line exactly and ran it in another instance of simutrans, it should be able to give back telemetrics with any given vehicle as well.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

isidoro

@James: that's not quite consistent with present behavior: you can build lines no matter what vehicles will populate them.  Imagine a vehicle is too heavy for a bridge.  You are not warned by the game until that vehicle tries to find a route and can't: too late.

And since ways can be changed, it may happen that a suitable vehicle is no longer suitable (for a weight reason or because there is no road connexion any longer or, that's my point, because the next station is now out of range)...

Simple and consistent with present way of doing things in ST.  And simple to program: simply add a depth limit in the A* algorithm...

Of course that if things are done well, there are details to think about: what happens with convoys with two locomotives, each one with a different range?


jamespetts

Actually, I think that, ultimately, it would be a good idea to have a system for assigning a maximum weight to a route: but that would be complicated, because the pathfinding would have to be run many times over, as there may be routes that are non-optimal for a lower weight but that would suffice for a higher weight: this would be a particular issue with road connexions. It would also be useful if the same could apply to way constraints, but, again, this would get complicated for the same reason. If you can think of any way of making this easier, it would be worth looking into.

However, the issue is more critical for range, as there is no easy way for a player to know what the distance is between two points, whereas a player can fairly easily check the way and bridge weights and way constraints.
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.

isidoro

Maybe it is because I play that way, but whenever I create a new line, I always test it with a convoy, and then, populate it...  Just more or less like in RL when you test a new train route.  If, in one of those tests, I detect a No route problem, I try to solve it (and, btw, sometimes it is very hard to know where the electric wires are not connected, for instance).

If I got an Out of range notification in one station in one of such tests, I would try with a vehicle with a longer range or build an intermediate station.  Eventually, if the vehicle specs say that its range is 200 tiles, with some practice, I'm sure one can guess more o less how far that is in the map.

To have range as another factor to choose a vehicle would add a better game experience, imho: cheaper steam locomotives would have another reason to be replaced by more expensive diesel, not to mention the clear advantage of electric vehicles with infinite range...  Another clear reason to invest in electrification gamewise...

jamespetts

Hmm - it would be greatly preferable if players did not have to use trial and error like this.
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.

ӔO

#22
If the convoy can detect that its next stop is out of range, how about the game giving a warning to the player about overage and sending it off on its way anyways?

That length of the journey should incur extra running costs.

A message like: "Convoy (#)'s next stop is out of range by X meters and is adding extra expenses."
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

I am not fond of the extra cost idea, as it makes no sense: if a vehicle runs out of fuel, it cannot go at any cost.
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.

ӔO

Think of it like calling out roadside assistance services.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

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.

Zeno

Well, cost of on-flight refuelling, or cost of emergency landing for refuelling... we could set max speed for vehicle to zero, but we'd need to implement towing of broken down vechicles; either reducing speed to 5% or a penalty fee could "simulate" the costs for refuelling the vehicle no matter the way to do that (emergency landing, towing to a gas station, etc...)

isidoro

But in RL those events don't occur on a regular basis.  They occur occasionally.  I'm with James.  That kind of money or speed penalties seem rather artificial to me.  A sort of workaround...


Zeno

Of course, they are a workaround. I'm not planning on coding out-of-fuel (range) rescues/consequences! ;)

ӔO

#29
Yes, they are workarounds to a complex solution that may not be easy to use.


The complex way: Do what GPS navigators do and use save data as a map.

- CPU checks shortest route based on saved (old) data
- CPU checks fastest route (ignoring elevation changes or curves) based on saved (old) data
- CPU gives back statistics of that route, including maximum weight, maximum distance, minimum speed, restrictions and electrified or not and can show calculated path on map
- User can then upgrade route to suite their needs

Obvious caveats
- Making changes to ways afterwards would require saving before map data is updated.
- Making changes to schedules may require rechecking. (discourages changes on the fly)

Positives
- Server CPU need not do this work, when the route can be calculated locally. Then schedule can copied to the server.
- Local CPU does not need to load convoys, only map, ways and stops, making navigator lighter than main program.
- If GPGPU can be used, path calculation can be much faster with multithreading and need not worry about multiplayer friendly code.
- User has an easier time identifying potential problems with their schedules.
- Possibly the easiest to use (least micro management) for the player

Negatives
- Separate tool, more coding
- May take users some time to get used to idea of using navigator.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Zeno

Blame me for bumping this again but I had a new thought about this. I've been reading about passenger features implemented in experimental and I thought of the impact that comfort has in longer routes. After analyzing one of my saved games, I've seen that travels between most of my airports are around 1 hour (game time), and then I took a look to comfort ratings: average (100) comfort gives 1:40 traveling time without "comfort penalty", so I thought of setting the airplanes' comfort setting to (just an example):

- 30 (30 minutes?) --> short range airplanes, for 30 minute or less flight time.
- 60 ( "       "        ) --> medium range planes, for 1 hour or less
- 120 ( "       "        ) --> long range planes (IRL -ER version), for 2 game hours or less

Maybe there's a bad impact from something I could have forgot, as I don't know very deeply all experimental features, but I thought this might be a nice and easy approximation by using existing features and thus avoiding new problems, locks or checks, so that's why I share the idea.

Any thoughts? Would that affect only to revenue or also to passenger tolerance to longer routes?
Thank you so much for your comments.

jamespetts

Comfort only affects revenue: we do not account for comfort in routing in order not to add excessive computational load (balancing two factors is orders of magnitude more complicated than using a single factor). The aircraft's comfort ratings are based on the comfort of the aircraft relative to other forms of transport, and based on realistic journey lengths. If a short haul flight is more comfortable for passengers than spending two hours on a coach or medium-distance train, then there is no reason that the revenues should not be greater to account for that; certainly, air should have a vastly higher cost than land transport, so the revenues will need to be greater to match that.

However, the intention is to use the pakset with very large maps where travelling from one end of the map to the other would be a medium haul flight rather than a short haul flight (over 1,000km), so it would not be right to calibrate everything on the basis of much shorter journey times.

For reference, all the vehicles in the forthcoming 0.9.0 have substantially recalibrated comfort settings.
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.

Zeno

Thanks a lot for your comments, james.

By affecting revenue we could think that a shorter aircraft going out of its range (traveling over its comfortable max time) is taking a penalty, in this case because of having a too low comfortability for such a long trip. I think it could be a good alternative for the "out of fuel" penalty that was discussed long ago.

Actually, I think it's a good fact that it only affects the trip income, because I was afraid of having too many parameters being changed just because of the comfort change, but that way it would be a more controlled tuning.

About the big maps, well, biggest airplanes (and/or extended range aircraft versions) could have maximum comfort (240 would give up to 4 hours of game time to complete the trip, which should be far enough even in biggest maps), and then find a good compromise for intermediate and short range configurations. The fact is, no matter if we want to use it for range management or not, all vehicles must have a comfort configuration (100 by default, which gives 1h40 with default settings), so we should calibrate everything thinking in an acceptable maximum value, then get to a good compromise for intermediate ranges. Obviously, the bigger the map, the more impact it will have in the game.

By the way, what if I use comfort 255 and catering level 5? Would that lead to an overflow (catering increases the comfort, and max value for comfort is 255, isn't it?), or it would just be truncated to 255?

jamespetts

I think that it would just be truncated to 255 - I think that I put range checking code in place, but it has been some time since I have worked on that now. You could easily check by trying it and running a test using the comfort graph.

I don't think that it is sensible to calibrate comfort based on anything other than the actual real life comfort of the vehicles in question, however: it will end up producing weird results when one compares one vehicle and another if they were calibrated, not on how comfortable that the real life counterparts actually are, but on some synthetic scale relative to the size of maps and likely journey times. I should also caution against using comfort as some sort of proxy for range: the two are very different, not least because comfort applies only to passengers and is a property of the passenger accommodation, not the motive power.
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.

Zeno

Quote from: jamespetts on June 07, 2013, 12:45:41 PM
I should also caution against using comfort as some sort of proxy for range: the two are very different, not least because comfort applies only to passengers and is a property of the passenger accommodation, not the motive power.
That's true, and it sounds reasonable. They are indeed very different. I will do some tests and maybe a "light" tuning is enough. Preventing low range planes getting too long routes by using comfort may be too radical for the reasons you exposed; however, making a little tweak (let's say decreasing from 100 to 80 or 70) to comfort on those aircraft that are supposed to be for regional or shortest ranges would do the job, aiming the player to use different vehicles for different situations/routes.

Thank you for your comments :)