Chill's patchpack v14_7

[bokkie]

I'm using ColdIce's build I'm on Win7 x64.
- OpenGFX
- settings: different settings don't matter (tried different settings for every option)
- reproduce: it happens every time I tried.

Could give screenshots but that won't give you more information, would it?

[ChillCore]

Could give screenshots but that won't give you more information, would it?

No they would not nor would savegames. I have edited my previous post while you was replying ...
Thanks again for reporting.

[ChillCore]

Sorry for the double post.

Found the problem.
Removing OpenGFX 2.2 and going back to v2.1 solves the problem.
I was reading the other day there was made an improvement to the mapgeneration graphics so I tried removing them first before going digging in the code.
I have not yet tested with a clean OTTD build but my "clean" More Heigt Levels build suffers the same problem when using v2.2.
Not much I can do except for going through the OpenGFX changelog on the Coopserver and trying to find out what the improvement is about.
I hope I can solve it ...

Edit:
After some testing ...
OpenGFX-nightly-r399 is the last one that loads without glitches.
From r402 the glitches apear.
The codeblock contains the changelog included with both. I suspect r400 & r401 to be the ones that "break" the moreheightlevels patch.
I have not fixed it yet but now I do know where to search.

Code: Select all

changeset:   402:e8eeec5ebf1f
tag:         tip
user:        Ammler <ammler@openttdcoop.org>
date:        Sat Mar 27 11:08:58 2010 +0100
summary:     Doc: update credits and blame list

changeset:   401:d457fa3c333b
user:        Ammler <ammler@openttdcoop.org>
date:        Sat Mar 27 10:20:06 2010 +0100
summary:     Feature [#869]: include gui icon for debug tools

changeset:   400:28d9710d143e
user:        Ammler <ammler@openttdcoop.org>
date:        Fri Mar 26 22:44:43 2010 +0100
summary:     Feature [#869]: gui icon for debug tools

changeset:   399:3d21b3586027
tag:         tip
user:        planetmaker <ottd@planetmaker.de>
date:        Thu Mar 25 17:13:02 2010 +0100
summary:     Doc: Update readme a bit

changeset:   398:39bc95ffc8b0
user:        planetmaker <ottd@planetmaker.de>
date:        Thu Mar 25 16:55:49 2010 +0100
summary:     Change: Make Debian and Fedora users happy (Rubidium)

changeset:   397:128315c6c280
user:        planetmaker <ottd@planetmaker.de>
date:        Thu Mar 25 16:39:00 2010 +0100
summary:     Fix: [Makefile] Don't build when calling clean and mrproper but clean more thoroughly (Rubidium)

changeset:   396:f27f00e31817
user:        planetmaker <ottd@planetmaker.de>
date:        Wed Mar 24 18:25:39 2010 +0100
summary:     Change: [Makefile] Update Makefile to r77

If you need to play without glitches but do want to have a somewhat recent OpenGFX version, "update" to r399 and move any later version you may have(r402, r405 and v2.2) to a directory where it is not seen by the patchpack or the clean More
Height Levels patch.
Clean trunk does not show these glitches.

I hope to have fixed version soon.

Edit2:
I have fixed in my build.
For the self compilers ...
Open table/sprites.h and change these two lines:

Code: Select all

-static const uint16 OPENTTD_SPRITE_COUNT = 172;
+static const uint16 OPENTTD_SPRITE_COUNT = 173;

...

-static const SpriteID SPR_FLAT_BLACKTILES               = SPR_OPENTTD_BASE + 153;
+static const SpriteID SPR_FLAT_BLACKTILES               = SPR_OPENTTD_BASE + 154;

For the binary providers, please wait to provide a new binary untill I am sure that my fix is the correct one. You will know when I will have posted a new diff.
For the binary downloaders, please "update" OpenGFX to r399 or earlier, as explained in edit 1, until a new binary is available.

[tsjook]

I can't wait to play a glitch-free version!

Thanks for all the hard work Chill!

[ChillCore]

I can't wait to play a glitch-free version!

Thanks for all the hard work Chill!

I do not consider doing something I like doing to be work, but I appreciate that you apreciate what I do.


Patch and zip replaced in the first post.

As reported using OpenGFX 2.2 caused glitches outside the map. This has been fixed now.
Also I have updated the chunnel patch to v12.

For people still playing previous versions, please read my previous post !

[tsjook]

Is there someone able to compile it for Win32? Would be awesome!

[2007Alain2007]

Hi

I just gave it a go and having A LOT of probles with liblzo2 tryed to install it and says its a viuse and also it dose not work so i am hoping some one esle who knows a bit more what there doing can make a win 32 build

and can we conpile with out liblzo2 if so i give it a go again tonight

if not liblzo2 is evil

[ChillCore]

Hi
I just gave it a go and having A LOT of probles with liblzo2 tryed to install it and says its a viuse and also it dose not work so i am hoping some one esle who knows a bit more what there doing can make a win 32 build
and can we conpile with out liblzo2 if so i give it a go again tonight
if not liblzo2 is evil

You may want to try and install liblzo2-dev instead.
You need the developers package.

What is a viuse?
I know I post my share of spelling errors but do take a little more time to re-read before hitting submit please.

Edit:
Where did you find the info to install liblzo2 ? More people have had this problem before and maybe the page needs some correcting.

Edit2:
Please wait for v4 to post a new binary.
I am updating cargodist and the station-build-gui and I might throw in a patch or two ...

[petert]

New binary as requested.

[ChillCore]

See second post for new patch and used_patches_zip.
Savegame compatibility with previous versions is broken.

Updated:
Cargodist to r19561. (demands_settings.h does no longer exist.)
Station build gui to v6.2_r19525

Added and changed:
Diesel smoke

- if ((v->vehstatus & VS_TRAIN_SLOWING) || (v->vehstatus & VS_STOPPED) || v->load_unload_time_rem != 0 || v->cur_speed < 2 ||
+ if ((v->vehstatus & VS_TRAIN_SLOWING) || (v->vehstatus & VS_STOPPED) || v->cur_speed < 2 ||

- tcache.cached_power
+ acc_cache.cached_power

- tcache.cached_weight
+ acc_cache.cached_weight

Added:
Stuck trains


Grass on tracks will not make it as I have added stuck trains, both use m7.
I have tried to include programmable signals but it fights with signals in tunnels. Maybe I will try again later.
Another patch I have tried is improved breakdowns but that needs a rewrite in some places before it will work properly. (I have the messages in the gui going but the trains do not slow down as they should.)

ps:
petert, I have reposted the patch for v2 as you seem to have removed it when you removed the binary.
Edit: Thank you for the link to the build output. I just noticed it now and I did not get those warnings. Very usefull.

[ChillCore]

Please find the updated patch and used patches zip in the second post.
Note: The used patches zip contains the original patches. You can not use them to recreate this patchpak.
(At least not without merging and retuning them yourself. The zip is provided for people wanting to know wich versions are included.)

Updated:
Cargodist updated to r19596.
More Height Levels to r19599.

Retuned:
More Height Levels: While generating a map, IND_LEVELLING_MAX_HEIGHT is limited to level 60 instead of level 20.
Signals in tunnels and bridges: Signal gap is 4 tiles instead of 6.



By request the patch attached to this post has the sprinkles part of this patch: http://www.tt-forums.net/viewtopic.php?f=33&t=46399.
variable-daylength_town-cargo_misc.patch against cargodist is the patch I have added to my patchpak.
Please note:

For daylength factors of 1, 2 and 3, the running costs behave correctly. However, with a daylength factor of 4 (DAY_TICKS = 296), the value of Vehicle::running_ticks will overflow, and thence running costs will be completely wrong.

Maybe the sprinkles part will be part of the next version maybe it will not.

[Scautura]

My turn!

I haven't played this yet, but I was sick of the last binary having issues with NuTracks (Steam engines being electrified in NARS2 - a bug that is fixed in this build, so I assume it was a trunk issue) so I built my own. As there hasn't been a post with a binary for this version (or a version since V4 came along), I figured I'd give it back to save others from doing their own.

This is built using MSYS/MinGW, so there's no crash info when you crash. Otherwise, enjoy.

[ChillCore]

My turn!

I haven't played this yet, but I was sick of the last binary having issues with NuTracks (Steam engines being electrified in NARS2) so I built my own. As there hasn't been a post with a binary for this version (or a version since V4 came along), I figured I'd give it back to save others from doing their own.

This is built using MSYS/MinGW, so there's no crash info when you crash. Otherwise, enjoy.

Thank you for the build Scautura. Many people will appreciate it.
I have updated the second post with a link to the latest available binary.
In the future feel free to post any issues you may have while you are having them.


In my own build I have changed "byte running_ticks;" into "int16 running_ticks;" in vehicle_base.h for testing.
The running costs seem to behave correctly with higher daylenght settings but I do not know if I have broken something else while doing so. That is why the posted patch does not include this change(yet).
I do however have discovered some inconsistencies in the dutch translation. Running costs is translated a few times differently. Once they are translated as "Operationele kosten" then as "(Vehicle)brandstofkosten" another time as "Gebruikskosten". In english.txt they remain "running costs" for all occasions.

[Freak_NL]

By request the patch attached to this post has the sprinkles part of this patch:[...].
variable-daylength_town-cargo_misc.patch against cargodist is the patch I have added to my patchpak.

Compiles and runs well so far. I'll take her for a spin tonight. Thanks for the effort.

[ChillCore]

Compiles and runs well so far. I'll take her for a spin tonight. Thanks for the effort.

Cool, let me know how it goes.


The next version will include an update for Cargodist.
I think that I will remove the signals in tunnels and on bridges for the moment and include the programmable signals patch instead.(Until I have solved the conflict between them). I have been toying around with it a bit yesterday and I enjoyed it very much.

With or without sprinkles? I have not yet tested it as much as I should. Has anybody experienced trouble with it?
Seeing some savegames would also be nice to to see how the patches included are used ... (Please also state the version used if you upload any.)

[Freak_NL]

Do the "sprinkles" have any influence on the rest of the patchpack and OpenTTD if you don't configure them in the option tree? Variable daylength and passenger/cargo generation work really well together if you lengthen the days and lower the passenger production.

[ChillCore]

Do the "sprinkles" have any influence on the rest of the patchpack and OpenTTD if you don't configure them in the option tree? Variable daylength and passenger/cargo generation work really well together if you lengthen the days and lower the passenger production.

I assume that when disabled there is no influence.
I liked to reduce passengers too when I was playing with Cargodest and advanced timetables before there was cargodist.

For daylength factors of 1, 2 and 3, the running costs behave correctly. However, with a daylength factor of 4 (DAY_TICKS = 296), the value of Vehicle::running_ticks will overflow, and thence running costs will be completely wrong.

In my own build I have changed "byte running_ticks;" into "int16 running_ticks;" in vehicle_base.h for testing.
The running costs seem to behave correctly with higher daylenght settings but I do not know if I have broken something else while doing so. That is why the posted patch does not include this change(yet).

I do not know what else may be broken(yet) with higher day lenght settings.

Also the difficulty setting for easy has been altered. you may want to have a looksie in settings.cpp around line 860.
For testing what may be broken you must play with the medium or hard difficulty setting.

[Cadde]

FINALLY, i compiled Chipp 4.2 and Programmable Signals as an extension to this already awesome package.

I spent a long time getting this to compile and it all boiled down to a few fixes in the end...
Here are the steps taken to make this build:

1. Applied Chipp 4.2 patch to trunk (r19639), created new SVN'ified diff.
2. Applied Programmable Signals to trunk (r19639), created new SVN'ified diff.
3. Made a clean copy of trunk (r19639) and applied Chipp 4.2.
4. Applied Programmable Signals.
5. Fixed any conflicts that occurred.
6. Had to manually edit signal.cpp
   1. Change any old style "flags" to "info.flags" under ExploreSegment()
   2. Fire up the file in notepad++ and fix missing curlybrace and indenting. (Still don't know why this happened after applying patch and only did so recently.)
   3. Split

      Code: Select all

      					DiagDirection dir = GetTunnelBridgeDirection(tile);

      into

      Code: Select all

      					DiagDirection dir;
      					dir = GetTunnelBridgeDirection(tile);

      Or the compiler would error with "Compiler Error C2361 : initialization of 'dir' is skipped by 'default' label"
7. Compile you !¤%# and it did indeed compile.

For those interested in the .patch and a Win32 Binary...

Chill's PatchPack 4.2 & Programmable Signals. (.patch | Binary)

Enjoy!

[ChillCore]

And version 5 is out.
Please find the updated patch and used patches zip in the second post.

Added and changed:
Sprinkles: variable daylenght, town cargo factor, more autosave options, longer vehicle names, ...
I have changed the running_ticks from byte to int16 to avoid them overflowing when using higher daylenght settings then 3.
Thank you Cadde for taking the time to merge the programmable signals patch with the signal in tunnels and on bridges patch.

Added:
Programmable Signals r19642.
Build while pause in editor r19627.
Show system time window.

Updated:
Cargodist to r19639

I have also made some more changes to the signals in tunnels and on bridges patch. As mentioned before I have reduced the gap to 4 tiles but I had forgotten to change it in another place too. I think it was rail_cmd.cpp but I would have to look it up to be 100% sure.

Again if you find something that seems wrong, please report here as some patches have been retuned by me. The original author would have to go searching in my patch to find out what I did, which is no fun. (Or worse, he may be searching in his patch for an non-existant bug ...)
If I know for sure the problem is not something I did I can still report where needed or undo my changes.

Little note:
Be careful when removing programmable signals and the signals they depend upon.
There are a few ways to crash the ProgSigs patch. They are some minor things that probably will be fixed very soon, I hope.
- When specifying a signal to depend upon make sure you do not click on a tile without rail.
- If you must remove a signal on which a programmable signal depends. You must first remove the programming or remove the programmable signal(which will also remove the programming), then you can remove the signal that it was depending upon.
- When deleting a section of your network, make sure not to remove a programmable signal and the one(s) it depends upon during the same action, doing so will also crash your game.
Other than that the patch seems pretty stable.

Enjoy.

[ColdIce]

I get errors when i try to compile

http://www.heypasteit.com/clip/J6I