News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Station costs variable over time

Started by The Hood, August 01, 2013, 07:19:41 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

The Hood

I'm just trying to balance the earliest part of the pak128.Britain timeline with very low speeds and while I can get the operation and track costs to balance fine the station costs are fixed in the game (72 per month per tile minimum!) and this dwarfs any profit the low capacity, low speed early vehicles can make. Could we have a sliding scale of station cost over time set something similar to speedbonus so the station costs can be brought in proportion?

Ters

I imagine that a particular style of station costs the same independent of time in a world without inflation (like Simutrans), so something like the speed bonus sounds wrong to me. Early on, you should have cheap, low capacity stations and later on more costly, high capacity stations, which are distinct objects. Have you tried adjusting the factors between level and costs?

The Hood

Is there a way to change the factors between level and cost? I thought it was hard coded?

kierongreen

Doesn't experimental have station costs that can be set in pak files? I'd rather go that way myself.

The Hood

It does - after I raised this a few years back it for the same problem. It never made it to standard though.

kierongreen

Well if there's no objections from other devs I'll add it from experimental then. My view is that it's better to do that than reinvent wheel with another system for standard.

Ters

It could be nice to just get rid of the level altogether and set capacity directly, if level would no longer be the link between capacity and cost. For now, I suggest The Hood take a look at cost_multiply_... and I assume maintenance_building (this is also multiplied by level for every tile).

prissi

Indeed, in order to make this porperly, we need maintenace, price and level (or capacity). The latter will be converted to the former upon loading of old object only. You need to step up makeobj number anyway.

Max-Max

Well I'm all for configurable params ;) I Was actually wondering myself why the station capacity and cost where all the same in the pak sets :P
- My code doesn't have bugs. It develops random features...

kierongreen

Right - here's an alpha patch. It's heavily inspired by experimental code (so much so that I've attributed the various functions to JamesPetts :) ). Formatting should have all been converted to standard though, and I've tidied a few things up as well (such as giving the magic number a define). Steps up building besch from 7 to 8 so for testing you'll need to compile new makeobj as well as sim.

prissi

The double height code needs a new makeobj for dirges anyway ...

On this patch: Simuconf.tab is fully parsed before loading a pakset (otherwise it would not know where to load it from, and left-/right and other stuff). Hence the price and maintenance could be updated in the building reader for all buildings with level!=0 and price==0 or maintenace==0. This would spare us a lot of useless if later in the code and improve readability.

Therefore those fields shoudl be rather named capacity, price, maintenance (without station). This woudl result also in more finetuned maintenance of depots and headquarters.

kierongreen

Problem is even when a pakset is loaded some settings might come from games after this?

prissi

When a building is defined with a price it will anyway overide this setting. As this will only affect old buildings (and buidligns without a proper definition) I would rather have the cleaner code later. Very few savegames use this option anyway, old servers. One may need to define a new setting maintance_building_multiplier and building_price_multiplier with default 100 or so to have the same flexibility. That would also affect all buidlings again.

The Hood

Is it now possible to define station costs in dats then? Not sure where this is up to...

kierongreen

Not yet - don't worry though it's time will come just been busy with other areas of code :)

The Hood

That's OK. I'll pause work on balancing for now then and work on some graphics.

kierongreen

Ok - I've added to trunk in 6656. The following changes were made from patch above in line with suggestions from prissi:
Removed station_ from price, maintenance and capacity. While buildings other than stations don't use these yet there will certainly be scope to add this in future.

Parameters read from dats are "capacity", "cost" and "maintenance". building besch writer also checks for "station_capacity", "station_price" and "station_maintenance" to give compatibility with Experimental dats. Note especially the change from "station_price" to "cost" in dat files - this is to match vehicle and way dats.

Code cleaned by moving all calculations regarding cost and maintenance from level to haus_besch. Other parts of simutrans just use besch->get_price(welt), besch->get_maintenance(welt) or besch->get_capacity(welt) and don't need to worry about whether the besch has these defined in the dat or not.

See http://simutrans-germany.com/files/upload/6656-makeobj-win.zip for compiling stations.

jamespetts

New keywords added to the 11.x branch of Simutrans-Experimental for forwards compatibility - the next version of Makeobj for Simutrans-Experimental should work with "capacity", "cost" and "maintenance" in .dat files prepared for Standard.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

kierongreen

Great :) jamespetts - I don't know whether you want to look at the diff between 6655 and 6656 to see how I've implemented this in standard. I know you have code already in experimental but you might want to reduce the differences between experimental and standard (and hence the headache merging the two!).

VS

Great improvement! I had a number of ideas for pak128 to have very different densities for cargo and pax stations... Thank you!

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!

kierongreen

Ok will need to see if cargo and passenger capacities are stored separately in stations.

VS

Oh, no need for that - the way I envisioned it, cargo parts would (will) have low capacity and cost, allowing (forcing?) you to build more of them, while pax would be the other way round.

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!

Ters

Quote from: VS on August 20, 2013, 05:51:13 PM
Oh, no need for that - the way I envisioned it, cargo parts would (will) have low capacity and cost, allowing (forcing?) you to build more of them, while pax would be the other way round.

But if you could just build a few passenger parts, you wouldn't need to build lots of cargo parts to get high capacity. So allowing would work, but not forcing.

wlindley

It would be handy, and authentic, to have some large multi-story grand station buildings (presumably with waiting rooms and restaurants) and multi-story warehouses -- for crowded downtown stations.  These would have high construction cost, and high monthly costs to go along -- but would let you build good looking downtown stations in tight spaces.

jamespetts

Quote from: kierongreen on August 19, 2013, 12:12:31 AM
Great :) jamespetts - I don't know whether you want to look at the diff between 6655 and 6656 to see how I've implemented this in standard. I know you have code already in experimental but you might want to reduce the differences between experimental and standard (and hence the headache merging the two!).

Thank you for this. I have merged some of these changes into the passenger_generation branch on Github. I do not think it desirable to merge all the way in Experimental, as the existing system of setting the prices works better with Experimetal's system of scaling these things by meters per tile.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

waerth

Quote from: wlindley on August 20, 2013, 08:07:25 PM
It would be handy, and authentic, to have some large multi-story grand station buildings (presumably with waiting rooms and restaurants) and multi-story warehouses -- for crowded downtown stations.  These would have high construction cost, and high monthly costs to go along -- but would let you build good looking downtown stations in tight spaces.

Something like I have build here WLindley but then with seperate elements :p

http://forum.simutrans.com/index.php?topic=12487.0

kierongreen

No problem - I did simplify that bit out as it was not applicable in Standard :)