Suggestion: Object::CreateHook

[Crazycarpet]

I know this'd probably be a pain to implement but I feel like it'd be a really great hook to have...

The problem I'm facing now is I'm trying to attach a "PhysicsMaterial" to every Leadwerks::Material that's created, and right now I just use PhysicsMaterial everywhere instead of Material and the methods in PhysicsMaterial create the Material... but this is kind of a head ache, and not so Lua friendly..

 

I was wondering if it would be possible to get an Object::CreateHook because it's make life easier in so many situations, and it'd be a great counterpart to Object::DeleteHook...

 

It'd be nice because then I could just create my PhysicsMaterial on this CreateHook for the material and that'd be that, instead of this big, headache of a class that makes creating materials in Lua a headache til I expose PhysicsMaterial through toLua++...

 

I just feel like in general it'd be a great hook to have in so many systems... especially because in things like Materials, many entities may share one Material so I can't create my "PhysicsMaterial" when the entity is created.

 

It'd be nice to hear back on this from you Josh because if you're planning on adding it I definitely want to put my project on hold as this would make life so much easier in the future.

 

Edit:

-Another problem w/ the way I'm doing it now is I have to do a sloppy hack spawning a huge box to change what type of material every LE entity and collapsed brush that's created in the editor uses...

 

-I also don't know how you'd implement CreateHook since like.. it'd have to be global and not object specific (because we obviously can't object->AddHook() when there's no object) but something like this would be so handy... I guess the hook system couldn't do it but if you could think of another way to implement this it'd be so amazing.

 

A callback like this is literally make-or-break (work-arounds working pretty well) for people who want to make robust C++ games, because otherwise we have to have tons of hacks every time we have a situation like this where we want to extend the behave of an LE object type.

I'll try to post an example of a situation where this'd help later... basically the problem right now is we need to implement seemingly unnecessary hacks (that could be avoided with a callback) every time we want to extend the behavior of LE object types, and in turn this really limits the type of projects that can be made in LE

 

But again, I do realize this'd be a pain to implement in a neat, working manner because we run into all kinds of issues like what type of object is it, etc.. maybe LE would benefit from some form of global-hook system?

 

Physics Material Files for info on how we're extending "Material":

http://pastebin.com/HZBfZGi6

http://pastebin.com/twVLUPWG

 

Again! I know this would be a pain, but it'd make LE Objects so much easier to extend, right now its SUCH a headache.

I really feel like LE is too focused on Lua, to the point where it's next-to-impossible to make a pure C++ project that is unique, and robust... this simple solution would make all our C++ problems go away! we even have our C++ entities working w/ the flowgraph editor (thx reepblue)! This is the last problem (to my knowledge) we need to conquer.

 

Edit2:

Why can't we just have some global hooks thru System::AddHook for creation of LE objects?

[Josh]

Have you thought about initializing the physics material the first time it is queried, if none is created yet?

PhysicsMaterial* GetMaterialPhysicsMaterial(Material* material)
{
if (material->userdata == NULL)
{
PhysicsMaterial* phymat = new PhysicsMaterial;
material->userdata = (void*)phymat;
}
return (PhysicsMaterial*)material->userdata;
}

[Crazycarpet]

Have you thought about initializing the physics material the first time it is queried, if none is created yet?

PhysicsMaterial* GetMaterialPhysicsMaterial(Material* material)
{
if (material->userdata = NULL)
{
PhysicsMaterial* phymat = new PhysicsMaterial;
material->userdata = (void*)phymat;
}
return (PhysicsMaterial*)material->userdata;
}

 

That's the work around I ended up doing... I just feel like it'd be nice to have these hooks regardless.