

Session Start: Tue Aug 30 00:00:00 2005

Session Ident: #trailblazer

[00:27] * sabren|coding is now known as sabren

[03:02] * Hippo has quit IRC ("MEEP!")

[04:14] * Disconnected

Session Close: Tue Aug 30 04:14:13 2005



Session Start: Tue Aug 30 06:59:10 2005

Session Ident: #trailblazer

[06:59] * Now talking in #trailblazer

[06:59] * Topic is 'if you don't have something to do, ask for an assignment!'

[06:59] * Set by sabren on Mon Aug 29 16:13:32

[07:00] <mcferrill> I'm up if anyone cares to notice

[07:00] <mcferrill> IO'll be working on my code

[07:11] <mcferrill> that movie looks nice! :-)

[07:12] * pyTM30 has joined #trailblazer

[07:13] <mcferrill> 'morning

[07:13] <mcferrill> or whatever it is

[07:14] <pyTM30> 3:20

[07:14] <mcferrill> AM?

[07:14] <mcferrill> or PM?

[07:14] <pyTM30> PM

[07:14] <mcferrill> ok

[07:14] <pyTM30> 15:20 if ya like

[07:14] <mcferrill> close enough ;-)

[07:14] <pyTM30> ye

[07:15] <mcferrill> did you see the movie on the pyweek site?

[07:15] <pyTM30> yes

[07:15] <mcferrill> it looks ppretty coocl

[07:15] <mcferrill> *pretty cool

[07:15] <mcferrill> now to get that little guy running!

[07:16] <mcferrill> I'm working on a script to tie all of the seperate modules together

[07:17] <mcferrill> I'm doing the event handler[s] now

[07:17] <pyTM30> nice one

[07:18] * sabren|asleep has quit IRC (Read error: 104 (Connection reset by peer))

[07:21] <mcferrill> I think that the way eventnet works you can put all of the handlers in as functions of a single class

[07:21] <mcferrill> so I can import that one class from a seperate module and people can work on that without modifying my script

[07:22] <pyTM30> cool

[07:23] <mcferrill> so now let's look into PyODE and such to see what events we need to post to eventnet

[07:24] <mcferrill> are you working on something?

[07:24] <mcferrill> (check the topic on this channel)

[07:24] <mcferrill> brb...

[07:24] <mcferrill> my coffee is ready :-)

[07:25] <mcferrill> I back

[07:25] <mcferrill> so do you have something to work on/

[07:25] <pyTM30> ye I'm doing all the physics for the hero

[07:26] <mcferrill> ok

[07:26] <mcferrill> just checking :-)

[07:26] <mcferrill> soo...

[07:27] <mcferrill> will the physics rely on the event handler?

[07:28] <pyTM30> no I don't think so

[07:28] <mcferrill> so how will it work?

[07:28] <mcferrill> how does it check for collisions and such?

[07:30] <pyTM30> you have a world and space that is basically a simulation of the game and the game will take coords and suchlike from the physics module

[07:30] <mcferrill> ok

[07:31] <mcferrill> soo...

[07:31] <mcferrill> the loader makes the levels SVG file into something that ODE will understand and then ODE spits out coordinates to everything?

[07:32] <mcferrill> so I need my mainloop to keep getting coordinates from ODE for all of the movable objects in the level

[07:33] <mcferrill> I think I'll go do breakfast while everyone (almost) is sleeping

[07:33] <pyTM30> ye although you could get the coords from pygame if that is easier

[07:33] <mcferrill> I feel like a good breakfast so I might make breakfast burritoes

[07:33] <mcferrill> then how would ODE fit in?

[07:34] <mcferrill> the level gives us the list of objects and coords for them all...

[07:34] <mcferrill> and then I give the coords to ODE along with other info from the level and then the objects in the level all move according to ODEs coords

[07:35] <mcferrill> isn't that how it works?

[07:35] <mcferrill> answer that while I'm gone...

[07:35] <mcferrill> I'll be back in a while

[07:40] <pyTM30> the main game calls the level loader thingys which sets up the world and space and gets the coords from it to make the UI. The physics module is then loaded and the hero created in the world and space. The ODE and pygame parts are then run simultaneously and pygame keeps getting the new coords for the hero from the physics module. When an action occurs like whatever the jump button is is pressed it will call a function in the physics modul

[08:35] <mcferrill> I'm back for a while

[08:35] <mcferrill> ok

[08:35] <mcferrill> so it all runs through your physics system

[08:39] <pyTM30> err ye I suppose so

[08:39] <mcferrill> ok

[08:40] <mcferrill> so I'll do a simple test that handles the escape key and makes it close the program

[08:40] <pyTM30> ok

[08:40] <mcferrill> and then people can add handlers for other things as they become ready

[08:40] <mcferrill> hmm

[08:40] <mcferrill> it doesn't like something

[08:40] <mcferrill> I'll fix it and get back to you

[08:47] <pyTM30> gtg for a bit cya

[08:47] * pyTM30 has left #trailblazer

[10:28] * pyTM30 has joined #trailblazer

[10:46] <mcferrill> hi

[10:47] <mcferrill> I'm trying to find eventnet's constants dict

[10:47] <mcferrill> I think it's in _pygame

[10:49] <pyTM30> sorry can't help you there

[11:07] * sabren|asleep has joined #trailblazer

[11:08] * sabren|asleep is now known as sabren

[11:08] <sabren> hello

[11:17] <mcferrill> hi...

[11:17] <mcferrill> I'm here off and on...

[11:17] <mcferrill> brb

[11:19] <sabren> how's it going?

[11:20] <pyTM30> hey

[11:20] <pyTM30> you checked the CVS?

[11:23] <sabren> i just got up

[11:23] <sabren> maintenance woke me up to fix something in my bathroom

[11:24] <sabren> i see the frmrate.py .. is that what I'm looking for?

[11:26] <sabren> ooh music

[11:26] <pyTM30> ye both of them

[11:27] <pyTM30> not really for the game but just an idea of tone and quality

[11:27] <sabren> ne sec... installing winamp on my dev box

[11:27] <pyTM30> the playing is a little iffy at times but like it says it's a 1 taker

[11:27] <pyTM30> ok

[11:27] <sabren> huh. StupidMop is a guitarist too..

[11:28] <sabren> you guys could do a collaboration thingy

[11:29] <pyTM30> ye if he's up for it

[11:30] <pyTM30> if there are any drummers and/or bass players as well that would be good or any other instrument for that matter

[11:30] * Hippo has joined #trailblazer

[11:30] <pyTM30> I found a better way to slow the dude down on the ODE site

[11:31] <pyTM30> Hippo you play any musical instruments?

[11:31] <Hippo> no :\

[11:34] <sabren> winamp still installing

[11:34] <pyTM30> hey no rush

[11:35] <sabren> anyone try running gravdemo.py ?

[11:36] <pyTM30> ye

[11:37] <pyTM30> seems to work alright what's the problem with it?

[11:38] <sabren> adam: thanks... uncomment the line that loads the room

[11:38] <sabren> search for roomFromFile

[11:39] <pyTM30> ok

[11:39] <Hippo> whoa, cool :D

[11:40] <pyTM30> rm = loader.roomFromFile(open("gravdemo-geom.svg")) this one?

[11:40] <sabren> yep

[11:40] <sabren> uncomment that and re-run

[11:40] <Hippo> hmm

[11:40] <sabren> if you're lucky, you'll see some boxes bouncing off the far right

[11:40] <Hippo> sabren: are the blocks supposed to sink through the floor?

[11:41] <pyTM30> ah I see

[11:41] <pyTM30> ODE Message 3: LCP internal error, s <= 0 (s=-1.5253e-13)

[11:41] <pyTM30> ODE Message 3: LCP internal error, s <= 0 (s=0.0000e+00)

[11:41] <sabren> so for some reason the platforms aren't in the right place

[11:41] <pyTM30> got these

[11:41] <sabren> yeah

[11:41] <sabren> the physics is all crappy cut and paste stuff

[11:42] <sabren> Hippo: for a while, even the *Floor* was falling :)

[11:42] <Hippo> :O

[11:42] <mcferrill> it's a start though

[11:42] <pyTM30> as for things sinking through each other that's to do with the CFM

[11:44] <pyTM30> if you set it to 0 then nothing can go through

[11:45] <sabren> ah

[11:45] <sabren> yeah, i just coppied the physics from that falling beam opengl demo on the pyode site

[11:45] <pyTM30> if you want to check anything like that the ODE user guide is the best

[11:46] <sabren> i was looking at it, but i haven't read it straight through

[11:46] <sabren> basically i was leaving all that for you :)

[11:46] <sabren> i don't understand why the platforms are in the wrong place

[11:46] <sabren> it's something wrong in the loader

[11:47] <sabren> i'm wondering if it's because i had to flip the y axis...

[11:50] <pyTM30> I'll be back in a bit cya

[11:50] <sabren> hmm. i can't get the ogg to play

[11:50] <sabren> you need to add binary files with:    cvs add -kb  filename

[11:52] <Hippo> sabren: could it be the matrices, or did you get that all figured out?

[11:53] <mcferrill> brb

[11:58] <sabren> hmm... setting the CFM to 0 didn't change much

[11:59] <Hippo> sabren: how do you change the CFM?

[12:00] <sabren> line 32 in gravdemo.py

[12:00] <Hippo> ah

[12:01] <mcferrill> brb... rebooting

[12:01] * Disconnected

Session Close: Tue Aug 30 12:01:53 2005



Session Start: Tue Aug 30 12:13:34 2005

Session Ident: #trailblazer

[12:13] * Now talking in #trailblazer

[12:13] * Topic is 'if you don't have something to do, ask for an assignment!'

[12:13] * Set by sabren on Mon Aug 29 16:13:32

[12:13] <mcferrill> I back

[12:17] <sabren> hey

[12:17] <sabren> so how's it going?

[12:17] <mcferrill> I'm trying to get eventnet to cooperate with my test event

[12:17] <mcferrill> it says that it can't find constants but I'm using ones it has built in

[12:18] <mcferrill> I'll check in my code

[12:20] <mcferrill> checked in

[12:20] <mcferrill> it doesn't work yet though

[12:20] <sabren> looking

[12:20] <mcferrill> it's supposed to quit when the user presses a button...

[12:20] <mcferrill> it does but for the wrong reason

[12:20] <mcferrill> it quits because of an error

[12:22] <mcferrill> do I need PyOPENGL?

[12:22] <sabren> no

[12:23] <mcferrill> k

[12:23] <mcferrill> maybe I'm doing the handler wrong

[12:23] <mcferrill> I modified main.py and events.py

[12:24] <sabren> do you know which one is failing?

[12:24] <mcferrill> it says that the error is in events.py

[12:24] <mcferrill> main.py imports events.py so that the event handler can be modified seperately from the main script

[12:25] <mcferrill> so main.py is the program that runs but there's an error in events.py

[12:28] <sabren> what error are you getting?

[12:28] <sabren> i see this:

[12:28] <sabren> Traceback (most recent call last):

[12:28] <sabren>   File "main.py", line 28, in ?

[12:28] <sabren>     events.Handler(e)

[12:28] <sabren>   File "C:\work\pyweek\events.py", line 34, in Handler

[12:28] <sabren>     eventnet.driver.post("KEYDOWN")

[12:28] <sabren>   File "C:\Python24\Lib\site-packages\eventnet\baseevent.py", line 55, in post

[12:28] <sabren>     print 'Unhandled event %s(%s) received.' % (const.lookup(eventType), kw)

[12:28] <sabren>   File "C:\Python24\Lib\site-packages\eventnet\const.py", line 30, in lookup

[12:28] <sabren>     raise NameError, 'Uknown constant.'

[12:28] <sabren> NameError: Uknown constant.

[12:29] <mcferrill> me too

[12:29] <mcferrill> I looked at _pygame and "KEYDOWN" was listed there

[12:30] <sabren> why do you say the error is in events.py then?

[12:30] <mcferrill> I thought I was doing something wrong

[12:30] <mcferrill> but I couldn't find it

[12:33] <sabren> can you just send a KEYDOWN event by itself?

[12:33] <mcferrill> so is it me or eventnet?

[12:33] <sabren> i don't know

[12:34] <pyTM30> https://blaze.versionhost.com/viewcvs.cgi/*checkout*/pyweek/1takeimprov.ogg?rev=HEAD&content-type=audio/ogg this might work

[12:35] <mcferrill> maybe I'll forget eventnet and just get pygame in place for now

[12:36] <sabren> sorry.. i'm helping someone else with another project... i'll take a closer look in a few minutes.

[12:36] <mcferrill> that's ok

[12:38] <pyTM30> Do you think I should just have one function for moving and let the call take care of the vector ie. func.move((20,0)) to apply 20N in the x-axis or should there be a seperate one for left, right and jump?

[12:45] <mcferrill> I think I found the solution...

[12:45] <mcferrill> I wasn't calling the ".capture" function

[12:45] <mcferrill> so let's see...

[13:03] <pyTM30> Michal, did the link work? and do you think I should just have one function for moving and let the call take care of the vector ie. func.move((20,0)) to apply 20N in the x-axis or should there be a seperate one for left, right and jump so that a single positive float can be passed?

[13:06] <sabren> pyTM30: just tried it.. yep it works.

[13:06] <sabren> haha.. this is cool

[13:06] <sabren> maybe throw in some drums...

[13:06] <pyTM30> ye maybe I can get hydrogen working or something

[13:06] <sabren> as for moving: yeah, just pass in the vector

[13:07] <pyTM30> ok that makes it easier

[13:07] <Hippo> sabren: I got a level to load/display properly zomg

[13:07] <sabren> we ought to set up the music as a loop with the intro.. then repeating.. then like sections for death or time running short

[13:08] <Hippo> I made a lot of misc. changes, but mainly: block = rm.addGeom((posX+r.width/2, -posY + r.height/2), r.width, r.height)

[13:08] <sabren> Hippo: you mean the platforms are in the right place?

[13:08] <Hippo> hrm..

[13:08] <Hippo> one sec

[13:08] <Hippo> yeah

[13:09] <Hippo> i'll paste the code in a sec

[13:09] <sabren> do they bounce in the gravity demo?? 

[13:09] <Hippo> not yet >_<

[13:10] <Hippo> change the line in roomFromRects to: block = rm.addGeom((r.x+r.width/2, -r.y + r.height/2), r.width, r.height)

[13:10] <sabren> do you have the roomFromFile line uncommented?

[13:10] <Hippo> yeah

[13:10] <mcferrill> eventnet is still telling me that it can't find constants

[13:10] <Hippo> I also made it display the room

[13:10] <pyTM30> sabren: yeah I was thinking of just making a few short pieces that could be easily looped

[13:10] <Hippo> I'm getting collisions when the blocks touch the level, but they aren't moving.. hmm

[13:10] <sabren> mcferrill: do you know which constant?

[13:11] <mcferrill> QUIT and KEYDOWN are the only ones I've tried thus far

[13:11] <sabren> mcferrill: try stepping through with the debugger?

[13:12] <mcferrill> you mean IDLE's traceback or something else?

[13:12] <sabren> Hippo: what do you mean by display the room?

[13:12] <sabren> draw the blocks?

[13:12] <Hippo> yeah

[13:13] <sabren> with the proper rotation?

[13:13] <Hippo> helps with trying to get it work >_>

[13:13] <Hippo> nos

[13:13] * Hippo coughs.

[13:13] <sabren> hmm

[13:13] <sabren> i was thinking about that but I had no idea how to do it 

[13:13] <mcferrill> Traceback (most recent call last):

[13:13] <mcferrill>   File "C:\CVS\pyweek\main.py", line 24, in ?

[13:13] <mcferrill>     handle.capture()

[13:13] <mcferrill>   File "C:\Python24\Lib\site-packages\eventnet\driver.py", line 33, in capture

[13:13] <mcferrill>     observer.register(getattr(self, meth), [getattr(const, meth[4:])])

[13:13] <mcferrill> AttributeError: '_ConstantCollection' object has no attribute 'QUIT'

[13:14] <mcferrill> is what I get

[13:14] <sabren> i didn't think of just drawing the boxes unrotated... :) duh

[13:14] <sabren> good idea

[13:14] <sabren> mcferrill: can you reduce the problem to a 2 or 3 line test case?

[13:15] <mcferrill> what do you mean?

[13:16] <sabren> i mean can you write a 3 line program that still has your problem?

[13:16] <sabren> try to isolate it

[13:16] <sabren> or 5 lines or whatever.

[13:16] <mcferrill> I think it takes more than three lines to use eventnet

[13:16] <mcferrill> yeah

[13:16] <mcferrill> closer

[13:17] <sabren> basically, if you see a bug, a good way to try and solve it is say "how could i make this bug happen if i wanted to?"

[13:17] <mcferrill> ok

[13:17] <sabren> that's what I'm asking myself but I don't know enough about eventnet to make that happen :)

[13:19] <mcferrill> me either :-(

[13:19] <mcferrill> but I'll do my best

[13:23] <Hippo> so.. anyone want to python this up? http://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToAngle/

[13:23] <Hippo> :\

[13:25] <Hippo> hmmmm

[13:26] <Hippo> I'm tempted to steal the OpenGL code from tutorial 3..

[13:47] <mcferrill> it works!

[13:47] <mcferrill> brb

[13:47] <sabren> something works

[13:48] <mcferrill> the main script

[13:48] <mcferrill> it'll close when any button is pressed and it works through eventnet

[13:48] <sabren> cool!

[13:49] <mcferrill> now to make it a little neater and post it

[13:49] <sabren> Hippo: I'm pretty sure Numeric can do rotations for us

[13:53] <mcferrill> I just posted new main.py and events.py

[13:53] <Hippo> back~

[13:53] <Hippo> sabren: ah, good

[13:53] <mcferrill> the new loop is taken from a _pygame function that was messed up

[13:54] <mcferrill> I would have fixed that but then everyone else would have to do the same so I just did a copy/paste/edit

[13:56] <sabren> micah: cool.. you ought to send a patch to the author (Simon?)

[13:57] <mcferrill> I'll make a note of that

[13:59] <sabren> micah: huh. this is cool.. so KEYDOWN is the pygame event (an object), and you're just reposting it as a "KEYDOWN" event (a string)?

[13:59] <mcferrill> yup

[13:59] <mcferrill> that's what the func did

[13:59] <mcferrill> or rather was supposed to

[14:00] <sabren> which part is the replacement for _pygame?

[14:00] <sabren> Handler()?

[14:00] <mcferrill> actually I just removed something from the loop

[14:00] <mcferrill> the mainloop at the bottom was in a _pygame func

[14:00] <mcferrill> it had an extra line at the bottom that stopped it

[14:01] <mcferrill> I just removed the line and copied it over

[14:01] <sabren> yield right?

[14:01] <mcferrill> yeah

[14:01] <sabren> yeah, i think he had his nanothreads module in mind

[14:01] <mcferrill> so let's see...

[14:01] <sabren> hmm

[14:01] <sabren> that's actually interesting

[14:01] <sabren> we have several threads:

[14:01] <sabren> - pygame

[14:02] <sabren> - pyode

[14:02] <sabren> at least those two

[14:02] <mcferrill> for pyODE I'm just transferring coordinates to pygame objects right?

[14:03] <sabren> micah: that's what render.py does

[14:03] <mcferrill> ok

[14:03] <mcferrill> I'll read the other modules and then add them in accordingly

[14:03] <sabren> did you see the gravity demo?

[14:03] <mcferrill> yeah

[14:03] <mcferrill> didn't you guys fix something with that?

[14:03] <sabren> Hippo's working on something right now

[14:03] <sabren> i haven't touched it since last night

[14:04] <mcferrill> ok

[14:04] <Hippo> oh, hmm, I stopped working on something

[14:04] <Hippo> since I couldn't see the rotated platforms.. rotated -_-

[14:04] <mcferrill> I'll just read through the other modules

[14:04] <sabren> hippo: check in what you've got

[14:05] <Hippo> sabren: I made a lot of stupid changes, so I'm going to remove them, check out the stuff again, and make better changes >_>

[14:05] <sabren> haha ok

[14:06] <sabren> pulling in the openGL code for a test environment is probably a great idea

[14:06] <sabren> (like you said earlier i mean)

[14:09] <mcferrill> is anyone working on render.py?

[14:10] <Hippo> not me

[14:10] <sabren> i think it's mostly done... why?

[14:10] <sabren> oh

[14:10] <mcferrill> it's complaining about not enough attributes for the...

[14:11] <mcferrill> BlockSprite func

[14:11] <sabren> i'll fix it

[14:11] <mcferrill> ok

[14:12] <sabren> fixed

[14:12] <sabren> originally I had the random colored sprites as part of the main code

[14:12] <sabren> then i made it so you had to pass the image in explicitly

[14:12] <sabren> but didn't fix the test :)

[14:14] <mcferrill> ok

[14:14] <mcferrill> updating cvs...

[14:15] <mcferrill> done

[14:16] <mcferrill> so...

[14:17] <mcferrill> the BlockSprite class turns a sprite into a pyODE object in room.py?

[14:18] <mcferrill> so let me see...

[14:19] <mcferrill> we need to combine the loader (to get level info from PNGs and SVG, room.py, render.py...

[14:19] <mcferrill> hmm

[14:19] <mcferrill> I'm a little confused

[14:19] <mcferrill> too many modules I think

[14:19] <mcferrill> help me out here someone

[14:22] <mcferrill> hmm

[14:35] <pyTM30> Ok I've got a first draft of the physics. I'll add them now

[14:36] <mcferrill> alright

[14:37] <pyTM30> should I update the current physics.py?

[14:37] <mcferrill> why not?

[14:38] <pyTM30> well I didn't know if it was something else that's needed

[14:39] <sabren> pyTM30: it's just a placeholder for you

[14:39] <pyTM30> ok cheers

[14:40] <sabren> mcferrill: have you read trhough the gravdemo?

[14:40] <sabren> it has all the steps..

[14:40] <mcferrill> not totally

[14:40] <sabren> probably some of that should be cleaned up and moved to the modules

[14:40] <pyTM30> ok it's there

[14:40] <sabren> it puts everything together except for the actual gameplay, etc

[14:40] <mcferrill> I'm working on the loader

[14:41] <mcferrill> on adding it into the main.py anyway

[14:41] <sabren> cool

[14:41] <mcferrill> it makes a list of names from files in a dir called lvl and then makes an object out of each that goes into a dictionary

[14:42] <Hippo> hmm

[14:42] <mcferrill> what?

[14:42] <sabren> call it "rooms" instead of lvl, but that's smart

[14:42] <mcferrill> ok

[14:42] <Hippo> sabren: what'd you do to make the rects in your SVG file?

[14:43] <mcferrill> on second thought it might be better to just do a list and load the files into objects when the level is requested by the player

[14:43] <Hippo> for some reason, they aren't working, but anything I create is :o

[14:43] <sabren> hippo: the one being loaded? i just drew them in inkscape

[14:43] <Hippo> sabren: hrm :|

[14:43] <sabren> Hippo: i think the coordinates may be funky

[14:43] <sabren> there are hidden walls all around the screen

[14:43] <sabren> maybe try taking them out?

[14:45] <sabren> hmm.. how are we going to request levels? we need some kind of menu system

[14:46] <pyTM30> I can start on that if you like. Although somebody should probably check and test my physics stuff first

[14:46] <sabren> micah: can you just simulate menus with raw_input()  so we can get the workflow done?

[14:46] <mcferrill> ok

[14:47] <mcferrill> or I can make it do the list but automatically load a pre-defined file

[14:47] <sabren> pyTM30: whoops. checking it out now

[14:48] <sabren> mcferrill: thats' fine for now.. i'm just saying at some point we need to map out the workflow

[14:48] <Hippo> ooh, physics stuff

[14:49] <sabren> mcferill: main.py should include all that, the "master loop" of menus, high scores, loading ,etc

[14:49] <mcferrill> ok

[14:50] <mcferrill> do we have a pygame gui or something we're using for the menus and such?

[14:50] <sabren> mcferill: nothing defined yet

[14:50] <mcferrill> ok

[14:50] <sabren> mcferill: pgu has a gui system

[14:50] <sabren> mcferill: don't know how good it is

[14:50] <mcferrill> maybe I'll check it out at some point

[14:51] <sabren> pyTM30: so bird.bird() is the movement?

[14:51] <sabren> oh no

[14:54] <sabren> pyTM30: in bird.bird()   you set self.bird ... :)

[14:55] <pyTM30> erm oh yeah woops!

[14:55] <sabren> pyTM30: also, in room.py, we're using THICKNESS on the z coordinate... looks like you're doing that with bird.height

[14:55] <Hippo> hmm, so why do the blocks sink, again? :|

[14:55] <Hippo> I changed the CFM to 0 :/

[14:56] <sabren> Hippo: I don't know

[14:56] <Hippo> hrm

[14:57] <pyTM30> eh? I thought it was the y coord height. I should get the THICKNESS I forgot about that

[14:57] <sabren> i'm confused i guess 

[14:57] <sabren> size = (2*fatness, self.height, 2*fatness)

[14:57] <sabren> line 39

[14:57] <sabren> really room.addBlock() will do what you need anyway

[14:58] <pyTM30> I was thinking that for collision detection the bird isn't just going to be as high as the diameter so we would need a seperate height

[14:58] <sabren> i don't understand

[14:58] <sabren> you mean because he's not a perfect square/circle?

[14:58] <pyTM30> yes

[14:59] <sabren> gotcha

[14:59] <sabren> room.addBlock() can do that for you

[14:59] <pyTM30> so I use the diameter for x, height for y and THICKNESS for z of the boxGeom

[14:59] <sabren> i get it now

[15:00] <sabren> i'm just trying to understand how to tie this into the rooms.. like, i don't think we need the pickles

[15:00] <pyTM30> so I should call room.addBlock() with the hero image?

[15:00] <sabren> not the image... room is all physics stuff

[15:00] <pyTM30> ok

[15:00] <sabren> it sets up the world for you to operate on

[15:01] <sabren> render ties the rooms to sprites

[15:01] <sabren> or rather render + some stuff that's in gravdemo at the moment :)

[15:01] <mcferrill> are we going to change that?

[15:02] <sabren> mcferrill: i guess i need to move some of the pieces back into render...

[15:02] <sabren> mcferrill: i was up all night working on it and didn't have time to clean it up 

[15:02] <mcferrill> ok

[15:03] <mcferrill> also...

[15:03] <mcferrill> do we have a program that parses a single svg into an SVG and 2 PNGs?

[15:03] <sabren> not yet

[15:03] <sabren> StupidMop is working on it

[15:03] <mcferrill> ok

[15:04] <mcferrill> have we heard from him today?

[15:04] <sabren> he's probably at work

[15:04] <mcferrill> ok

[15:04] <sabren> oh he was having trouble checking stuff in

[15:04] <mcferrill> we could tell people to save layers as layer1, layer2, etc. and then parse for those as in loader.py

[15:05] <sabren> mcferrill: but we'd have to render the svg to a bitmap

[15:05] <mcferrill> doesn't inkscape have a python tool for that?

[15:05] <sabren> right, that's what he's working on

[15:06] <sabren> that's why he's doing it in inkscape 

[15:06] <mcferrill> ok

[15:06] <sabren> and since it's in inkscape, he's using DOM and xpath for the xml instead of sax to get at the layers

[15:07] <mcferrill> I'm going to have the loader look for dirs with the three needed files in it

[15:07] <sabren> hrmm

[15:08] <mcferrill> or maybe StupidMop could use his stuff to modify loader.py in such a way that we can just save levels into a single file

[15:08] <sabren> i was thinking  like if the level is   asdf

[15:08] <sabren> then asdf-fore.png

[15:08] <sabren> asdf-back.png

[15:08] <sabren> and asdf-geom.svg

[15:08] <mcferrill> ok

[15:08] <sabren> adn then then list would put them in order

[15:08] <sabren> level[1] = "asdf"

[15:09] <mcferrill> so just stick with splitting into three files?

[15:09] <sabren> i dunno.. i'm not dictating.. i'm just telling you what i was thinking.. what do you think?

[15:10] <mcferrill> I think it might be better to have loader.py load the geometry from a certain layer in a single svg and render the images from the other two layers...

[15:10] <mcferrill> then it would just make three temporary files and delete them when that level was over

[15:10] <mcferrill> that way we only have one file per level instead of three

[15:11] <sabren> hmm

[15:11] <mcferrill> and it saves the user a step when they're making a level

[15:11] <sabren> but we'd need inskape

[15:11] <mcferrill> it'd still use it

[15:11] <sabren> er inkscape

[15:11] <sabren> but you'd need inkscape to play the game.. :)

[15:11] <mcferrill> not with py2exe

[15:11] <sabren> inkscape isn't a library

[15:12] <pyTM30> there's a problem with using room.addBlock(), it won't allow me to set the body

[15:12] <sabren> python is embedded in inkscape

[15:12] <mcferrill> although that doesn't help Linux and MacOSX users

[15:12] <mcferrill> hmm

[15:12] <sabren> pyTM30: you need a custom body?

[15:12] <mcferrill> maybe we could make it into one?

[15:12] <sabren> pyTM30: use addGeom()

[15:12] <sabren> mcferrill: good luck with that!!!

[15:13] <mcferrill> I haven't looked at it so I don't know how hard it'd be

[15:13] <sabren> mcferrill: you'd be writing a c extension for python

[15:13] <mcferrill> we can just stick to your method if you want

[15:13] <sabren> mcferrill: it would be a major undertaking

[15:13] <pyTM30> I need to tie the geom to the body so that I don't have to try and keep the coords of each in sync

[15:14] <pyTM30> oh yeah ok

[15:14] <sabren> mcferrill: the level designer only has to make the one svg file... there will be a button to compile them once StupidMop is done

[15:14] <mcferrill> so he's just making an inkscape extension?

[15:14] <sabren> mcferrill: yep, exactly

[15:14] <mcferrill> ok

[15:15] <mcferrill> then would you rather that we add your loader to that or we just stick with what we've got?

[15:16] <mcferrill> brb

[15:16] <sabren> mcferrill: i dont understand your question

[15:17] <mcferrill> what is his extension written in?

[15:18] <sabren> python

[15:18] <mcferrill> never mind...

[15:18] <mcferrill> I was confused

[15:19] <sabren> haha me too

[15:19] <mcferrill> so let's see what's next...

[15:20] <mcferrill> ok, I'm good for now

[15:22] <pyTM30> ok I've improved physics.py

[15:23] <mcferrill> and checked in?

[15:23] <pyTM30> yes

[15:23] <mcferrill> ok

[15:26] <pyTM30> what d'ya think?

[15:27] <mcferrill> haven't looked at it in detail...

[15:27] <mcferrill> trying to do the loader

[15:30] <sabren> C:\work\pyweek>python physics.py

[15:30] <sabren> Traceback (most recent call last):

[15:30] <sabren>   File "physics.py", line 112, in ?

[15:30] <sabren>     test()

[15:30] <sabren>   File "physics.py", line 103, in test

[15:30] <sabren>     bird = Bird(ode.World(), ode.Space(), 7)

[15:30] <sabren> TypeError: __init__() takes exactly 5 arguments (4 given)

[15:31] <pyTM30> ye I should have checked before I'm just cleaning it up now

[15:33] <sabren> pyTM30: it looks great.

[15:34] <sabren> pyTM30: i think it could be two objects: bird and roomphysics... ?

[15:34] <sabren> because we need to apply changes to the bird directly from pygame

[15:35] <sabren> and other things could be moving around too

[15:35] <sabren> like if we use the birds that fly back and forth

[15:36] <pyTM30> ok I'll see what I can do tomorrow, I've got to get some sleep though. I've updated the current physics.py so that it actually runs. cya

[15:37] <mcferrill> g'night

[15:38] * pyTM30 has left #trailblazer

[15:38] <sabren> ah

[15:38] <sabren> missed him

[15:38] <sabren> :)

[15:38] <sabren> oh well

[15:38] <mcferrill> what?

[15:38] <mcferrill> are Hippo and illume still with us?

[15:39] <sabren> illume is in australia i believe... not sure what time it is there

[15:39] <mcferrill> hmm...

[15:39] <sabren> i know he's got a massive load at work this week

[15:39] <sabren> he's only got an hour or so for us, which is why he gave up his own entry and joined our team

[15:40] <sabren> dunno if hippo is here or not :)

[15:40] <mcferrill> looks like it's morning there

[15:46] <sabren> yeah.. i don't know what his schedule's like

[15:47] <sabren> he's mostly working on sound.. he's the author of one of the libraries listed on the contact page

[15:47] <sabren> er the rules page

[15:47] <sabren> so he's got a good head start on sound already

[15:47] <sabren> in terms of learning curve, etc i mean

[15:48] <mcferrill> ok

[15:57] <mcferrill> just checked in another revision of main.py

[15:58] <mcferrill> I think I might take a break now

[15:58] <mcferrill> let me know what you think, I'll wait

[16:00] <sabren> k.. brb and then i'll check it out

[16:01] <mcferrill> I'll go ahead and take that break then...

[16:01] <mcferrill> leave me a note and I'll read it when I get back

[16:05] <mcferrill> ok, so it was a really short break...

[16:05] <mcferrill> but there wasn't anything else going on so I came back

[16:07] <sabren> haha

[16:07] <sabren> it looks good

[16:08] <sabren> do you know about list comprehensions?

[16:08] <mcferrill> maybe under a different name...

[16:08] <mcferrill> or no name at all

[16:08] <sabren> load up the pair window, and I'll show ya

[16:09] <mcferrill> roge'

[16:09] <sabren> are you having fun, btw?

[16:09] <mcferrill> heck yeah!

[16:09] <sabren> cool :)

[16:10] <mcferrill> multilpe screens again

[16:10] <mcferrill> *multiple

[16:10] <sabren> ah

[16:10] <sabren> try it now

[16:11] <sabren> better?

[16:11] <mcferrill> yes

[16:16] <sabren> ok

[16:16] <sabren> i just added a test so we can show that the two functions are equivalent

[16:16] <mcferrill> ok

[16:16] <sabren> now. check this out

[16:17] <sabren> have you seen that style before?

[16:17] <mcferrill> don't think so

[16:18] <mcferrill> maybe and I just don't remember

[16:18] <sabren> it's a neat feature of python that you don't find too many other places

[16:18] <sabren> it's called a list comprehension

[16:18] <mcferrill> ok

[16:18] <sabren> what it does is it makes your job a little easier when you're building a list

[16:19] <mcferrill> IC

[16:20] <sabren> eh, just thought you might think that was cool :)

[16:21] <mcferrill> yeah...

[16:21] <mcferrill> one of the reasons I'm on a team is so I can learn some of these tricks

[16:22] <sabren> haha cool.. :)

[16:22] <mcferrill> was team trailblazer going to stop with PyWeek?

[16:23] <sabren> hmm

[16:23] <sabren> i don't know

[16:23] <mcferrill> ok

[16:23] <mcferrill> just wondering

[16:23] <sabren> i guess it depends what people want to do :)

[16:23] <mcferrill> I'd be willing to stay for more :-)

[16:24] <mcferrill> you and I could just keep working on ideas we both have

[16:24] <mcferrill> for example...

[16:24] <mcferrill> I've been wanting to make a 3rd person game that involves swordplay and martial arts

[16:24] <mcferrill> have you seen Jedi Academy?

[16:25] <mcferrill> or any of the Jedi Knight series?

[16:25] <sabren> nope

[16:25] <sabren> googling

[16:25] <mcferrill> it was partially inspired by those

[16:25] <mcferrill> the Jedi Academy Demo shows what I mean

[16:26] <mcferrill> when using lightsaber the camera goes to 3rd person

[16:26] <sabren> ah looks pretty cool

[16:26] <mcferrill> the computer calculates where the player is pointing and what buttons are being pressed and makes the character do moves

[16:26] <mcferrill> extremely cool and fun

[16:27] <mcferrill> and I've had ideas on how one might could take that combat element to another level

[16:27] <mcferrill> where the computer also calculates positions of enemies' weapons, environment obstacles, and so forth to make the character more believable and cool

[16:28] <mcferrill> I don't know enough to do that yet though so it's on my ideas list

[16:28] <sabren> is jedi academy realtime?

[16:28] <mcferrill> yes

[16:28] <mcferrill> I actually prefer realtime games

[16:28] <mcferrill> why?

[16:29] <sabren> but it doesn't calculate the enemy's positions and weapons?

[16:29] <sabren> i didn't understand that part

[16:29] <mcferrill> ahh

[16:29] <mcferrill> Jedi Academy does that to a certain extent but not as far as one might like

[16:30] <sabren> i see

[16:30] <mcferrill> it turns off all defenses when attacking instead of multi-tasking

[16:30] <mcferrill> but as I said I can't do anything like that yet

[16:30] <sabren> so the physics is sort of blocky and you want to fill it in

[16:30] <sabren> and make it more realistic

[16:31] <mcferrill> yeah

[16:31] <sabren> cool

[16:31] <mcferrill> but I was thinking of making another game

[16:31] <mcferrill> just similar

[16:31] <mcferrill> have you seen LOTR (Lord Of The Rings)?

[16:31] <sabren> oh right.. your own world, not the jedi world

[16:31] <sabren> yep

[16:32] <mcferrill> think Aragorn + Karate Kid

[16:32] <mcferrill> that's what I picture for the hero of my game

[16:34] <mcferrill> but enough about that... what's next?

[16:34] <sabren> haha

[16:35] <sabren> interesting

[16:35] <mcferrill> the event handler is supposed to call functions from the physics module

[16:36] <mcferrill> or at least that's what he (Adam?) told me

[16:37] <sabren> yes

[16:37] <mcferrill> so we need the event handler and levels

[16:38] <sabren> hmm

[16:38] <sabren> let's see

[16:38] <mcferrill> and that tool for inkscape

[16:38] <sabren> we're only going to be dealing with one room at a time

[16:38] <mcferrill> ok

[16:38] <sabren> i mean we only need physics running when we have a room

[16:39] <mcferrill> right

[16:39] <sabren> and there's only one room on the screen..

[16:39] <mcferrill> right

[16:39] <sabren> see

[16:39] <sabren> what i'm thinking is that main.py ought to transition between various "states"

[16:39] <mcferrill> ok

[16:39] <sabren> like we have a state of "playing the game"

[16:39] <sabren> and one of "showing the high scores"

[16:39] <sabren> and one of "pause"

[16:39] <sabren> and one of "main menu"

[16:40] <sabren> and one of "load level"

[16:40] <mcferrill> so multiple modes

[16:40] <mcferrill> and each could have it's own event handler

[16:40] <sabren> right.. managing those big chunks makes up the main program

[16:40] <sabren> right

[16:40] <mcferrill> ok

[16:41] <sabren> because in play, pressing up should jump or do an action or something

[16:41] <mcferrill> right

[16:41] <mcferrill> while in the menu it'd select another item

[16:41] <sabren> and on the main menu, might pick a different item

[16:41] <mcferrill> yeah

[16:41] <sabren> haha yeah

[16:41] <sabren> :)

[16:41] <mcferrill> that was scary

[16:42] <sabren> great minds think alike as they say

[16:42] <sabren> so

[16:42] <mcferrill> great ;-)

[16:43] <sabren> i guess really the states are different sets of event handlers

[16:43] <mcferrill> I could have the mainloop check for mode changes...

[16:43] <mcferrill> and the event handlers would change the mode

[16:44] <mcferrill> then when it was seen by the mainloop it'd wipe the screen and do something different

[16:44] <sabren> let's figure it out...

[16:45] <mcferrill> for pause we could just freeze the screen until unpause and display a "Pause" text meanwhile

[16:45] <sabren> yeah, we might not need a real state for pause

[16:46] <sabren> it's more just a mode of game play i guess isn't it?

[16:46] <mcferrill> that makes 4

[16:46] <mcferrill> I'd think so

[16:46] <sabren> let's write it out like code

[16:46] <sabren> in the window

[16:47] <sabren> workflow is a bad word for it but i don't know what to call it

[16:47] <mcferrill> what is it?

[16:47] <sabren> like.. here i'll show you what i'm thinking of

[16:48] <mcferrill> maybe a list of modes and then a function for each?

[16:49] <mcferrill> and then have the event handlers take over?

[16:49] <sabren> hmm

[16:49] <sabren> yeah

[16:49] <sabren> the list could just be the functions

[16:50] <sabren> i'm just brainstorming

[16:51] <mcferrill> perhaps we could make a "mode" class with each mode as a subclass

[16:51] <sabren> yeah that makes more sense than functions..

[16:53] <sabren> do you see where i'm going with this?

[16:53] <mcferrill> I think so

[16:54] <mcferrill> each mode has a function that has it's own mainloop

[16:54] <mcferrill> and thereby event handlers, images, etc.

[16:54] <sabren> yeah

[16:54] <sabren> only like you said they should probably be objects

[16:54] <sabren> all subclasses of a Mode

[16:54] <mcferrill> then we could put all of the common denominators into the masterclass

[16:55] <sabren> let's work out the logic here..

[16:55] <mcferrill> ok

[16:55] <sabren> and then turn this into real code

[16:55] <sabren> actually you want to take a crrack at it?

[16:55] <sabren> i'll brb..

[16:55] <mcferrill> here or on the screen?

[16:55] <mcferrill> ok

[16:56] <sabren> yeah on the screen

[16:56] <sabren> so we can figure this out together

[16:56] <sabren> unless you'd rather do it on your own... either way

[16:56] <mcferrill> I could do a draft and then we go over it together

[16:58] <sabren> back

[16:58] <mcferrill> what?

[16:58] <mcferrill> ah

[16:58] <sabren> i'm back

[16:58] <mcferrill> ok

[16:58] <sabren> and this time... i mean business...

[16:59] <mcferrill> meaning?

[16:59] <sabren> haha.. just being silly...

[16:59] <mcferrill> ok

[16:59] <mcferrill> that's about what I thought...

[16:59] <mcferrill> or that someone had hijacked your computer

[16:59] <sabren> you don't like people making jokes much, huh?

[17:00] <mcferrill> that's not true!

[17:00] <mcferrill> it's just that I like some jokes better than others

[17:00] <sabren> haha :) ok

[17:00] <mcferrill> why did the nutty scientist remove his doorbell?

[17:01] <sabren> hmm. i don't know

[17:01] <mcferrill> he wanted to win the no-bell prize :-)

[17:01] <sabren> haha :) i like it

[17:01] <mcferrill> me too :-)

[17:02] <sabren> so

[17:02] <mcferrill> shall I just do a draft and get that to you for review?

[17:02] <sabren> it's up to you

[17:02] <mcferrill> I'm much better (and faster) with IDLE

[17:03] <sabren> one place i worked we always had two people on a computer...

[17:03] <sabren> i think it's more fun to program that way once you get used to it

[17:03] <sabren> (depending who you're working with of course)

[17:03] <mcferrill> yeah, maybe

[17:03] <sabren> certainly not required though 

[17:04] <mcferrill> when I'm doing this I think I like to talk and let someone else type

[17:04] <mcferrill> usually someone who know a lot more about the editor :)

[17:04] <sabren> does that help?

[17:05] <mcferrill> yeah...

[17:05] <mcferrill> it's hard sometimes for me to type up ideas for someone

[17:05] <mcferrill> especially when I'm not experienced with their editor

[17:05] <sabren> you mean to type up their ideas or your ideas?

[17:06] <mcferrill> mine...

[17:06] <mcferrill> both?...

[17:06] <mcferrill> I'm not sure

[17:06] <mcferrill> it varies

[17:06] <sabren> haha

[17:06] <sabren> i'm not trying to put you on the spot or anything

[17:06] <mcferrill> I know

[17:06] <sabren> I have *no* clue what this is going to look like when it's done

[17:07] <mcferrill> then let's get done and see :)

[17:07] <sabren> ok.. so you'd rather i did the typing then?

[17:07] <mcferrill> when we're in a shared window yes

[17:07] <sabren> ok

[17:07] <sabren> sounds good

[17:07] <sabren> no problem

[17:13] <mcferrill> maybe we could call those as events and have a master handler take those and change modes as needed

[17:14] <sabren> i think you're right about a master *something* changing the modes

[17:14] <sabren> i'm not sure about making them events

[17:14] <sabren> the main reason for events is because a lot of stuff is happening at once

[17:14] <mcferrill> me either to tell you the truth

[17:15] <mcferrill> ok

[17:15] <sabren> see: like when we're in the game, all kinds of things could happen

[17:15] <sabren> collisions

[17:15] <mcferrill> so maybe as functions that initialize the mode classes?

[17:15] <sabren> player pressing buttons

[17:15] <sabren> etc..

[17:16] <sabren> what if we just returned the "next" class?

[17:16] <sabren> like the next mode?

[17:16] <sabren> nextMode = currentMode.run()

[17:17] <mcferrill> ok

[17:19] <mcferrill> brb

[17:20] <sabren> ok

[17:24] <mcferrill> I'm back

[17:24] <sabren> hey :)

[17:24] <sabren> do you know what design patterns are?

[17:25] <sabren> in terms of programming?

[17:25] <mcferrill> umm

[17:25] <mcferrill> maybe

[17:25] <sabren> :)

[17:25] <mcferrill> like personal patters?

[17:25] <sabren> i don't expect you to know what they are, i'm just asking

[17:25] <mcferrill> similar to a fingerprint?

[17:25] <mcferrill> *patterns

[17:25] <sabren> no

[17:25] <mcferrill> ok

[17:25] <sabren> they're liked canned solutions

[17:26] <sabren> there are whole books of them

[17:26] <sabren> this is very much like the State or Strategy design patterns

[17:26] <sabren> i don't remember which

[17:26] <sabren> i'm looking it up

[17:29] <sabren> yeah

[17:29] <sabren> state pattern

[17:29] <mcferrill> oook

[17:30] <sabren> http://www.informit.com/articles/article.asp?p=28677&redir=1

[17:30] <sabren> i think this is what we want

[17:31] <sabren> <reading>

[17:33] <sabren> huh that state diagram is pretty cool

[17:36] <sabren> did you read that?

[17:36] <mcferrill> yeah

[17:38] <sabren> not 100% what i was looking for... but

[17:38] <sabren> suppose we have a Console object that represents the game console

[17:38] <sabren> and it can be in various states

[17:38] <mcferrill> ok

[17:39] <sabren> each state has a display system, it's own main loop, and an event handler

[17:39] <mcferrill> right

[17:39] <sabren> basically i'm just restating the same basic idea you already said but trying to nail it down into a design

[17:39] <sabren> i think .run() should just return the next state

[17:40] <sabren> so..

[17:40] <mcferrill> next state as in...

[17:40] <sabren> State == Mode

[17:40] <mcferrill> next on a list or next needed?

[17:40] <sabren> next needed

[17:40] <mcferrill> ok

[17:40] <sabren> depending on the input

[17:41] <mcferrill> so how would .run() be called?

[17:41] <sabren> hmm

[17:41] <sabren> lemme think here

[17:41] <sabren> not sure

[17:41] <sabren> let's write a test case

[17:42] <mcferrill> I was thinking that each class has those components and have an __init__ func or something similar that sets up the neded parts

[17:42] <sabren> i agree

[17:42] <sabren> i don't think we need to pass them in though

[17:42] <sabren> maybe.. we'll see...

[17:45] <sabren> so

[17:45] <sabren> you're sitting there looking at the console

[17:45] <sabren> and it's showing you a menu

[17:45] <mcferrill> right

[17:47] <mcferrill> while 1:

[17:47] <mcferrill>     for event in pygame.event.get():

[17:47] <mcferrill>         eventnet.driver.post(event.type, **event.dict)

[17:47] <sabren> right

[17:47] <sabren> i'm pretending that's running

[17:47] <sabren> that's pulling in events from pygame

[17:47] <mcferrill> k

[17:47] <sabren> but we can also just send an arbitrary event

[17:48] <mcferrill> I think it has to be registered ir it'll generate an error

[17:48] <mcferrill> *or

[17:48] <sabren> i think you're right.. we'll see

[17:49] <sabren> does that make sense to you?

[17:49] <sabren> the code on screen

[17:49] <mcferrill> I think so

[17:51] <mcferrill> I think it wants you to register the new event type

[17:51] <sabren> i think it wants us to register a listener

[17:52] <sabren> the event just went off into the ether somewhere..

[17:52] <mcferrill> hmm

[17:52] <mcferrill> oh yeah

[17:52] <mcferrill> handler.capture()

[17:52] <mcferrill> (Console.capture() in this case I think)

[17:52] <sabren> you're rigth

[17:54] <sabren> what do you think?

[17:54] <mcferrill> that's about what I had in mind

[17:54] <mcferrill> btw...

[17:54] <mcferrill> my parents just left so I'm babysitting

[17:54] <sabren> ok :)

[17:54] <mcferrill> I think I should go for now

[17:54] <sabren> do you need to go?

[17:54] <sabren> ok

[17:54] <sabren> yeah i'm going to go get some food anyway

[17:54] <sabren> i'll check this in if you want to play with it

[17:55] <mcferrill> ok

[17:55] <mcferrill> maybe I'll take my laptop downstairs and do that

[17:55] <mcferrill> ttyl

[17:55] <sabren> later!

[18:07] * eykd has joined #trailblazer

[18:08] <eykd> Hey all.  How's it coming?

[18:10] <sabren> hey davi

[18:10] <sabren> d

[18:10] <sabren> i've lost track

[18:10] <sabren> of when i last saw you :)

[18:10] <sabren> we've got... worlds loading, a physics demo..

[18:10] <eykd> Late last night.  I've had a busy day, so I'm getting a late start today.

[18:11] <sabren> the rendering engine works 

[18:11] <eykd> Wonderful. :)

[18:11] <sabren> so we can map sprites to the physics

[18:11] <sabren> adam's got a good start on collisions

[18:11] <sabren> micah and i just worked out the beginnings of a state machine

[18:11] <sabren> for the master loop of the game i mean (screen transitions, etc)

[18:11] <eykd> Right.

[18:12] <eykd> Cool. :)

[18:12] <sabren> i dunno. i was about to go pick up some dinner

[18:12] <sabren> but i'd say things are moving along pretty well

[18:13] <eykd> Okay.  I'll poke around, get familiar with it again.

[18:13] <sabren> run cvs up -d to get the new directories

[18:13] <sabren> then try running demo/gravdemo.py

[18:13] <eykd> Ah, good call.

[18:13] <sabren> i'll be back in a little while

[18:13] <eykd> Okay. :)  See you soon.

[18:14] * sabren is now known as sabren|dinner

[18:22] <eykd> Micah, you there?

[18:23] <eykd> mcferrill: you there?

[18:25] <mcferrill> for the moment

[18:25] <eykd> :)

[18:25] <eykd> Can I quiz you really quick on your plan for the event handler?

[18:26] <mcferrill> look at eventtest.py and events.py

[18:26] <mcferrill> events.py has the main event handler class

[18:26] <mcferrill> modify that

[18:26] <mcferrill> currently it terminates the program when any key is pressed

[18:28] <eykd> Okay, so events.event_handler gets called in the main script, right?  And that's the only event_handler there will be?

[18:28] <mcferrill> for the game mode

[18:28] <mcferrill> you see there will be a main menu etc. and they'll want their own event handlers

[18:29] <mcferrill> but the actual game mode will just be event_handler

[18:29] <eykd> Okay.  In the __doc__ you mentioned "handlers" so I wasn't sure if the health system would need its own handler or not.

[18:30] <mcferrill> we'll need to modify the main script to register/post events for that

[18:30] <eykd> So for each event that exists, we just register one function in event_handler, and stuff it full of everything that needs to be done with that event?

[18:30] <mcferrill> yes

[18:30] <eykd> Excellent. :)  That's what I wanted to be sure of.

[18:30] <mcferrill> then tell me what the events are called so I can register with eventnet and then post from the mainloop

[18:31] <mcferrill> so make the handlers and a list of event names

[18:31] <eykd> Okay.  I was planning to declare all my events as constants either in event_handler or in events itself.  Any preference?

[18:31] <eykd> They're in event_handler now.

[18:32] <mcferrill> ok here...

[18:32] <mcferrill> when you make a handler...

[18:32] <mcferrill> see the EVT_KEYDOWN func?

[18:32] <eykd> *nods*

[18:33] <mcferrill> all of the handlers should be functions with the EVT_ prefix and the event name (KEYDOWN) as the suffix

[18:33] <eykd> Right, I've read through the eventnet stuff, and I think I understand it.

[18:34] <mcferrill> so just make copies of that function and put the results for the event into it

[18:34] <mcferrill> then I can modify the main script so that it'll post those events without errors

[18:35] <eykd> Michal and I thought it might be convenient and communicative to declare events as constants, so we can see at a glance which are available, and call them like eventnet.driver.post(eventhandler.BLOOD_CHANGED)

[18:35] <eykd> That's what I meant.

[18:36] <mcferrill> so when BLOOD_CHANGED happens it checks what the new blood level is?

[18:37] <mcferrill> if so then def EVT_BLOOD_CHANGED(self, event):

[18:37] <eykd> Yeah, EVT_BLOOD_CHANGED would do that.

[18:37] <mcferrill> if xyz:

[18:37] <mcferrill> such()

[18:37] <mcferrill> ok

[18:38] <mcferrill> so that's where you want to put your info

[18:38] <eykd> Right.  Just trying to make sure we're on the same page.

[18:38] <mcferrill> ok

[18:39] <mcferrill> I think so

[18:41] <eykd> Okay.  Thanks.

[18:43] <mcferrill> I'll be here off and on...

[18:43] <mcferrill> off for now ;)

[18:43] <eykd> Have fun.

[18:54] <mcferrill> on again

[18:59] <mcferrill> off again

[19:02] <mcferrill> on again :)

[19:07] <eykd> Okay, so I'm pretty excited about that demo. :)

[19:07] <mcferrill> which one?

[19:07] <eykd> Gravity. Finally got it to run on my local machine.

[19:08] <mcferrill> cool :)

[19:09] <eykd> Definitely taxes my poor Pentium II laptop though...  of course, most everything does.

[19:09] <mcferrill> I have a pentium III desktop and a P4 laptop

[19:10] <mcferrill> I'm upgrading my desktop soon though

[19:10] <mcferrill> just as soon as I have money (soon)

[19:11] <eykd> Yeah, that whole money thing. :)  I just can't justify it right now--most of what I do involves Firefox, emacs, and PuTTY.  Don't need a lot of muscle for that.

[19:11] <mcferrill> I'm doing PythonCard, and plan on doing Blender (extremely demanding)

[19:12] <illume> hey.  nice demo!

[19:12] <mcferrill> welcome!

[19:12] <mcferrill> the gravity one?

[19:13] <illume> yeah.  just had a look.  it can help to step ode twice sometimes

[19:13] <illume> doesn't run too badly here

[19:14] <mcferrill> I'm busy making the full version

[19:14] <illume> nice one

[19:16] <mcferrill> Michal and I were trying to set up a mode-changing system and menues

[19:16] <mcferrill> I'm still doing that and I think he's getting dinner

[19:20] <illume> they kind of look like they are skipping.  I think because of the float -> int conversion

[19:21] <mcferrill> what are skipping?

[19:22] <illume> the falling blocks.  do they skip as they fall down on your machine?

[19:22] <mcferrill> umm...

[19:22] <mcferrill> yes

[19:24] <illume> or maybe because it is setting it to the center position

[19:24] <mcferrill> off again

[19:25] <illume> the other thing it could be is because they are moving in the z axis

[19:35] <mcferrill> on again

[19:40] * sabren|dinner has quit IRC (Read error: 104 (Connection reset by peer))

[19:40] <mcferrill> so does everyone have something to do or is everyone just sitting and watching nothing?

[19:43] <eykd> I've been poking around, seeing what all's changed since yesterday.  I have some ideas for tweaks to the health model, but if there's something else that's more pressing, well, I could take a crack.

[19:43] * sabren has joined #trailblazer

[19:43] <mcferrill> I don't know...

[19:43] <mcferrill> ask him

[19:44] <eykd> Good timing.

[19:44] <mcferrill> indeed

[19:44] <sabren> hey

[19:44] <mcferrill> hey yo'self

[19:44] <sabren> i saw illume saying something about doing something with ode.. adn then my system locked up

[19:44] <sabren> and i didn't see anything before that either

[19:44] <sabren> because i was out :)

[19:44] <mcferrill> I'll post a log

[19:44] <sabren> so.. what'd i miss?

[19:45] <sabren> thanks :)

