Transport Tycoon Forums

U didn't include 'data/yelsig2.grf' and i'data/yelsig2C.grf' in the patch file,
not that it was a problem beacus i got them from the windows zip, but just wanted to let u know

Greetings
Jeroen

Very good work on the nightly
I'm too lazy to compile that much patches Great!

|Jeroen| wrote:U didn't include 'data/yelsig2.grf' and i'data/yelsig2C.grf' in the patch file,
not that it was a problem beacus i got them from the windows zip, but just wanted to let u know

Greetings
Jeroen

Those two are binary files, so it's kinda hard to include them in a diff.

Wonderful!!!

I'm downloading and installing it right now.

Thank you, richk67.

webfreakz.nl wrote: Btw: Can people load their old savegames ( from IN4) with this new one?

All you have to do is try...
Seriously - I'd say it won't be possible, because of modified patches and/or different patches in the two builds...

BTW - webfreakz - would it be possible for you to host an INT3345 server?

Your combined patch doesn't work on OS X. It compiles without problems, but when loading the intro game, it fails with the assertion "!Disconnecting train". As far as I can see, this is caused by something other than the first wagon (locomotive) of a train hitting then end of a track. (See train_cmd.c:3160)
(Yes, I tried both using the original data files and the ones from the windows zip.)

Loading old savegames (from the original TTD) seem to be screwed up!

Anyway, I love the integrated nightly.

^Cartman^ wrote:Loading old savegames (from the original TTD) seem to be screwed up!

Well - loading old integrated_savegames is not a feature by itself. You have to understand, that there are different (versions of) patces used for different releases of integrated_nightly, so the savegames cannot load properly. Ordinary (0.4.0.1) save-games work well...

egladil wrote:Your combined patch doesn't work on OS X. It compiles without problems, but when loading the intro game, it fails with the assertion "!Disconnecting train". As far as I can see, this is caused by something other than the first wagon (locomotive) of a train hitting then end of a track. (See train_cmd.c:3160)
(Yes, I tried both using the original data files and the ones from the windows zip.)

Well.... if you can compile, you can debug

Seriously, this IN is provided AS IS. If there are problems, and *especially* if there are problems on a platform for which I cannot test, then the IN is unsupported.

Given how cleanly the 25 patches fitted together (only conflicts were in english.txt and easy to resolve), the errors must be in a specific patch - and probably would cause the crash if installed individually. I will be uploading all the individual patches, and if you can identify which causes the problem when installed alone, then it can be fixed.

(My guess is that I remember one patch had several calls to IsFrontEngine(v)... sounds like it may have problems.)

egladil wrote:

|Jeroen| wrote:U didn't include 'data/yelsig2.grf' and i'data/yelsig2C.grf' in the patch file,
not that it was a problem beacus i got them from the windows zip, but just wanted to let u know

Greetings
Jeroen

Those two are binary files, so it's kinda hard to include them in a diff.

But they are included in the data directory of the zip...

webfreakz.nl wrote:I guess Dalestan means the source of the compilation (in the ZIP file)

Bit more complicated than that. There are a whole host of directories you get when you do an SVN, but some have proj files in, some have scenarios, some have scripts, some have executables (strgen)... I dont want to upload a total bloat.

webfreakz.nl wrote:Btw: Can people load their old savegames ( from IN4) with this new one?

No, I tried to load and it doesnt. Too much has changed. Also, without the Municipal Airports & Subsids, its almost guaranteed not to.

OK... here are the source patches, and the revised patches after individual testing for R3345IN.

Any developers who have a patch included may want to consider comparing my revision with their patch, and if Ive done the changes in a way you dont want/like/wont work, then please update me with a new patch. Thanks.

SirkoZ wrote:Ordinary (0.4.0.1) save-games work well...

No, not after loading one of my saves from a nightly build.

^Cartman^ wrote:

SirkoZ wrote:Ordinary (0.4.0.1) save-games work well...

No, not after loading one of my saves from a nightly build.

Looks like the signal bug...anyway - I said 0.4.0.1, the release...

You'd probably be able to restart those trains one way or another (deleting and re-placing signals).

^Cartman^ wrote:

SirkoZ wrote:Ordinary (0.4.0.1) save-games work well...

No, not after loading one of my saves from a nightly build.

Personally I would not expect the IN to load anything other than its own games well. The past2090 patch modifies all stored dates, so its possible that is what is having the problem there.

Just start a new game. If you are desperate to play your old game with new features, download the patches, compile & debug.

[edit]I just tried loading an OLD game .... ie, a TTDLX save. And it had precisely the same problem - date in the 3900+, towns of all tower blocks, etc. All my 0.4.0.1 and nightly saves and autosaves import perfectly.

richk67 wrote:

^Cartman^ wrote:

SirkoZ wrote:Ordinary (0.4.0.1) save-games work well...

No, not after loading one of my saves from a nightly build.

Personally I would not expect the IN to load anything other than its own games well. The past2090 patch modifies all stored dates, so its possible that is what is having the problem there.

Just start a new game. If you are desperate to play your old game with new features, download the patches, compile & debug.

[edit]I just tried loading an OLD game .... ie, a TTDLX save. And it had precisely the same problem - date in the 3900+, towns of all tower blocks, etc. All my 0.4.0.1 and nightly saves and autosaves import perfectly.

Interesting...

Well - it must be cause by some patch...maybe by "2090+" and some other patch...strange anyway...

richk67 wrote:PNGmap 9 (sorry, I had difficulties with 10... maybe next time).

What kind of difficulties did you have?
I just tried applying the patch to a fresh copy of r3345, and it worked fine, just a few line offsets were different. I could try making a new diff for PNGmap 10 against the patched IN source if the only problem was integrating it...

cccp wrote:

richk67 wrote:PNGmap 9 (sorry, I had difficulties with 10... maybe next time).

What kind of difficulties did you have?
I just tried applying the patch to a fresh copy of r3345, and it worked fine, just a few line offsets were different. I could try making a new diff for PNGmap 10 against the patched IN source if the only problem was integrating it...

I have a whole suite of PNGs (with correct palettes), and none would import properly. It wasnt so much the contours being wrong - the translation to Greyscale had clipped my lev1 layer as water - but that a 1024x1024 PNG importing onto a 1024x1024 map created 2 copies of the PNG on the map - as if it had imported 1024x512 twice. Very weird.

I decided I didnt want to spend the time working out how much of the problem is my old data (probably most of it), or whether it was the new patch. So I went with a tried and trusted.

When I do the next IN, I will definitely include PNG10.

Further analysis - yes, it was the PNGs. PNGmap10 works fine for new greyscale PNGs, but now doesnt handle the old 4-bit colour PNGs. Oh well... thats progess I suppose.

Anyway. Here is my 4-bit grey pallette for PaintshopPro 7. If you have old 4-bit PNGs, and want to convert them, do this:
1) Load PNG into PSP
2) Check that the palette is in a sane order (lowest level is color 0, next is level 1, etc.) (Use Color/Edit Palette)
3) Load the B+W.pal palette, with the "Maintain Indexes" option.
4) Convert to Greyscale.
5) Save As - dont use Save. You need to set the "Do Not Optimise palette" option in the Options of the Save As dialog.
6) Import into OTTD using PNGmap10.

Thats all folks....

Is anyone else having problems with the signals. When using the GUI to choose whether to place entrance/combo/exit signals, it is only placing normal signals. Is there a setting I need to enable to get it to work?

Thank you for all the work on this build,

richk67 wrote:Further analysis - yes, it was the PNGs. PNGmap10 works fine for new greyscale PNGs, but now doesnt handle the old 4-bit colour PNGs.

I just found and fixed the problem... I mistakenly omitted a call to png_set_packing() before loading, which apparently kept images with 1, 2, or 4-bit color packed with multiple pixels per byte instead of expanding to one pixel per byte. The libpng docs say that the PNG_TRANSFORM_PACKING flag should do the same thing, but it doesn't.
The other flags for stripping alpha and 16-bit color values seem to work though... at least for the test files that I tried. Anyway, the problems with loading 4-bit images have been fixed now.

Updated patch file (for revision 3345 as well)

If you still have any problems, could you please post the problematic PNGs in the PNGmap thread?