Decode and reencode doesn't seem to work.

[Nrgte]

So I just did a small test. Taken a random grf, ran:

yagl.exe -d : Decompile the GRF to create YAGL and associated spritesheets.

And then just reencoded it with:

yagl.exe -e : Recompile the YAGL and spritesheets to create a GRF (backs up the original GRF if present)

added it into a tarball and replaced the existing NewGRF. While the game wouldn't crash, it would not load the NewGRF despite being added in the list of NewGRFs to add.

The output from YAGL seems okay:

E:\Programme2\grfcodec-6.0.6>yagl -d FRIMS_maglev_set_1.3.grf

yagl (Yet Another GRF Language) v0.4-0-g13d5ee5
Copyright 2019 Alan Chambers (unicycle.bloke@gmail.com)
Released under GNU General Public License version 3

Reading GRF:      FRIMS_maglev_set_1.3.grf
Writing YAGL:     sprites\FRIMS_maglev_set_1.3.yagl
Output directory: sprites
Image base:       sprites\FRIMS_maglev_set_1.3

Reading GRF...
Number of records: 4090
Writing YAGL and other files...
Writing sprite sheet: sprites\FRIMS_maglev_set_1.3-8bpp-normal-0.png...
Writing YAGL script...

E:\Programme2\grfcodec-6.0.6>yagl -e FRIMS_maglev_set_1.3.grf

yagl (Yet Another GRF Language) v0.4-0-g13d5ee5
Copyright 2019 Alan Chambers (unicycle.bloke@gmail.com)
Released under GNU General Public License version 3

Reading YAGL:     sprites\FRIMS_maglev_set_1.3.yagl
Writing GRF:      FRIMS_maglev_set_1.3.grf
Source directory: sprites
Image base:       sprites\FRIMS_maglev_set_1.3

Lexing YAGL...
Parsing YAGL...
Opening sprite sheet: sprites\FRIMS_maglev_set_1.3-8bpp-normal-0.png...
Creating back up GRF: FRIMS_maglev_set_1.3.grf => FRIMS_maglev_set_1.3.grf.bak
Writing GRF...

Any help would be appreciated.

[UnicycleBloke]

Thanks for reporting this. Was there any output from OTTD as to why it didn't like it? I'll reproduce your steps and diff the GRFs.

[Nrgte]

I haven't seen any, but I don't know where the log file is. There is no log file in the OpenTTD installation folder and also none in the OpenTTD folder under documents where the crash reports usually end up.

In case it matters, I'm using the jgrpp fork v0.58.1 and not the upstream version of OpenTTD.

[UnicycleBloke]

It's been years since I played OpenTTD... I've just build the source and run it against FRIMS_maglev_set_1.3 as you did. There is a yagl option -x to dump the GRF to hex for ease of comparison. I compared the before and after GRFs and do see some discrepancies. They may not be significant because the data encoding is not unique in all cases. That being said, there are about twenty examples of exactly the same issue with Action D records. I'll have to review the code in light of the spec, but it's clear from my comments that I was a bit vague on some of this when I wrote it.

Record #21 set_parameter 0D 7F 00 FF FF 4C 43 41 45 // Before 0D 7F 00 FF 00 4C 43 41 45 // After

The difference is the "source2" value.

[Nrgte]

Thank you for your effort! I wasn't aware about the -x option. I was mainly using this to use yagl:

https://github.com/UnicycleBloke/yagl/releases/tag/v0.4

[UnicycleBloke]

Hi. Would you be able to test a possible fix for this issue?

I can send you a binary. Basically I think my understanding the Action D spec differed subtly from the game's. I have implemented a much simpler approach in which I don't try to interpret the numbers at all. The before and after GRFs are identical now aside from some expected string encoding discrepancies. Now it looks like this:

set_parameter // Action0D { target: 0x7F; operation: 0x00; source1: 0xFF; source2: 0xFF; data_value: 0x4941434C; }

[Nrgte]

Yes sure, I can try it. It may take a while. I'm not well versed with the NewGRF native format and your tool, but I'll see if I can test it out. Thanks for your work!

[UnicycleBloke]

I just meant to repeat the experiment: decode, encode, and see if the game loads it.

[Nrgte]

Sure I can do that.