[00:36:10] --> Kirben has joined #pentagram
[00:36:10] --- ChanServ gives channel operator status to Kirben
[12:47:39] --> wjp has joined #pentagram
[12:47:39] --- ChanServ gives channel operator status to wjp
[14:56:00] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[15:02:54] * DarkeZzz rewrites a large chunk of Code That Sucks(tm). Y'know, I've come to the conclusion that not even interactions between bugs in the preprocessor/compiler/code could make code this amazingly pathetic work. We'll blame Cosmic Rays, that's it.
[15:03:44] <wjp> :-)
[15:03:46] <wjp> that bad? :-)
[15:04:07] <DarkeZzz> Yes. *grin*
[15:04:51] <wjp> hmm... isGameRunning()... what an interesting intrinsic
[15:05:59] <wjp> I wonder if that's to distinguish between game/editor
[15:06:21] <wjp> it seems to control triggering traps in chests
[15:06:28] <DarkeZzz> I made one change to internal compiler logic which threw the entire front end (which walks through compiling multiple files, failing cleanly on a compile error) into an infinate loop. This Should Not Have Happened, and upon looking at the dog's breakfast of a code, I'm still trying to work out why. Or rather, I'm in the middle of rewriting it 'cause I can't work out why. *grin*
[15:06:30] <wjp> (among other things, probably)
[15:06:37] <DarkeZzz> That would make sense.
[15:16:43] <DarkeZzz> Hmm... was some of the isGameRunning() stuff not successfully #if-ed out like a lot of it seems to have been? Or was it a case of their #ifdef stuff being too dumb and having to store the isGameRunning() value into a temporary variable, then #if(var) testing that? (Which of course would have left the store in the code.)
[15:17:13] <wjp> it's used in usecode
[15:19:43] * DarkeZzz nods. He gets the feeling he did some research into this a while back, but doesn't remember anything in specific about it. Needs a memory upgrade or something, he does.
[15:22:01] --> Colourless has joined #Pentagram
[15:22:01] --- ChanServ gives channel operator status to Colourless
[15:22:04] <DarkeZzz> Unless they cut&pasted a lot of code, their sub classing must have literally dragged the entire function structure of the parent into it, and just dumped it out into the appropriate functions. There's an aweful lot of repeating code in here.
[15:22:24] <DarkeZzz> Greetings Great Dragon. *bow*
[15:22:25] <Colourless> hi
[15:22:27] <wjp> hi
[15:22:54] <wjp> Colourless: what's the point of the 'shape' variable in Gump?
[15:23:06] <wjp> (if it can only be drawn at (0,0), that is)
[15:24:08] <Colourless> ah ha. it doesn't have to be drawn at 0,0
[15:24:15] <Colourless> you can change the local coords of the gump :-)
[15:24:35] <wjp> so the "(always painted at 0,0)" is relative to the gump?
[15:24:40] <Colourless> yes
[15:24:44] <wjp> how interesting :-)
[15:24:47] <Colourless> dims.x and dims.y represent the offset
[15:24:57] <wjp> ok, so a container gump would just set shape to the right shape
[15:25:06] <Colourless> anyway, i checked all the gump shapes, and they all are at 0,0 :-)
[15:27:08] <Colourless> yes
[15:27:33] <Colourless> i 'attempted' to make everything as simple as possible, in a complex manner
[15:28:53] <wjp> I seem to remember something about a container gump's position being relative to the container
[15:29:00] <wjp> (so if you or the container moves, the gump would move too)
[15:29:06] <Colourless> yes it does
[15:29:18] --- DarkeZzz has changed the topic to: http://pentagram.sf.net/ An ActionRPG Operating System where we're attempting to make everything as simple as possible, in a complex manner.
[15:29:19] <wjp> can ItemRelativeGump keep a gump at an offset?
[15:29:30] <Colourless> yes in theory it 'should' work
[15:29:38] <wjp> DarkeZzz: add that to the quotes? :-)
[15:29:39] <Colourless> i never tested it though
[15:30:04] <Colourless> the Gump::x and Gump::y are set to 0
[15:30:06] <DarkeZzz> wjp: Colourless can. He's rather good at adding his own quotes. *grin*
[15:30:57] <Colourless> you should make sure that if you want to know a gumps position relative to it's parent you should the GumpToParent
[15:30:59] <Colourless> function
[15:31:47] <Colourless> ItemRelativeGump::ix and iy are the items location relative to the parent of the ItemRelativeGump
[15:31:57] <DarkeZzz> wjp: Of course we're still missing you saying anything overly weird, surreal, wize, perverted, or Just Plain Dumb(tm). You shall have to rectify that sometime. *grin*
[15:32:28] <wjp> DarkeZzz: that's just because I never say anything weird, surreal, perverted or Just Plain Dumb(tm) :-)
[15:32:41] <Colourless> so you can change Gump::x and Gump::y and it will still stay relative to the item
[15:32:42] <wjp> I should rectify the wise part sometime, though ;-)
[15:34:44] * DarkeZzz thinks he's got an almost full hand, one of these days he'll get a 'wise' quote in there.
[15:45:25] <wjp> Colourless: how would you construct a ContainerGump? I was thinking of passing it an x,y,shape,frame, but I need a width/height for the ItemRelativeGump constructor
[15:46:08] <Colourless> you could pass a dummy width,height
[15:46:25] <Colourless> i do that with the BarkGump
[15:46:40] <Colourless> i just set it after with the correct width and height
[15:46:54] * wjp nods
[16:12:38] <wjp> ok, using a barrel/basket now pops up a container gump
[16:12:48] <wjp> now let's draw its contents...
[16:15:03] <Colourless> are you setting the 'Item::gump member' ?
[16:15:27] <Colourless> not that it matters yet
[16:15:33] <Colourless> but it will
[16:15:51] <Colourless> once i update the ItemRelativeGump code
[16:15:56] <wjp> yes
[16:17:17] <Colourless> hmm,
[16:17:22] * Colourless thinks for a moment
[16:17:33] <Colourless> ItemRelativeGump.... will cause some interesting behaviour for containers
[16:17:57] <Colourless> bascially when you drag a gump, it will also drag the gumps of any item within that container too
[16:18:24] <wjp> I don't think the original did that
[16:18:31] <Colourless> no it didn't :-)
[16:19:06] <Colourless> i'll probably change that sometime in the future
[16:20:32] <Colourless> probably just have a flag that makes it always stay relative to the 'base' object in the world rather than attempt to get the coords of the heighest item in a gump
[16:30:46] * DarkeZzz yawns and decides to slip off to sleep and dream of taking over the world 'n stuff... or something. Nighties!
[16:30:58] <Colourless> cya
[16:31:11] <Colourless> i think i'll be off now too
[16:31:15] <-- Colourless has left IRC ("casts invisibility")
[18:00:01] <-- wjp has left IRC ("bbl")
[18:00:35] <-- DarkeZzz has left IRC (sterling.freenode.net irc.freenode.net)
[18:00:54] --> DarkeZzz has joined #pentagram
[18:11:35] --> SB-X has joined #pentagram
[18:29:27] --> wjp has joined #pentagram
[18:29:27] --- ChanServ gives channel operator status to wjp
[21:42:09] --- SB-X is now known as sbx|sleep
[21:42:15] * sbx|sleep is away: ZzzZzz