|
From: Andy R. <and...@gm...> - 2007-05-11 23:58:41
|
> > How about if I take a simple entity from RF1 and modify it to show you > what I mean? I was thinking maybe the 3dAudio one or Trigger. > Sure, sounds great, please get an account on SourceForge and I'll make a branch of RF2 in Subversion for you to test it out in. If it's a built-in entity and you change it's behavior you would have to > rebuild. However, the optional, overriding Python script can be > autoreloaded. > Sorry, I didn't explain fully. I meant I don't know whether you can unload then reload the DLL itself in real-time. If he doesn't need the flexibility all we've done is slowed down the > execution of the entity. What I proposed does not take away any > flexibility, all it does is provide a base functionality in C++ that can be > extended or replaced by a script only if the user needs to. > That is true, but a big part of learning would be copying and pasting the code from one entity to his own personal Python entity. If it is C++ he wouldn't be able to do so. However, if we went to the effort of writing all entities both in Python and C++ (which wouldn't be terribly difficult), and had RF2 prefer the C++ one but choose the Python one if that were all that was available, we will have conquered that too. I'm not talking about the execution of the compiled Python code (which I > assume will be slightly slower than C++), but more so the fact that every > time Python needs to call an Ogre method or function it will have to go > through another level of indirection (through the wrapper). This will take > additional time and you can multiply that tiny bit of time times hundreds or > thousands making it very significant. What I'm proposing allows us to > eliminate this penalty for built in things that work ok the way we > programmed them in C++ for the user. But, if he needs additional or > completely different functionality he can have it by writing the script. I > love the way you can script almost anything in your vision of RF2, all I > want to do is add a base functionality you can use also. If the base > functionality works for the user's needs then he doesn't have to use a > script, but the possibility is still there. Here is an example: Let's say > we have an entity that simulates a model in RF1. If this model is currently > animating then we must call the Ogre animation object every frame supplying > the elapsedtime. Why not have that call performed by the base entity > functionality instead of making the script do that every frame? The script > could then just execute the logic to decide when to start or stop animating. > However, if the user had a reason to, he could decide to tell the base C++ > code not to call the animation object with the elapsedtime every frame and > perform that function himself in the script. Most users will never need to > modify this aspect of the model entity. Why not have theirs execute the > fastest which will save them time for scripting another entity where they > need different behavior than the base? But, again, if they need to, they > can. > Sounds good to me. Whether we design these base entities as plugins or built-ins I haven't > really thought about much, but we can discuss it more. I think that the base entities being plugins is the best choice. That way users can make plugins and post them on the forums for download rather than having to splice together various versions of RF2, all with different entities, and recompile it if you want the functionality of more than one extender's work. Best Regards, - Andy Riordan |