Chill's patchpack v14_7

[Eddi]

NFORenum is part of GRFCodec

you need to add new action 5 blocks. One section in src/newgrf.cpp around line 4800 (take r20370 (Airport previews) as an example), this should not change any of your sprite numbers, the sprites will be put at the places that you choose. And the other section in NFORenum to recognize these new action 5 blocks, take this patch as reference: http://devs.openttd.org/~planetmaker/pa ... ridswitch/ (grids_grfcodec.diff)

[ChillCore]

Thank you.
Having a looksie.

[oberhümer]

So why exactly doesn't it make sense to leave income per trip untouched and change the time period income is calculated for instead?

[Eddi]

what stops you from simply changing the base costs by use of an appropriate newgrf, if you really have too little income?

[oberhümer]

That's not accurate enough because it can only change them by powers of two.

[planetmaker]

- 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 ...

Well. Changing openttd.grf is not enough for 65% of the people - those who use OpenGFX for the reason that openttd.grf is part of the TTD base set only. Thus you'd need to (also) provide an updated OpenGFX or the game would complain about missing sprites; thus for a patch pack a (New)GRF approach is probably easier.

That said, I've a patch (queue) which implements a new action5, as well as the necessary patches to grfcodec, openttd.grf, OpenGFX.

[Eddi]

i seriously don't understand your problem. it's not like the original game balance is awfully accurate in the first place. and i see really no point in discussing whether you reach the "i earn more than i can spend" boundary after 20 minutes or 25 minutes of gameplay.

[ChillCore]

So why exactly doesn't it make sense to leave income per trip untouched and change the time period income is calculated for instead?

What exactly do you mean by "changing the time period income is calculated"?
How am I supposed do that and what would be the difference from the current situation?
Payment is done on delivery of the goods, not sooner not later (transfer fee is only an estimate).

If I do not touch the income per trip, how are things going to add up in the end of the year.?
Do you want me to let the vehicles make 9 trips for free and let it have a its normal fee the tenth trip so things add up at daylength factor 10?
What if you sell your vehicle after nine trips?

You want me to do some complicated stuff in multiple places instead of simply deviding the income at each trip made?
Your income will still be lower per trip at higher daylength factors. Just like it is now.

I know a vehicle cannot do 10 trips a month with daylength factor 1 as there is not enough time but below is just an example.
If a vehicle can do 10 trips/month a ratio of 100$ at daylength factor 1 then that makes 12000$ at the end of the year.
With daylength factor 10 you still want 100$ for the same trip displayed but the vehicle can do 100 trips/month which makes for 120000$ a year, right?
I can not justify displaying 100$ a trip and then at the end of the year say: "Sorry but the bank made a misstake, we'll have to deduct 108000$ from your account. Have a nice day and see you next year".


Forgive me but I simply do not know what you want me to do ... I should not touch the income per trip yet in the end you want to earn the same amount with every daylength factor.

* snip to avoid too many quotes *

Well. Changing openttd.grf is not enough for 65% of the people - those who use OpenGFX for the reason that openttd.grf is part of the TTD base set only. Thus you'd need to (also) provide an updated OpenGFX or the game would complain about missing sprites; thus for a patch pack a (New)GRF approach is probably easier.

That said, I've a patch (queue) which implements a new action5, as well as the necessary patches to grfcodec, openttd.grf, OpenGFX.

I sees said the blind man.
I will post my version with updated needed GRFs tomorrow then and continue reading for a bit ... I might still try to do it locally just for the fun of doing so and so I know how to do it correctly when I really need to do it [wishfull thinking]->one of the five patches needing GRFs making trunk [/wishfull thinking].
Thank you for the heads up and the links planetmaker.

[Muzzly]

"Sorry but the bank made a misstake, we'll have to deduct 108000$ from your account. Have a nice day and see you next year".

[Wasila]

I just got round to compiling v13 of your patchpack. Upon opening it I got the following message:

ini: trailing characters at end of setting 'gui.date_with_time'

The game appears to run as normal afterwards; I have not yet tested it properly.

[ChillCore]

The warning will also show when you exit the game.
Minor thingy that got fixed in the in the departureboards patch between the previous version and this version of the patchpack.

As mentioned near the patchfile and lower also on page 77 ...
Open your config file and delete the line that reads "date_with_time" in the gui section, it will be re-added later and the message will no longer appear.

[Wasila]

The warning will also show when you exit the game.
Minor thingy that got fixed in the in the departureboards patch between the previous version and this version of the patchpack.

As mentioned near the patchfile and lower also on page 77 ...
Open your config file and delete the line that reads "date_with_time" in the gui section, it will be re-added later and the message will no longer appear.

So the error message won't actually have any impact on gameplay? Otherwise it doesn't really matter to me (not as much as transfer unload orders ).

[ChillCore]

So the error message won't actually have any impact on gameplay? Otherwise it doesn't really matter to me

For as far as I am aware of no, besides that the message showing is annoying ...
Anyway the fix is easy and should take no more then 20 seconds before you fire up the game the next time.

(not as much as transfer unload orders ).

Fix, coming to a patchpack near you soon (TM) as promised.

Monday I am going to visit my future house again to do some cleaning and am going to make further arrangements for the exact date of me actually moving.
As there is a lot more then only CargoDist to be updated it might take a little while -> settings.h needs to be exported to the ini files but as that file is actually a new file now and the trunk lines and patch lines are not extractable from the patchfile (they are all patchlines so to speak) I need to go over the complete file line by line.
Also some other things need to be reverted to reflect current trunk.

All in all I think it will take me three/four days (unless I spend an entire day coding without stopping).
While updating I will not be able to compile ... so I need to focus to not make misstakes. After moving I have one less thing to worry about and distract me and will put myself to it.

When that is done I am going to focus on the MoreHeightLevels patch for a bit, rewriting the splitting of the patch in a hopefully more acceptable way for trunk. -> does not mean it will be included right away as some things may still need to be changed.

[Eddi]

merging settings.h into settings.ini is actually not difficult at all

just take a diff from right before the commit, and add each changed line into settings.ini at the right place. then split up each line according to the templates at the beginning of the file. takes half an hour for the whole thing, tops.

[ChillCore]

I could do that and you are right it is not that hard. Make it 45 minutes because I can not type blind.

Then I still have to compare the diff from right after the change with the diff from now to add the changes I made since then.
After that I have to put back all the other ini files I removed and revert the other changes in the code for them to be used. (yes, I reverted that too)
At this point I can compile and test again.

Next step would be updating CargoDist to current version -> bugfixes (correct order handling), syntax changes and the linkgraph overlay ingame.

At that point the savegamecompatibility will be broken anyway, so I can remove all the savegame magic restoring current trunk savegamecompatibility and start again keeping it for a while.

Then I need to test if everything still works as expected and that will take time too, unless I release and let the players find possible errors I made ...

All of the above adds up. Not that I mind, I knew that it would come to this point one day.

[hthhs]

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.

My exams finished on Thursday, so I'll take a look at the current version of the patchpack this weekend and see if I can work out what's broken.

[Wasila]

All in all I think it will take me three/four days (unless I spend an entire day coding without stopping).
While updating I will not be able to compile ... so I need to focus to not make misstakes. After moving I have one less thing to worry about and distract me and will put myself to it.

Sounds good. I guess I'll hold out on starting a new game until next weekend if you're breaking savegame compatibility .

[Kogut]

"Sorry but the bank made a misstake, we'll have to deduct 108000$ from your account. Have a nice day and see you next year".

It happens: http://www.goodthink.com/writing/view_s ... &page_id=2 (sorry for offtopic)

[ChillCore]

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.

My exams finished on Thursday, so I'll take a look at the current version of the patchpack this weekend and see if I can work out what's broken.

That would be great, thank you in advance.

When comparing v16 and v17 of your patch, I only have to revert DateTicks back to Date and Ticks and it works again.
I guess there is something in the patchpack that needs changing because when I tried your patch alone I could still set the startdate ...

All in all I think it will take me three/four days (unless I spend an entire day coding without stopping).
While updating I will not be able to compile ... so I need to focus to not make misstakes. After moving I have one less thing to worry about and distract me and will put myself to it.

Sounds good. I guess I'll hold out on starting a new game until next weekend if you're breaking savegame compatibility .

I do not think that I will have finished moving by next weekend ... most likely the weekend after, it depends what I will find on monday and what the owners already did. (In any case, If you want me to say a date, the house I am in right now has to be vacant by the 1st as the whole block has been sold and will be renovated.)
In the meantime, you may want to try a (smaller) game without setting loading and unloading orders and appreciate what cargoDist is really about?

"Sorry but the bank made a misstake, we'll have to deduct 108000$ from your account. Have a nice day and see you next year".

It happens: http://www.goodthink.com/writing/view_s ... &page_id=2 (sorry for offtopic)

Yeah sometimes the bank makes misstakes.

In the patchpack however the income will be devided or it will not and you get to keep it.
Just to make sure that not deviding income is an option some of you really want ... see attachment.

I added the button to the cheat menu in my debug build.
The only thing I did to produce the picture was increase and lower the daylength factor and hit Fast Forward without actually doing anything else ... Note that I was still playing in 2371 and if I had not spent 20.000.000 my profit would have been +-13.000.000 but you get the idea ...

[Wasila]

I do not think that I will have finished moving by next weekend ... most likely the weekend after, it depends what I will find on monday and what the owners already did. (In any case, If you want me to say a date, the house I am in right now has to be vacant by the 1st as the whole block has been sold and will be renovated.)
In the meantime, you may want to try a (smaller) game without setting loading and unloading orders and appreciate what cargoDist is really about?

Oh, I thought you had already finished moving - my bad. Yeah; I had never really used that setting much before my last game and I don't mind that much if it's not working - besides, I want to focus more on industry anyway (trying out FIRS!). Thanks .