[WF-General] Entity creator improvements

Erik Hjortsberg erik.hjortsberg at iteam.se
Fri Sep 19 04:02:30 PDT 2008


Hi,

I think using setfenv would be a good idea, and then at the same time exposing the global scope through a variable, say _G or global. That way there's less risk that the script by mistake messes up the global scope while at the same time providing access to all the global stuff.
Something like this: http://www.lua.org/pil/14.3.html

CEGUI has a tree control, it's already in use in the modeleditor for example (when you've selected a model).

/erik

-----Original Message-----
From: Alexey Torkhov [mailto:atorkhov at gmail.com]
Sent: den 19 september 2008 12:03
To: Erik Hjortsberg
Subject: Re: Entity creator improvements

Hi.

В Птн, 19/09/2008 в 11:49 +0200, Erik Hjortsberg пишет:
> Hi, as you’ve perhaps seen I’ve committed some improvements to the
> Entity Creator.
> ...

Great!


> I’ve found an issue with how the preview Model is displayed though,
> see here: https://bugs.launchpad.net/ember/+bug/272044

Yeah, all that model transformation code should be splitted from
EmberPhysicalEntity.


> I’m also a little bit concerned about how we now use the global lua
> scripting scope for placing our scripting code. Since it’s the global
> scope we run the risk of interfering with other functionality, such as
> the gui methods and data. An option would be to use a completely
> separate virtual machine for the script editor, but that is quite
> expensive (since lua doesn’t make any distinction between code and
> variables, so each new virtual machine would require a complete
> duplication of the lua memory structure). We’ll have to think a little
> more about how to encapsulate the scripts used by the entity creator
> in a way that they still can reuse parts from each other and the main
> lua environment.

We can encapsulate with calling setfenv() from our calling code. But
this hides all global variables - bindings, useful global-space
functions, etc. I decided think what exactly should be in script context
later.

> Another thing I’ve found is that we probably need to add some kind of
> grouping mechanism for the recipes. As the amount of recipes grow they
> will become unwieldy to search through. I’m thinking of just allowing
> the name of the recipe be in the form of “/trees/oak” and that would
> then be shown in as a hierarcy:

Nice idea. We have tree widget in CEGUI, right?


--
Alexey Torkhov <atorkhov at gmail.com>



More information about the General mailing list