Feature: Add cost multiplier to affect Expenditure types

[ltsSmitty]

I've seen various requests to be able to scale pricing up or down, such as making ride building costs 50% more expensive, or landscaping costs 25% cheaper. This could be used to increase difficulty, or to create a new kind of game mode (e.g., a roguelike that influences costs every few minutes to change complexity, etc.)

This PR goes about it by adding a new cost multiplier expenditure table vs the % to multiply.

/**
* Sets wages to be 50% of their standard value. E.g.handymen are now $25 per month.
**/
gameState.CostMultiplierExpenditureTable[EnumValue(ExpenditureType::Wages)] = 50;

A helper function is introduced to interface between the original hardcoded cost and the new cost to be calculated, money64 FinanceGetModifiedCost(money64 cost, ExpenditureType type).

There are very few places in the codebase where the financial transaction actually occurs, so implementing there was straightforward. The remaining changes are on various UI elements, ensuring that the price shown aligns with the new charge.

This build has a 50% markdown on all costs, implemented in FinanceInit().

Since this touches so many pieces of code, I'm going to pause here and wait for feedback. Hopefully this can open the door to future fun!

[Sadret]

Where would you set the cost modifier in the UI? Will it only work together with a plugin? If yes, I do not think this is the right way to go. Afaik we have not yet introduced any game mechanics that are only accessible by plugins.

My suggestion would be to solve this by a cost expenditure hook where you can modify the costs, similar how it is done with game actions.

[Sadret]

My suggestion would be to solve this by a cost expenditure hook where you can modify the costs, similar how it is done with game actions.

See implementation of action.execute or #21521 for a working example.

[Basssiiie]

I agree with Sadret. I think the implementation can be simplified by implementing the strategy of #21521 also for game actions (probably both query and execute). It gives plugins even more control over the cost and should affect less of the internal code base. 🙂