[02:35:11] iceeey__ has joined #peragro-dev
[03:16:18] PK has quit: Read error: 104 (Connection reset by peer)
[04:50:19] CyaNox has quit: Read error: 54 (Connection reset by peer)
[04:50:19] CyaNox_ has joined #peragro-dev
[04:50:35] CyaNox_ changed nick to: CyaNox
[04:54:53] sueastside has quit: "Night, sweet dreams, dont let the bedbugs bite, watchout for the mare, dont mistake the sandman for a burglar, ..."
[10:52:16] caedes has joined #peragro-dev
[13:26:28] caedes has quit: Read error: 60 (Operation timed out)
[13:38:26] caedes has joined #peragro-dev
[14:00:26] caedes has quit: Read error: 60 (Operation timed out)
[14:02:28] caedes has joined #peragro-dev
[14:20:02] caedes has quit: Read error: 60 (Operation timed out)
[14:30:56] caedes has joined #peragro-dev
[14:41:03] sueastside has joined #peragro-dev
[14:41:03] ChanServ sets mode: +o sueastside
[16:03:23] caedes_ has joined #peragro-dev
[16:03:33] caedes has quit: Read error: 110 (Connection timed out)
[16:23:23] caedes has joined #peragro-dev
[16:41:12] ChanServ sets mode: +o thebolt
[16:45:06] caedes has quit: Read error: 60 (Operation timed out)
[16:53:55] caedes has joined #peragro-dev
[17:54:41] * thebolt begins talking aobut iceeey to summon him ;)
[17:58:12] iceeey has joined #peragro-dev
[17:58:12] ChanServ sets mode: +o iceeey
[17:59:04] <sueastside> thebolt: cool, you have to teach me that :D
[18:02:30] <thebolt> :-)
[18:02:33] <thebolt> hey iceeey
[18:02:47] <thebolt> ·17:54· thebolt begins talking aobut iceeey to summon him ;)
[18:02:47] <thebolt> ·17:58· iceeey >>> [n=ice@unaffiliated/iceeey] joins #peragro-dev
[18:02:48] <thebolt> ;)
[18:05:27] <JohnTitor> SVN--> thebolt commited r553 to peragro_src with log message: - Marten did a small refactor on the entity/entitytemplate parts., - Marten added some first python binding things. (+1106, -261).
[18:11:49] <JohnTitor> SVN--> thebolt commited r554 to peragro_src with log message: - Marten did some file reorganization. (+915, -1099).
[18:16:12] <iceeey> hi thebolt
[18:40:28] <thebolt> iceeey: care to bear with me for some "reiteration" of how stuff is supposed to work in a little while?
[18:43:17] <iceeey> sure
[19:12:05] thebolt2 has joined #peragro-dev
[19:18:05] caedes_ has joined #peragro-dev
[19:19:25] caedes has quit: Read error: 54 (Connection reset by peer)
[19:23:34] thebolt has quit: Read error: 110 (Connection timed out)
[19:29:31] ChanServ sets mode: +o thebolt
[19:29:45] <thebolt> iceeey: okay, you there?
[19:29:47] <iceeey> yea
[19:29:59] <thebolt> so.. how to connect stuff to behaviours?
[19:30:13] <thebolt> as far as i can say there are two things that could result in a behaviour script being called..
[19:30:26] <thebolt> a property change (event) and an event/call from a component
[19:30:39] <thebolt> any other?
[19:30:46] <iceeey> action
[19:30:55] <thebolt> hm?
[19:31:30] <thebolt> ahm.. right
[19:35:17] <thebolt> i'm trying to work out (a basic) python connection thingy.. and it isn't trivial how it should work ;)
[19:36:02] <iceeey> yeah
[19:38:08] <thebolt> my idéa atm..
[19:38:30] <sueastside> dont just say yeah, help thebolt think or atleast rub his temples or feet or something...
[19:38:54] <thebolt> each python fragment (function) is compiled into a python object, a handle to it stored
[19:39:49] <thebolt> a "behaviour" class keeps a lists of fragments and a python class with all the fragments combined
[19:42:12] <thebolt> upon creation an Entity (Which contains definition of all properties, components and behaviours) gets a "master-class" (or rather a python dictionary ;) that have all the behaviour methods, all the properties (exposed as members in "self") and components (via self.)
[19:43:05] <thebolt> so, to call a behaviour script on an EntityInstance you call the function handle (via boost::python stuff), passing along the dictionary comming from the entity class
[19:47:29] <iceeey> that sounds good
[19:47:59] <thebolt> currently i'm experimenting with how to actually do the exposure ;)
[19:49:18] <JohnTitor> SVN--> iceeey commited r555 to peragro_src with log message: Fixed various compile errors/warnings for Linux., (+11, -3).
[19:49:53] <iceeey> okay
[19:49:55] <thebolt> ie how and when to register stuff to python ;)
[19:50:30] <iceeey> hm
[19:50:42] <iceeey> you should be able to register everything at load time, right?
[19:51:13] <thebolt> yea
[19:51:25] <thebolt> just need to do it in right order (Esp with regards to entity definitions etc ;)
[19:52:29] <iceeey> but the 'class' itself will not be created until Entity is flattened, and then entity instances will receive an instance which has the default values set and any values overridden by the instance
[19:52:55] <thebolt> hm, now i don't follow you?
[19:54:09] <iceeey> the class containing all properties and components that is passed to python behavior method as "self" is made (not instantiated) in Entity
[19:55:00] <thebolt> Yes
[19:55:53] <iceeey> then when you create an EntityInstance, the Entity::CreateInstance() will fill in the default values
[20:00:17] <thebolt> well, the Entity should already have all information needed to create the instance
[20:00:43] caedesX has joined #peragro-dev
[20:00:45] <iceeey> well yes
[20:01:09] <iceeey> except instances can set property values
[20:01:35] <iceeey> but that is a separate step i suppose
[20:01:44] <thebolt> well, that have to be done by the party creating the instance after actually creating the instance ;)
[20:01:46] <iceeey> like when loading from a DB, you would set the properties
[20:01:48] <iceeey> right
[20:01:53] <iceeey> okay
[21:24:18] <thebolt> hm, intresting.. my python calling works ;)
[21:25:29] <sueastside> thebolt's code works??? its a miracle!!
[21:26:18] <thebolt> and the intresting thing is that it is very easy to dynamically expose c++ methods :)
[21:26:51] <thebolt> http://rafb.net/p/OGIDx711.html
[21:33:30] <thebolt> (if anyone is intrested in very sloppy test-code ;)
[21:33:38] <sueastside> Blah!
[21:36:16] <thebolt> the intresting part is that it proves our ideas are feasible ;)
[21:36:33] <thebolt> iceeey: one thing.. we need to define "preset" call signatures for the behaviours
[21:36:55] <thebolt> or well, per-event rather ;)
[21:40:56] <thebolt> so that say a PropertyUpdated script always is called with say OnUpdate (EntityInstance, Property)
[22:18:55] <iceeey> yeah
[22:19:58] <iceeey> i would try to make them as clear as possible
[22:20:08] <thebolt> definitly
[22:20:11] <thebolt> and documented ;)
[22:20:41] <thebolt> (however as python is dynamically typed you cannot "compile-time" check them to be correct)
[22:23:37] <iceeey> maybe the prefix specifies what kind of behavior method it is? action, event, and update are the different types, so: Action, Event, Update could be prefixes?
[22:24:21] <thebolt> hm, how do you mean?
[22:24:28] <iceeey> in the template's behavior map
[22:24:40] <iceeey> ActionInteract = SomeBehavior.OnInteract
[22:25:26] <iceeey> UpdateState = SomeBehavior.OnStateChange
[22:25:47] <thebolt> well, its just a naming convention
[22:26:02] <iceeey> yes, well you need some way to map the actual 'events'
[22:26:28] <iceeey> in the case of events, the event name is defined by the component
[22:26:35] <thebolt> yep
[22:26:41] <iceeey> but actions and updates need some convention
[22:26:58] <iceeey> and it would be good to reinforce the naming at a higher level
[22:27:03] <thebolt> well, updates would be propertyname.change or propertyname.update or so
[22:27:09] <iceeey> sure, that could work
[22:27:11] <thebolt> but yes, it is a good idea to keep to a standard for names
[22:30:27] <thebolt> so, idea is, you have "behaviour binding points" and you have "behaviour functions".. those are bound together in the entity(template)
[22:30:49] <thebolt> binding points are either defined in the entity(template) (for actions), in the property or in components
[22:32:41] caedes_ has joined #peragro-dev
[22:37:43] caedesX has quit: Read error: 110 (Connection timed out)
[22:46:47] <iceeey> thebolt, that sounds right
[23:05:15] <thebolt> hm, i think (if boost::function works as i think) that we can have behaviour functions logically disconnected from the python interface, without loosing any performance
[23:06:08] <thebolt> so "central" behaviours could be written in c++
[23:17:31] caedes has joined #peragro-dev