[00:32:08] iceeey has joined #peragro-dev
[00:32:08] ChanServ sets mode: +o iceeey
[00:32:12] <thebolt> hi iceeey
[00:32:22] <iceeey> hi
[00:37:24] <thebolt> hm, about custom network packing..maybe only allow that to be defined in c++? then you can do lots of trickery to make it mostly compile-time
[00:45:55] <thebolt> same with any more fancy persistence
[00:46:03] <PK> did someone mention network? what are you planing?
[00:46:42] <thebolt> nothing really.. just had a little discussion earlier (and the other day) on how to fit networking into this;)
[00:49:00] <thebolt> and there i just think he proved it will never work, and we'll never see any usable from it (or at least not within lifetime of this project :P)
[00:49:20] <PK> he? iceeey?
[00:49:42] <thebolt> no, daraknor :P
[00:50:04] <PK> darn... I really need to spend more time in the PT channel :-)
[00:51:17] <PK> as for me, personally, I prefere custon network packages on a rather high level if possible. Mainly because the more you know about the data, the better you can compress them. For a mmorpg the most critial factor is imho ping and bandwidth.
[00:51:36] <PK> And I don't really see a problem with custom messages.
[00:51:50] <iceeey> besides that you have to write each and every one
[00:51:59] <iceeey> and that they are prone to error
[00:51:59] <thebolt> well, custom messages means custom c++ code for every entity.. which is one thing we would like to get away from
[00:52:44] <PK> no, you don't have to write custom code for each message.
[00:53:11] <iceeey> re daraknor, his idea is not new (we intend to implement it in some way for NPC clients), but he seems insistent on its implementation
[00:53:18] <PK> you can either store it as data, or let the code be written from that defined data.
[00:53:42] <thebolt> PK: custom network packages.. custom for what?
[00:53:48] <PK> There are things like ASN.1, WSDL or we can use our own, custom package description language
[00:53:55] <iceeey> he means generating it
[00:54:03] <PK> custom for our needs.
[00:54:17] <PK> like PickupRequest, KillResponse, etc.
[00:54:21] <thebolt> well, of course they should be "custom" in that way.. what we mean by custom is entity-custom
[00:54:30] <PK> rather than sending 1001 PropertyUpdate(X,Y);
[00:54:33] <thebolt> which might be uneeded in most cases
[00:54:54] <iceeey> PK, that is what i call "actions"
[00:55:00] <PK> I would create the message action based
[00:55:06] <PK> iceeey: there you go :)
[00:55:47] <thebolt> yea, but having one action == one custom, hand defined, message would be to kind of take two steps back imo :P
[00:55:48] <PK> so login and getAllEntitiesNearbyAfterLogin are actions for me too.
[00:56:11] <iceeey> yes, we disagree on how to implement actions
[00:56:40] <PK> well, depends on how you implement actions...
[00:56:51] <iceeey> I actually haven't thought about it too much
[00:58:01] <PK> if you have some kind of action interface that goes like doAction(request, response); you could probably have one 'Action' message... or rather two, ActionRequest and ActionResponse :)
[00:58:40] <PK> then you let the client execute the same action with the same parameters which 'should' result in the same.
[00:59:06] <thebolt> well, from the python script side of thing it would probably be a normal function call.. how it looks on the c++ side is up to us to decide ;)
[00:59:26] <PK> anyway, can we discuss that tomorrow? maybe before midnight? :)
[00:59:34] <iceeey> or before dinner ;)
[00:59:43] <iceeey> nice to see you back, PK
[00:59:48] <PK> good night.
[00:59:51] <iceeey> night
[01:00:00] <PK> thanks, it's good to be back as well... I guess :)
[01:00:20] PK has quit: "Leaving"
[01:01:18] <iceeey> where did this daraknor guy come from anyway?
[01:05:05] <thebolt> no idea
[01:05:43] <iceeey> perhaps ryzom
[01:06:00] <iceeey> they all probably have "revolutionary" ideas :)
[01:06:16] <thebolt> :-)
[01:08:02] <iceeey> how do you intend to implement NPC clients?
[01:08:43] caedes has joined #peragro-dev
[01:08:43] ChanServ sets mode: +v caedes
[01:10:43] <iceeey> iceeey, #1 a generalized game engine with common client/server code that different games can use <--- definitely ryzom then
[01:21:19] <thebolt|zzz> at least i won't waste time on his effort.. i have too much to do as it is
[01:21:32] <thebolt|zzz> as for NPC.,. not sure, haven't thought too much about it
[01:26:28] <iceeey> night
[02:34:26] caedes has quit: Remote closed the connection
[04:19:37] thebolt2 has joined #peragro-dev
[07:08:31] sueastside has joined #peragro-dev
[07:08:32] ChanServ sets mode: +o sueastside
[07:19:58] iceeey has quit: "Leaving"
[07:20:09] iceeey has joined #peragro-dev
[07:20:14] ChanServ sets mode: +o iceeey
[07:53:35] caedes has joined #peragro-dev
[07:53:35] ChanServ sets mode: +v caedes
[09:45:05] ChanServ sets mode: +o thebolt
[10:47:32] caedes has quit: "nightmare reset by peer"
[11:32:19] caedes has joined #peragro-dev
[11:32:20] ChanServ sets mode: +v caedes
[19:34:16] PK has joined #peragro-dev
[19:34:16] ChanServ sets mode: +o PK
[19:34:17] PK has quit: Client Quit
[19:34:45] PK has joined #peragro-dev
[19:34:45] ChanServ sets mode: +o PK
[19:37:06] caedes has quit: "nightmare reset by peer"
[20:11:25] iceeey_ has joined #peragro-dev
[20:12:25] theboltEatingStu changed nick to: thebolt
[20:12:50] iceeey has quit: Read error: 110 (Connection timed out)
[20:18:44] PK changed nick to: PK|dinner
[20:37:26] |sueasts| has joined #peragro-dev
[20:39:58] PK|dinner changed nick to: PK
[20:42:57] |sueasts| has joined #peragro-dev
[20:50:38] sueastside has quit: Nick collision from services.
[20:50:55] ChanServ sets mode: +o sueastside
[21:45:38] bathman changed nick to: sueastside
[22:00:55] JohnTitor has joined #peragro-dev
[22:00:56] ChanServ sets mode: +v JohnTitor
[22:08:06] iceeey_ has quit: Read error: 110 (Connection timed out)
[22:08:18] iceeey_ has joined #peragro-dev
[22:30:55] <thebolt> just so that you are all aware of it.. i am _not_ going to work on any combined project.. one of my reasons for choosing peragro to work with was that it was a small team (little overhead) and i know the people (met most of them irl ;)
[22:32:41] <sueastside> thebolt: overhead as in decision making?
[22:33:08] <iceeey_> well the point is, we know each other for a long time, and we have small numbers
[22:35:39] <thebolt> sueastside: yea, discussions, people wanting different things.. also things like "requirements" etc :P
[22:44:56] <iceeey_> anyone up to talk about the entity system?
[22:45:11] <thebolt> sure
[22:45:17] <thebolt> for 1:15 at least
[22:45:55] <iceeey_> okay, I'm just going to try and figure out which parts we haven't covered
[22:47:15] <iceeey_> here are some things we haven't talked much about: actions, how exactly client/server entities are separated, networking, threading, editor
[22:48:06] <iceeey_> pick one :)
[22:48:28] <thebolt> make your pick :)
[22:49:22] <iceeey_> they are all related :) but let's start with actions i guess
[22:49:30] * PK picks threading
[22:49:46] <iceeey_> okay, if you wish
[22:50:17] <iceeey_> we talked about using stackless python before and microthreads, is that still on the menu?
[22:50:41] <thebolt> well, one thing which is related to actions, threading, and behaviours is the use of stackless pythons microthreads
[22:50:44] <thebolt> hehe:P
[22:51:26] <thebolt> there is a slight complication in scheduling them from c++ (could be solved) as well as running several c++ threads with python code..
[22:54:09] <PK> btw, have you seen that graphic conversation editor screenshot I posted here a few days ago?
[22:55:58] <thebolt> so, question is if stackless python is a good choice.. i guess we could try out a small prototype to see if it is working (or what would be needed to make it work)
[22:56:05] <iceeey_> one thing about stackless, installation is kind of annoying: on nix, you need to compile it, on windows, copy over some dlls
[22:56:17] <iceeey_> yeah
[22:57:57] <sueastside> want my MUD? :D
[23:00:32] <iceeey_> of course it could get better packaging eventually
[23:03:55] <thebolt> hm, i'll see what i can write up tomorrow or so (just a small application that schedules stackless threads, possibly in multiple c++ threads)
[23:04:10] <iceeey_> http://www.stackless.com/wiki/BoostPython
[23:04:48] <iceeey_> i thought boost.python is a bunch of headers, so is "compiling against it" necessary?
[23:04:50] <PK> also interesting about all the threading is, how do we design the system that it scales.
[23:05:15] <iceeey_> scales to what?
[23:05:52] <PK> multiple cpus for example
[23:06:06] <thebolt> iceeey_: boost::python is both headers and source
[23:06:33] <iceeey_> thebolt, then people will have to compile boost python against stackless :) more work
[23:06:36] <thebolt> PK: which is why it is intresting to see if you can run behaviours on several threads (at once)
[23:06:47] <thebolt> iceeey_: it just needs to link against stackless ;)
[23:06:52] <PK> or if one player manages to lock a thread for a few seconds, the other players are still being served by other threads (take webservers for example, apache httpd)
[23:06:53] <thebolt> and linking is when linking your app ;)
[23:06:56] <iceeey_> my bad
[23:07:11] <iceeey_> didn't make sense to me either :)
[23:07:19] <iceeey_> hm, i think i read somewhere that stackless doesn't support multiple processors but they want to do that in the future
[23:07:57] <thebolt> yea.. i am guessing there is global data in there:/
[23:09:36] <iceeey_> anything we actually need to worry about though? I mean assume they implement it at some point, anything we need to do? or can we live with running stuff on one processor for the time being (we only intend to accommodate ~100 players anyway on short term at least)
[23:11:12] <thebolt> yea, at least one thread for the python stuff should be enough i think
[23:11:12] <sueastside> iceeey_: wasnt that automatic processor migration? iirc i read somewhere you can spawn as many real threads and run tasklets in there...
[23:12:53] <PK> we could also run a "behaviour" process and instance it once for each cpu :)
[23:13:19] <iceeey_> now what actually runs as a microthread?
[23:14:55] <thebolt> iceeey_: well, i would think each behaviour/action would? problem is if two behaviours starts modifying same state etc.. but that could be solved by saying that the python code must make sure it doesn't
[23:15:56] <iceeey_> e.g. locks
[23:16:18] <thebolt> yea
[23:17:07] <thebolt> "Scheduling and Threads
[23:17:09] <thebolt> The Stackless scheduler is directly linked to the current thread, so if you use more than one thread, the tasklets you create on each will be local to that thread. You can see the thread-safe Sleep function independently manage the tasklets that were added on any given thread on that thread."
[23:17:39] <iceeey_> right, you have complete control over scheduling
[23:18:39] <PK> another question... what do you guys think about a graphical behaviour editor / designer? I guess it could work like LEGO Mindstorm programming? (not that I ever used that, maybe iceeey_ would know more about it?).... if we have a good editor, it doesn't matter in what language the behaviour is written in... could be python, xml or c++ all the same.
[23:19:08] <iceeey_> PK, sorry, i hated that :)
[23:19:42] <iceeey_> i'd rather have one language that is well supported
[23:19:43] <PK> Some stuff I hacked together as a tutorial on eclipse GMF: http://img184.imageshack.us/img184/6246/dialogeditor6en.jpg <-- NPC Converstation Editor with question <-> answer relations
[23:20:35] <PK> it's really just 30 minutes I spent for creating that editor... so it doesn't look that nice :)
[23:21:27] <iceeey_> we could certainly have a nice NPC dialogue editor
[23:21:30] <PK> the diagram is being stored in two xml files. One for the datamodel, and one for the graphical representation. So you can just parse the xml in your app now and use whatever you modeled
[23:21:44] <iceeey_> but it is only read in by the behavior code, it isn't the code itself
[23:22:02] <PK> the question is, would it work for behaviour and actions too.
[23:22:19] <PK> Can you define the behaviour in XML (CEL can for example)
[23:22:29] <iceeey_> well, one option is to allow designers to connect events to behavior functions
[23:22:37] <PK> and you don't have to write the unfamiliar looking XML code because it's graphical for you
[23:23:01] <iceeey_> I'd rather not use XML to write code
[23:23:44] <PK> you don't use it... you use the graphical editor :-) xml just how you store it in the file.
[23:24:01] <PK> you could also let it generate python code if you want (write the generator for it)
[23:24:07] <iceeey_> what's the point?
[23:24:38] <PK> but I guess you can't parse the python code back into the editor again that nicely.
[23:24:55] <iceeey_> i really think that isn't part of the core code.. sounds more like a way of designing quests, e.g. data for some behavior
[23:25:11] <PK> yes
[23:25:16] <PK> of course
[23:25:32] <PK> I mean, in CEL the xml isn't the core code either.
[23:26:18] <PK> it's fully datadriven behaviour then... or well, where do you differ between data and code?
[23:32:24] <iceeey_> when it looks like CEL xml :)
[23:32:36] <PK> I was thinking that with a good datamodel, you wouldn't need much more than flow control... for example you have an Action "OpenDoor". That action has two Conditions "IsDoorClosed" and "IsDoorUnlocked". If both are true, then it leads to an event. OpenDoor event of course.
[23:33:13] <iceeey_> it's simple, but it's limitting too
[23:33:56] <PK> go ahead
[23:34:35] <iceeey_> i wanted to make the action system have like: validation (a function returning true/false), then perform (performs the action)
[23:36:23] <PK> well, that's the same... Conditions are the validation, and the event is the perform part.
[23:36:27] <iceeey_> i know
[23:36:38] <PK> so where's the problem?
[23:36:40] <iceeey_> but they are all code
[23:37:15] <iceeey_> or is that what you meant too?
[23:37:16] <PK> which is good or bad? or both...
[23:37:50] <iceeey_> it's fine imo
[23:38:50] <PK> well, as for conditions, I would like to keep it simple. Maybe just "door_state" 'is equal' "closed" for the IsDoorClosed validation... eh, condition. If you keep it simple, it will be cleaner to maintain imho.
[23:40:13] <PK> in c++ you could go like if (door->getState == Door::State_Closed) then or if (door->isClosed() ) then... you see, it gets quickly complex.
[23:40:26] <iceeey_> def validateOpenDoor(self, player):
[23:40:27] <iceeey_> return (player.distanceTo(self.position) <= self.minDistance) and (self.state == "Closed")
[23:41:14] <PK> yep, two conditions: one for the distance and one for the state
[23:42:06] <iceeey_> in the end, you're welcome to implement conditions in a simpler way