Chill's patchpack v14_7

[Kogut]

What is your daylenght setting?

1

[Hamilton2007]

Is this patch compatible with 32bit tars? Cause i added the tars to the data folder, changed the openttd.cfg, but only the tools are changed, no graphics or so???

It works for me.
Depending on which tars you are using you may need to change your setting to the original graphics and or download and activate the extra "32bppExtra NewGRF" available from ingame download content.
If you need further help, I will need to know from where you got the tars.

I tried those two things but nothing changed. I got the tars from http://www.tt-forums.net/viewtopic.php?f=36&t=46682 and some that are available on the wiki pages..

If i activate the 32bppExtra NewGRF the land is very strange..

[Muzzly]

Here I am again proudly presenting another bug

Message:
Assertion failed at line 39 of c:\openttd_folder_kompilacyjny\chillpathcpack\src\rail_map.h: IsTileType(t, MP_RAILWAY)

Occurs on removing signals with CTRL key pressed. See crash.png image.

[ChillCore]

I got the tars from viewtopic.php?f=36&t=46682 and some that are available on the wiki pages..
If i activate the 32bppExtra NewGRF the land is very strange..

I'll get back to you on that. Rapidshare is not as rapid as its name suggests.
Those glitches look like missing sprites.
Will test some more when my download is complete.

Here I am again proudly presenting another bug

It seems like dragging while removing signals is broken in your savegame. I can repoduce.
Removing signals without dragging seems to work just fine.
If I try the same in a newgame it works fine. Tested with the same win binary as yours.

While typing and looking at your crash.png again I noticed you have signals on bridges on the same stretch of track you tried deleting the signals from.
Dragging to place/remove signals stops at junctions and a bridge/tunnel is not a junction. Could it be ... ?
I will test some more in a bit in my debug build.

Edit:
Muzzy, if you remove a piece of rail in front of the bridge and then drag to remove the signals it will not crash.
Not yet fixed but I do know now where to search for the error.

[Kogut]

FIRS glitch happening only in Chill's patchpack.
No problem in r20246 or stable.
http://www.tt-forums.net/viewtopic.php?p=893318#p893318

[ChillCore]

I got the tars from viewtopic.php?f=36&t=46682

After a very long download (4.5 hours or something like that) I have had at looksie in that graphics pack and almost all graphics in there are for the extra zoom patch. It is normal that they will not show up.
You may want to look for a graphics set that has 32bpp graphics for the normal zoom levels.

To help you in your search for the correct sprites:
- If the graphics in the tar are named 1234.png -> normal zoom
- If the graphics are named 1234_z0.png or 134_z1.png -> extra zoom and will not show in an OpenTTD version (patched or not) without extra zoom patch.

The ones you got from the wiki are most likely the ones that do show up (eg. Your toolbar in the previous posted screenshot has the 32bpp graphics.)

FIRS glitch happening only in Chill's patchpack.
No problem in r20246 or stable.
viewtopic.php?p=893318#p893318

Thank you for reporting.
You may blame that one on the moreheightlevels patch. I have adjusted the logfile on my computer.



Also allow me to mention again the importance of not reporting bugs outside this thread unless you can reproduce it with clean trunk or only one patch applied.
There are a few ways bugs can be included in the patchpack.

- I have made a mistake while merging a patch in my patchpack.
- An included patch is not completely finished or still has a bug.
- There is a bug in trunk.
- There is a bug in a grf that is being used.
- ...

For example I suspect the bug while using CTRL+drag to remove signals from track in combination with bridges to come from the signals in tunnels and on bridges patch, however I will not report it there until I have tested with only that patch applied.
People do what they do, be it be writing patches, creating graphics or composing music, in their free time and searching for non-existant bugs is never fun and a waste of time ...

[Hamilton2007]

Than for the effort Chil!! Will look in to it..

[Hamilton2007]

Damn, still not getting it to work, only toolbar works, strange..

[ChillCore]

Maybe you did not search hard enough ...

Brickland has some nice tiles to replace the Toyland ones and a few more sprites (Originals.)
If you want them to replace the OpenGFX sprites you can do as described here:
http://www.tt-forums.net/viewtopic.php? ... start=3020
The discussion leading up to my post there started on the previous page ...

I know it can be quite confusing with 32bpp normal zoom sprites and 32bpp extra zoom sprites, patch and no patch ...
I know there is a thread somewhere with 32bpp normal zoom graphics but I can not find it for the moment.

[Dante123]

because of the daylength, a tree growth reduction / remover patch would be nice to add
great patchpack!

[Scautura]

Here I am again proudly presenting another bug

Message:
Assertion failed at line 39 of c:\openttd_folder_kompilacyjny\chillpathcpack\src\rail_map.h: IsTileType(t, MP_RAILWAY)

Occurs on removing signals with CTRL key pressed. See crash.png image.

I can confirm this bug - but I can also give some more details.

For me it originally occurred when removing signals with CTRL pressed, along a line that contained a tunnel that had signals attached. I had a prior saved game, so I went back and tried again with a removed piece of rail in front of it when fixed. So I tried removing the signals from the tunnel first, and got the same crash. Removing the tunnel completely (exploded), recreating the tunnel, then doing the line with the CTRL+remove works fine.

It looks like it gets stuck on the "signals in tunnels and on bridges" patch.

[ChillCore]

because of the daylength, a tree growth reduction / remover patch would be nice to add
great patchpack!

Can do. Will be in v9.
Thank you for your kind words.

Here I am again proudly presenting another bug

Message:
Assertion failed at line 39 of c:\openttd_folder_kompilacyjny\chillpathcpack\src\rail_map.h: IsTileType(t, MP_RAILWAY)

Occurs on removing signals with CTRL key pressed. See crash.png image.

I can confirm this bug - but I can also give some more details.

For me it originally occurred when removing signals with CTRL pressed, along a line that contained a tunnel that had signals attached. I had a prior saved game, so I went back and tried again with a removed piece of rail in front of it when fixed. So I tried removing the signals from the tunnel first, and got the same crash. Removing the tunnel completely (exploded), recreating the tunnel, then doing the line with the CTRL+remove works fine.

It looks like it gets stuck on the "signals in tunnels and on bridges" patch.

Cool that confirms it being the Signals on bridges and in tunnel patch.
I had not yet tested further as I was busy updating the patch to trunk.
I will report in a bit. (Still have to test with that patch alone as it is merged with the programmable signals patch.)
I think the problem is that bridges and tunnels are not really there so to speak, they are wormholes ...

Thank you for the report.


I will release v9 ,hopefully later today, and skip v8.5 because of to many changes and broken savegame compatibility with the previous version due to a few new patches.
I have to write a switch because of a trunk revert I have done and adjust some more things here (check if I correctly bumped to trunk).
More info will follow with the release ...

[thetzar]

Hey, I just wanted to take a minute to say thanks for all the work you're doing on this patchpack. It makes my day every time I see it.



I'm also going to take a moment to ask if anyone else is seeing performance hits either with this pack or recent trunks? My last serious games were played with r16883 (my own assemblage of cargodest+signalbridges). Chill Patchpack v8 seems to be quite a bit slower than that, even fairly early in the games. I think I've tracked the behavior back to Cargodest's linkgraph recompile. Anyone have a good way to keep that functionality without killing things? This is OSX/Mac Pro, btw.

Speaking of which, as a complete aside: As someone sitting on top of eight cores, I really wish OTTD would use more than one.

[Dante123]

something here i dont understand. (not sure what patch makes this happen, therefore i post here)

-

Q02.PNG (170.38 KiB) Viewed 2953 times

-
when you look at the screenshot, you see that the train that just dropped off goods has not a "income E..." but it says "Cost: E108,634"
now, the train dropped off a full load of cargo.. so why does this train make losses because of this ?

anyone can help me out on this one ?

[Vitus]

Are there any transfers before the cargo gets to its final destination? If so, please check this link to see what causes it and how to solve it.

Edit: Silly me, there's Cargodist included in this patchpack. I don't know how Cargodist handles this, but if I remember correctly, it was discussed somewhere in Cargodist thread.

[Dante123]

nope, no transfers.
mm i will check that cargodist tomorrow and see what is wrong. or maybe its a bug ?

[keoz]

Are there any transfers before the cargo gets to its final destination? If so, please check this link to see what causes it and how to solve it.

Edit: Silly me, there's Cargodist included in this patchpack. I don't know how Cargodist handles this, but if I remember correctly, it was discussed somewhere in Cargodist thread.

It just handles it like standard OTTD, that means that when a packet is send across different vehicles, with transferts, the last one generally loses cash. That's perfectly normal. But there is a setting now, which allow to only pay a part of the iincome to the first vehicles.

[keoz]

nope, no transfers.
mm i will check that cargodist tomorrow and see what is wrong. or maybe its a bug ?

Take care, if are using cargodist and you don't know how it works, chances are that transfers happens and you didn't see them.

[Vitus]

nope, no transfers.
mm i will check that cargodist tomorrow and see what is wrong. or maybe its a bug ?

I just checked with some recent win32 build found in Cargodist thread and yes, it happens even without explicitly setting orders to transfer. That also means, that the wiki link I provided should help you deal with this.

Also what keoz said.

[ChillCore]

I'm also going to take a moment to ask if anyone else is seeing performance hits either with this pack or recent trunks? My last serious games were played with r16883 (my own assemblage of cargodest+signalbridges). Chill Patchpack v8 seems to be quite a bit slower than that, even fairly early in the games. I think I've tracked the behavior back to Cargodest's linkgraph recompile. Anyone have a good way to keep that functionality without killing things? This is OSX/Mac Pro, btw.

There are two settings in Advanced Settings->Linkgraph that you may adjust to speedup the recalculation to test if Cargodist linkgraphs is what is causing the slowdowns.
- Link graph recalculation interval
- Accuracy when calculating things on the link graph.

Also the more patches that get added the slower the game will become ...

Thank you for the kind words again.

Speaking of which, as a complete aside: As someone sitting on top of eight cores, I really wish OTTD would use more than one.

OpenTTD already uses two cores while saving if available.
For the rest of the game ... not everybody has multiple cores and backward compatibility with older systems is one of the things I like about OpenTTD.
I started playing it on a pII 233mhz overclocked to 266mhz, 128MB, and a voodoo3 and win98.
I only bought a P4 to be able to compile myself as until then I was more then happy with my old machine.
I would hate to see the single core (older machines) support disappear.
I still have my old baby and she is still going strong



About the transfer orders ...
Cargodist uses tranfers by default. How else would it work?
Best is to not give any orders except telling where vehicles have to go. Corgodist will do the rest.
So yes, the solution to Dante123's problem is at the bottom of that page as Vitus mentioned.



I think I am pretty much ready with v9 but as Devs are on a submitting frenzy, 70+ in only 2 days, I would prefer to wait a bit longer before I post the next version and take some more time reviewing the code.
Yay for the Devs, OpenTTD is getting better and better and better and ...