This is the basic pseudo code is below:
(the_thread == stack index index of lua_newthread())
newmetatable = {}
newmetatable.__index = _G
threadtable = {}
threadtable._G = _G
threadtable._THIS = this
threadtable._THREAD = the_thread
setmetatable ( threadtable, newmetatable )
_G._THREADS[this] = threadtable
setfenv( the_thread, threadtable )
Raymond Jacobs wrote:
> David,
>
> That sounds like a plan, could you 'or anyone else' elaborate on how I
> would do the following 'im still pretty new to lua'.
>
> so how can i create a new table, and add _G to it, which points to the
> 'true' global environment, and then how do I set this new table as the
> co-routines environment.
>
> some sample code, or a list of the functions I need to investigate
> would be really helpful.
>
> Thanks again =)
>
> -Raymond
>
> On 7/10/06, David Morris-Oliveros <david.morrisoliveros@teambondi.com>
> wrote:
>> First of all, sorry about the chaotic email, it's still too early in the
>> morning for me :)
>>
>> You can try sandboxing the coroutine. That's what we do in our game.
>> Each coroutine gets it's own environment, but still with access to the
>> global env.
>>
>> You create a table, whose metatable is the global global, and set that
>> to be the local global's table, with an explicit entry to _G. That way,
>> you can create local and global stuff:
>>
>> local really_local_variable = 1
>> local_variable = 1
>> _G.global_variable = 1
>> function local_function () end
>> function _G.global_function () end
>>
>> Also, if you set the local global's metatable to be the global global,
>> you get everything else for free. That is, you can access all the
>> functions and variables defined in the global global as if they where
>> local:
>>
>> _G.fibonacci(5)
>> fibonacci()
>>
>> would be the same call (as long as you haven't created a new fibonacci()
>> function in you local global).
>>
>> From C, you can obtain the local global and then call the function by
>> name within that local global.
>>
>> We keep a table with all of these things:
>>
>> _G._THREADS = {}
>>
>> I then add each local global to that table using the C's substate
>> pointer's numerical value as key. That way it's easy to extract the
>> local global from C, and then call whatever.
>>
>> This way, you can easily set global variables ( _G.var = value ), or
>> local ones (but still have access to them from outside), and all will be
>> cleaned up on coroutine exit, because "local" functions exist only
>> within the local global table.
>>
>> Raymond Jacobs wrote:
>> > Hey all,
>> >
>> > In our game we utilize a single Lua_State, and create a co routine
>> > (initialized with the main lua_state) for each other script we run.
>> >
>> > It is great that the variables we create in these other scripts remain
>> > global and accessible from any other script we run, however, we run
>> > into this problem:
>> >
>> >
>> > if we load 'scriptA.lua' which contains the function onClick()
>> >
>> > and later load 'scriptB.lua' which doesn't contain an onClick()
>> > function, the previous onClick function still remains.
>> >
>> > so in short, when we run a script (through a co-routine) we would like
>> > to start a clean slate as far as functions are concerned, but we still
>> > want to be able to access all of the global variables we've created.
>> >
>> > now, i noticed it is seemingly valid to create functions with the
>> > 'local' prefix on them, to me this sounds like what we need (so that
>> > the functions don't get embedded into the global area) however I can't
>> > figure out how to call a local function from C (all of our co-routine
>> > creation, script loading, and function calling happens from C).
>> >
>> > I am pretty sure someone has run into this issue before, any help
>> > would be appreciated.
>> >
>> > Thanks for your time,
>> > Raymond Jacobs
>> > Owner,
>> > Ethereal Darkness Interactive
>> >
>>
>> --
>>
>> // david morris-oliveros
>> // camera & lua coder
>> // david@teambondi.com
>>
>>
>
--
// david morris-oliveros
// camera & lua coder
// david@teambondi.com
