Bobs scripting woes

[lwho]

Is there any function to force LUA to destroy the object even if it's still referenced at other places in the code?

I don't think, there is. Scripting languages tend to do their memory management by themselves, so that dangerous thinks like dangling references can't happen.

So, you have essentially three choices

1. Cleanup everywhere on game end (and game start, to be safe ;))
   For example, is the UI having a reference really an issue? I would imagine that the UI object that holds the reference needs to be cleaned up anyway, so that reference to the discoveries will be gone anyway. And probably your seconds point of reference (which I didn't totally understand where this was) needs cleanup anyway, as well.
2. Only store in one place (the lib) and let the other places obtain a fresh reference from the lib when they need it.
   Does the UI need to permanently store a reference? Instead it could do something like

   Code: Select all

   local disc = Game.player:GetDiscoveries()
   -- or
   local disc = Discovery.GetDiscoveriesFor(Game.player)
   

   when it needs to display something discovery-related. So, that would even continue to work if the list of discoveries could change within the game.
3. Add a level of indirection, e.g. have something like discoveries = { list = ... }, pass the reference to discoveries around and on cleanup, set discoveries.list = nil. (Actually, this is a variant of #2, as there is ever ony one reference to discoveries.list. I probably wouldn't go with this one, though. I can't tell why, but it feels "hacky".

[TheBob]

Does the UI need to permanently store a reference?

Well, it imports it, which is about the same thing...

Only store in one place (the lib) and let the other places obtain a fresh reference from the lib when they need it.

So... instead of returning the whole thing in the lib, I'd instead return an object that does not contain the data itself, but a function to retrieve it. Nice Idea, didn't think of that

Add a level of indirection, e.g. have something like discoveries = { list = ... }

That's the way I solved it currently. Since Discoveries only really has an array and a bunch of functions, it came pretty naturally...

Thanks for the advice!

[TheBob]

Ummm... is it possible that player.frameBody is nil if the player is LANDED? It seems that way to me, but maybe I'm just doing something wrong...

[robn]

You can test by doing this is in the console:

Code: Select all

> import("Game").player.frameBody
userdata [Planet]: 0xc134e18

I can't think of any time where it would be nil. Maybe in hyperspace, but that's a really weird case (and not really usable from Lua anyway).

[FluffyFreak]

Also, @FluffyFreak: I already wrote this a few days ago, but then there was server trouble and it would seem the backup ate my post.
You remember that faction stuff we talked about? Now that I know the Pioneer LUA-structure somewhat better, I see that it doesn't actually need core support for most things (some calls for starport behavior will be neccessary, but that isn't directly related). When I get to it, I can just shove the faction creation off into a lib and retrieve the faction list from there, without having to get it from the Pioneer core. Sorry for the work I've caused you.

No worries Bob :) I've still got to expose more of the factions stuff to Lua, I've just been distracted by a few things.