ok, so I kinda ended up getting drunk and having way too much caffiene after
having my mind go into crazy speed-mode while at a party where I couldn't make
use of the wonderful extra brainpower it unlocked.
I didn't bring my notebook and didn't think of finding pencil & paper so I
ended up writing in sidedwalk chalk. *then* afterwards I got pencil&paper and
copied it down.

some of it doesn't translate well, some does.
first, was thinking abot ways to pass messages. like for power supply parts,
they have to get energy from the engine. this should prolly be done with a
power event. I figure those'll probably be sent out on a timer, it's the
easiest way... unf, but what about lightbulbs? you don't want flicker. you
want constant light. in which case you'd want DC-like, a signl for on and a
signal for off. for the sprite that is. oooh, that's how you have parts seem
to control each other. you don't have the switch part change hte bulb sprite,
you ave the bulb part change itself on a power-change event.
but then you have other things that want an AC-like pulse, an event every x
tick for as long as the power's on. like, the part that actually sends out
packets of 'light' to other agents. in a way that's more like polling really
but anyways.
regardless of whether they're on AC or DC, they're passively responding to
events. now, what I had in chalk was two approaches to events.
if you ahve a generic ebvent with a string, say, "power", hten it's very
flexible for adding new stuff but every time any event happens every cob has
to see if they're interested in it. badbad.
otoh if you have different functions for different events, you have to add a
new function (or signal/slot, whatever) every time you want a new sort of
event. very inflexible. but events only go to those interested in them.
on the gripping hand, you can combine the two ways and probably come up with a
decent compromise. have different functions for different families of events,
hten a string to clarify what specfic event this is. could even also have the
engine do some lookupbased on the string and only notify cobs most likely to
care - hmm, but that would be if you're not using qt's signals&slots.

oh yeah, did I mention that? I realised that it was kinda silly to get bogged
down in hte networking stuff so soon, so I decided to do a simple little
prototype with qt, taking advantage of al its nice useful features to get the
stuff together and implement ideas withouthaving to worry about details yet.
then I can get a better idea of what works for the cob & parts side of things,
and once that's more solid I can do it in a server/client mode and start on
all the stuff related to that. :) much more sensible.

I need to get some stuff actually implemented though. need a body class which
should be easy, don't worry much about dna for now, then get a basic part
interface that part clases can inherit and make some simple parts. then I can
add actual physical world stuff to the bodies and use qt to get an nice easy
graphical representation o stuff.

thought of several different ways for bodies in a 2d world to be defined.
circles, ovals, sticks, rectangles or diamonds. c3 seems to use rectangles for
sprites but diamonds for wall-collisions. I haven't a clue which would work
best for what, but there's nothing stopping me from trying several different
approaches. :)

so, uh, yeah, I need to get this prototype thing started. starting things is
hard. need to do it before SoC begins, too, or I won't have time. um, so where
do I start? a folder to start in would be a good thing, yes, but then... hmm.
need to look at the existing code, reimplement the classes I've done with
whatever qt-aditions may help them, then make a basic gui. for now maybe just
a dialog or qapp with an agentlist, add & delete buttons.

yeah. bet I fall asleep instead.