SquirrelGRF: Squirrel scripting for GRF-like files

[DaleStan]

Note: I have never heard someone saying, PovRay is restrictive and hard to understand. Usually one fails dealing with 3D stuff without inmediatelly seeing the result.

Well, that may very well be because PovRay is easy to understand, and NFO isn't. (I'm not guessing that PovRay isn't hard--I know it isn't). Could it have something to do with the fact that PovRay is, as you said, text-based, while NFO is hexcode-based?

"If the hex-ness of NFO is the only thing that bothers you, then it's the only thing that needs fixing. This means either improving/fixing GRFMaker, or writing a 'plain text'->NFO converter."

If the multiplexing bothers you too, then just don't expose it. Generate the demultiplexer automatically, based on which callback functions the user supplied.

Do we at least agree in that NFO is a language designed to be easily read by a computer and not by a human, and that it takes (most) humans longer to read and write than the average human-friendly language?

We (I, anyway) can agree on that.

If Squirrel is deemed to be a bad choice as an alternative, and a better option is found (easily parsed by both humans and computers), would OpenTTD be willing to accept it?

But here, I'd guess not. Unless $LANGUAGE provides something that NFO can't, then you're probably going to get told exactly the same thing: "[Convert] it to NFO, then use the already-working NFO support in OTTD."
"Convert it to GRF" would be just as good, at least in my opinion. It'd make it more difficult to verify the output with NFORenum, but not impossible, and would probably have the advantage of a substantially more permissive set of image file formats.

And yes, I know you said

why not create this SquirrelGRF as an external tool that writes NFO code from SquirrelGRF? It can then readily be used in OpenTTD without any modifications and leave raw GRF code for the parts that are as of yet unsupported.

In my humble opinion as an experienced programmer, because that would be reinventing the wheel (a language-to-bytecode compiler, when we already have several generic ones available).

But I'm not convinced. If a generic compiler is available, why not modify it as necessary to produce NFO? No need to re-invent the wheel. You'd hardly be re-inventing the NFO output part, because there's only program in existence that generates NFO, GRFMaker, and (AIUI) it's rather more an assembler than a compiler.

[Eddi]

actually, the NDL compiler has a working NFO-generating backend. just it only generates a very limited subset of NFO (action0 + action1/2/3 for trains (where it would be trivial to extend to other "features" (as in NFO-speak)))

[DaleStan]

Two. I stan^H^H^Hit corrected.