Transport Tycoon Forums

Don't need a branch for that. Users can do that on their own.
It won't be the first time and it will not be the last one either.

Agreed, this is not necessary as such.

But if anyone who understands the OpenTTD code fancies it, it would still be quite useful to create some sort of program that brings all the economical variables (including things like daylength) into a few menus that are easy to understand and use.

It would be a bit like various editing programs that I remember, such as the one for Civilisation 3, or the third party editors for Grand Prix 3.

With something like this the project could possibly follow in the footsteps of NoAI, which created a new easier way of writing and sharing AI's. Lots of people are now on board for that project.

Just putting the idea out there if anyone thinks it is worth their time.

Airplanes definitely need their running costs highly increased. In real life the airline industry was in real trouble when the gas prices rose in 2006-07. It certainly is not a way to make easy millions like it is in TTD. They also should also be much more expensive to build, currently they are about as expensive as the train engines, which doesn't make sense.

Train stations should also be more expensive, a lot more. It's odd that a set of metal rails costs close to as much as a platform with a house. The size of the platform should also determine how much cargo can be held in it, maybe 100 per tile?

All interesting ideas ervin, unfortunately there's no real way to test them for actualy playability now without recompiling the code. Hence my suggestion (and yoyo1505 too), that someone create a build where these things are all easily accessable to the player.

Hi All,

I've been reading this thread for a while and recently found suggestion from yoyo1505 and Moriarty interesting. Instead of deciding what should be the ideal economy model ourselves, why don't we make the modeling logic easily accessible to all users and let them experiment, so that rest of the users can choose the features that really rock by experience in action?

My suggestion is to make 4 patches in sequence and finally achieve the first initial economy balancing goal.

1st patch
Instead of having a global "Transport Fee vs Transport Days" curve (for each type of cargo), why don't we have each curve for each demand unit (e.g. Factory which demanding cargo from elsewhere like farm). 01.png, 02.png.

2nd patch
Now add some simplied ratio variable (the "m" in 03.png) to control grow and sink of the Transport Fee. This simulate the "Demand level" of the demand unit.


(to be continue ...)

Continues my last post ..



3rd patch



The "m" can be adjusted by some logic (this is the main point of this patch, but not the ultimate goal of my suggestions). For example, if a city keeps receiving millions of passengers every weeks, then it is likely that this city's demand level on passengers is going to decrease (I guess so, but again, this behavior is not the main point of my suggestion. The main point is that it can change seperately for each city). So the economy model logic makes "m" to decrease as well. So finally, Airplane is not always money maker in the long run.
Another example of adjusting "m" is by the demand level of demand unit of that demand unit (... okok, pls read on the eample). In 04.png, the output of the upper factory has more demand level by Bigger city, so its "m" increases.

4th patch
Externalize the logic that drives the changes of "m" for each demand unit, in a form like the NoAI framework (see 05.png). In this way, idea of experimenting many good ideas in this thread can be easily brought into life. And users can pick the nice one by trying them out instead of discussing on paper/concept.

After some modelings have been kicked started, there will be force to drive more features in the OpenTTD core to expose more variables and extend variaty of variable calculation in the future.



This is my idea. Please comment.

Couldn't that all be done in one patch? I'm assuming the actual Calculate_Actual_Payment function is a small affair and could be easily changed with an If statement that would allow folks to chose which particular payment method they want to use using the current patch-selection screen. I should probably attempt to look at the code at some point.

Anyone ever edit the original command and conquer red alert, it had a really cool ini file that allowed you to change the balance of the game, maybe something like that could happen here?

Neuralize wrote:Anyone ever edit the original command and conquer red alert, it had a really cool ini file that allowed you to change the balance of the game, maybe something like that could happen here?

Some values can be edited through GRF files. Including costs of stuff. It can even do some deeper modifications of how game economy works (see George's ECS Vectors).

CommanderZ wrote:Some values can be edited through GRF files. Including costs of stuff. It can even do some deeper modifications of how game economy works (see George's ECS Vectors).

The problem with GRF's is the obscene learning curves. The reasoning behind the easy-edit .ini files was that anyone could dabble with them.

Moriarty wrote:

CommanderZ wrote:Some values can be edited through GRF files. Including costs of stuff. It can even do some deeper modifications of how game economy works (see George's ECS Vectors).

The problem with GRF's is the obscene learning curves. The reasoning behind the easy-edit .ini files was that anyone could dabble with them.

You aren't able to create the same amount of complexity in ini files AFAIK.

text files, ini files, xml files, whatever files...

the arguments have been brought up a million times... it is useless to discuss this all over again

XeryusTC wrote:You aren't able to create the same amount of complexity in ini files AFAIK.

Here. Let me remove that "AFAIK" for you:
You aren't able to create the same amount of complexity in ini files.

Moriarty wrote: The problem with GRF's is the obscene learning curves. The reasoning behind the easy-edit .ini files was that anyone could dabble with them.

And the reasoning behind things other than ini files is that you can't do much with ini files.

<Pedantic>Are the NoAI's not plaintext? Seem pretty complex to me.</pedantic>

But no, I wasn't asking nor suggesting dumping the entire economy into an ini file - that'd be silly. Just externalise some variables and some hackish "multipliers". I.e. you could end up with something like this:
That's the entirety of my suggestion. No fancy "bits" (bad pun ) needed. It wouldn't be in the trunk, just a dev-build like cargo-dest for instance.

such a file already exists. it is called "openttd.cfg"

Moriarty wrote:<Pedantic>Are the NoAI's not plaintext? Seem pretty complex to me.</pedantic>

plaintext != ini

INI files are a very specific subset of plain text files. And yes, we know that plain text can be complicated and powerful, almost every programming language in existence uses plain text for its source code. So yes, the NoAIs are plain text. No the NoAIs are not INI files.

Eddi wrote:such a file already exists. it is called "openttd.cfg"

I know. But the variables aren't in there which is why they're being requested.

Some of those variables are been accessed, requested, manipulated, expected by newgrfs.
So if they are made "public", it will certainly change a lot. Some grf authors would yell an awful lot. And between you and me, they have a much stronger voice then a regular player, since they do supply a good amount of work in their art. Therefor, a much bigger veto. If you see what I mean.

Another factor to consider: some of these values, been changed locally on your system, but not on other systems, will make it so that the similarities we are expecting between each player's environment in multiplayer games will be broken. And that will lead to desyncs. Do you want that?

So all in all, the best way to go, the cleanest for everyone, is to go the newgrf way.

belugas - All makes sense, except I was asking for this within a testing branch, not within the official trunk, that'd be silly (as you so eloquently said ).
Then folks who had an interest in trying to figure out a balanced economy could use that testing branch. Heck, it wouldn't really need to be a branch, just a patched, pre-compiled release.
On the matter of desyncs, whilst not particularly relevent given I'm not suggesting it for a "proper" release, surely the game ensures the config settings are the same at present - i.e., pathfinding settings.