Does this mean what I think it does?

[Argh]

* Loaded all FeatureDefs at the beginning of the game

* Added LuaParser for the following:
UnitDefs < gamestate/unitdefs.lua >
FeatureDefs < gamestate/featuredefs.lua >
WeaponD├óÔé¼┬ª

For the confused, go here:

http://spring.clan-sy.com/fisheye/chang ... g/?cs=4271

So, er... Trepan, are we gonna be able to, at least in theory, be able to finally declare properties of a Feature that are essentially == a Unit, such as a COB script? I can see that as a logical extension of converting the entire UnitDef stuff to LUA (internally or otherwise) and needless to say, I'm pretty excited by this, it's going to (finally) remove one of the final, legacy areas of Spring. However, I'd like to know if any changes to object-destruction precedence and other things will / can be changed when this is working. IOW, will we be able to (finally) escape from the OTA tyranny of "only one real Corpse per Unit", or is this basically just an intermediate step, which will require LUA to fully exploit?

And, er, from reading the preface on the changes, let alone the actual code, it appears that you're going to expose the Weapon code entirely to LUA?

Is it maybe time to maybe have a meaningful discussion of the Universal Weapon Type proposal (long ago, MTR'd and pretty much forgotten by most), so that we can have a common feature-set to play with here, that makes sense and allows for more possible combos, whilst preserving backwards compatibility? Or are you just gong to convert this to LUA (so that, for example, we could code weapons that do variable damage, etc.- trust me, "just" is a very understated word here)... but otherwise leave this unchanged? I don't want to assume what you're doing here, but this has implications, some of which I think all of us game people would like to weigh in on.

In short, if you're going to tear up part of that mess, it might be a good time to clean it all up, and I'm perfectly willing to help, where I can (this more-or-less supercedes my shorter-term goal of replacing all hardcoded ExplosionGenerators an explosion events with CEGs, obviously, not that I've gotten much of anywhere), given that you seem to be replacing that as well... it kind've all fits in one larger whole here, and it might be time to review why we're doing things, not just what. I don't want to push you towards any particular solution, mind you, but I feel like we (game people) and you should probably at least understand where you're going with this. The Unit stuff makes perfect sense, the Weapon stuff takes us into all sorts of interesting territory that I don't feel has been explored well yet.

At any rate, I apologize for the length of my musings, however... this set of commits raises a number of philosophical issues, and I'd at least like to hear a bit about where you're going with this, if nothing else, because it looks like we're heading into some very new territory here.

[trepan]

1. I don't think you understand what that commit did. It does not change the
internal properties of FeatureDefs, UnitDefs, or WeaponDefs, it simply changes
the way that their definition files are loaded.

2. LuaRules already allows you to implement multiple wreck types per unit.

3. It's already working.

4. Related to (1.), this is not in any way, shape, or form, related to exposing
weapons code to the dynamic lua scripts. I do have some code done for that,
but it's an entirely separate thing.

5. Here is an example of some converted FBI -> LUA files
(using my fbi2lua.lua widget, which I'm still tuning):
http://trepan.bzflag.bz/noshow/ca665-fbi2lua.zip

[Argh]

1. I don't think you understand what that commit did. It does not change the
internal properties of FeatureDefs, UnitDefs, or WeaponDefs, it simply changes
the way that their definition files are loaded.

I understood that. But the logical next step here is pretty clear. From where you're at, after that commit, it's a fairly short step to cutting another major part of what constitutes "content" free from portions of the engine that have been somewhat resistant previously. It's less sexy than new rendering techniques, but it has much greater implications for gameplay.

And that raises some philosophical issues, that might be profitably explored. For the longest time, the incentive to write and commit new Weapon types has been fairly null, because of the associated overhead added to Spring. This appears to me like a wedge that might be used to alter that situation somewhat, going forwards.

[edit]

Ok, took a look at the FBI-->LUA stuff. You're essentially populating a Table (which, basically, would mean that no LUA script would have to populate its own UnitDef tables- they could all just share from this common Table, unless there were compelling reasons not to).

Now, imagine Weapons were essentially the same way, and could be manipulatable in sync code. While this could have some profitable results fairly easily (random damage, "critical hits", range / AOE changes, etc.) there are more fundamental things that could be done, eventually (how it's drawn, how it travels, what model it's using, other things like this).

From your (edited) reply, I can see we're on the same wavelength here. My take on this is that if you're going to go there, then we probably all need to at least think about how that's going to work. At any rate, I don't wish to impose a POV here, and I am reluctant to express any thoughts on the design at this time. I just thought that we should probably start thinking about this.

[trepan]

1. The next logical step? I just painted my car, the next logical step is
to bore out the cylinders? Adding COB scripts to features isn't even
remotely close to being related to my commit (using a concrete example
from your first post). Is the reason that you'd think so because you
don't really know the code?

2. All lua scripts already share from a common form of UnitDef table
(see rts/Lua/LuaUnitDefs.cpp). Rather than use up a chunk of memory,
and to make it read-only for the standard parameters names, lua
metatables are used (which also avoids the extra (measurable) delay
incurred at the beginning of a game when populating full unitDef tables).
Also note that this means that no lua script has to populate its own tables.
Another advantage to this approach is that lua scripts read the values after
the engine has done whatever modifications it decides to do for specific
parameters.

3. You can manipulate Unit/Feature/Weapon definitions with synced lua
code, but you have to use: .editdefs (it's a safety precaution, data values
are unchecked). This may be changed at a later date (but checks for any
accessible data type would have to be added). Just changing a definition's
value also means that you'd have to create a new unit/feature/weapon to
see the change.

I consider your query closed (w.r.t. my commit). I'm sure you could have
a grand conversation about abstracting x, y, and z functions to provide
more flexibility to lots of engine components, but it is not really related to
what I was doing, nor should it be implied.

[Argh]

Fair enough, I'll let it rest. That actually answered several important questions, thanks for taking the time.