Chill's patchpack v14_7

[ChillCore]

Code: Select all

   /* Pay something when the income is too low after devision by daylength.*/
   profit = profit / _date_daylength_factor;
   if (_date_daylength_factor > 1 && profit < 1) profit = 1;

Maybe I should add another Advanced setting to switch this behaviour on or off?

Is this switch added to version 13? 'Cause if so, I can't find it, and I love this patch so much, but the income makes it useless to play without higher income.

I have not (yet) included a switch for this as IMHO it does not feel right to undo the income devision by daylengh factor.
If a vehicle makes 1000$ a month at daylength factor 1 it will make 30000$ at daylength factor 30 for the same month, simply because it has time to do 60 trips instead of 2.
Many people already claim that making money is too easy and thanks to the code you quoted the vehicle income stays (roughly) 1000$ no matter what daylength factor you use. (See the rest of the discussion from where you quoted for the same explanation in more detail.)

If you insist I can add it without too much trouble, eventhough if I will not use it, but the game will become unbalanced bigtime and way too easy.

The (flashing with animation on) pink colour in the smallmap is a flood warning "feature" -> Level 0 ... may flood, be carefull where you build.

imho it's a bad feature. in trunk, there is a "colours for minimap" setting, maybe one should be able to select one with and one without "level 0" warning colour?

I could do that by means of a switch, I have alreay one extra colour in the extended (unfinished) arrays for this purpose.
So either I make a construction where it uses "colour + 1" if the switch is off, or I add 3 more arrays without the flood warning colour and add a few more if elses.
I'll have a looksie in a bit. It certainly is possible to do that.

A switch and a few if elses to display "colour" or "colour + 1" later ...
This now works in my debug build and will be ported to my normal folder to be included in the next version.
Additionally, if enabled the floodwarning will also show if the MoreHeightLevels patch is off (in the current version there is no floodwarning in the old arrays).

I might try to use three arrays instead of 6 in a later version -> use every 16th heightmap colour of the extended arrays if moreheightlevels is off and remove the old arrays ... but first some more bugfixing.



Edit:

New page, added quote.

... dashing shade of handsome pink.

Lol.
Thank you for mentioning the new needed GRFs in your post JGR.

[vanDyk101]

If you insist I can add it without too much trouble, eventhough if I will not use it, but the game will become unbalanced bigtime and way too easy.

Yes, please add it, and let people choose on there own if they switch it on or off. With the default offcourse on "off".

[oberhümer]

I'd say so too. I think the whole point of day lengthening is to allow the player to do more in the same amount of game years - otherwise, it adds almost nothing.

[ChillCore]

If you insist I can add it without too much trouble, eventhough if I will not use it, but the game will become unbalanced bigtime and way too easy.

Yes, please add it, and let people choose on there own if they switch it on or off. With the default offcourse on "off".

Default off was the plan.

I'd say so too. I think the whole point of day lengthening is to allow the player to do more in the same amount of game years - otherwise, it adds almost nothing.

IMHO the point of a daylength patch is to allow slow players, like myself, to have more time to tweak the network.
If you spend two years, without daylength factor, looking at the network, the stations and vehicle orders, the game will be over in no time and many vehicles will have passed the revue without you having had the chance to use them. Unless you enable the vehicles never expire option at the cost of having many, many vehicles in the lists. (Not a problem for me as one can not have enough vehicles available.)

However if vehicle income is not devided then you can turn a badly designed network that loses money in a profitable one by simply increasing the daylength factor.
I do not see the fun in that ...
Honestly, I can not imagine that any of the Devs will accept this to be included in trunk, in the event that "a" daylength patch makes it to trunk.

Ofcourse this is a patchpack with 0 chance of making it to trunk and I can do whatever I/you/we want. As I said before, I will not be using this -> switch.

On a sidenote but somewhat related,
I also do not play on maps that are 4k * 4k in size but I may play on a 4K * 64 map as the total size of that one is the same size as a 512 * 512 map.
I still have not seen a 4k * 4k map being finished and even romazoon decreased the size of the map in his current MP game because of performance issues with the previous game ...

[3iff]

For my first experience with a daylength modification (factor 10) I can make money no problem. I'm just playing as I would normally play.

It's a mistake to measure how much money you make in a trip as a factor of 10 essentially means you can make 10 trips in the time you could make one trip in a 'normal' time setting. In order to assess real profitablity, you must measure how much profit a vehicle makes in one full year. My current multiplayer game is showing that all companies are making acceptable profits.

I'm quite enjoying the extended time available with a long daylength as I have more time to look around and do things. The drawback is a lack of cashflow at the start of the game...thanks to a game year taking a few hours of play.

[rileyk]

Is there any chance anyone could post a Win32 binary, I notice the last binary posted was Win64. It would be very much appreciated

Thank you

[Yexo]

Which topic should this belong too?

[rileyk]

Sorry, I meant this to go into Chills Patchpack

[ChillCore]

Is there any chance anyone could post a Win32 binary, I notice the last binary posted was Win64. It would be very much appreciated

The x86 version on page 77 is a win32 binary.

[rileyk]

Thank you for your quick reply, I wasn't aware of that , Thank you again, very much appreciated, you do really great work for this forum

[ChillCore]

For my first experience with a daylength modification (factor 10) I can make money no problem. I'm just playing as I would normally play.

As (most) money/time related things are balanced you should be able to play as you normally would.
If you find something that is not yet balanced, feel free to say so.

It's a mistake to measure how much money you make in a trip as a factor of 10 essentially means you can make 10 trips in the time you could make one trip in a 'normal' time setting. In order to assess real profitablity, you must measure how much profit a vehicle makes in one full year. My current multiplayer game is showing that all companies are making acceptable profits.

Exactly my point but you explained it better with less words.

I'm quite enjoying the extended time available with a long daylength as I have more time to look around and do things. The drawback is a lack of cashflow at the start of the game...thanks to a game year taking a few hours of play.

Usually I start with passengers and mail (as they are a reliable source of income) using the cheapest track (NuTracks) and cheapest vehicles available.
Once I have a few vehicles running around I start looking around planning my next moves.
It also helps a bit if you keep your loan at a minimum and only take a loan when you need one, after which you pay it back as fast as you can.

Thank you for your quick reply, I wasn't aware of that , Thank you again, very much appreciated, you do really great work for this forum

My pleasure, I am getting a lot back also.


EDIT:

topic merged as requested

Thank you for the effort planetmaker.

[3iff]

Quote:
I'm quite enjoying the extended time available with a long daylength as I have more time to look around and do things. The drawback is a lack of cashflow at the start of the game...thanks to a game year taking a few hours of play.

Usually I start with passengers and mail (as they are a reliable source of income) using the cheapest track (NuTracks) and cheapest vehicles available.
Once I have a few vehicles running around I start looking around planning my next moves.
It also helps a bit if you keep your loan at a minimum and only take a loan when you need one, after which you pay it back as fast as you can.

Actually what I meant that is once my cash is spent then it takes a long time in real-time to get enough money to continue expanding. In a normal game I've enough in 10 minutes to build a second route. A longer daylength and I have to wait far longer as the cash just trickles in...

I continue to start with cheap vehicles and skimp on trackbuilding. Where I usually start with a 5*2 station I can build a 3*2 station and allow room for it to expand later. Early on I'm not going to be building long trains.

[oberhümer]

However if vehicle income is not devided then you can turn a badly designed network that loses money in a profitable one by simply increasing the daylength factor.

That's a fallacy: A longer day length increases the number of trips a vehicle makes, so if it loses money per trip with regular day length, it'll use even more with a longer day length. Day length multiplies the income, it doesn't add to it.

[ChillCore]

Actually what I meant that is once my cash is spent then it takes a long time in real-time to get enough money to continue expanding. In a normal game I've enough in 10 minutes to build a second route. A longer daylength and I have to wait far longer as the cash just trickles in...

There are two ways to bridge the "long waiting gaps" if you are just waiting for funds.

The first is Fast Forward.

The second is only semi-safe ... lower the daylength factor for a bit so times passes faster.
Important Note:
Put it back to its original value before you save your game and do not save manually during the same day that you have changed the value.
The reason to not save your game during the same day is that the date_fraction might be inconsistent, corrupting your savegame. You will not notice this happened untill you try to load that savegame.
Best is to first make a backup of your savegame, lower the value, use FF, put it back, wait a day or two, save and try to load that save immediately. If you can load it you can continue. If it fails load your backup and try again.
I have not yet noticed problems with autosaves but that does not mean that they can not corrupt too because of the day_fraction.

As the income is devided by daylength factor, I do not consider the above cheating but creative use of available tools.

However if vehicle income is not devided then you can turn a badly designed network that loses money in a profitable one by simply increasing the daylength factor.

That's a fallacy: A longer day length increases the number of trips a vehicle makes, so if it loses money per trip with regular day length, it'll use even more with a longer day length. Day length multiplies the income, it doesn't add to it.

I was talking about the network as a whole ... not just one vehicle. You are right that I should have written "barely makes money" instead of "loses money".
You'll see what I mean in the next version, when I will have added the switch for this ... so you can try for yourself.

Also how is multiplying not adding? As far as I know:
income * 3 == income + income + income.

[oberhümer]

I should have said that day length is multiplied with income, not somehow added to it. That was a quick post anyway; and it doesn't matter whether you are looking at the vehicles themselves or the whole "network", because they're what it consists of.

I do see what you mean, but I think dividing the interval for which income statistics are counted by day length makes more sense than dividing the actual income. Why? Consistency; if the distance in tiles and the transported cargo is the same, you ought to be paid the same.

[ChillCore]

if the distance in tiles and the transported cargo is the same, you ought to be paid the same.

But you are paid the same with current code and you will no longer when ignoring the daylength factor.

To see for yourself:
Start a new game and make a simple route A to B, let it run for a year with daylength factor 1 and check the income in the Company Finaces gui.
Next change the daylength factor and let it run for another year and check again ...

[oberhümer]

I meant for the trip.

[ChillCore]

I know We are talking in circles and we are back at the start.
You will have your switch ... most likely in the cheat menu ... and you will be able to do as you like, even if that means that your game will be unbalanced.



I am still looking at the start date issue and an update will follow soon,
If I can not fix it properly tonight I will revert part of the departureboards patch and post tomorrow, that will mean that the date will overflow faster again. But you will be able to set the start date again.
I can then take my time at fixing it properly for the version there after ... maybe I need to ask hthhs for help when his exams are over.

Further there will be:
- 2 new NewGRFs (speed signs and programmbale signals.)
- A newer version of the watch gui patch that muxy sent me. (no more compiler warnings).
- ON/OFF selectable floodwarning feature.
- I also fixed the wrong colour being displayed in one of the smallmap views (Industry view shows always green instead of based on the land colour selected when not showing the height levels)
- The other fixes already mentioned on the last few pages.

[Eddi]

- 2 new NewGRFs (speed signs and programmbale signals.)

technically, those are not "newgrfs"

maybe you should consider putting all those into openttd.grf (modify it in media/extra_grf, potentially needs changing NFORenum as well)

[ChillCore]

- 2 new NewGRFs (speed signs and programmbale signals.)

technically, those are not "newgrfs"

maybe you should consider putting all those into openttd.grf (modify it in media/extra_grf, potentially needs changing NFORenum as well)

Technically, they are not.
Maybe I could add all five of them to openttd.grf, but I have lots of questions before I can.

I am not sure about the procedure to follow to do it correctly.

- I put the png(s) and nfo(s) in media/extra_grf.
- I include the nfo(s) in openttd.nfo.

But then ...
- I need to figure out how to reference the correct spritenumbers of the new sprites in table/sprites.h. How do I find out what those numbers are? Are they added at the end of OPENTTD_SPRITE_COUNT or somewhere else?
- If sprites are added later to openttd.grf in trunk ... Do I need to adjust all my numbers?

NFORenum is not part of the source is it? I could not find it (yet).
What do I need to change? and why?


Edit:
Five needed GRfs not four ...