[00:01:21] <iceeey> well how are behaviors written? they are free functions, no?
[00:02:04] <thebolt> if entitys are python classes i would say they are either free functions taking a self parameter or member functions
[00:02:13] <thebolt> pretty much along the lines of the sample you wrote up the other day
[00:02:46] <iceeey> if they are members of the entity, doesn't that pretty much tie behaviors to specific entity templates?
[00:03:37] <thebolt> well, if you want a new behaviour, subclass it and attach the new functions instead then
[00:03:55] <thebolt> as simple as having a table of mappings or so
[00:04:07] <iceeey> hm ok
[00:04:47] <iceeey> it seems like an editor for that would have to be a text editor
[00:05:04] <iceeey> at least for the behavior part
[00:05:10] <thebolt> not neccesarily
[00:05:19] <thebolt> python have reflection you know ;)
[00:06:32] <thebolt> but initially i would say main editor would be a text editor, yes
[00:06:38] * PK will create a lego mindstorm like graphical editor for the behaviours ^_^
[00:06:51] <PK> I guess the hard part would be the python generation then...
[00:07:23] <iceeey> PK, not a bad idea, except don't make it like them :)
[00:08:03] <iceeey> so how does the "data" fit into the entity template?
[00:08:08] <PK> iceeey: don't worry, I've never seen a lego mindstorm ide... it would really just be coincidence... :)
[00:08:39] <PK> well, what do you really want to store in the templates?
[00:08:54] <iceeey> i assume you would have it as a field, like a property, but it would be of a certain type like Quest, which has functions that deal with quests, and is capable of serializing itself
[00:09:37] <PK> I see it like a recipe (spelling correct this time :-P)...
[00:10:08] <thebolt> iceeey: hm, i would say more explicit.. like
[00:10:34] <PK> 100g AI + 300g Combat... mix it, bake it at 300° for 15min and your entity is read to go
[00:10:53] <thebolt> (writing..)
[00:11:09] <thebolt> class SlayDragonQuest(Quest):
[00:11:11] <thebolt> ...
[00:11:20] <thebolt> def __init__ (..):
[00:11:41] <thebolt> questEngineComponent.LoadQuestScript (PT.Persistence.GetScript(...))
[00:12:01] <thebolt> (or possibly just set a property on the component to the name of the data item ;)
[00:12:11] <thebolt> but you get the idea
[00:12:37] <iceeey> well quests are tricky because they are kind of like data, but they have some procedural aspect
[00:12:50] <iceeey> just like rules and conversations even
[00:13:33] <PK> I guess the rules will be the trickiest imho...
[00:13:50] <thebolt> well, what do you mean by "rules"?
[00:14:39] <iceeey> I'm thinking of calculations for attack by race
[00:14:41] <PK> I guess stuff like combat rules.... hit = 3d12 + 3 or so
[00:15:26] <iceeey> or by weapon even
[00:15:41] <thebolt> hm, behaviour/script/action on weapon item?
[00:16:29] <iceeey> sounds good to me..
[00:16:53] <thebolt> hm, i really need to sleep now
[00:17:00] <thebolt> i got some ideas after reading the eve ppt
[00:17:03] <iceeey> okay
[00:17:10] <thebolt> but tomorrow i don't have much time until late evening
[00:17:12] <iceeey> I'll try and put stuff on wiki
[00:17:19] <thebolt> but we'll see if i can make some progress on some prototyping
[00:17:28] <thebolt> (some kind of execution core prototype)
[00:17:28] <iceeey> late evening.. I'll be around :)
[00:17:38] <iceeey> cya
[00:18:06] <PK> sleep... seems like a sounds idea :)
[00:18:21] <PK> good night
[00:18:28] <iceeey> uthreads.sleep ;)
[00:18:35] <iceeey> night PK
[00:18:56] <PK> late evening huh? ... so maybe I'll see you leaving tomorrow morning :)
[00:19:01] PK has quit: "night"
[07:08:33] sueastside has joined #peragro-dev
[07:08:33] ChanServ sets mode: +o sueastside
[10:29:42] PK has joined #peragro-dev
[10:29:43] ChanServ sets mode: +o PK
[10:58:58] caedes has joined #peragro-dev
[10:58:59] ChanServ sets mode: +v caedes
[11:07:23] PK has quit: Read error: 113 (No route to host)
[11:08:31] PK has joined #peragro-dev
[11:08:31] ChanServ sets mode: +o PK
[11:52:04] caedes has quit: Read error: 104 (Connection reset by peer)
[11:52:31] caedes has joined #peragro-dev
[11:52:31] ChanServ sets mode: +v caedes
[12:15:30] thebolt|away changed nick to: thebolt
[15:54:47] iceeey has quit: Read error: 110 (Connection timed out)
[16:14:54] PK has quit: Read error: 104 (Connection reset by peer)
[17:06:22] iceeey has joined #peragro-dev
[17:06:23] ChanServ sets mode: +o iceeey
[17:08:17] <iceeey> hi
[18:12:32] iceeey has quit: "Leaving"
[18:16:26] Induane has joined #peragro-dev
[18:16:26] ChanServ sets mode: +o Induane
[18:50:33] PK has joined #peragro-dev
[18:50:33] ChanServ sets mode: +o PK
[18:57:41] thebolt|away changed nick to: thebolt
[19:39:35] PK has quit: Read error: 110 (Connection timed out)
[19:56:26] PK has joined #peragro-dev
[19:56:26] ChanServ sets mode: +o PK
[19:59:27] caedes changed nick to: caedes|away
[20:28:57] Lightwave has quit: "http://www.silversounds.org/ - Join the forums; fuel the debate."
[20:36:44] caedes_ has joined #peragro-dev
[20:36:44] ChanServ sets mode: +v caedes_
[20:50:06] caedes|away has quit: Read error: 110 (Connection timed out)
[21:05:18] iceeey has joined #peragro-dev
[21:05:19] ChanServ sets mode: +o iceeey
[22:15:35] PK_ has joined #peragro-dev
[22:15:35] ChanServ sets mode: +o PK_
[22:23:06] PK has quit: Read error: 60 (Operation timed out)
[22:28:21] PK_ changed nick to: PK
[22:35:17] Lightwave has joined #Peragro-Dev
[22:35:17] ChanServ sets mode: +v Lightwave
[22:49:30] <iceeey> did i say they were idealists? ;)
[22:50:09] <sueastside> no...
[22:50:24] <iceeey> ryzom people
[22:50:44] <sueastside> i said no, not who
[22:51:02] <iceeey> i know what you said
[22:51:18] <iceeey> it was a scoffing remark
[22:51:39] <iceeey> but apparently IRC didn't send you that part
[22:52:23] <sueastside> my client nlocks scoffing...
[22:52:26] <sueastside> *blocks
[22:53:16] <iceeey> anyway i thought about the entity system a bit today
[22:53:33] <iceeey> I'll wait till thebolt wakes up to start :)
[22:53:43] <iceeey> unless anyone else wants to talk
[22:54:07] Induane has quit: "BitchX: for distribution only with a new PC"
[22:54:24] <sueastside> im always interested...
[22:54:30] * sueastside summons thebolt
[22:55:08] <iceeey> okay, the main thing is sending entity updates in sets
[22:55:21] <iceeey> instead of "random" updates of properties, they are sent atomically
[22:56:35] <iceeey> so if you go OpenDoor(), the server broadcasts to the clients that a door was opened, not that some state property changed
[22:56:45] <iceeey> but that's too simple, since it's just one property
[22:56:56] <iceeey> something like WalkTo
[22:57:05] <iceeey> or equipping a weapon
[22:57:38] <iceeey> the clients see a WalkTo event and then they know how to respond to it
[22:57:46] <sueastside> soo a message per 'action'?
[22:57:53] <iceeey> usually it will correspond to actions
[22:58:04] <iceeey> but i'm sure some actions are more private and not visible to others
[22:58:16] <iceeey> which is why there should be a sort of filtering system
[22:58:28] <iceeey> based on the capabilities of the player
[22:58:57] <iceeey> so only things in a certain range accounts for vision (some races may have better vision even)
[22:59:47] <iceeey> it's also analogous to encapsulating the properties
[23:00:07] <iceeey> it doesn't matter how the door's state is kept
[23:00:19] <iceeey> the client will still see an OpenDoor message
[23:00:44] <iceeey> just like the server has encapsulation with Actions
[23:01:07] <iceeey> and then another advantage is that it makes it easier to write AI
[23:02:08] <iceeey> the messages are essentially everything the client "sees"
[23:03:33] <sueastside> disadvantage seems that you need to explicitly define these message and when they are send (instead of just doing something like SendUpdateProp() or whatever)
[23:03:37] <iceeey> it's more meaningful than a bunch of state changes
[23:03:48] <iceeey> i know
[23:03:50] <iceeey> it's explicit
[23:03:54] <iceeey> but that's good
[23:04:08] <iceeey> you should be aware of what you're sending clients
[23:04:13] <iceeey> and i have to go, sorry
[23:04:18] <sueastside> k cu
[23:04:31] iceeey has quit: "Leaving"
[23:50:30] <thebolt> hi everyone
[23:52:52] <PK> hey thebolt
[23:54:54] <PK> sueastside: hm, it's odd, but I even agree with iceeey for once :-) sending messages per action is probably the highest abstraction level we can get and therefore also the best possibilities to avoid unneeded network traffic. (The more you know about the data, the better you can compress it)
[23:55:49] <PK> There is a problem with the sending on action... you also need to send the entity states when you first send an entity to the client. Otherwise you wouldn't know whether that door is now open or closed.
[23:55:56] <sueastside> Damn pending apocalypse!
[23:56:03] <thebolt> hehe