#nuvie@irc.freenode.net logs for 22 Jul 2007 (GMT)

Archive Today Yesterday Tomorrow
Nuvie homepage


[00:19:21] --> Kirben has joined #nuvie
[02:23:09] <-- SB-X has left IRC (Remote closed the connection)
[02:32:58] --> SB-X has joined #nuvie
[04:39:06] <SB-X> part of the sun appears below the horizon now (at sunset)
[06:27:01] --> luteijn has joined #nuvie
[06:27:07] <luteijn> I thought to try out some maic, but I can't figure out how to move spells into the spellbook; did that ever work, or does move only work to push around things on the map?
[06:33:37] <SB-X> luteijn! well met
[06:33:47] <SB-X> how fare thee?
[06:34:33] <luteijn> Too busy do to do too much fun stuff.
[06:34:47] <luteijn> But otherwise I'm well ;)
[06:35:28] <SB-X> good to hear
[06:35:32] <SB-X> i saw you in the logs though
[06:35:42] <SB-X> join
[06:37:01] <SB-X> bye
[06:37:13] <SB-X> i see you're too busy to play the game
[06:37:33] <SB-X> heh sorry, to answer your question, no it never worked
[06:37:41] <SB-X> guess i'll work on that next
[06:37:50] <luteijn> Tried out the cga graphics mode yesterday; had to clean up some compile errors, but otherwise worked fine. Did you get it to work?
[06:39:08] <SB-X> actually, right now you can still use the mouse to drag spells (or anything) into a spellbook you're holding
[06:39:14] <SB-X> that's buggy obviously
[06:39:19] <SB-X> i havn't tried cga or ega again
[06:40:03] <luteijn> Let me try dragging a spell again, I think it didn't work..
[06:40:16] <SB-X> this is in the scripting branch
[06:40:27] <SB-X> where that code might be a bit older
[06:40:49] <luteijn> Hmm, it just seems to treat it as an attempt toready the spell.
[06:41:35] <luteijn> Ready-spell Can't be readied. maybe I'm doing it wrong..
[06:41:50] <SB-X> unequip the book
[06:43:00] <SB-X> drag an object from the floor
[06:43:22] <SB-X> as you can see, this is unintented behavior we're trying to exploit
[06:43:26] <SB-X> unintended*
[06:43:44] <luteijn> Hmm that just seems to do a 'Get-spell'
[06:44:06] <SB-X> it should get it into your book
[06:44:46] <luteijn> maybe my book is 'wrong' somehow; e.g. not considered a proper container? or I'm dropping the item in the wrong way.
[06:45:00] <SB-X> you're dragging it from the floor?
[06:45:07] <SB-X> and the book is in your inventory but not held?
[06:45:35] <luteijn> yes, spell is on the floor book in inventory, 'drag' spell until over book, then release button to drop it.
[06:46:04] <SB-X> i can put a ship deed into the book
[06:46:54] <SB-X> yes that's odd
[06:47:02] <SB-X> it doesn't work with a spell, i was just assuming it would
[06:47:02] <SB-X> sorry
[06:47:07] <SB-X> try a deed
[06:47:27] <SB-X> or anything else :p
[06:47:35] <luteijn> hmm so actually, maybe there's just a mistake that it's mistaking a deed for a spell?
[06:48:36] <SB-X> i've got an invis. ring, shovel, sword, and sextant in my spellbook
[06:48:58] <luteijn> hmm boomerang didn't work, let me try a sword, I think I have one somewhere
[06:49:47] <SB-X> when dropping the object in inventory, the inventory view changes to the spellbook and the object goes there
[06:49:49] <luteijn> sword also doesn't work; I think my book isn't conuted as a container somehow
[06:50:20] <luteijn> draging the sword into a bag works that way.
[06:51:03] <luteijn> hmm readying the sword from the bag made it disappear.
[06:51:07] <SB-X> well, then no you can't put anything into a spellbook
[06:51:09] <SB-X> hmm
[06:51:17] <SB-X> it's like magic
[06:51:20] <SB-X> you don't need spells
[06:54:02] <SB-X> :)
[06:54:08] <luteijn> If I look at my spellbook, it doesn't say 'container' in the console output..
[06:54:44] <SB-X> doesn't show its contents? try the book at the castle
[06:56:51] <SB-X> perhaps you have an empty one and the game didn't mark it as a container
[06:57:22] <luteijn> yes, I think it's totally empty. probabbly spammed it up
[07:00:51] <luteijn> Meanwhile, my testbag is empty, except for a sword that is considered Readied.
[07:03:01] <SB-X> the engine only considers certain specific objects containers, unless an object contains other objects on load, then it's always considered a container
[07:03:24] <SB-X> i mean, it's always considered a container if it contains other objects
[07:03:37] <SB-X> even if its a tree or a flag or something that's obviously not a container
[07:03:45] <luteijn> I guess the spellbook is not considered a container by default then.
[07:04:29] <SB-X> i'd like to work on merging the scripting branch back to main first
[07:04:39] <SB-X> before fixing anything like that
[07:04:55] <SB-X> unless it's simple to fix...
[07:05:06] <luteijn> yes, definately more important to unify the branches first.
[07:05:51] <SB-X> i think you can't just mark it as a container because then the inventory will let you open it up to look into it, instead of equipping it, when you tab over to it and press enter
[07:06:39] <SB-X> then again, it's letting me equip this spellbook which is a container
[07:06:49] <luteijn> either it has to be a special container that you can't look into, or a special non-container that you can move spells in..
[07:08:03] <SB-X> yes, it has to be specially considered either way... "Only spells can go into the spellbook!"
[07:09:14] <SB-X> did you try the book at the castle?
[07:09:49] <luteijn> I think that would work as it already has some spells in it..
[07:11:15] <luteijn> Let me see if it's still at its spot..
[07:13:00] <luteijn> Yes, that one works as advertised.
[07:13:42] <SB-X> if you change the line for the spellbook in usecode/U6ObjectTypes.h, so that the last field is OBJTYPE_CONTAINER, you will be able to open it and drag spells to it that way from the ground, but it wont be normally equippable then (except by dragging to the equip slot)
[07:13:44] <SB-X> cool
[07:15:44] <SB-X> what do you think of an OBJTYPE_SPELLBOOK that is equippable, can't be looked *into* but will call code to display the spell list, and allows objects of type OBJTYPE_SPELL to be dragged/moved into it?
[07:16:43] <luteijn> Wasn't there an idea to have usecode for things like 'look' 'move-on' 'drop' etc?
[07:17:05] <SB-X> yes, there is already some for look and drop
[07:17:07] <SB-X> good point
[07:18:00] <SB-X> that would handle the displaying of the spell list at least
[07:18:25] <luteijn> probably that would be a nicer way to handle exceptions like this. If there's no special usecode like 'show spell list'
[07:18:41] <luteijn> then default to code for generic item of that type.
[07:19:25] <luteijn> probably means that the event system has to be polished up first...
[07:19:47] <SB-X> well it's not inherited, so it would be tied only to spellbook anyway
[07:20:14] <SB-X> nah, i don't think it's strictly a requirement, but i plan to change event first anyway
[07:22:08] <SB-X> i dont want usecode events for interface actions like "click while in inventory", but for actual gameplay/object-manipulation actions like "move into"
[07:22:23] <luteijn> I think that a lot of the things that need to be fixed to make nuvie finishable use the event system, so if it's fixed/changed we'd probably need to re-implement them anyway.
[07:22:35] <SB-X> so that wouldnt handle looking into the container or not when it's selected, that's an InventoryView issue
[07:23:10] <SB-X> true
[07:23:25] <luteijn> I'd think we could have usecode override what the 'look-<object>' action does.
[07:24:46] <luteijn> e.g. look-<container> would by default 'open up' the container and have that handled by the inventory viewer, but in case of the spellbook, call the spellbook-viewer instead.
[07:26:40] <SB-X> but you dont look at a container to open it, you just select it
[07:27:03] <SB-X> which is what will equip the spellbook
[07:27:16] <luteijn> I wouldn't want to go so far as to be able to override individual clicks, but at the level of the major actions (USE, LOOK, MOVE, 'SELECT' etc)
[07:27:28] <SB-X> so yeah for look that will work but not equip
[07:27:39] <SB-X> actually, we have equip usecode too now that i think about it
[07:27:42] <SB-X> maybe that should be used
[07:28:09] <SB-X> hmm, i think we went over this before, but can you equip a backpack?
[07:28:16] <SB-X> how do we handle that?
[07:28:21] <luteijn> there's no 'back' slot
[07:28:34] <SB-X> hehe, ah k
[07:29:22] <SB-X> have you seen this bug? http://kaldosh.kicks-ass.net:8080/default/phpbb2/viewtopic.php?t=835
[07:29:48] <luteijn> Just selecting something would try 'READY' use code (which for containers would default to open it up)
[07:30:17] <luteijn> is that the look tab cross fingers look at LB's stuff and grab it bug?
[07:31:21] <SB-X> yup
[07:31:42] <SB-X> and yes that's what I meant by equip, we have READY usecode already :)
[07:31:49] <luteijn> I saw the post on the u6o board, but didn't try it out yet or ever accidentally ran into it..
[07:31:56] <SB-X> I guess we just don't use it for opening up bags yet.
[07:32:12] <SB-X> ah ok
[07:32:26] <SB-X> I just tried it minutes ago and it works as advertised.
[07:32:38] <luteijn> I think Nuvie is not affected, which would be a bug in nuvie then ;)
[07:32:54] <SB-X> yep, that's a killer bug though
[07:33:35] <SB-X> well maybe killer is the wrong word, you dont run into it accidentally, but it's a kickass trick let's say
[07:34:24] <luteijn> I was just looking at it in a 'What does it tell us of the internal workings of U6?' way.
[07:35:36] <SB-X> I thought about that too. It's pretty understandable actually. I've seen similar effects with tabbing to inventory before.
[07:36:35] <luteijn> I guess there's some sort of current or active 'character' that's set and not properly popped back to the party becasue of the combination of mouse and keyboard.
[07:36:50] <SB-X> yeah, a bit like nuvie's handling of views
[07:37:51] <SB-X> combine that with the feature that lets you select/drop objects from the currently viewed party member
[07:38:54] <luteijn> I think when I played u6 I just used the mouse to walk, and the keys for most object manipulation
[07:39:51] <SB-X> i was going to ask if you ever used the mouse at all, it was too troublesome for me
[07:40:43] --> Yuv422 has joined #nuvie
[07:40:58] <luteijn> I think I might have also used it to target spells..
[07:41:16] <Yuv422> hi guys
[07:41:22] <luteijn> it's just too long ago to know for sure, but I'm pretty certain I used it for walking..
[07:41:27] <luteijn> Hi Yuv
[07:41:40] <SB-X> hi Yuv
[07:42:51] * Yuv422 catches up on the logs
[07:43:00] <luteijn> Hmm about the sun/horizon thing.. I vaguely remember something about the hills being off by one pixel.. Maybe fixing that broke the sun (i.e. the sun/moons should also be moved up by one pixel?)
[07:43:18] <Yuv422> the sun moons need clipping
[07:43:54] <Yuv422> We I changed the positions to match the original they poked out the bottom. :)
[07:44:11] <-- SB-X has left IRC ("*casts gate travel*")
[07:44:28] --> SB-X has joined #nuvie
[07:59:45] <SB-X> oops, oh, that explains it
[08:00:14] <SB-X> (replying to what Yuv422 last said)
[08:00:45] <SB-X> you could just use an SDL_Rect when blitting those tiles
[08:01:02] <luteijn> just draw a 'yellow' line underneath the hill ?
[08:01:19] <SB-X> it has to be 'bg_color' :)
[08:01:25] <Yuv422> hehe
[08:19:32] <SB-X> oh yeah...
[08:20:33] <SB-X> Yuv422: Did you say Obj.use(obj) is just the normal way to USE an object from scripts?
[08:20:45] <Yuv422> fomr memory
[08:20:48] <Yuv422> from
[08:20:49] <SB-X> I don't remember clearly what you told me for some reason.
[08:20:54] <SB-X> ah ok
[08:21:09] <Yuv422> let me check
[08:21:20] <SB-X> also, why did you rename get_obj_container() to get_container_obj()?
[08:22:02] <Yuv422> Obj.use() just calls usecode->use_obj(obj,actor);
[08:22:11] <Yuv422> with actor being the caster
[08:22:36] <Yuv422> hmm now that's an interesting one
[08:22:59] <Yuv422> might have been more inline with some other method names
[08:23:04] <Yuv422> not too sure
[08:23:16] <SB-X> ok! i think it's better that way too
[08:23:42] <Yuv422> I see Event as being more a message broker
[08:23:51] <Yuv422> where objects ask for actions
[08:24:14] <Yuv422> I'd like to get some of the engine specific logic out.
[08:24:17] <SB-X> and you fixed anything that used the function, so np there
[08:24:43] <SB-X> get_container_obj is unambiguous
[08:25:23] <Yuv422> do you tihnk mapwindow should handle more map related taks
[08:25:26] <Yuv422> tasks
[08:25:31] <SB-X> i just thought i'd ask in case it was meant to do something different
[08:25:35] <SB-X> well, yes
[08:25:37] <Yuv422> righto
[08:25:46] <Yuv422> I'm reviewing Event now
[08:25:54] <SB-X> ok
[08:26:20] <Yuv422> I might start by writing down all the functions it currently does
[08:26:35] <Yuv422> then we can see if they should be handled elsewhere
[08:26:39] <SB-X> rather than changing anything right away, let's share ideas for the new Event
[08:26:46] <Yuv422> yes
[08:26:51] <SB-X> what happened to Nuvieki?
[08:27:19] <SB-X> i want to merge the scripting branch into main before improving Event first anyway
[08:27:33] <Yuv422> yeah that sounds good
[08:27:42] <Yuv422> we can have a new event branch. ;-)
[08:28:48] <SB-X> im fixing Drop objects with Drag-n-drop at the moment
[08:28:58] <Yuv422> ah k cool
[08:29:07] <Yuv422> I noticed that that wasn't working properly
[08:30:27] <SB-X> it's because drop_select() expects mode to not be INPUT_MODE, but it is because drop_start() set it and the mode was never reverted to DROP_MODE
[08:32:47] <Yuv422> ah k
[08:34:34] <SB-X> anyway, it's just due to me not considering drag-n-drop when last working on event
[08:35:20] <SB-X> so what happened to Nuvieki?
[08:38:58] <servus> OK I gotchya! How about those website updates I mentioned? *grin*
[08:41:29] <Yuv422> hmm....
[08:41:42] <Yuv422> very sneaky
[08:41:54] <luteijn> it is still there..
[08:42:06] <SB-X> servus: we decided not to update the website for another year
[08:42:24] <Yuv422> the yearly update
[08:44:23] <servus> But... the gallery goes the wrong direction and people always see the oldest and least impressive screenshots... :)
[08:44:33] <servus> Doesn't that make the project look... dead?
[08:45:20] <SB-X> oh, that... I agree it goes in the wrong direction
[08:46:06] <Yuv422> how about we post a news article when we merge scripting back into the main branch
[08:46:57] <SB-X> sure, that may take a week
[08:47:19] <Yuv422> there's no real hurry
[08:47:37] <SB-X> what about the gallery?
[08:47:49] <Yuv422> is that a code change?
[08:48:27] <SB-X> yes
[08:48:39] <servus> Am I part of the Nuvie sf group? Maybe I can do it :-p
[08:48:43] <Yuv422> probably not a big one I'd imagine
[08:48:53] <Yuv422> let me check
[08:49:20] <SB-X> the newest screenshots are pretty old though
[08:49:35] <Yuv422> servus: yes you are
[08:49:52] <Yuv422> feel free to change it
[08:49:57] <servus> Yeah! We need lighting and stuff - to look like a past-alpha project :)
[08:50:02] <servus> ok!
[08:50:10] <SB-X> it's still pre-alpha
[08:50:21] <servus> Really? Well, it's looking pretty good... :)
[08:50:31] <SB-X> well maybe alpha... we havn't released anything
[08:51:00] <Yuv422> servus: we just need to update it with the script
[08:52:04] <servus> Script? Is it OK if I edit index.php directly?
[08:52:57] <Yuv422> sorry I mean actually updating the the website
[08:53:02] <Yuv422> on the shell server
[08:53:04] <Yuv422> from cvs
[08:53:28] <Yuv422> if that is the logical place then feel free
[08:53:59] <SB-X> there is also a list file you can edit to specify which pictures get shown on the front page
[08:54:36] <Yuv422> bbl dinner time
[09:01:55] <servus> OK, screenshots reversed. Another trivial task accomplished *gigglemoos and scampers off* I incidentally ran into random Ultima VI hacking issues the other day. :)
[09:14:46] <SB-X> oh?
[09:22:55] <servus> Turns out LZMAP is encoded a similar way as another older game's files by New World Computing :)
[09:25:13] <SB-X> oh, interesting, just LZW compressed?
[09:25:38] <servus> Yeah, and it turns out the only non-GIF implementation out there seems to be U6Decode :-p
[09:26:04] <servus> Ended up practically rewriting it anyway, but still! *grin*
[09:26:41] <SB-X> hehe
[09:26:45] <SB-X> what game?
[09:30:24] <servus> http://www.mobygames.com/game/dos/tunnels-trolls-crusaders-of-khazan
[09:31:56] <SB-X> gameplay looks like ultima
[09:31:58] <SB-X> is it any good?
[09:32:48] <servus> It's very much based on the pen-and-paper; the gameplay is pretty deep. It looks fairly good (I honestly haven't really played it:P)
[09:33:39] <SB-X> are you going to code a new engine for it?
[09:34:41] <servus> It's bad luck to say so at this point. Just poking at it with a certain bunny : o)
[09:52:49] <luteijn> for reference: http://luteijn.xs4all.nl/nuvieki
[10:58:20] <SB-X> luteijn: wasn't it linked from the website before?
[11:18:42] <luteijn> I doubt it, as it was for our own use.. I wonder how servus fixed the screenshots, and if they revert back to the wrong way when/if I run the web update script..
[11:20:13] <SB-X> hmm
[11:20:17] <SB-X> go for it :)
[11:20:40] <SB-X> we could use a few ega/cga screenshots
[11:22:03] <luteijn> ah nuvieki is under contact, not links
[11:23:05] <luteijn> I'll try to preserve the new order instead of blindly running the script ;)
[11:24:00] <SB-X> i see it now, thanks for reminding me
[11:24:26] <SB-X> why is there a page called SB-X with a note from you?
[11:24:52] <SB-X> about not putting speculative links on your pages? it also says "Describe sbx here."
[11:25:25] <SB-X> and it's orphaned!
[11:27:10] <luteijn> I forget. probably you made a link to a variant spelling of sbx on a somewhere?
[11:28:01] <SB-X> I forget too.
[11:29:15] <luteijn> actually reading the page, I think it's because I made a link to 'SB-X' or it got made automatically somewhere, and I didn't want it to be a dead link. But if it's orphaned.. ah SB-X redirects to sbx and sbx is probably not orphaned but used somewhere.
[11:30:46] <SB-X> that whole paragraph is bright red
[11:31:04] <SB-X> in x-chat
[11:31:48] <SB-X> not that you cared to know that, but... ow my eyes!
[11:31:51] <SB-X> ...
[11:31:54] <luteijn> Maybe because it is in a little box? ... We should add a question to the FAQ. Is nuvie dead? No.
[11:32:20] <luteijn> or maybe because it is a slightly redish dark brown on yellow in reality
[11:32:27] <SB-X> heh, that's a good answer
[11:32:47] <SB-X> i meant red text of what you just said in x-chat
[11:32:59] <SB-X> anyway, will we update that answer if nuvie is ever dead?
[11:33:05] <luteijn> No is also a good answer ;)
[11:33:19] <SB-X> that's what i said
[11:33:29] <SB-X> it's also a good question though
[11:33:53] <luteijn> of course we won't update the answer, because that would mean we're still working on the project, so it wouldn't be dead, (loop)
[11:34:08] <luteijn> SB-X is mentioned so this is bright red?
[11:34:15] <SB-X> yes
[11:34:37] <SB-X> how will people know if nuvie is dead?
[11:34:49] <SB-X> that's dishonest if we say no
[11:35:31] <SB-X> unless we say "No. (at the time of this writing)" or "No. (unless it is, and we have just not updated this FAQ)"
[11:35:32] <luteijn> well no, it wasn't dead when we wrote that, so we're not lying.. maybe we could do "No (last updated 20070722)"
[11:35:57] <SB-X> that's good too
[11:36:05] <SB-X> but make the date auto-updating in case we forget to update it
[11:36:13] <SB-X> since if it gets too far out of date people will assume nuvie is dead
[11:36:14] <luteijn> (actually the SB-X page on nuvieki is bright red in links..)
[11:37:55] <SB-X> (interesting coincidence... the text is the same color as on any other nuvieki page in firefox)
[11:38:40] <luteijn> (Then I suppose the text is red everywhere else in links too, let me verify that)
[11:39:49] <luteijn> (verified.)
[11:40:18] <SB-X> (haha, ok then...)
[11:40:27] <SB-X> why are you using links anyway?
[11:40:32] <luteijn> nuvie.sf.net only has reddish brown headings, but the actual text is black( rendered as white)
[11:40:55] <SB-X> why is the text red anyway?
[11:41:05] <luteijn> well you mentioned X-chat, and I thought 'Does that have a webbrowser build in? In that case it would probably only have basic colors... )
[11:41:38] <luteijn> the text is brownish red because U6 has brownish red colored text on the message-scroll
[11:41:43] <SB-X> nope
[11:42:26] <SB-X> well its not really red then, it's brownish red
[11:42:37] <SB-X> or what i call brown
[11:43:21] <SB-X> is that why links makes it red?
[11:43:21] <luteijn> well links things it's more red than brown and renders it in red..
[11:43:33] <SB-X> i thought it was some preset color for text
[11:43:47] <SB-X> it probably looks more brown on yellow
[11:44:40] <luteijn> the 'earth' in U6 always looked red to me, I guess it is supposed to be a kind of brown.
[11:45:02] <Yuv422> yeah I thought it looked red too
[11:45:11] <SB-X> it looks red to me too
[11:45:48] <SB-X> but the same color seems different on yellow :)
[11:45:56] <Yuv422> I was thinking objects could register hotkeys with Event
[11:46:07] <Yuv422> ctrl-q
[11:46:10] <Yuv422> alt-123
[11:46:18] <Yuv422> a for attack
[11:46:35] <Yuv422> then the corresponding class could handle the logic
[11:46:53] <Yuv422> You could also request input from Event by proxy for other objects
[11:47:02] <Yuv422> Event::get_map_target()
[11:47:20] <Yuv422> Event::get_msg_scroll_input
[11:47:33] <Yuv422> it would get the input then return it to you in a callback
[11:47:41] <SB-X> i dont like callbacks
[11:47:51] <Yuv422> why?
[11:47:56] <SB-X> but i guess we have to use them
[11:48:38] <Yuv422> then we can stack event requests
[11:48:39] <SB-X> because how we've done them you have to inherit from a callback class
[11:48:55] <Yuv422> only to get the callback definition
[11:49:04] <SB-X> and use pointers to the untyped data
[11:49:15] <SB-X> and casting it to some other type
[11:49:44] <SB-X> just dont like the way it looks, guess its a style viewpoint
[11:49:50] <SB-X> what do you mean stack event requests?
[11:50:08] <Yuv422> get input, get map coord, quit
[11:50:32] <SB-X> where do you get the callback def?
[11:51:17] <luteijn> (servus just changed the checked out copy of index.php as far as I can tell. luckily it is only one line where my $c is replaced by $total-$c a few times. fixing...)
[11:51:44] <SB-X> (?)
[11:53:27] <Yuv422> we need to unify the two callback classes
[11:53:53] <Yuv422> we have one type from GUI and another for nuvie specific callbacks
[11:54:31] <Yuv422> we need callbacks for scripting
[11:57:19] <luteijn> (updated the file in cvs, now just have to wait for anonymous CVS to 'catch up')
[11:57:19] <SB-X> i prefer callbacks if they are contained in a client object, where a manager class has a constant loop checking for messages from registered callback classes... seems cleaner that way
[11:57:39] <SB-X> but yeah, the ones we have should at least inherit from the same general type
[11:57:53] <SB-X> (?)
[11:59:24] <SB-X> one problem with callbacks is if they are part of a managed class that gets deleted (like Obj*) and can't report the deletion to everything that registered it, for example
[11:59:47] <SB-X> i think that was the main problem i was having with usecode before, just remembered :)
[11:59:56] <Yuv422> ah k
[12:00:08] <luteijn> re (?). The website is stored in CVS too, and the 'live' website is a checked out version of the anon CVS.
[12:00:11] <Yuv422> well we have a new garbage collector for objects
[12:00:22] <Yuv422> we could keep them alive untill they get a callback
[12:01:00] <Yuv422> or design the logic to only delete if no callbacks are pending
[12:01:01] <luteijn> or cancel outstanding callbacks somehow..
[12:01:08] <SB-X> oh yeah, we can work around it somehow
[12:01:29] <SB-X> should be easier with the new garbage collector
[12:02:31] <SB-X> luteijn: so it was just that the live webpage was updated but not the cvs version?
[12:02:51] <luteijn> yup
[12:03:12] <SB-X> ah k, i see
[12:03:21] <luteijn> breaking the web update,, becuase it will see a modified file and not update it..
[12:03:59] <SB-X> that's no good
[12:04:09] <SB-X> except that we don't care to update the website anyway
[12:04:15] <SB-X> but we might someday
[12:04:33] <SB-X> Yuv422: is there a function to get the "root container" of an object?
[12:04:44] <luteijn> well we want to soon, it's been almost a year.. slightly less for the screen shots, I added some in september I think.
[12:04:57] <luteijn> root: I think so.
[12:04:58] <SB-X> someone should add some ega/cga shots :)
[12:05:21] <Yuv422> SB-X: I thought I added one but I'm not too sure now
[12:05:29] <luteijn> maybe tomorrow I'll take a few.. or move the ones from the temp dir into the regular dir and update the description file.
[12:05:40] <SB-X> ok
[12:06:46] <SB-X> I didn't know there was such a function... check out my version at usecode/U6UseCode.cpp:2512. :)
[12:06:49] <luteijn> Yuv422: only raw shots, no description etc yet.
[12:07:01] <SB-X> (scripting branch)
[12:08:10] <luteijn> I think I made one, but maybe I didn't.. Just walk up parent links unless the parent you are about to step to has no parent itself.
[12:08:31] <Yuv422> SB-X: looks good
[12:08:57] <Yuv422> we should make a method on stick it in Obj
[12:09:08] <Yuv422> but parent can be an actor
[12:09:10] <Yuv422> ;-)
[12:09:17] <Yuv422> if in inventory
[12:10:19] <Yuv422> luteijn: do you think we should keep the screenshots at 1x
[12:10:27] <luteijn> ok looking at the loop you made it seems familiar. I probably did something similar and didn't put it in its own little function..
[12:10:28] <Yuv422> for the main page.
[12:10:54] <luteijn> Yuv422: IIRC, I have a mainpage version at 1x and a fullscreen version you get when you click on it.
[12:11:05] <Yuv422> ah k cool
[12:11:14] <luteijn> although all my own screen shots are probably both the same file at 1x scale
[12:14:05] <luteijn> SBX: it looks familliar, I have an 'is_held()' function in objmanager.h that checks if an object is held by actor.
[12:15:50] <SB-X> Yuv422 renamed it to is_in_inventory()
[12:16:25] <SB-X> it now has a boolean flag you can set to false to mimic the old is_in_inventory() behavior
[12:17:13] <SB-X> in this case i just wanted the top-most container object, even if held by an actor
[12:17:13] <luteijn> ah so it can see if it is directly in inventory or nested in bags but ultimately in inventory
[12:17:36] <SB-X> actually i assumed it wasnt held by an actor since i'd checked that case already
[12:17:37] <SB-X> yes
[12:17:49] <Yuv422> ok I'm off to bed now
[12:17:52] <Yuv422> cya
[12:18:03] <SB-X> ok
[12:18:07] <Yuv422> I'll work on my Event notes
[12:18:09] <SB-X> i still have to look up some of these lua functions
[12:18:12] <SB-X> alright, cya
[12:18:15] <Yuv422> hehe cool
[12:18:24] <Yuv422> I have the lua book
[12:18:29] <Yuv422> it's quite good
[12:18:37] <SB-X> nice ;)
[12:18:44] <luteijn> I have to do some more real work.. see you later
[12:18:47] <SB-X> i'll just use the website
[12:18:52] <SB-X> bye
[12:19:07] <Yuv422> cya guys
[12:19:17] <-- Yuv422 has left IRC ()
[14:33:46] <-- Kirben has left IRC (Read error: 110 (Connection timed out))
[15:04:03] <-- SB-X has left IRC ("*casts gate travel*")