the way i see how it could work:

it's really rather straightforward to emit the unitdef with proper definition, e.g. if you have

then generation of UnitDef.gen.h would be like:

this is the simplest case, but you get the idea. the writer should actually be extensible so you can add custom types easily, etc.

What do we need step 1 for if we could just write the class by hand and let the compiler / preprocessor generate lua / AI bindings?

if you can make the preprocessor and compiler to do that... i know i wouldn't bother.

An easy (but incredibly ugly and hacky IMO) way is to make a list of fields in a file "UnitDefFields.inc" like this:

and to then have UnitDef.h like this:


But TBH I wouldn't be happy to see this kind of dirty hacks in the engine. And no, I don't consider template metaprogramming tricks to be any better..

Whats the advantage of you example over



And, tbh, the whole unitdef-thing (hey, lets add all variables a unit of any mod might ever need in one class) is screwed and not suiting for a project which claims to be a flexible engine.

You missed the point entirely, the suggested idea was to generate not only UnitDef, but also the AI and Lua interface, without having to parse C++ sourcecode using an extra tool.

E.g. add this:



You missed the point here again, the point ("a" point, it has multiple) is NOT to add all members of all mods ever made as hardcoded variables inside the engine, the point of the thread is to design a generic solution so both engine and mod variables get similar treatment in in particular Lua and AI interfaces.



Anyway, just putting a comment in UnitDef.h still seems best solution to me, possibly combined by a small script integrated in build system that fails if there's a mismatch between UnitDef members and AI/Lua interface.

All the code generation or property system designs in this thread seem overcomplicated to me.

In relation to the original comment on variables in unitdef that dont tell you what theyre for ro where in the code they're used, doxygen should be suitable, so its best worked into any autogeneration found

the checking script would have to parse C++...

For checking a parser can be much more crude usually, in my experience.

(It doesn't matter if the script skips some properties, if -for example- it reads 90% of the UnitDef properties correctly then it would already reduce the amount of times someone forgets to add a property to Lua/AI interface with 90%.)

YAML?

hmm...
this making a comment and checking with a script if the property is added to Lua and AI interface...
it is simple, but would help in only one aspect: we would more likely be exporting all props that are meant to be exported.
it would not make management and accessing properties more unified eg.
also... i see it happening like this:
somoene adds a property, compiles spring, and uses it, not even noticing the wrarnings, and someone later an other dev would have to go through the wranings and try to find out if the prop is usefull for Lua and/or AI, and add code to export it. i would not like to be that dev.
otherwise, the guy adding the property would have to add a line somewhere that contains everything needed anyway (eg name, type, description, flags (AI | LUA | ...)).

i still think having something like a WorldObjectWithProperties solution is the best way to go. it is not hacky at all, has all the pros, and .. if its not the speed, then i dont know what contra.

it would be like this:
UnitDef.cpp:


in the mod:


in an AI:

output:


the details in this example are not correct (like property indices and name handling and such). its just meant as an intro to the idea in general.

i'm not convinced that anything that results in more than a single memory access is a good idea, *defs are used everywhere and it may be too expensive to make reading them more complex...

as tobi pointed out, this method can be used with a single memory access only aswell.

eg:

possible.

i'm starting to get confused what the cons and pros of this change would be. i could use some convincing that it's really needed.