News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

A lot of questions about dat parameters

Started by An_dz, March 01, 2016, 01:39:16 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

An_dz

I went on reading the source of all /besch/writer/ files to better understand the dat parameters and also for documentation. But I ran through some questions, so I need some answers from the devs about some parameters:

1. Why does the speed of citycars is multiplied by 16 to be saved on the pak?
Not that we need a citycar faster than 4095km/h, but it's just strange.

2. Why does the cost of signals does not take account the cents, but all the rest do?

3. Why topspeed on bridges is uint16, but for tunnels, ways and way objects it's sint32? It does not even make sense to have negative speeds.

4. For vehicles there's a parameter called fixed_cost, when it's omitted then maintenance is used. I could not notice any differences on them from the code, is fixed_cost an old deprecated parameter?

5. And why maintenance is uint16 for vehicles when for the others it's uint32?

6. Why distributionweight for trees is uint8, but for the others it's uint16?

7. What's parameter clusters for buildings?

Buildings: What are the differences between:
8. station_capacity & capacity?
9. station_maintenance & maintenance?
10. station_price & cost?
To me the ones with station_ are old values.

11. Why parameter cost for ground objects is sint32 when all the others are uint32?

12. Why all parameters for fields are int? Is it not a waste of resources? I mean, 255 for number of fields is already quite impossible. I guess it's unnecessary to expect anything bigger.

Leartin

Quote from: An_dz on March 01, 2016, 01:39:16 AM

7. What's parameter clusters for buildings?

Buildings: What are the differences between:
8. station_capacity & capacity?
9. station_maintenance & maintenance?
10. station_price & cost?
To me the ones with station_ are old values.

when a new citybuilding spawns on a tile next to other citybuildings, the clusters for those buildings will be looked up. of the available buildings to spawn, those which have the same clusters parameter get a boost in probability to spawn, the amount of which can be set in the simconf.tab
Sadly I still don't know if it's cumulative or not.

IIRC, the code for maintainence and co in stations was backported from experimental, where the station prefix was used. For compatibility reasons, both standard and experimental support both parameters.

Ters

This is mostly speculation, but some of this goes so far back that even those amongst us who once knew, might not remember. In some cases, no one might ever have known why.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
1. Why does the speed of citycars is multiplied by 16 to be saved on the pak?
Not that we need a citycar faster than 4095km/h, but it's just strange.
The only reason I can think of is to allow speeds lower than 1 km/h in the pak format.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
2. Why does the cost of signals does not take account the cents, but all the rest do?
Most likely because whoever wrote the signals didn't need cents at the moment and didn't think to check how other things did it.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
3. Why topspeed on bridges is uint16, but for tunnels, ways and way objects it's sint32? It does not even make sense to have negative speeds.
Integers are signed by default in C and C++. Compilers yell at you when you mix unsigned and signed. Since values are never going to be high enough that it matters, it might have been easier to use signed ints than unsigned ints.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
5. And why maintenance is uint16 for vehicles when for the others it's uint32?
Vehicles don't have maintenance, they have fixed_cost. They are not the same, were not made at the same time (maintenance is way older, I think), perhaps not by the same person, and perhaps without having the older one in mind when implementing the newer.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
6. Why distributionweight for trees is uint8, but for the others it's uint16?
Trees had distribution_weight long before at least some of the others even existed. It is possible that by the time the others came around, a larger range of values was seen as ideal, but not important enough to bother altering the existing format of trees.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
11. Why parameter cost for ground objects is sint32 when all the others are uint32?
Maybe some of them are so ugly that the local government will pay you to remove them? :P

Quote from: An_dz on March 01, 2016, 01:39:16 AM
12. Why all parameters for fields are int? Is it not a waste of resources? I mean, 255 for number of fields is already quite impossible. I guess it's unnecessary to expect anything bigger.
Memory is not really a constraint for besch-types (except images, where the limit trying to restrain memory usage was contested and defeated). However, I can't see any field fields that are plain ints. Some are uint16, but I don't think farms covering more than 16x16 tiles is too far-fetched.

Dwachs

Quote from: An_dz on March 01, 2016, 01:39:16 AM
1. Why does the speed of citycars is multiplied by 16 to be saved on the pak?
Not that we need a citycar faster than 4095km/h, but it's just strange.
The factor 16 is only in the pak file. The reader class rescales again. I guess historic reasons.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
2. Why does the cost of signals does not take account the cents, but all the rest do?
It is there since 88.03, changing it would break all existing dat-files silently.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
3. Why topspeed on bridges is uint16, but for tunnels, ways and way objects it's sint32? It does not even make sense to have negative speeds.
At some point, all speed related variables were decided to be sint32. Topspeed for bridges is uint16 in the pak file, but sint32 in the program.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
4. For vehicles there's a parameter called fixed_cost, when it's omitted then maintenance is used. I could not notice any differences on them from the code, is fixed_cost an old deprecated parameter?
It seems to me that the code related to 'maintenance' was accidentally committed. Please use fixed_cost.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
5. And why maintenance is uint16 for vehicles when for the others it's uint32?
The types were chosen by the person implementing it at that time. Inconsistencies build up over time.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
7. What's parameter clusters for buildings?

The parameter cluster is a list of integers with values from 1 to 32. It is composed into a 32bit bit-field.

If a city decides to build/renovate a building it checks the four neighbor tiles: the cluster bitfields of neighbor buildings
are collected (bitwise or). Then a house with suitable cluster has it chance multiplied with cluster_factor (from cityrules.tab).
If the house does not fit, then the chance is divided by cluster_factor. A house is suitable if at least one bit in the cluster-variable of the neighborhood is set for the house. Hope this makes sense.

Quote from: An_dz on March 01, 2016, 01:39:16 AM
Buildings: What are the differences between:
8. station_capacity & capacity?
9. station_maintenance & maintenance?
10. station_price & cost?
To me the ones with station_ are old values.
This was implemented after experimental implemented it. station_* are from experimental.
Parsley, sage, rosemary, and maggikraut.

prissi

I think 80% of you answers are historic reasons (or bluntly nobody [and especially not me  possibly for a lot of them] bothered).

Maintenance and fixed_cost have the same function for ways and vehicles (monthly reoccuring costs); hence I though of allowing the same name for them.

About smaller or larger field sizes: If you are bothered, one can fix it. But so far nobody complained. (On signal costs: I am not sure how many pak sets actually uses them, so braking compatiblity may be an option).

An_dz

Thanks everybody for the explanations.

The field sizes don't need to be changed, only when someone complains. I was just curious.

Only that multiplication for citycars that still bogus me, but that could be reverted with another useful change.

As for signals, I agree with breaking it, a pakset has just a few of them and adding two zeros is not that hard.

Vladki

As pak.cs signalling maintainer I agree with changing the signal costs. Especially if the change will make them 100x cheaper. It won't ruin the games/paks without fix. And the costs are not very well balanced anyway.

Edit: on second thought this should be coordinated with experimental to keep at least some compatibility of dat files.