Community Decision - Standardized Entity Message Format?

[TylerH]

This is a simple poll, that can have lasting, constructive results on the community and how we can continue developing thingoids and other entities, both in Lua and C/C++, across multiple developers who may not even know each other, but can build off of other published entities and communicate with them due to a standardized format for message handling.

 

My proposal is this (the theory, not the example formatting I am using):

 

Even though we have the single-state Lua development model for the Editor and the Engine now, entities still will have a level of communication via the Leadwerks Entity Message System. This is key, because it is core in the engine, and works across all language barriers, namely Lua <---> C/C++/Blitzmax.

 

The key theory here, is to have a standard format for the names, values, purpose, function, etc. of various messages, and code base entity classes that have hooks for interface, not necessarily functionality and implementation, of all of these standards.

 

The main points of the idea are as such:

• A community-managed, standardized, extended core class.lua type file that contains all of the to-be-mentioned functionality
  
• A standard form of communication, via messages, between entities through the entity SendMessage, ReceiveMessage, etc. set of methods and callbacks
  
• Some type of standard format that all message names would share, that is human-readable/friendly, informs purpose, and provides description. Such an example would be: "Info_Position_Update",a message that an entity would send to another entity to give it its position as an update. Another example could be: "Game_AI_PlayerSeen". Squad AI thingoids could send this message and relay it to other squad members to alert them that the player is seen.
  

 

Those are VERY specific examples, but standards always help with things like this.

 

You could have a general purpose prefix, like Info, Game, Engine, Render, etc. to indicate what the message will be relaying or functioning FOR. Follow that with a topic, such as Entity, [Position,Rotation,Scale], Model, Force, Joint, Weapon, Projectile, etc. to tell WHAT the message is ABOUT. Follow that with more and more WHAT's to describe the message further (Game_Vehicle_Tank is more descriptive than Game_Vehicle, e.g.). End it with a WHAT it is DOING, for example Update, Kill, Alert, DriveForward, Expload, Enter, Exit, Spawn, etc. (these are the specific parts).

 

This would form a hierarchy similar to:

FOR -> WHAT [specific What] -> HOW/WHY

 

It would simulate:

Namespace -> Class -> Method, but in a message form that all entities could support and share. Someone developing a weapon thingoid, would know from checking the standard that the AI and Player thingoids have messages the Weapon thingoid can utilize to interact with said pawn thingoids (AI and player). And vice versa, and so on.

 

So, what do you all think?

[Josh]

It might be better to call Lua class methods directly. You can do this from C++.

[TylerH]

That is always an option.

 

Did I miss something during my inactive period that made entity messages obsolete?

[Josh]

My original concept was to rely on messaging for everything between multiple Lua states. A single-state ended up being used, which made this approach unnecessary. The disadvantages I see to using messages is the data you can transfer is limited to strings, the parameters you can call are limited, and it is not as simple as just using the lua object function for whatever you want to do.

[Rick]

It might be better to call Lua class methods directly. You can do this from C++.

 

Unless you made the change of renaming your lua methods you made this can only be done with modifying engine.h. Even then, calling a lua object method from C++ hasn't been demonstrated yet.

[Josh]

This is how I do it:

size=luastate.stacksize()
lua_getglobal(luastate.L,"objecttable")
If lua_istable(luastate.L,-1)
lua_pushobject(luastate.L,Self)
lua_gettable(luastate.L,-2)
If lua_istable(luastate.L,-1)
	lua_remove(luastate.L,-2)
	lua_getfield(luastate.L,-1,"UpdateMatrix")
	If lua_isfunction(luastate.L,-1)
		lua_pushvalue(luastate.L,-2)
		lua_remove(luastate.L,-3)
		luastate.invoke(1,0)
	EndIf
EndIf
EndIf
luastate.setstacksize(size)

 

It's confusing, but you don't really have to understand what each line does. Just copy and paste that code and you can reuse it.

[Rick]

That's good stuff. Now the issue of us having to modify engine.h to rename your lua methods so we can use the real lua in our program without conflicts. From what I can see some of those methods you didn't create in engine.h, which would mean we need to bring in lua to our projects, which leads to the function name conflicts.