[00:14:34] <watt> nice.
[09:21:21] --> sbx|afk has joined #pentagram
[10:28:59] --> Jett has joined #pentagram
[10:46:43] <-- Darke has left IRC (Read error: 110 (Connection timed out))
[12:15:33] <-- Colourless has left IRC ("casts improved invisibility")
[12:42:03] --> Fl00der has joined #pentagram
[12:52:06] --> MagicMop has joined #pentagram
[13:58:52] <-- Kirben has left IRC ("System Meltdown")
[14:01:59] --- Jett is now known as Darke
[14:15:11] <-- Fl00der has left IRC ()
[14:33:45] <-- MagicMop has left IRC (Read error: 110 (Connection timed out))
[14:33:45] <-- Darke has left IRC (Read error: 104 (Connection reset by peer))
[14:49:15] --> Darke has joined #pentagram
[16:45:55] --> Ember has joined #pentagram
[16:45:56] <-- Darke has left IRC (Connection reset by peer)
[17:18:13] <wjp> I wonder if we should use XML for our data files after all
[17:18:25] <wjp> (not for the config files)
[17:18:45] <wjp> the .ini files are fairly limited when trying to describe things
[17:31:38] --> Ladynix has joined #pentagram
[18:21:07] <sbx|afk> hey wjp
[18:21:10] <sbx|afk> what are you going to do?
[18:24:01] <wjp> hm?
[18:24:12] <sbx|afk> with xml data files
[18:24:47] <wjp> we have some things that were hardcoded in u8 in .ini files in the data/ directory
[18:26:24] <sbx|afk> you can do subsections [text/something]
[18:27:37] <wjp> yeah, I know we _can_ do various things like that, but was just wondering if XML wouldn't be better suited for it after all
[18:28:11] <sbx|afk> don't you use .ini just so it will be easier to edit? that's not really important for the datafiles
[18:28:11] <wjp> for the config file I think .ini is probably a better choice than XML precisely because of its simplicity
[18:28:22] <wjp> exactly
[18:28:44] <sbx|afk> ok
[19:08:02] --- sbx|afk is now known as sbx
[19:54:53] <-- Ladynix has left IRC ("Client Exiting")
[19:55:50] --> Fl00der has joined #pentagram
[20:06:46] <-- sbx has left IRC (Read error: 232 (Connection reset by peer))
[20:31:28] * wjp hmmms...
[20:31:55] <wjp> the avatar's first 'stand up' animation is getting terminated and a second one is started immediately
[20:33:28] <wjp> strange... it's getting killed by usecode
[20:39:39] <wjp> first one is started from AVATAR::cachein
[20:39:45] <wjp> second from FIRST::hatch
[20:41:18] <wjp> both use METHOD::15E7 to call doAnim, and that method calls resetRef first
[20:53:52] <wjp> maybe I'll modify the original's usecode to see which one should be the one that lets the avatar stand up
[21:00:39] <wjp> well, that definitely had an effect, so the FIRST egg is the one that should make the avatar stand up
[21:01:34] <wjp> ...which means the cachein is doing things it shouldn't be doing
[21:17:48] <-- Fl00der has left IRC ()
[21:20:47] --> Fl00der has joined #pentagram
[21:31:45] <wjp> tinkering with AVATAR::cachein seems to have no effect at all
[21:32:00] <wjp> at least not on startup; haven't tried changing maps
[21:47:22] <wjp> indeed, the flag that's set by AVATAR::cachein isn't set in the original after talking to devon
[21:48:08] <wjp> nor in another of my saves further in the game
[21:48:33] <Fl00der> arf
[21:49:21] <Fl00der> hi wjp, what's up?
[21:49:42] <wjp> oh, trying to figure out some subtleties of U8's behaviour :-)
[21:50:16] <Fl00der> :)
[21:53:18] <wjp> that does raise the question if AVATAR::cachein should be called at all anywhere...
[21:59:12] <wjp> ah, yes, it does get called on teleport
[21:59:34] <wjp> hacking the original's usecode is fun :-)
[22:00:00] <wjp> I changed the start of AVATAR::cachein to a 'playEndgame' call :-)
[22:02:27] <Fl00der> :)
[22:05:26] <wjp> right, now let's see if that fixed the issues
[22:17:45] <wjp> oh great... now the avatar plays a standUp animation when changing maps
[22:20:22] <Fl00der> \o/
[22:22:20] * wjp doesn't get it
[22:22:29] <wjp> the original really did play the endgame when I teleported
[22:22:36] <Fl00der> hmm
[22:22:42] <wjp> so what's preventing it from playing that stand animation... *sigh*
[22:23:07] <wjp> more experimenting I guess
[22:23:13] <Fl00der> yay!
[22:24:05] <wjp> the easy way would just be not to call cachein on actors at all...
[22:25:00] * Fl00der doesn't understand at all (much) but it's nice to listen wjp always :)
[22:25:41] * wjp blinks
[22:25:49] <wjp> now that getUp flag _is_ set
[22:26:13] <wjp> so that would explain why he isn't standing up, but what set that flag in the first place... *sigh*
[22:26:32] <Fl00der> seek and repair :)
[22:27:45] <wjp> yes... :-)
[22:31:15] <wjp> hmm...
[22:31:34] <wjp> I wonder if the avatar actually _is_ getting up in the original but you just don't see it because he's hidden by the city walls
[22:32:17] <Fl00der> right...
[22:32:59] <Fl00der> well, anyway, happy coding, I gotta go sleep now, it's 1:33 AM :D
[22:33:24] <wjp> night
[22:33:30] <wjp> no... he's not hidden by the walls
[22:33:32] <wjp> *sigh*
[22:33:38] <Fl00der> sigh
[22:33:39] <Fl00der> well
[22:33:45] <Fl00der> hope you find solution
[22:33:47] <Fl00der> cya, night
[22:33:49] <-- Fl00der has left IRC ()
[22:56:22] <watt> hmm.. I really think XML is not the right answer for any conifgs here... or at very least not the old broken <quote>XML</quote> parser :-)
[22:57:34] <wjp> not config; data files
[22:57:44] --> Kirben has joined #pentagram
[22:57:44] --- ChanServ gives channel operator status to Kirben
[22:57:45] <watt> If ini doesn't handle things in a rebust enough way for us, then a completely custom config would probably be the best bet.... considering that at that point it's not something users should edit
[22:57:58] <watt> s/rebust/robust.
[22:58:23] <wjp> the point of using XML would kind of be that we wouldn't have to write a completely custom parser :-)
[22:58:33] <wjp> gah... I don't get this cachein stuff
[22:58:55] <watt> I assume you mean amour info and moster info by data files
[22:58:56] <wjp> if I put an 'endgame' call at the start of AVATAR::cachein it gets called by the original
[22:59:06] <wjp> yeah, stuff like that
[22:59:25] <wjp> if I put an 'endgame' call at the _end_, it doesn't get called
[23:00:47] <wjp> there's nothing in between that would cause it to terminate, though...
[23:00:52] <watt> yeah.... ini isn't great for that, but it's not something we really want anyone mucking about in..
[23:00:59] <wjp> infinite loop, possibly, but very very unlikely
[23:01:23] <watt> hmmm. i dunno on the usecode
[23:02:41] <wjp> me neither :-(
[23:02:51] <wjp> I'm tempted to just remove the cachein calls for actors
[23:04:13] <watt> change the usecode to fix pentagram ???
[23:05:10] <wjp> I meant the cachein calls in pentagram
[23:05:14] --> Colourless has joined #Pentagram
[23:05:16] <watt> or is this something pentagram is doing?
[23:05:19] <wjp> yes
[23:05:21] <wjp> hi Ryan
[23:05:23] --- ChanServ gives channel operator status to Colourless
[23:05:31] <watt> ok.... ya scared me a bit
[23:05:38] <watt> hiya Colourless
[23:07:37] <Colourless> hi
[23:10:06] <wjp> at times like this I wish the original had that usecode debugger compiled into it :-)
[23:10:31] <watt> Any ideas for the "Not Quite as Broken Targeted Jumping"
[23:10:45] <wjp> in which way is it broken right now?
[23:10:56] <watt> It's just funky.
[23:12:29] <watt> I was hoping for something that works closer to how things might work in reality... jumping up or down too far is the really bad issue... although, jumping up is solved by "You can't jump that high"
[23:13:58] <watt> jumping down should probably repeat frames and never allow z be modified higher than the original.
[23:14:37] <wjp> or do a normal fall with some mild inertia after a while
[23:14:56] <watt> still needs more frames right?
[23:16:04] <wjp> hm, not necessarily; could have the GravityProcess take care of things
[23:17:41] <watt> maybe....
[23:17:54] <wjp> it'll have to special-case falling actors anyway...
[23:18:07] <wjp> (to apply damage)
[23:18:18] <wjp> hm, I should really be going
[23:18:26] <wjp> should've been in bed a while ago :-)
[23:18:40] <watt> then we might be saying that you don't have good accuracy when jumping down... I have no problem with that.
[23:19:08] <wjp> does the original have perfect accuracy when jumping far down?
[23:19:23] <watt> I dunno... time to check
[23:19:43] <wjp> anyway, leaving... good night :-)
[23:20:46] <watt> no, it didn't...
[23:20:51] <watt> night.
[23:21:10] <Colourless> jumping down should probably repeat frames and never allow z be modified higher than the original. < so no gravity?
[23:21:46] <watt> nope.. wjp's right...
[23:22:32] <watt> I actually should simply never modify z and let the gravity process apply inertia... when we add that
[23:27:16] <watt> should I just remove z as an option to the target altogether??? I think yes, but not sure
[23:28:46] --> Fingolfin has joined #pentagram
[23:28:46] --- ChanServ gives channel operator status to Fingolfin
[23:29:28] <Colourless> hmm
[23:32:20] <watt> well, yup, looks like the original never modified z... and it seems to be the right move in pentagram too... although it looks funny without inertia
[23:33:38] <watt> That ttf font looks soooo much nicer
[23:38:18] <watt> hmm.. well considering I still might want to modify my target based on z (x and y targets could if z it less or greater than the current z) I guess the z option should still be there.. but completely ignored.
[23:45:18] <watt> hmmm... and avatar shouldn't jump at sides of objects... the mouse should be over the top face.
[23:48:08] <watt> but then again.. I don't think it does any harm