News:

Congratulations!
 You've won the News Item Lottery! Your prize? Reading this news item! :)

max_weight / axle_load in simutrans standard

Started by Vladki, April 16, 2017, 02:05:16 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

I'm not sure if this question is in the right subforum, so please move it if you fell to some other place.

I'm trying to implement weight limits for ways in pak128.CS. While there is quite a good reference for simutrans-extended, I could not find how max_weight and axle_load work in simutrans standard. I see them both defined for railways, and makeobj accepts them just fine, so I would like to know what they mean, and how they are enforced.


prissi

They are not yet enforced. But they would be enforced that a convoi cannot got on track wih too low axle load.

Leartin

Is already clear how they will be enforced?
Will it just be "max_weight" in ways and "axle_load" in vehicles, and any vehicle with "axle_load" higher than "max_weight" can't use the way?

If so, may I suggest using more generic names, like "level[]" for vehicles and "max_level[]" and "min_level[]" for ways? Unless something like "axles" in EX will be implemented at a later time, there is no relationship between those parameters and actual weight. And there are other potential mechanics that could use the same schematic - eg. clearence in height and to the sides, depht of waterways, perhaps the kind of signaling used, if they progressed in a linear way, or more exotic things for future vehicles. Or even binary things - technically, you could say "level[0]" refers to electrification, so level[0]=0 can't use any way with 'min_level[0]=1'.
I'd say there can many things be done with a tool like that, so I'd like to see it made as flexible as possible, not hardcoded to a single purpose.

Vladki

If it is not implemented yet, then I would like to suggest implementing it in the same way as in extended. Including the names: max_weight for ways and axle_load + axles for vehicles.

For other restrictions there is already another concept in extended: permissive and prohibitive way constraints. They are used for various types of electrification (ac/dc/3rail), as well as waterway depth/width, or tunnel clearance (tube or train).

Sent from my ONEPLUS A3003 using Tapatalk


Ters

I think just axle load is enough. That seems to be the typical restriction. The only place where total weight is an issue seems to be bridges, but I think the issue there is the total weight of all vehicles on a span. Or rather the sum of the loads on all axles on the bridge, but Simutrans has no concept of where the axles on a vehicle are. Either way, it is a rather complex limitation to implement.

Vladki

It is already implemented in extended. Just as you said, for normal ways and tunnels, the max_weight parameter actually means axle load. For bridges it is the total weight of the convoy (or part of it, if the convoy is longer than bridge.)

For vehicles axle load is calculated from weight (including cargo) / axles. If the load is not split evenly, you can override it by setting axle_load explicitly.

Sent from my ONEPLUS A3003 using Tapatalk


Leartin

Quote from: Vladki on April 20, 2017, 09:36:15 PMFor vehicles axle load is calculated from weight (including cargo) / axles. If the load is not split evenly, you can override it by setting axle_load explicitly.

Which is great, until your coal train can enter the coal platform, but is then too heavy to leave it, and you can't even send it back to depot. I don't know how that is solved in EX, or if it's solved at all, but in Standard, the question whether a vehicle can use a way or not should be rather static.

Yes, the suggested "level[]" parameter is very similar to way constraints, but there are two differences:
For one, with way constraints, you can only do a binary constraint. You can specify whether a channel is deep or not, and whether a boat requires a deep channel. But if you want to have a shallow channel as well, it becomes complicated. I think you can have shallow channels require shallow boats, and deep boats require deep channels. Levels could give you ten or more different channel dephts at once - the exact number depends on how many bits are used. Can't say one approach is better than another, but they are different.
But more important: It needs less extra code. Axle load is more likely to come than way constraints. You could not use way constraints for the same purpose as axle load. But you could use the axle load code as way constraints. Why implement way constraints if (then) existing code could already do the same?

Ters

Quote from: Leartin on April 21, 2017, 08:05:42 AM
Which is great, until your coal train can enter the coal platform, but is then too heavy to leave it, and you can't even send it back to depot. I don't know how that is solved in EX, or if it's solved at all, but in Standard, the question whether a vehicle can use a way or not should be rather static.

Indeed. The axle load must be the one given in the dat file, even if it is slightly unrealistic.

Vladki

Extended has several sizes of canals, all of them as constraints. Smaller boats have specs, that they can use multiple types of canal.

Well, you can calculate the axle load as if the vehicle is always fully loaded.

In extended, it can happen that empty vehicle is ok and cannot return full. It wil show 'no route' warning, and if you do not upgrade the way, it will eventually teleport to depot.

Axle load in extended is used for more than limiting where you can go. Way wear is also simulated, therefore it has to really be based on current weight. But I don't ask for that in standard.

All I want is that if I specify max_weight, axle_load or axles in dat file, it will mean the same in both extended and standard.

Sent from my ONEPLUS A3003 using Tapatalk


Leartin

Quote from: Vladki on April 21, 2017, 04:40:33 PM
Well, you can calculate the axle load as if the vehicle is always fully loaded.
Goods have different weights though, and a vehicle is not aware what it will pick up at a station. So it would need to pick the heaviest good of the class it can transport - even if that good is not produced by any factory on the map. Even worse, if you add a good at a later point, if it is heavier than all the goods of the same class, it might break a map just for existing.

Vladki

Then just use the same solution as extended: show no route warning and teleport to depot after a while.

Sent from my ONEPLUS A3003 using Tapatalk


Leartin

That only mitigates the side effects of blocking the station with the stuck train, but does nothing to solve the issue itself.

Actually, it's even worse than just letting the train being stuck, since it might take a player longer to even realize there is an issue if they dismissed the no_route warning - "Must have forgotten to send it on it's way..." and if they realize there is an issue, it does not help one bit in fixing it. Instead, the player will assume there is a manual way to teleport the vehicle to a depot, or the vehicle might teleport while the player tries to fix its way. This might be good behaviour for a network game, to get rid of trains of idle players who won't solve their issues themselves - so you might want that as a seperate, toggle-able function - but for this particular issue, that's just no good.

Vladki

And do you have any better solution? Teleporting could be enabled only for network games, where a stuck vehicle could affect other players.

Leartin

Yes, the better solution is not to use an "axles" parameter, so that this kind of situation does not even appear.

Axles are only useful if they are used to divide the current weight of the vehicle. If you go for the max possible weight the vehicle could have anyway, you could as well pre-calculate that and write it as a constant axle_load with the exact same results, therefore you don't need axles.
Using the current weight of the vehicle including cargo means the axle_load is variable, thus can't be stated in the dat. However, by being variable, the same train can't always use the same track. This is undesired behavior, thus should not happen, and unless an solution for this issue is found, "axles" can't get a green light.

One such solution could be to have the system work it non-binary. Instead of not allowing too heavy vehicles on a way with max_weight, we could make it so those vehicles need to go very, very slowly. Therefore, no vehicle can get totally stuck because of weight limit.
While such behaviour would work on the players side, it's probably a nightmare for route finding. For route finding in Standard, it does not matter how quick a vehicle could move on a given way. Therefore, all way tiles on which a vehicle will be overweight would just be seen as eligable for travel. Here in Austria, we have many "No GPS"-signs scattered around, because there are some mountain paths shortcuts provided by navigational systems, while actually being too narrow for trucks. This is pretty much what you would have to do with that 'solution' - add signs and signals for weight limits so they would be excluded from routing by heavy vehicles. While that could technically work, it's definitelly not worth following up on it.


So just scrap axles for Standard. What's the downside, anyway?

Ters

Quote from: Leartin on April 23, 2017, 11:36:46 AM
So just scrap axles for Standard. What's the downside, anyway?

One can either skip axles or skip axle_load. In the first case, axle_load becomes a constant independent of the actual weight of both vehicle and cargo. In the second case, one would divide the sum of vehicle and cargo weight on the number of axles. For many vehicles, this would not be correct, as the weight is distributed unevenly on the different axles. Having a fixed axle load is probably the proposed behavior that best matches the actual axle load of a real-life vehicle, under the assumption that vehicles move back and forth on the same path (making the fact that the axle road is wrong on the empty run irrelevant) and that the possible cargos do not differ much in weight. I don't have enough knowledge on how the different pak sets differ in weight for cargo belonging to the same group to tell whether the latter assumption holds.

Quote from: Leartin on April 23, 2017, 11:36:46 AM
Here in Austria, we have many "No GPS"-signs scattered around, because there are some mountain paths shortcuts provided by navigational systems, while actually being too narrow for trucks.

Does that actually work? It seems to me that GPS slaves ignore signs completely. Then again, I remember trucks getting stuck long before GPS became commonplace. Although those cases were due to following the main road when they should not, typically due to low bridges, it was still a matter of not reading signs (and/or not knowing the actual dimensions of their vehicle).

Leartin

Quote from: Ters on April 23, 2017, 12:19:09 PMDoes that actually work? It seems to me that GPS slaves ignore signs completely. Then again, I remember trucks getting stuck long before GPS became commonplace. Although those cases were due to following the main road when they should not, typically due to low bridges, it was still a matter of not reading signs (and/or not knowing the actual dimensions of their vehicle).

I usually encounter them while using GPS, and they don't stop me, but I'm not a truck driver.
Though just to clarify, it's not that those roads are too narrow for a truck to pass through, like it would be with low bridges. But the road is, over long stretches, just broad enough for one vehicle. If two cars meet, they might go a bit offroad and pass each other, but with trucks, it's a different story. These signs legally don't exist, and there is no real way of stopping a truck driver to use the road. It's just that he won't save any time and instead block the road for everyone else.

Vladki

I have asked Jamespetts for some clarifications, where I was not really sure. So here it is:

Quote from: jamespetts on April 23, 2017, 02:53:25 PM
(1) There is a setting in simuconf.tab, enforce_weight_limits, which affects the behaviour. I have just looked at this and updated the comments for this, which now read as follows:


# This setting allows the way in which weight limits are enforced to be customised.
# The meanings of each setting are as follows:
# 0: weight limits are ignored entirely.
# 1: then vehicles can travel over roads, rails, tunnels and bridges for which they are too heavy, but only at greatly reduced speed.
# 2: Vehicles cannot travel over ways for which they are overweight at all.
# 3: Vehciles cannot travel over ways for which they are more than 10% overweight at all, and will travel on ways for which they are up to 10% overweight at a greatly reduced speed.
#
# To revert to the behaviour of Simutrans-Standard, set enforce_weight_limits=0


(2) Allowing max_weight for ways in the .dat files is a backwards compatibility measure: it does the same thing as axle_load. If both are specified, axle_load takes precedence.