[Bf-committers] BGE Components Proposal
mogurijin at gmail.com
Thu Oct 7 09:01:55 CEST 2010
> I confess that the workflow confused me a little bit. Why to go to outliner
> instead of loading the class straight from a text (internal or not)
> datablock? If I'm not mistaken your original proposal (the one in the
> was doing something like this, no?
This serves a couple of purposes (although, I think I neglected to mention
either in the proposal).
1) Packages in the list could automatically be added to the path.
2) Components in the list could be used for pointer lookup stuff such as the
Although, both of these could be added after the fact, and maybe with a bit
more thought behind them.
> Some details:
> 1) how to tell blender what is the type of the game property you are adding
> (in your example "Health", "Energy" and "Regen" are floats, but and if they
> are boolean, strings, timer, ...)
I was planning to check the type of the value in the dict (The Python C API
has functions for this). So, if you have a float for "Health", a float is
used for property.
> 2) your "update" function runs every logic tic. I can see some cases where
> this is more often than the necessary (given the overhead that
> can sometimes produce). Maybe something to be workarounded with some
> internal counter (e.g. if counter%5: return).
Yeah, an Nth frame setting would be good and fairly straight forward to
implement. I'll add it to the proposal.
> Those are my 2 cents for now. I think that to be able to do more with
> is a great gain for BGE. Too bad we don't have a "feature roadmap", but
> my understanding this kind of functionality fits well with present and
> future plans for BGE.
Thanks for the input. :)
Mitchell Stokes (Moguri)
More information about the Bf-committers