[00:09:09] genjix has quit: Remote closed the connection
[00:09:47] genjix has joined #peragro-dev
[00:35:32] genjix has quit: Read error: 104 (Connection reset by peer)
[00:35:54] genjix has joined #peragro-dev
[02:31:14] genjix has quit: Remote closed the connection
[02:34:23] genjix has joined #peragro-dev
[02:34:37] genjix has quit: Read error: 104 (Connection reset by peer)
[02:37:59] genjix has joined #peragro-dev
[02:39:40] genjix has quit: Remote closed the connection
[02:41:47] genjix has joined #peragro-dev
[02:41:48] genjix has quit: Remote closed the connection
[02:43:29] genjix has joined #peragro-dev
[02:49:42] genjix has quit: Remote closed the connection
[02:50:25] genjix has joined #peragro-dev
[03:51:24] iceeey has quit: "Leaving"
[04:20:20] genjix has quit: Remote closed the connection
[04:43:39] thebolt|zzz has joined #peragro-dev
[05:29:11] thebolt|zzz has joined #peragro-dev
[06:14:13] thebolt|zzz has joined #peragro-dev
[07:09:55] sueastside has joined #peragro-dev
[07:09:55] ChanServ sets mode: +o sueastside
[08:39:30] thebolt|zzz has joined #peragro-dev
[09:07:53] ChanServ sets mode: +o thebolt
[13:53:16] PK has joined #peragro-dev
[13:53:16] ChanServ sets mode: +o PK
[14:33:17] Lightwave has quit: Read error: 54 (Connection reset by peer)
[15:22:53] PK has quit: "Leaving"
[15:24:52] thebolt changed nick to: thebolt|away
[15:28:07] genjix has joined #peragro-dev
[15:32:43] caedes has joined #peragro-dev
[15:32:43] ChanServ sets mode: +v caedes
[17:23:22] genjix has quit: Read error: 104 (Connection reset by peer)
[17:27:05] genjix has joined #peragro-dev
[17:33:14] genjix has quit: Remote closed the connection
[17:40:28] caedes has quit: Read error: 110 (Connection timed out)
[17:56:29] iceeey has joined #peragro-dev
[17:56:29] ChanServ sets mode: +o iceeey
[22:13:12] iceeey has quit: Remote closed the connection
[22:13:42] iceeey has joined #peragro-dev
[22:13:42] ChanServ sets mode: +o iceeey
[22:19:30] <thebolt> iceeey: we really should start to think about the data representation of the world (ie how entities are stored in memory, ind atabase etc) and how that fits together..
[22:21:10] <CyaNox> I was thinking about binary ... :D
[22:21:31] <thebolt> :P
[22:22:11] sueastside changed nick to: bathman
[22:33:26] <iceeey> thebolt, iirc we had some stuff on the entity system page, might need some updating
[22:33:38] <thebolt> yea
[22:34:09] <CyaNox> for the zones dfletcher did some thinking aswell ... I'll dig the old dev repos
[22:34:28] <iceeey> zones are just entities so they are subject to same things :)
[22:37:31] <iceeey> thebolt, everything is an entity, right?
[22:37:51] <thebolt> yea
[22:41:37] <CyaNox> ok well then the ideas of dfletcher are not relevant anymore
[22:42:39] <iceeey> aw
[22:42:46] <iceeey> that's a little harsh
[22:44:16] <CyaNox> well his optimisations where mostly a sort of bitmap compression.
[22:45:21] <iceeey> just because it's an entity doesn't mean that you can't store the data however you want
[22:46:10] <CyaNox> true
[22:46:10] <CyaNox> then again ... I'd have to find his notes ... :p
[22:55:56] <CyaNox> hhhmmm can't find the page but did found the images.
[22:56:24] <CyaNox> http://repos.peragro.org/index.php?id=264 and http://repos.peragro.org/index.php?id=262
[23:01:43] <CyaNox> some screenies of the test with procedural terrain: http://repos.peragro.org/index.php?id=202
[23:07:11] <thebolt> so, how long will you be here iceeey ? an hour or two more?
[23:07:29] <thebolt> (wondered if you're up to talking some actual code-design)
[23:12:37] * thebolt pokes iceeey
[23:12:52] <iceeey> I will be here as long as you want ;)
[23:13:04] <thebolt> heh okay :)
[23:13:16] <thebolt> i have maybe two hours (a bit under)
[23:13:23] <thebolt> so how about some actual planning of code?
[23:13:28] <iceeey> sure
[23:13:40] <thebolt> hm, too bad we don't have any virtual whiteboard..
[23:14:31] <iceeey> isn't there some?
[23:17:04] <thebolt> try http://www.skrbl.com/37815378
[23:18:08] <thebolt> so, there we have some way of writing down things, nice :)
[23:18:14] <iceeey> yeah cool
[23:18:22] <thebolt> anyhow, so i guess we should start by defining the major components ?
[23:18:28] <iceeey> sure
[23:18:48] <thebolt> i'll write down what i can come up with..
[23:20:03] <thebolt> okay, it isn't good for drawing but works for text-boxes ;)
[23:21:14] bathman changed nick to: sueastside
[23:22:04] <thebolt> argh, it is deleting my boxes :7
[23:22:10] <thebolt> i think we'll have to use text for now :)
[23:22:55] <iceeey> ok
[23:23:34] <thebolt> so anyhow, the basic components i think are the python manager (pycore), the entity system (entity+property+component+a few more), network manager, db manager
[23:24:03] <iceeey> yup
[23:24:56] <thebolt> python manager is responsible for registration of basic classes to python; getting a "callable" from a script path; running a script given a path and executing/scheduling tasklets
[23:25:00] <thebolt> anything more?
[23:25:32] <iceeey> no
[23:25:38] <thebolt> ie the idea with the second one is that you give it a path to a script and you get (potentially an array/map) of functions as python callables (boost::python::objects which can be called from python or c++)
[23:26:00] <iceeey> ok
[23:26:45] <thebolt> so.. that brings us back to the entity system.. one thing we really need to finalize on is how to define entities
[23:26:51] <iceeey> yes
[23:26:53] <thebolt> custom scripts, xml, python code etc etc
[23:27:59] <thebolt> there are some nice things about using python code.. but i don't know in the end if it is the best
[23:28:14] <thebolt> as you have to use python "reflection" to get enough data out to construct storage and network packages etc
[23:28:34] <iceeey> well if we can come up with a superior format, why not use it, except laziness
[23:29:02] <iceeey> remember that we will edit them from the editor so python might be too free-form
[23:29:03] <thebolt> well, greatest flexibility would be either custom or say xml markup (those are equivalent really)
[23:29:07] <thebolt> yea
[23:29:30] <thebolt> also my fear
[23:30:24] <iceeey> so what goes into an entity? i've forgotten
[23:31:37] <thebolt> well, our last idea at least was that an entity is made up of a number of settable properties (variables), a number of components defining basic behaviour, scripts connected to events on the components
[23:31:52] <thebolt> and then possibly actions, but i don't know if we want them, or if you should route them via a component instead
[23:32:21] <iceeey> the scripts are the part where i get confused
[23:33:07] <thebolt> okay?
[23:33:44] <iceeey> what is the point where you differentiate between behavior and component?
[23:34:03] <thebolt> a component is c++ functionality
[23:34:16] <thebolt> so one component could be "3DMesh"
[23:34:28] <thebolt> which handles loading of the mesh into crystalspace, updating its position etc
[23:34:28] <iceeey> is that the only difference? implementation detail?
[23:34:39] <thebolt> not really
[23:34:54] <thebolt> or well, guess you could see it as such, but i don't ;)
[23:35:34] <iceeey> i guess our goal is to reduce the abuse of the system :) and right now it seems that you can do too much with it when we want you to do it a certain way
[23:35:53] <thebolt> another component could be Collidable which handles server-side collision detection using whatever mechanism we'll have for that
[23:36:03] <iceeey> like when i was doing the door entity, i was constantly thinking about what part goes where
[23:36:07] <thebolt> a third could be the entire weather simulation subsystem
[23:36:39] <thebolt> what we haven't really touched is how entities communicate
[23:36:42] <thebolt> and the need for "actions"
[23:36:49] <thebolt> (i am not so sure they are really needed.. but not sure)
[23:37:32] <iceeey> well they are like RPCs
[23:37:58] <thebolt> yea but i mean i am not sure i think we should use them.. or even have them, due to cleaness issues ;)
[23:37:59] <iceeey> maybe they are RPCs :)
[23:38:08] <iceeey> how would you do it?
[23:38:40] <thebolt> have all script/interactivity in response to either a property update or a event in a component
[23:39:24] <iceeey> well how do you tell the server you want to open a door?
[23:40:30] <thebolt> well, lets for discussion sake say entities use messages to interact (i think this is the sanest approach)
[23:40:48] <iceeey> isn't that basically an event?
[23:41:13] <thebolt> well, events can be implemented via messages or via direct calls/callbacks
[23:41:32] <iceeey> ok
[23:43:24] <thebolt> anyhow, player on client clicks on door.. player have the component Interactable; so the mouse input script calls the interactable on the player and says "interact with thing at relative position XYZ"; the client part of interactable might do some first checking of validity then send a network message to the serverside component; the serverside component does some more checking of if it is valid and then finds what enti
[23:44:07] <thebolt> now if the door is the entity choosen, its Interactable component (on server) well catch that message; possibly check it for validity; and dispatch it to its OnInteract script event
[23:44:19] <thebolt> where a entity-specific script decides what to do
[23:45:21] <thebolt> such as "start playing open animation; in six seconds reschedule this script and when we get control back, check if animation is finished and if so update the state and finish script"
[23:46:02] <thebolt> (the start playing open animation in turn would be a call to the 3DMesh component on the door)
[23:46:43] <thebolt> get my idea?
[23:47:13] <thebolt> (the sending a message between entities above might either be a "queue a message in an event queue" or "call a method")
[23:47:28] <sueastside> night
[23:47:42] <iceeey> so the difference is that the component handles everything, and all the entity specific stuff is done in behavior
[23:48:20] <thebolt> yea ;)
[23:48:21] <iceeey> so there is no OpenDoor message but simply Interact with XYZ
[23:48:58] <thebolt> yea; although at times it might need to be more complicated (with back-and-forth messages) setups
[23:48:58] <iceeey> which means that all of the behaviors have to interpret what that means
[23:49:15] <thebolt> hm?
[23:49:21] <thebolt> no?
[23:49:37] <iceeey> they have to figure out what Interacting with XYZ is
[23:49:39] <thebolt> the "OnInteract" behaviour on a door knows that when something interacts with us, it means they want to open or close the door
[23:49:50] <iceeey> ok
[23:50:26] <thebolt> but i think that for more complicated things the Interactable components needs to be smarter
[23:50:32] <thebolt> so it can defines multiple interactions
[23:50:42] <iceeey> I guess it makes sense that actions (not in the sense I was talking about) on something should all happen through the components
[23:50:56] <thebolt> (Interactable probably one of the more complicated components)
[23:51:06] <iceeey> yeah
[23:51:11] <iceeey> you're method is better
[23:51:12] <thebolt> so an entity can say "i can be interacted with in these three ways, with these three callbacks, default is this"
[23:51:28] <thebolt> and another interactable (such as player) can ask for "what can i do to you" ;)
[23:51:40] <iceeey> heh
[23:51:49] <thebolt> so say you right-click on an entity it asks for "what can you do" and then you get a list of options
[23:52:11] <thebolt> that way the player entity for example does not need to explicitly know what another entity can do
[23:52:33] <iceeey> that's like implementing my actions system as a component :)
[23:52:41] <thebolt> Yes
[23:52:45] <thebolt> which imo makes it cleaner ;)
[23:52:47] <iceeey> it's simpler
[23:52:48] <iceeey> yep
[23:54:34] <iceeey> it seems like property update handlers will not be used very much
[23:54:53] <thebolt> well, they could be used for simple things such as updating UI when player helth changes etc
[23:55:47] <iceeey> hm, yes
[23:55:54] <iceeey> that is like listener
[23:57:28] <thebolt> yea