[01:45:19] iceeey_ has joined #peragro-dev
[01:45:35] iceeey has quit: Nick collision from services.
[01:45:41] iceeey_ changed nick to: iceeey
[01:45:47] ChanServ sets mode: +o iceeey
[07:30:26] iceeey has quit: Remote closed the connection
[08:06:55] thebolt|zzz changed nick to: thebolt
[08:13:29] PK has joined #peragro-dev
[08:13:30] ChanServ sets mode: +o PK
[09:22:38] PK has quit: Read error: 54 (Connection reset by peer)
[11:27:12] sueastside has joined #peragro-dev
[11:27:12] ChanServ sets mode: +o sueastside
[12:12:19] thebolt|away changed nick to: thebolt
[13:21:09] caedes_ has quit: Remote closed the connection
[13:21:28] caedesX has joined #peragro-dev
[13:22:06] caedesX changed nick to: caedes
[13:22:20] ChanServ sets mode: +v caedes
[13:51:34] PK has joined #peragro-dev
[13:51:34] ChanServ sets mode: +o PK
[15:10:39] thebolt|away changed nick to: thebolt
[16:38:32] thebolt2 has joined #peragro-dev
[16:38:51] ChanServ sets mode: +o thebolt
[16:42:04] PK has quit: "Leaving"
[17:47:12] iceeey has joined #peragro-dev
[17:47:12] ChanServ sets mode: +o iceeey
[18:49:16] iceeey has quit: Remote closed the connection
[19:06:24] thebolt|away changed nick to: thebolt
[20:03:13] iceeey has joined #peragro-dev
[20:03:14] ChanServ sets mode: +o iceeey
[20:03:54] <thebolt> hey iceeey
[20:04:05] <iceeey> hi
[20:17:08] <iceeey> interesting: http://www.devmaster.net/articles/mmo-scalable-server/
[20:17:28] <iceeey> i don't really know Erlang, but what's your opinion of it?
[20:19:15] <iceeey> it looks too low-level
[20:19:30] <thebolt> i like erlang
[20:19:43] <thebolt> it is functional language
[20:19:51] <thebolt> from the beginning made to code phone exchanges ;)
[20:20:03] <iceeey> the question is, would it be useful to us? :)
[20:20:52] <thebolt> well, functional coding is very different form imperative.. i have no idea how to do c++ interfacing in erlang (probably much hand-coding;) etc
[20:20:55] <thebolt> so, i think no
[20:21:50] <iceeey> perhaps a better question is, do we leave the possibility to use languages other than python?
[20:22:09] <thebolt> i think not
[20:22:14] <thebolt> a system that is so open ends up too open
[20:22:18] <iceeey> :)
[20:22:19] <thebolt> to many levels of abstraction etc
[20:22:33] <iceeey> it's actually still possible
[20:22:42] <iceeey> if you bind behaviors to erlang or whatever
[20:23:21] <thebolt> well, then you would have to write custom marshalling for it
[20:23:37] <thebolt> having them all in pyton allows us to use PyCallable* as the base
[20:24:07] <iceeey> from the outside it would be a python call
[20:24:35] <iceeey> anyway that's just hypothetical :)
[20:24:53] <iceeey> but there could be use in other languages for specific things, who knows
[20:25:27] <iceeey> I'll shutup since I'm piling on the abstraction :)
[20:28:09] <thebolt> btw, my goal for the night is to implement a telnet-server to use as debugging console ;) (probably will write it entirely in python, scheduled as a new tasklet by the startup code ;)
[20:28:38] <iceeey> cool
[20:29:49] <iceeey> I'd like to start thinking about the editor
[20:30:13] <iceeey> i thought about opentree's editor yesterday, really helped solidify the design
[20:32:46] <sueastside> interesting article...
[20:34:43] <sueastside> thebolt: i guess you know about the mud py example, it implements a telnet server....
[20:34:44] <iceeey> first off: do we even want a designer to touch the behavior code?
[20:34:59] <thebolt> sueastside: yep :)
[20:39:24] <sueastside> no, a 'true designer' would only use existing buildingblocks....
[20:39:29] <iceeey> yeah
[20:40:13] <iceeey> so he should be able to connect events to behaviors
[20:41:00] <iceeey> hm, each entity template is technically made up of: common, client, and server
[20:41:03] <thebolt> if he are to make new entity _types_ at all..
[20:41:05] <thebolt> bbiab
[20:44:08] <sueastside> iceeey: what do you mean by that? does it concern the designer?
[20:44:23] <iceeey> it shouldn't concern the designer
[20:45:43] <iceeey> if that's the case, then you need someone else to make the building blocks
[20:47:12] <iceeey> say you want to make a wolf monster
[20:47:15] <sueastside> true, but dont forget the dungeon siege story, making it too easy will end in having thousands of templates :)
[20:47:53] <iceeey> and then you want to make a fire wolf monster, a more powerful, one that breathes fire
[20:50:36] <iceeey> first you need a wolf
[20:50:42] <sueastside> wolf monster is a template? or wolf is an instance of monster template, then attacks would be properties?
[20:51:43] <iceeey> if you don't make it a template, then you have to set all of the things for the monster instance each time
[20:51:50] <iceeey> so it must be a template
[20:52:29] <sueastside> "copy settings from entity"-button? :)
[20:52:43] <iceeey> duplication it will get out of sync :)
[20:52:52] <iceeey> anyway
[20:53:03] <iceeey> what does monster template have?
[20:55:07] <iceeey> at least a mesh and location
[20:55:59] <sueastside> mesh, stats, inventory, equipment, attacks, AI-behaviour(friendly, aggressive), location, ...
[20:56:35] <iceeey> all of those seem fine except for attacks
[20:56:56] <iceeey> i would allow child templates to define the attacks
[20:57:31] <iceeey> like all wolves could have a claw swipe attack
[20:59:20] <sueastside> so should we only allow to inheritance from some higher level templates(like item, npc, monster,..)?
[20:59:47] <iceeey> no..
[20:59:57] <sueastside> i mean in the editor...
[21:00:16] <iceeey> well some of those templates might be marked "incomplete"
[21:00:43] <iceeey> or abstract
[21:05:56] <iceeey> obviously a scripter would write the wolf's attack code
[21:08:52] <iceeey> it really depends on how much control you want to give to the designer at the risk of simplification :)
[21:16:26] <sueastside> iceeey: thats the options i can think of http://rafb.net/p/ZhS4gh82.html
[21:22:27] <iceeey> in terms of code though, it's not as easy as just adding templates and properties
[21:22:35] <iceeey> they need to interact in some way
[21:22:43] <iceeey> like actions and events
[21:23:30] <iceeey> components/properties only define what it has, not what it does
[21:29:02] <sueastside> i know, im just trying to describe what freedom we should give the designer...
[21:29:31] <iceeey> you have to realize that all of those basically do nothing :)
[21:30:21] <sueastside> i know, theyre pure data...
[21:32:49] <sueastside> but behaviours (from your description, it subscribes to certain events) sound complicated for a designer, what happens when he adds multiple behaviours that all listen to the same event? wont that possibly screw things up if theyre not compatible?
[21:33:56] <sueastside> or did you already consider that and added somthing to prevent such stuff from happening?
[21:34:46] <thebolt> you tie a specific behaviour to a specific event.. it is more of a signal/slot system than event system
[21:35:06] <iceeey> yea i was thinking that too yesterday when playing around with Qt Designer :)
[21:36:18] <sueastside> thebolt: so 1 and only 1 behaviour for each event?
[21:37:14] <thebolt> yes
[21:37:23] <sueastside> ok
[21:44:33] <iceeey> thebolt, btw, what did you think of the 'event' example i showed you?
[21:44:43] <thebolt> hm.. not sure..
[21:45:27] <iceeey> it's all really a bunch of RPCs :)
[21:46:07] <thebolt> my first feeling was that i didn't like it .P
[21:46:20] <iceeey> so you prefer less encapsulation?
[21:46:31] <thebolt> you have the url again?
[21:46:41] <thebolt> well, i think i liked the look of some of the earlier ones more ;)
[21:47:00] <iceeey> hehe
[21:48:16] <iceeey> http://rafb.net/p/afFsQN93.html
[22:02:04] <iceeey> i agree i don't like it either :)
[22:03:25] <thebolt> so, take it back a few steps and rethink?
[22:03:59] <iceeey> yeah
[22:16:12] <thebolt> sorry for not being of more help atm.. but i just cannot come up with anything intelligent to say :P
[22:17:04] <iceeey> me neither :P
[22:18:48] <iceeey> perhaps if things are more implicit
[22:19:00] <iceeey> like meshes always being associated with the client side
[22:21:34] <iceeey> or you can think of it as MVC, model exists on server, called be controller on client, and then displayed by view on client
[22:23:28] <thebolt> except that C is both client and server side ;)
[22:24:06] <iceeey> is it?
[22:24:29] <thebolt> server side behaviours, yes? (i would see that as part of the controller)
[22:25:08] <iceeey> for example?
[22:25:44] <thebolt> well, you don't mean for example all monster AI should be client side? or simpler things as opening doors when player wants to go through..
[22:26:04] <iceeey> well you can think of AI as being clients
[22:26:09] <iceeey> and it makes sense that way
[22:40:02] <iceeey> no problems with that? :)
[22:47:51] <thebolt> not really no.. but every door or so shouldn't be a client ;)
[22:48:05] <iceeey> it's not
[22:48:40] <iceeey> i'm defining a model as a state and methods that manipulate that state
[22:49:01] <iceeey> so 'open' is part of the model
[23:35:59] <iceeey> or not