kamnet wrote:Snail wrote:Erato wrote:Because m4nfo is trash this set will not be expanded upon.
Funny. I used m4nfo to develop my entire set
Now I'm curious, what makes m4nfo not work well for developing a station set?
An excellent question. And the answer comes in several strands.
The idea of m4nfo as a NewGRF coding language is excellent; I must commend it on it's compact style and the speed at which it compiles. Sometimes. See, what m4nfo does it translate in to nfo which it doesn't do all that well, for stations at least.
When I use a coding language/compiler I expect it to give reliable results and to give errors that are down to my coding, rather than its inability to cobble together the relevant bytes and such. This is not the case with m4nfo. I've had experience of a couple of examples where it just writes the wrong
byte, not set of bytes or anything, just a single byte incorrectly, causing none of the NewGRF to function correctly. An example for the curious:
(Skip this bit if you're not interested in the code)
I started coding with the program. I had some working results, so I started coding lots of stations. Then apparently randomly, the compile started giving two errors in the grfcodec stage.
Code: Select all
...
Linter failure on sprite 235.
Error on sprite 287.
...
I had read some nfo documentation before using m4nfo, so took a look at the .nfo file. The first error seems to originate on line 503 to 514 on the .nfx, even though the syntax etc is identical to line 516 to line 527 (which doesn't give an error). The 7th byte on sprite 235 (line 634 in the .nfo) is "03". On every other action 0 in that area, the 7th byte is "02". What has caused this?
Similarly, the error with sprite 287 is with the 6th byte, it seems, which is "0a", as apposed to the "01" seen in every other similar example (line 1109 in the .nfx, line 1197 in the .nfo)
I changed these bytes manually, then ran grfcodec and the grf compiled without errors.
(You can start reading again)
This isn't me miss-typing the code. The compiler thinks everything is fine, but leaves it to the NFO compiler to tell me it's wrong.
Additionally, the documentation is rather poor at explaining the compiler process, the correct process eventually being explained to me by Erato and was completely different from the documentation. Other things missing from the documentation are the fact that station IDs have to be valid octal numbers, while the limit still being the hex standard of "FF" (256) station IDs. What is the logic behind this? I don't know.
I have also been completely unable to get 32bpp sprites to be recognised by the m4 compiler, despite following the documentation. Something that has also been unhelpful in this process is the lack of contact I've been able to have with the original author of m4nfo (michael blunck) and his unwillingness to share large sections of code. This seems to be a trait of m4nfo coders.
I chose m4nfo as a simpler, quicker and more accessible alternative to NFO. I now almost know enough NFO to code a station set from going through the NFO output from the m4 compiler and it's poor error handling to try to work out what's wrong, commonly resulting in me needing to make a manual change. I know Snail has been able to get a fully functional (and a seemingly excellent) trainset out of it but I really can't realistically see myself using it for a large scale station set. If you're interesting in seeing my code/want to say I've been coding it wrong feel free to take a look at this
repo
I know a lot of this repeats Erato's post, but I've been experiencing basically the same issues and want to express the same frustrations.
But to be honest, that bug, glitch or figment of my imagination, whichever you prefer 
