On Wed, Apr 22, 2009 at 9:50 AM, Kai Sterker <kai.ster...@gmail.com> wrote
> Starting with implementation on Monday, I stumbled across the first > problems around line 3 or so :-). My idea for get_area_of_effect() is > to return a radius and an arc to define the area in which to check for > affected objects. Got a somewhat simplified version working. All it does for now is to print Player triggered action with NPC whenever you interact with the NPC in worldtest (press left ctrl). I'm not so happy with the key bindings now. I guess it would be better to exchange the jump and interaction keys. Anyway, what remains now is to integrate the dialogue widget, so that this gets opened instead of just printing the note above. One fairly large issue has come up again, however: there's no way to get at the map instance from anywhere outside map views or things placed on the map. I think we need to decide how we want to handle maps. Have a global map manager that can return a map by its id? Have only one global map? Have references to the map for more objects? Proposals welcome. Finally, a brief word on the implementation: it lives more or less completely on Python side. The initial trigger is in data/schedules/char/player.py: elif btn == input.control_event.C_BUTTON: actions.perform_action (self.pc, self.state) This calls perform_action in data/schedules/char/actions.py, which in turn will access the character implementation at data/characters/character.py. Latter is the class that contains the RPG character template. It can be different for different types of characters and thus implement different behaviors for the same action (i.e. no talking with animals). I plan to add a more detailed description to the Scripting section of the Wiki, but probably only after the code is a bit more mature and less likely to change. Apropos scripting. As I found out, the Python wrappers are in quite a bad shape. Seems that SWIG doesn't work too well with namespaces. If you have C++ code like this namespace world { class entity { }; class x { entity *a() world::entity *b() }; } then SWIG will create code that compiles fine, but internally it will treat entity and world::entity as two different types. In fact, it will know that world::entity matches the class entity defined in namespace world, whereas it will know nothing about entity as returned by method a(). That means, we'll have to go over our header files and make sure that any of our classes is properly prefixed by its namespace. When looking for "SWIGTYPE_p_" in the generated wrapper files, it's fairly easy to see if anything is wrapped wrongly: #define SWIGTYPE_p_entity swig_types[8] <-- something's wrong #define SWIGTYPE_p_world__entity swig_types[38] <-- okay Of course, that doesn't tell where in the headers the error is, but it allows to narrow down the search to a few types. Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel