#nuvie@irc.freenode.net logs for 23 Sep 2006 (GMT)

Archive Today Yesterday Tomorrow
Nuvie homepage

[01:00:10] --> Yuv422 has joined #nuvie
[01:45:18] <Yuv422> brb reboot
[01:45:22] <-- Yuv422 has left IRC ()
[01:58:44] --> SB-X has joined #nuvie
[02:01:08] --> Yuv422 has joined #nuvie
[02:02:18] <SB-X> Hi, Eric.
[02:03:33] <Yuv422> Hey Joseph
[02:03:42] <Yuv422> How' s it going?
[02:03:58] <Yuv422> I've got hay fever at the moment
[02:04:06] <Yuv422> damn spring
[02:04:18] <SB-X> I'm fine, nothing as bad as that. :)
[02:04:20] <SB-X> sorry to hear
[02:04:25] <SB-X> about that
[02:04:37] <SB-X> you have frequent allergies?
[02:04:56] <Yuv422> hehe nah just spring mainly
[02:05:01] <SB-X> :\
[02:08:21] <SB-X> I don't either, fortunately.
[02:09:15] <Yuv422> I am allergic to peanuts!
[02:09:22] <Yuv422> which is a big pain
[02:09:24] <SB-X> argh
[02:10:44] <SB-X> sorry to hear about that too :)
[02:10:49] <SB-X> that's got to be annoying, at least
[02:10:57] <Yuv422> yeah it is
[02:11:06] <Yuv422> so many things 'may contain peanuts'
[02:11:12] <SB-X> lol
[02:11:20] <SB-X> I noticed that on wrappers here too.
[02:11:24] <SB-X> packages
[02:11:36] <SB-X> things that don't even have peanuts in the ingredients
[02:11:36] <Yuv422> yeah that's because of people like me. ;-)
[02:11:49] <SB-X> so it's YOUR fault!
[02:11:53] <SB-X> ;)
[02:11:57] <Yuv422> :-P
[02:12:03] <Yuv422> I guess so. :-)
[02:12:33] <SB-X> I've only known one other person who had that allergy.
[02:12:35] <Yuv422> noone wants to get sued so they all stick 'may contain peanuts' on their products
[02:12:41] <Yuv422> ah k
[02:12:57] <SB-X> what can you eat then?
[02:13:34] <Yuv422> I tend to stay away from products that have a peanut version
[02:13:39] <Yuv422> like m&ms
[02:13:51] <Yuv422> or mars/snickers bars
[02:14:07] <Yuv422> chocolate can be a problem too
[02:14:22] <Yuv422> oh and thai
[02:15:13] <SB-X> thai food?
[02:15:19] <Yuv422> yes
[02:15:25] <SB-X> ah k
[02:15:27] <Yuv422> they use lots of peanuts in their food
[02:15:33] <SB-X> never had any myself
[02:15:35] <SB-X> oh
[02:15:52] <Yuv422> I had a bad experience with thai and peanus
[02:16:27] <Yuv422> I ate something with nuts in it.
[02:18:34] <SB-X> eek
[02:19:36] <SB-X> so you know from experience :)
[02:19:55] <Yuv422> yes :(
[02:20:26] <SB-X> what other allergies should we know about?
[02:21:03] <Yuv422> hehe that's it for me really
[02:21:37] <SB-X> ah k
[02:21:42] <SB-X> Good. :)
[02:21:46] <Yuv422> how does this sound
[02:22:05] <Yuv422> new_obj = Obj.moveToMap(obj)
[02:22:10] <Yuv422> in lua
[02:22:28] <SB-X> what is Obj?
[02:22:40] <Yuv422> the object class
[02:22:44] <Yuv422> a table
[02:23:00] <SB-X> ah, so it has a global scope
[02:23:07] <Yuv422> yes
[02:23:15] <Yuv422> it could be a function instead
[02:23:26] <Yuv422> like obj_move_to_map(obj)
[02:23:42] <Yuv422> I've been thinking about how to handle objects in lua
[02:23:50] <Yuv422> I think we have two types
[02:24:01] <Yuv422> an object that is connected to the game engine
[02:24:21] <Yuv422> eg on map, in container or in inventory
[02:24:31] <Yuv422> then we have new objects
[02:24:35] <Yuv422> that are only in lua
[02:25:04] <Yuv422> I need to store these differently so that lua's garbage collection can collect them correctly
[02:25:54] <Yuv422> if you make a new object in lua then move it to the engine it will be converted into an engine obj and returned as a new variable in lua
[02:26:12] <Yuv422> which will be a pointer to the actual C Obj *
[02:26:48] <Yuv422> Obj.SetCanTake(obj, true)
[02:27:05] <Yuv422> Obj.SetTemp(obj, true)
[02:27:39] <Yuv422> inv_obj = Obj.MoveToInv(actor_id, obj)
[02:27:58] <SB-X> what happened to obj?
[02:28:13] <Yuv422> gone
[02:28:22] <SB-X> what happens if you try to use it?
[02:28:38] <Yuv422> hmm
[02:28:48] <Yuv422> I can see this isn't very intuitive
[02:29:17] <Yuv422> I wonder if I can convert the userdata for the obj without needing a new obj
[02:29:30] <SB-X> is it necessary to have the two states? is there any time we need to manipulate an object that doesnt exist in game?
[02:29:39] <Yuv422> yes
[02:29:58] <Yuv422> because you need to make an obj before adding it to the engine
[02:30:22] <Yuv422> and you could make an obj then never use it
[02:30:37] <Yuv422> and we want the gc to remove the object for us
[02:31:19] <SB-X> but does it have to be that way?
[02:31:43] <SB-X> can't we just initialize new objects as being in the game (ie call moveToMap) for new objects
[02:32:11] <SB-X> er, not sure I phrased that correctly
[02:32:34] <SB-X> im wondering if its really helpful to make an obj then never use it
[02:32:52] <SB-X> or if we do that anywhere already
[02:33:08] <Yuv422> we shouldn't allow the script author the chance
[02:33:39] <Yuv422> I can do it with a union
[02:33:55] <Yuv422> the union would be either Obj *
[02:33:57] <Yuv422> or Obj
[02:33:57] <SB-X> true, you could do everything you listed above transparently
[02:34:09] <SB-X> when new objects are made
[02:34:12] <SB-X> what's the difference?
[02:34:20] <SB-X> except one is a pointer
[02:34:34] <Yuv422> if the obj is only in lua then we reference it as a full Obj struct
[02:34:49] <Yuv422> but if it is in the game we reference it via a pointer
[02:35:48] <SB-X> oh i see
[02:35:51] <Yuv422> then the lua gc will remove it correctly
[02:36:12] <Yuv422> and we just convert it when we move it from lua only into the game egnine
[02:37:18] <Yuv422> Obj.location(obj) returns "MAP", "INV", "CONTAINER", "NONE"
[02:37:42] <SB-X> but objects cant be at none
[02:37:57] <Yuv422> none would be only in lua
[02:38:12] <Yuv422> we might need to change the wording there
[02:38:23] <Yuv422> maybe "SCRIPT"
[02:38:27] <Yuv422> or "LUA"
[02:38:42] <SB-X> NONE is fine too
[02:38:55] <Yuv422> it just means that the object isn't being used in the game engine
[02:38:59] <SB-X> that actually makes more sense to me, as long as people know it's not available in the engine
[02:39:07] <SB-X> or maybe SCRIPT_ONLY
[02:39:14] <Yuv422> yu
[02:39:16] <Yuv422> +p
[02:39:18] <SB-X> what kind of situation would we use that in? :)
[02:39:24] <SB-X> or use it for
[02:39:25] <SB-X> *
[02:39:27] <Yuv422> not sure
[02:39:34] <Yuv422> hehe
[02:40:07] <Yuv422> you might want to know if an object is on the map if the object is returned from another script
[02:40:18] <Yuv422> and you don't know where it came from
[02:40:29] <Yuv422> just a thought
[02:40:49] <SB-X> do you know what kind of script would be returning an object?
[02:41:16] <Yuv422> hehe not off the top of my head
[02:41:23] <SB-X> heh me neither
[02:41:41] <SB-X> you mean on the map instead of NONE?
[02:41:44] <SB-X> or SCRIPT_ONLY
[02:41:50] <Yuv422> yes
[02:41:58] <SB-X> ah k
[02:42:16] <SB-X> as for the function name format, obj_move_to_map or Obj.moveToMap, I'm not sure which is better
[02:42:37] <Yuv422> I don't think the script author should have access to obj.status
[02:42:42] <SB-X> the n_ prefix should be on there somewhere
[02:42:46] <Yuv422> in the C struct
[02:43:02] <SB-X> oh, yes, that makes sense
[02:43:03] <Yuv422> n_obj_move_to_map()
[02:43:36] <SB-X> I wasn't so much asking when we would use the location() function.
[02:43:50] <Yuv422> and you can move an object to any location regardless of where it currently resides
[02:44:12] <SB-X> I wonder when we would need to keep an object at NONE or SCRIPT_ONLY location and check for that with the location() function. :)
[02:45:34] <SB-X> Requiring scripts to use location() and moveToMap(), moveToContainer(), or moveToInventory() makes sense and is a better idea than manipulating status directly. That's why I think we should use those functions even in the engine more often. :)
[02:46:08] <Yuv422> yes
[02:46:13] <Yuv422> I agree
[03:01:57] <Yuv422> hmm I can't put an Obj struct in my union because it has a constructor
[03:31:39] <SB-X> it could look confusing to have an Obj and an Obj* in a union anyway, might not be necessary
[03:31:57] <SB-X> are they both userdata types in lua?
[03:32:27] <Yuv422> I'm going with a struct with a pointer and a Obj struct
[03:32:40] <Yuv422> struct ScriptObj
[03:32:40] <Yuv422> {
[03:32:41] <Yuv422> Obj *obj_ptr;
[03:32:41] <Yuv422> Obj script_obj;
[03:32:41] <Yuv422> };
[03:32:53] <Yuv422> if obj_ptr != NULL then it's in the engine
[03:33:07] <Yuv422> otherwise it's script only
[03:33:53] <SB-X> ah k, that's less confusing I suppose... there wasnt much purpose to put an obj* and obj at the same location
[03:34:14] <Yuv422> it saves 3 bytes
[03:34:16] <Yuv422> ;-)
[03:34:35] <Yuv422> because then you just need 1 byte for the type
[03:34:46] <Yuv422> not 4 for the obj pointer
[03:35:15] <SB-X> i thought a union always took the amount of space of the largest type?
[03:35:23] <Yuv422> yes
[03:35:46] <Yuv422> so we would have had 1 byte for the union type then the size of Obj
[03:35:59] <SB-X> union type?
[03:36:01] <Yuv422> now we have the size of Obj * and the size of Obj
[03:36:12] <Yuv422> uint8 union_type
[03:36:18] <Yuv422> so we could tell what was in the union
[03:36:35] <Yuv422> #define OBJ_PTR 1
[03:36:44] <Yuv422> #define OBJ_DATA 2
[03:36:48] <SB-X> i thought the union would have the Obj too
[03:36:50] <Yuv422> something like that
[03:36:54] <Yuv422> yes
[03:37:03] <Yuv422> but you need to know what's in the union
[03:37:06] <SB-X> so it would always be sizeof(Obj)
[03:37:22] <Yuv422> yes
[03:37:46] <SB-X> lol
[03:37:49] <SB-X> ah k
[03:37:50] <SB-X> i see
[03:38:05] <SB-X> it saved 4 bytes over the new structure :)
[03:38:10] <SB-X> 3
[03:38:12] <SB-X> *
[03:38:15] <Yuv422> yes
[03:38:28] <SB-X> what is the type in lua? userdata?
[03:38:38] <Yuv422> yes userdata
[03:39:28] <SB-X> for either object type?
[03:39:43] <Yuv422> hmm just thought of something, what are we going to do with script only containers
[03:40:00] <Yuv422> yes they are one and the same
[03:40:13] <SB-X> i wonder how a person is supposed to compare userdata types in scripts
[03:40:23] <SB-X> if they want to implement multiple userdata types
[03:41:03] <Yuv422> you could make then structs with a common first element
[03:41:13] <Yuv422> which was a type variable
[03:41:21] <SB-X> true, good point there
[03:41:32] <SB-X> that's probably what you're supposed to do
[03:41:59] <Yuv422> I think lua has a gc destructor metamethod
[03:42:01] <SB-X> or should do, if you have multiple types
[03:42:09] <Yuv422> we can use that to clean up the containers
[03:42:09] <SB-X> garbage collector?
[03:42:11] <Yuv422> I think
[03:42:13] <Yuv422> yes
[03:42:27] <SB-X> from what I read so far, gc in lua is automatic
[03:42:43] <SB-X> you're not supposed to worry about it or call any functions yourself
[03:42:44] <Yuv422> yes it is
[03:43:07] <Yuv422> but we need to free userdata when the gc removes our obj
[03:43:18] <SB-X> hmm
[03:43:29] <Yuv422> because it will grow outside the original ScriptObj
[03:43:33] <SB-X> objects in containers arent script objs
[03:43:37] <Yuv422> with the containerised objects
[03:43:44] <Yuv422> hmm
[03:43:47] <Yuv422> good point
[03:43:50] <Yuv422> they will be
[03:44:08] <SB-X> oh
[03:44:13] <SB-X> they will?
[03:44:15] <Yuv422> hmm
[03:44:25] <Yuv422> this could get tricky
[03:44:30] <SB-X> i thought you just said once you move it to a location it moves to an engine obj
[03:44:32] <SB-X> :)
[03:44:46] <SB-X> yes, trying to remember how it works myself :)
[03:44:53] <SB-X> or will work
[03:45:24] <SB-X> im just glad i remembered that point about objects getting converted from script objs to engine objs :)
[03:45:50] <SB-X> is there a way to tell the gc to leave it alone?
[03:45:58] <SB-X> when converting objs we could put them in a global table
[03:45:59] <Yuv422> maybe
[03:46:03] <SB-X> nuvie_objects
[03:46:14] <Yuv422> yeah
[03:46:18] <SB-X> as long as they aren't nil, the gc will leave them alone
[03:46:57] <SB-X> the data anyway, if I know what you're talking about
[03:47:18] <Yuv422> then we make them nil when their parent gets removed
[03:47:58] <SB-X> ok you're talking about containers now, i thought you meant what to do when converting them to engine_obj to prevent lua from freeing them again
[03:48:11] <SB-X> why do containers need to be script_objs?
[03:48:57] <SB-X> or, when would they ever be?
[03:49:05] <SB-X> im not sure
[03:50:41] <Yuv422> I need to think about this a little more
[03:52:26] <SB-X> no problem
[03:52:40] <SB-X> I'm afraid I havn't read enough of the lua manual to be of much help designing Nuvie's scripting engine.
[03:52:58] <SB-X> I know how to use lua tables though.
[03:53:15] <Yuv422> that's a good start
[03:53:22] <Yuv422> everything is a table in lua
[03:53:32] <Yuv422> well it seems like that anyway
[03:53:35] <Yuv422> :-)
[03:53:41] <SB-X> yeah it seems very flexible and simple in construction
[03:54:16] <SB-X> so maybe there arent any advanced tricks to them I dont know yet, but I don't know many functions for manipulating them
[03:54:23] <SB-X> or how to interface them in C
[03:55:42] <SB-X> well except for simple variables, I believe I read about that in the chapter on using Lua for config files
[03:55:50] <SB-X> that's a really cool feature too
[03:57:03] <Yuv422> yeah lua has some neat uses
[04:04:15] <SB-X> should we use that for config files?
[04:04:19] <SB-X> in nuvie
[04:06:35] <SB-X> I mean do you plan to use that for anything?
[04:07:09] <Yuv422> we could use lua for config
[04:57:39] --> Yuv422_ has joined #nuvie
[04:58:47] <-- Yuv422 has left IRC (Read error: 104 (Connection reset by peer))
[05:08:47] --- Yuv422_ is now known as Yuv422
[06:40:17] <Yuv422> you check userdata by looking at the metatable associated with it.
[07:18:19] <SB-X> ?
[07:28:46] <Yuv422> you associate a meta table with the user data
[07:29:02] <Yuv422> then when you get userdata on the stack you check its metatable
[07:29:17] <Yuv422> and if it has the correct name then it is the correct userdata type
[07:29:17] <SB-X> from scripts?
[07:29:27] <Yuv422> from c
[07:29:47] <SB-X> oh, i read a little about the stack to call functions from C
[07:29:48] <Yuv422> there is also a __gc method on the metattable
[07:29:58] <SB-X> how do you set the metadata and read it in lua?
[07:30:09] <Yuv422> which gets called when the gc is about to remove userdata
[07:30:19] <SB-X> cool
[07:31:21] <Yuv422> setmetattable()
[07:31:26] <Yuv422> -t
[07:48:53] <SB-X> ok, so you'd call that in moveTo
[07:49:26] <SB-X> assuming the script passed a script obj
[07:49:37] <Yuv422> yes
[07:49:53] <Yuv422> it will be like this now
[07:50:03] <Yuv422> obj.moveToMap()
[07:52:16] <SB-X> what's obj?
[07:52:26] <Yuv422> the variable
[07:52:31] <Yuv422> obj = Obj.new()
[07:52:41] <SB-X> oh ok
[07:52:42] <Yuv422> obj.frame_n = 1
[07:52:46] <Yuv422> :-)
[07:53:01] <SB-X> that's different from the previous examples
[07:53:05] <SB-X> what about obj = n_Obj.new() ?
[07:53:12] <Yuv422> yeah
[07:53:28] <Yuv422> I'm just playing with ideas at the moment
[07:53:32] <SB-X> ok
[07:53:32] <SB-X> cool
[07:53:51] <Yuv422> they'll end up with n_
[07:53:54] <SB-X> you can also add x,y,z param to moveTo, so you don't need to set the location in a separate call
[07:54:02] <Yuv422> yes
[07:54:24] <Yuv422> or even obj.movetoMap(loc)
[07:54:32] <SB-X> cool
[07:54:41] <Yuv422> where loc is a table {x=1,y=1,z=1}
[07:54:42] <Yuv422> etc
[07:54:51] <SB-X> yes, I forgot that we deal with MapCoords (or the equivalent) in scripts
[08:00:56] <-- SB-X has left IRC ("BRB")
[08:05:05] <-- Yuv422 has left IRC (Read error: 104 (Connection reset by peer))
[08:06:35] --> Yuv422 has joined #nuvie
[08:19:22] --> SB-X has joined #nuvie
[08:19:54] <Yuv422> wb SB-X
[08:20:09] <SB-X> thanks
[08:20:29] <SB-X> I was busy forgot to restart for a few minutes. :p
[08:20:33] <SB-X> and forgot to restart*
[12:29:07] <SB-X> cya
[12:29:08] <-- SB-X has left IRC ("*casts gate travel*")
[12:53:31] <-- Yuv422 has left IRC (Read error: 104 (Connection reset by peer))
[12:54:13] --> Yuv422 has joined #nuvie
[13:02:09] <-- Kirben has left IRC (Read error: 110 (Connection timed out))
[13:34:28] --> Yuv422_ has joined #nuvie
[13:35:26] <-- Yuv422 has left IRC (Read error: 104 (Connection reset by peer))
[14:37:03] --> Yuv422 has joined #nuvie
[14:37:36] <-- Yuv422_ has left IRC (Read error: 104 (Connection reset by peer))
[15:03:50] <Yuv422> time for bed
[15:03:53] <Yuv422> cya
[15:04:06] <-- Yuv422 has left IRC ()
[22:59:36] --> Kirben has joined #nuvie
[23:01:46] <-- Kirben has left IRC (Client Quit)
[23:05:57] --> Kirben has joined #nuvie
[23:55:06] --> SB-X has joined #nuvie