News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Vehicle weights in kilogram instead of ton

Started by ӔO, June 16, 2012, 12:13:08 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ӔO

Per title, I think it would be better if vehicle weights were done in (kg), instead of (t).

- Tons are inflexible, 1000kg, at the smaller end of the scale. Smaller trucks, two wheelers and horses are all under 1t. Some smaller trucks can be in between, 1t and 2t. Currently, you can add power or gear to compensate for the extra weight, but this may not be immediately obvious to new players looking at the power to weight ratio.

- Goods are in kg and I think it would be better to use the same units. It's not as terrible as mixing imperial and metric numbers, like tyres, but surely it wouldn't hurt to use one consistent system.

Perhaps, for the sake of compatibility, a value like "weight_kg" would be good?
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

DirrrtyDirk

Or maybe just allowing tenths of a ton (like 3.5 tons or 40.4... 0.5 or such) would be enough for a compromise?
  
***** PAK128 Dev Team - semi-retired*****

ӔO

that would work too, but I was under the impression that " . " were not allowed?
" , " I remember being used for offsets.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

VS

Well, if it's not an image reference, then the special meanings do not apply :) Dat file syntax is the least of problems.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jk271

I support this extension request. I considered to suggest it some time ago.

Currently weight is saved as uint16, so maximal allowed weight is 65 535t (according to variable type of unsigned 16-bit integer - I have not tried it).
Changing weight to unsigned 32-bit integer (in kilograms) enables creation of large capacity crude oil tankers as limit will be increased over 4.29 millions tons.

prissi

THis is a very easy change an will be done today. You will just use weight=1.333 for 1333 kg in the dat file.

ӔO

My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

kierongreen

r5777 | prissi | 2012-06-17 21:26:00 +0100 (Sun, 17 Jun 2012) | 1 line

ADD: weight in dat fields are in tons but kg can bei give like 1.350

In trunk as of revision 5777 thanks to prissi :)

TurfIt

#8
Quote from: prissi on June 17, 2012, 07:38:58 PM
THis is a very easy change an will be done today. You will just use weight=1.333 for 1333 kg in the dat file.
1.333??? unless I'm missing something, the implementation in r5777 needs weight=1333. i.e. decimals are not required/allowed.

More importantly, there's no way there's enough bits left in the calc_accelleration routine to handle this multiplication by 1000.
When I found the sint32s overflowing and moved the calcs to sint64 as required, in testing I was observing numbers using up to ~59bits. Which was why I used sint64s instead of doubles despite the performance hit, the doubles were also overflowing. Now, you'll need 69 bit variables to handle this! Something's got to give... Add different calculations for light vs heavy convois? (retain calc in tons for heavies?)

Also, by moving the bracket in the deccel= statement, you've introduced possibly 4 extra 32<>64 conversions, compiler mood depending. performance--.

Dwachs

Quote from: TurfIt on June 18, 2012, 05:20:27 AM
1.333??? unless I'm missing something, the implementation in r5777 needs weight=1333. i.e. decimals are not required/allowed.
Probably multiplication by 1000 is missing in vehicle-writer.
Parsley, sage, rosemary, and maggikraut.

prissi

#10
Yes, this is indeed missing ...

About the brakets is deccel:
since sum_..._gesamtgewicht are now sint64 anyway, it actually should have removed a conversion for sint32 to sint64 (I just overlooked sum_friction_weight, setting this to 64 should solve this.)

But you comment about overflowing is more severe. Which vehicle did overflow? On my limited tests yesterday non came close to the limit. But one could change it:
from

sint32 deccel = (sint32)( ( (sint64)akt_speed * (sint64)sum_friction_weight * (sint64)akt_speed ) / (25ll*256ll) + sum_gesamtgewicht * 64ll) / 1000ll;

to
sint32 deccel = (sint32)( ( ( (sint64)akt_speed * (sum_friction_weight * (sint64)akt_speed)/3125ll ) / 2048ll) + (sum_gesamtgewicht * 64ll) / 1000ll );



TurfIt

Quote from: prissi on June 18, 2012, 10:04:03 PM
But you comment about overflowing is more severe. Which vehicle did overflow? On my limited tests yesterday non came close to the limit.
The pak64 concorde as it starts the landing approach - still at full speed as friction jumps up - is the one I found pushing the limits. It briefly requires 60 bits.


Quote from: prissi on June 18, 2012, 10:04:03 PM
But one could change it:
I haven't tested, but won't this cause issues for light, slow, low friction convois?
Big difference between a 1t 15km/h horse carriage and a 100t 2170km/h supersonic jet!

prissi

It would only case issues if the vehicles if (actual_speed*sum_friction_weight)<3125ll. For a weight of 1000 kg this would be a speed of 3, i.e. 0,25 km/h. Even with 100 kg, it would be still 3 km/h. But of course one could add 1 to this to avoid non-zero issues ...

sint32 deccel = (sint32)( ( (sint64)akt_speed * ( (sum_friction_weight * (sint64)akt_speed ) / 3125ll + 1ll) ) / 2048ll + (sum_gesamtgewicht * 64ll) / 1000ll);