[DGD]DGD and Melville

[Nightlith]

> Nightlith writes:
>
> >user.c inherits login.c like always. But I want to also inherit
creation.c
> >so after a new user is created, it moves on to creating the player.
> >creation.c only has the functions neccessary to create a new player and
> >that's it. player.c inherits living.c and both have all the stat accessor
> >functions. Obviously creation.c needs access to those functions, so I
> >thought by putting creation.c in user.c after login.c, it would have
access
> >to the cloned player object at login. I was wrong, and the error is
simply
> >an undifined variable error (a variable set in player.c).
> >If that makes sense, great. But I haven't slept in 36+ hrs...so I'm kinda
>
> Right - I think I understand what you're doing now.  You've changed things
> from the Melville system, and now have:
>
> living ---> player
>
> creation -+-> user
> login ----+

Yah, that's it :-) I'm glad I didn't sound like a complete lunatic.

> user has a variable telling it which player object to use.  The player
> object (itself, or inherited from living) has functions to set the
> necessary variables.  You want creation to call that function.  But
> creation needs to know which player object to call it in.
>
> So far, OK.  Unfortunately, it is impossible for an inherited object to
> access the variables of objects that inherit it.   creation is an
> independent object, and it doesn't have the player variable (DGD doesn't
> know that you'll never use it except in user).  So when it tries to
compile
> it, it finds you using a variable that doesn't exist, and complains.
>
> Your situation is worse because both login and creation need that
variable.
> The best solution I can think of is to pass it as a parameter to all
> functions that need it.  Or you could define get_player_object() in user.c
> and have creation and login call this_object()->get_player_object() every
> time they need it.  I'd recommend you don't give them both a private
> variable that gets set appropriately by user.  That's just begging to get
> them out of sync sometime, and it'd be hell to debug.

Ah, ok. It makes alot more sense when you talk stuff like this out. Thanks
for the help :-) I though that since login.c creates the player object,
inheriting creation below login would give creation access to the player
object.

Dereck.



List config page:  http://list.imaginary.com/mailman/listinfo/dgd