[00:19:04] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[00:19:10] --> Kirben2 has joined #pentagram
[00:40:52] --- Kirben2 is now known as Kirben
[00:59:34] <-- Kirben has left IRC ("System Meltdown")
[01:01:43] --> Kirben has joined #pentagram
[01:01:43] --- ChanServ gives channel operator status to Kirben
[03:35:02] <watt> ugh. I'm trying to write some new key event handling code and I'm getting this error.
[03:35:02] <watt> kernel/event/QuickSaveHandler.cpp: In member function `virtual bool
[03:35:03] <watt> QuickSaveHandler::IsOfType(const RunTimeClassType&)':
[03:35:03] <watt> kernel/event/QuickSaveHandler.cpp:25: error: cannot call member function `
[03:35:04] <watt> virtual bool EventHandler::IsOfType(const RunTimeClassType&)' without object
[03:35:36] <watt> Which is a total 'huh?' for me.
[03:57:27] <watt> oh duh.. I'm extremely retarded.
[04:11:15] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[04:12:34] --> Kirben has joined #pentagram
[04:12:34] --- ChanServ gives channel operator status to Kirben
[04:19:34] <watt> hmm.. but including GUIApp.h is causing many errors in one of my sources
[04:59:41] <watt> and now it works fine? .. ok. I guess it just needed to succeed at compiling once to set up other things it needed to allow the inclusion of GUIApp.h
[04:59:45] <watt> meh?
[06:38:33] --> Colourless has joined #Pentagram
[06:38:34] --- ChanServ gives channel operator status to Colourless
[06:39:02] <Colourless> hi
[06:48:18] <watt> hey.
[07:02:34] <watt> I've been making really bad names for the classes I'm writing in this patch.. the last one was "BackpackOpenHandler"
[07:02:52] <watt> I think I'd better change the names before submitting the patch
[07:03:07] <Colourless> what exactly would that do?
[07:03:19] <watt> the class or the name?
[07:03:25] <Colourless> the class
[07:05:12] <watt> it's an "EventHandler". The event handlers will be bound to keys and used in GUIApp's handleEvent()... basically that one just opens the backpack.
[07:05:47] <Colourless> hmmm
[07:05:54] <watt> I'm hoping my idea allows for configurable keys without speed issues
[07:06:26] <watt> rips out most of the switch logic as well when I finish
[07:06:35] <Colourless> depending on what you are doing it may not fit the over plan of things.
[07:06:53] <Colourless> you see, key handing isn't intended to be in GUIApp ones things are a little more fleshed out
[07:07:04] <Colourless> there is a lot of temporary code still in pentagram
[07:07:21] <Colourless> keyboard code is one huge example.
[07:08:00] <watt> I noticed. I'm hoping this will be flexible enough.. if not.. at least I'll learn as I do it.
[07:09:02] <Colourless> if it is, then that is fine... it will just likely be moved somewhere else :-)
[07:09:20] <Colourless> since we will have key binding at some point, where it would be i don't think anyone has exactly decided
[07:09:41] <Colourless> anyway using the name 'EventHandler' is a bit too generic, if they are only specifically for handling keyboard input
[07:09:50] <Colourless> should be something like KeyInputHandler
[07:11:32] <watt> hmm.. Good idea.. I'm trying to think if I could have mouse work on it as well.
[07:12:35] <Darke> PeripheralInputHandler would work in that instance too. Could even drop joystick support in it without even changing the name. *grin*
[07:12:52] <watt> hmmm...
[07:12:54] <Colourless> HumanInterfaceDeviceInputHandler ?
[07:13:04] <Colourless> :_)
[07:13:05] <Darke> HIDHandler would work.
[07:13:07] <Colourless> uh
[07:13:09] <Colourless> :-)
[07:13:14] * Darke fixes Colourless' nose.
[07:14:05] <watt> I like it.
[07:14:24] <Darke> I think input handling (at least this part of it) would be tightly tied to GUIApp, if not directly inside of it. Though it'd be better if it was a bit more seperated.
[07:14:38] <Darke> What? Colourless' nose? Or the class name?
[07:14:50] <watt> both.
[07:14:54] <Darke> Cool.
[07:15:05] <Colourless> thinking about it. the default input handler, which would handle bound key might be placed in the GUIApp
[07:17:12] <Colourless> somewhere you'd have support for loading a key binding file, maybe just be specifing a filename
[07:17:26] <Colourless> that would be grabbed from the user config file, or the game definition config file
[07:17:32] <Colourless> (for defaults)
[07:18:30] <Colourless> it would probably be usefuk non game GUIApps to also also support the keybinding interface, even if they don't support keybinding files
[07:19:44] <Colourless> if the HIDHandler or whatever class is flexible enough, having an method such as GUIApp::BindKey(int scancode, HIDHandler &) would allow an easy method to set keys
[07:20:16] * Colourless thinks for a second or two
[07:20:28] <watt> I'm thinking the regular pentagram.cfg could work for storing the keybindings - <key value="toggle_combat" first="c" second="Tab" />
[07:20:46] <Colourless> that will not be suitable in the long run
[07:20:55] <Colourless> pentagram will support multiple game types
[07:20:56] <watt> hmm.. too large/
[07:21:03] <watt> ah
[07:21:14] <Colourless> which do not have compatible key settings
[07:21:35] <Colourless> anyway, being able to re-use key binding stuff in gumps themselves might be somewhat useful
[07:22:39] <Colourless> so it might be useful if the keybinding stuff wasn't in GUIApp...
[07:23:18] <Colourless> but, if needed it could be moved at a later time
[07:25:14] <watt> that's about the idea I was running on.. then handleEvent() would only have to look up the key in a map (or some other more appropiate collection) and run a method.
[07:25:31] <watt> Basic Command Pattern.
[07:26:05] <watt> somewhat.
[07:27:27] <watt> actually maybe in this case it's closer to a strategy.
[07:28:33] <Colourless> using an array of pointers would be fastest
[07:28:39] <watt> Commands are usually undoable and redoable if I'm not mistaken
[07:29:23] <watt> are the scancodes mostly sequential?
[07:29:25] <Colourless> an array would be made to be of size SDLK_LAST for keyboard
[07:30:01] <Colourless> look in SDL_keysym.h for all the sdl keyboard 'scan codes' :-)
[07:30:45] <watt> oh.. well that would make a nice lookup time.
[07:31:18] <Colourless> mouse and joystick stuff (which actually will be supported, in case you didn't realize) will have their own 'arrays' or whatever
[07:33:14] <Colourless> also, in case you don't already, if you do any string comparisons, try to do them case insensitive. Q_strcasecmp is in the sources for just that purpose
[07:33:34] <watt> right.. thanks..
[07:39:02] <Colourless> hmmm
[07:39:14] <Colourless> using an array may not actually be 'wise'
[07:41:09] <Colourless> it would be nice if pentagram would automatically support all the keys supported by the SDL binary, and for it not to actually be hard coded
[07:42:04] <Colourless> sdl has the function SDL_GetKeyName(SDLKey key) which will return the key name for a key
[07:46:01] <Colourless> SDL_GetKeyState(int *numkeys) can be used to obtain the number of keys supported by the current implementation
[07:47:00] <Colourless> using those 2 in combination, means you shouldn't have to hard code the supported keys
[07:47:07] <Colourless> it would just be automatically supported
[07:53:55] <Colourless> you might for example on startup get the number of keys. create a Map that mapped the string names of the keys to a SDLKey code, which you would use for reading the keybinding file.
[07:54:28] <Colourless> you would then create an array HIDHandler* of the size of the number of keys, which you would use for the key mappings
[07:54:41] <Colourless> s/mappings/beindings/
[07:54:49] <Colourless> s/beindings/bindings/
[08:13:37] <watt> I love the execution scene.
[08:39:02] <-- Colourless has left IRC ("bbl")
[09:49:28] --> Colourless has joined #Pentagram
[09:49:40] --- ChanServ gives channel operator status to Colourless
[12:17:03] --> wjp has joined #pentagram
[12:17:03] --- ChanServ gives channel operator status to wjp
[12:57:59] <wjp> wasn't the hanoi puzzle working at some point?
[12:58:24] <wjp> currently the pressure plates don't seem to raise again after you remove the clock
[12:59:28] <wjp> (or did I screw something up locally? :-) )
[13:12:36] <wjp> ok, let's see... I think I have running and retreating in combat mode now
[13:37:11] <Colourless> something screwy with the collision detection has broken hanoi AFAIK
[13:39:06] <Colourless> of course it could be totally unrealated
[13:39:29] <Colourless> it hasn't worked properly for ages, and I assumed it was something that i had done
[13:40:22] <Colourless> which i still think it is :-)
[13:44:34] <wjp> :-)
[13:46:24] <wjp> oh, btw, sprites are currently too much 'like' normal objects
[13:46:33] <wjp> especially in the sense that item searches return them
[13:46:37] <Colourless> what do you mean?
[13:46:58] <Colourless> well, they are normal objects :-)
[13:47:35] <wjp> one result of this is that explosions are thrown away by other explosions
[13:47:54] <wjp> ...which looks interesting but probably shouldn't happen :-)
[13:49:47] <Colourless> probably should add another EXT flag EXT_SPRITE or something that will stop them from being returned by searches
[13:50:30] <Colourless> i think the original just placed the sprites directly into the display list
[13:51:11] <wjp> yes, most likely
[13:53:32] <wjp> ok, now checking for EXT_SPRITE in areaSearch, surfaceSearch, isValidPosition, sweepTest
[13:55:45] * wjp just loves modifying files like Item.h
[13:57:07] <Colourless> could be worse, could be Object.h
[13:57:24] <Colourless> or pent_include.h
[13:57:39] <Colourless> you know that modifying pent_include.h automatically implies full recompile :-)
[14:06:17] <wjp> you know, there's this nice little typo in pent_include.h that I'd like to fix ;-)
[14:15:03] <Colourless> yeah?
[15:01:52] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[18:18:58] --> Dark-Star has joined #pentagram
[19:01:16] <-- Colourless has left IRC ("casts invisibility")
[22:54:57] --> Fingolfin has joined #pentagram
[22:54:57] --- ChanServ gives channel operator status to Fingolfin
[23:45:58] <-- wjp has left IRC ("Zzzz....")
[23:58:53] --> Kirben has joined #pentagram
[23:58:53] --- ChanServ gives channel operator status to Kirben