News:

Want to praise Simutrans?
Your feedback is important for us ;D.

[r6656] Capacity of station is not correct

Started by z9999+, August 26, 2013, 10:17:49 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

z9999+

Station capacity is still hardcoded in haltestelle_t::add_to_station_typ.


if(besch) {
// enabled the matching types
enables |= besch->get_enabled();
if (welt->get_settings().is_separate_halt_capacities()) {
if(besch->get_enabled()&1) {
capacity[0] += besch->get_level()*32;
}
if(besch->get_enabled()&2) {
capacity[1] += besch->get_level()*32;
}
if(besch->get_enabled()&4) {
capacity[2] += besch->get_level()*32;
}
}
else {
// no sperate capacities: sum up all
capacity[0] += besch->get_level()*32;
capacity[2] = capacity[1] = capacity[0];
}
}


Additionally, cost of removal station and cost of upgrade station may still refer to building level.

kierongreen

Will look into capacity later. Removal cost has always been fixed not dependent on level let alone price/capacity.

z9999+

BTW, do you think station level is still meaningfull ?

Currently, tool menu order is sorted by level. (See compare_station_besch())
Additionary, upgrade/downgrade station is depend on level. (See wkz_station_aux())

But now, capacity is not related to level.
Should these level above replaced by capacity, or should not ?
How should pak developers treat station level ?

prissi

I think this code still is another construction area due to an "aparently easy patch". Thank you very much fpr spotting this out.

Ters

Upgrade/downgrade had capacity in mind when it was implemented, so that one should use capacity. For arrangement in toolbar, I would prefer something that kept related buildings together. Internal names is an easy and flexible way to do this, but requires that all pak sets adapt, and that is not a small thing to ask for.

Fabio

there could be a few sorting options, selectable via menuconf.tab

prissi