[Adonthell-devel] Re: Interaction on the map

[Kai Sterker]

On Wed, Apr 22, 2009 at 9:50 AM, Kai Sterker <address@hidden> 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