On Fri, Jan 27, 2012 at 7:10 PM, StyxD <sty...@gmail.com> wrote: > Basically, there'll be a python module that has a persisting event > factory that creates events for closing and moving text balloons. > It'll keep a list of currently displayed balloons too, just to avoid > messing with "thisown" once and for all. I originally intended > comments to be created as objects and then handling all the > displaying/event stuff inside, but it seems to be problematic. > > Is that an OK design (persisting objects in a module, I mean)?
Should be okay, as part of the actual game implementation will be on Python side anyway. (Items are mostly Python modules, for example, so they are persisted from a module as well) > By the way, is there some way of passing arbitrary arguments to a > python function called from an event? There seems to be one method for > that, connect_callback from listener, but it requires full path to the > function in a file (I suppose it's used for all those map events) and > it seems impossible in event factory (where the python version of > register_event just converts the call to a c++ functor.). You can only do it through the low level interface, as you already figured out. There's an example in test/eventtest.py lst = fty.add (ev1) lst.connect_callback ("time_events", "event_script", "callback_1", ("#1", 1)) In there we pass the string '#1' and the integer '1' as additional argument. The callback in test/data/game_events/time_events.py then has the following signature: def callback_1 (self, lst, evt, str, num): The last two arguments are where it receives the string and number. The only restriction here is that those additional arguments must be persistable themselves. This basically limits them to strings and integers. See python::put_tuple(...) for the reason. The alternative (although not sure if that is viable in your case) would be to pass additional data through the event structure itself. The triggering event is always passed to the callback (the evt parameter in the example above) and can be used to convey runtime data that needs no persisting. > I don't strictly need this, but it just seems weird to me. I think I added the python version of factory::register_event as a shortcut, for when you don't need the persistence. But initially you were supposed to make the two steps by calling factory::add and then connect the callback to the resulting listener by specifying the module, class and function name. That way, the callback can be reconnected when restoring a persisted factory. (I guess all that data could be gathered via introspection nowadays, but I'm not sure if that was already possible with Python 2.0 back then.) Hope that helps explain the weirdness. If you can think of better ways to handle this, we can improve the API at that point. Most of the stuff has been written a long time ago and could have been designed better. > I hope I'll be able to get this done by the end of the next week. > Sorry for the delays. No need to apologize! Looking forward to the resutls, however :-). Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/adonthell-devel