Expresso wrote:LUA is a complete scripting language, which would seem like overkill to me. However, XML seems seems just fine for the job and provides a lower learning curve as LUA and a lot lower learning curve as NFO.
Besides the webbed sprite lookups, there are other problems with using XML. NFO is, among other things, Turing complete and self-modifying. I've not yet seen an XML spec that is either, unless what you're considering is merely a byte-for-byte translation of NFO.
Haukinger wrote:If I'm wrong, please correct me, but I think the newgrf-thing is older than ottd. Obviously, the ttdpatch-developer don't have access to the source code, so they had to cope with what the executable offers and what can be hacked into it. The newgrf format is not as it is because it is clever or fast or has any other hidden benefits, but because the ttdpatch-executable understands it.
What Brianetta said.
Also, you're confusing the GRF container and the NFO language. We use the GRF container because TTD understands it. Support for NFO, however, is entirely found within the TTDPatch executable. Without Patch's help, a TTD executable wouldn't have the vaguest clue what to do with a newgrf file. It wouldn't even know to look for one.
Haukinger wrote:As for performance, most of the nfo-processing seems to be done upon loading the newgrf, and that's effectively free time.
Most of the NFO processing is done at load, yes. But, as Patchman said, it is executed tens of thousands of times every tick. I've seen a TTDPatch game (so single player, 256x256 map) with over 11,000 vehicles. (Yes that's eleven thousand. There is not an extra character there.) This comes to just short of half a million vehicle sprite lookups alone, every single second, plus the vehicle callbacks, station and industry tile sprite selection and callbacks, industry production calculations, &c.. I would guess that NFO will start saturating a 1GHz processor at around 2 to 4 million lookups per second.
Unless your LUA scripts are at least half that fast, I really don't see the point.
Haukinger wrote:The game then uses map<cargo_id,spriteset>::operator[] to lookup the correct spriteset (std::map is quite fast, O(log N), I think
It is my understanding that NFO is quite faster. Specifically, I'm pretty sure it's O(1).
Not to mention the minor detail of "OpenTTD is written in C, not C++".
Haukinger wrote:That would solve some (most ?) problems, but it means stopping half way. You can still only do what newgrfs can do in ttdpatch.
Name one thing that NFO *can't* do. (Besides (see below) things that no one has yet considered doing.)
Haukinger wrote:Lua could be allowed to do everything from the beginning.
No, it can't. You simply cannot write a language that supports things that no one has yet thought of doing.
If you want to claim otherwise, make sure your proposed spec includes a way to set train property 2B.
Expresso wrote:the compiler, which could produce a NFO file and a linker information file (so you just link the graphics and NFO file together and don't have to figure out the correct order of the graphics).
More nit-pickyness: An NFO file, by definition, already has the sprite references and the code properly interleaved.
If the sprite references are in some other file, or are not properly interleaved with the code, you're not looking at an NFO file.