[...] I tried your m4nfo for bridges (stefino_cz wrote you PM about problems with compilation). But more easy was use NFO. Your m4nfo not support all. For example front of bridge with different sprite for roads and rails.
After reading stefinos reply, I´ve been testing bridges, and indeed it was buggy. I´m sorry, but this was the first time that I took a look on bridges since 4 years (nobody coded a new bridge set since years), and the reason for buggyness was a number of changes in m4nfo since 2014.
I´ve already fixed the original bug, but when being on it I decided to rewrite some parts of the bridge code as well. I´ll post a new m4nfo bridge module with a revised tutorial in the next couple of days.
I think that m4nfo is for little set developers. But if I need big set or some special actions in set, then i must understand NFO.
I totally disagree here. Coding a large (station) set in plain nfo is a real challenge[*] (I´ve done it for quite a long time). In addition, m4nfo is best prepared to be used for large sets, you could even handle distributed files, and "link" grf part files, to reduce "compile time".
[*] For example, take a look on ISR´s nfo code, and try to "understand" it.
m4nfo for stations, objects and (train) vehicles is mature, since these are the areas I´m constantly working on. There might be some inconveniences with other TTD "features" (due to a long time of absence from those), but usually even those will be fixed in a short time, if reported.
Im goinig to try m4nfo with stations and understand what is in generated NFO. Its only one way for me, i think.
Feel free to contact me in case.