Currently, city buildings have "level", which determines amount of pax/mail, destruction price and other factors. Even player buildings have "level"; here it determines capacity, price and maintenance. These values can be manipulated by simuconf settings.
However, having shared multipliers for player buildings as they are now makes it impossible to balance a set so that eg. at once: bus stops are cheap, waiting halls expensive, rail platforms expensive, cargo extensions cheap.
Extending the simuconf multiplier system is almost impossible since the parameters are just too many (building type / waytype / cargo type). Thus: Is it possible to have capacity, price and maintenance per-besch for player's buildings? The simuconf adjustments would be likely deprecated by this, but is that a too big price?
edit: It seems that it is better explained as: I wish for capacity, price and maintenance to be set for each building in its dat file.
What is the meaning of per besch? I googled it with no success.
"besch" is short for German "Beschreibung": description. So, "desc" would be a very good translation :) .
It is used in the Simutrans source code quite often (and is one of the headbreakers for non-German coders, because you can't google it as you found out).
"per" is the same in German and English as far as I know.
Knowing that I must confess that VS proposal is still quite unclear to me! I am guessing that he wants capacity, price and maintenance costs different for each combination of building type, waytype and cargo type. That looks like a little nightmare to me...
And I thought it was just me who didn't understand what VS was saying...
Thanks Combuijs!
If what you said Combuijs is what VS is wanting, I think it might get to be one of those multiple arrays the C++ tutorial warned us about - a one liner that takes 3 gig of memory!
Actually just joking about the 3 gig but it does appear it would be a fairly large table or however it could be handled.
If it's unclear...
I want capacity, price and maintenance to be set for each building in its dat file.
Besches are "prototypes" of objects, you can say that object in pak = besch in running game.
Gotcha VS and thanks. Your idea sounds good to me. It looks like it would allow a lot of flexibility without upsetting the whole game.
as far as I'm aware, you can already do this under experimental, so there might already be code for it.
I do like the idea of paying less to expand capacity with station extensions instead of platforms.
Quote from: ӔO on October 09, 2012, 11:06:16 AM
I do like the idea of paying less to expand capacity with station extensions instead of platforms.
How expensive can a pair of concrete rectangles be? Even with a simple roof? The rails and overhead wires are not included, and you already own the ground. But decoupling price from capacity, if I understood it right, sounds like a good idea.
Honestly I would go (also with the current level system) for
PLATFORMS: cheap but with few or no capacity (e.g. level 1 to 4)
EXTENSIONS: high capacity, but expensive (level 8+)
One could add as many platforms as he likes, but the capacity won't change much.
Extensions would be needed, to add real capacity.
How should those the idea work im the undergrund?
That it for me a mystery.
Fabio: Perhaps so, perhaps not. It has to be possible first, though...
If this is added I would suggest just copying across the experimental code.
What fabio says is what was discussed before -don't remember the thread- when rebalancing this stuff; actually I asked for such an extension, but obviously I didn't thought about it as well as VS has done, neither I explained myself successfully.
+1 for this, no doubt (although +10 would be better!)
The change is not very difficult. What words does experimental used in the dat files? Running_const will not work for buildings ...
(And this will need a lot of time to propagate into pak sets, as all buildings need to be changed. Or the old system still keeps preference.)
pak128-britain-experimental
snippet from concrete-platform.dat
Obj=building
Name=ConcretePlatformBuildingTrainStop
copyright=Kieron
type=stop
waytype=track
enables_pax=1
noconstruction=1
intro_year=1960
Dims=1,1,16
NoInfo=1
Level=2
station_maintenance=3000
station_price=500000
station_capacity=31
and busstops.dat
Obj=building
Name=StagingPost
# must be 1*1
type=stop
waytype=road
intro_year=1700
intro_month=1
retire_year=1844
retire_month=4
noconstruction=1
enables_pax=1
enables_post=1
enables_ware=1
NoInfo=1
Dims=1,1,2
level=1
station_capacity=10
station_price=4000
station_maintenance=400
the latter is also interesting since it allows mail, pax, and freight.
i think it is a rather sensible change, experience with it in experimental was very good. It was required there to balanace more finely over two centuries. XIIX century infrastructure needs to be very cheap to be useable. (See the staging post)
Simple way to introduce it is to have the level setting being overriden iff those other values are set, else the default level is used. Pak-sets don't have to change everything, but could do so as needed.
@Fabio:
James already uses a system where pure platforms have zero capacity, only platforms with additional shelters have a bit of capacity. For large capacity station extension buildings are needed.
Quote...XIIX century...
It seems Simutrans Experimental is experimenting with Roman numbers as well ?! :o
In Simutrans Standard it would have been XVIII...
i looked somehow strange when i wrote it, i couldn't put my finger on it though :-)