[DGD] Shadows issue

[Shentino]

This might be a bit of advanced gobbledegook, but I think this might work
for shadowing:

override call_other to check the shadow with a "function_object" check to
see if the shadower defines an alternative version.

If so, call it, otherwise, call the normal object.

You might have trouble with variables though.

Personally I found shadowing to be an obfuscatory mess when dealing with
actual code from what little I learned of it.  So, YMMV.

On Fri, Jul 17, 2009 at 2:49 AM, Kamil Niechajewicz <kamiln at gmail.com>wrote:

> Hello all,
> I just recently discovered DGD mudlib and it looks reallypromising and
> interesting. My experience as MUD developer started with Diku type
> MUDs, but I quickly dumped them in favor of LpMUDs, and spent most of
> my coding time with LPC & CD driver for Genesis LPMUD.
>
> I haven't really done anything in LPC in last 6-7 years but recenly I
> regained my interest in MUDs and decided to try and write my own
> mudlib based on DGD driver (even if I never finish it, it may be a
> good fun to try :). So far I really like what DGD offers and most of
> the design decisions made by its authors, but with one thing I
> encountered some "theoretical" problems. As I'm used to functions that
> CD offered, I wonder what is the best way to achieve effect that
> "shadowing" had in mudlibs based on CD.
>
> Just to remind - shadows in CD mudlibs were mostly used for things
> like guild membership - player inherited pre-defined empty methods
> that described guild titles, taxes and other things and when he joined
> a guild he was given a shadow that masked those methods, so they
> started to return proper guild title, tax etc. Same for stuff like
> changing appearance, lets say we want to give player a chance to
> become an undead - I think the easiest way it was done in CD was to
> give him some kind of "undead" shadow that overriden all necessary
> methods like player description, player shorts, even how he
> enters/leaves the room, how he acts in combat etc. etc. Same for
> "fluff" like mounts if I remember well - it was all based on shadowing
> certain methods, and by doing it achieving very varied effects. Also
> this method didn't force coders to design and imagine every possible
> change that should be allowed in certain objects - they could always
> mask these methods by using shadows (unless it was prevented for that
> object).
>
> I hope I described the uses of shadows I'm interested in good enough,
> if not please say so and I will try to provide some sample code or
> something :) I searched for this topic before writing this mail, but
> haven't found too much information. There was even attempt to mimic
> shadows behavior in mudlib by overriding call_other, but I'm not sure
> I should use this method if whole shadow thing was skipped in driver
> (there was some reason I guess).
>
> Maybe you know different approaches to code things that I described
> (some nice new way to do this "modern" way), so: guild membership,
> changing user behavior or even whole user "living" object so it
> becomes undead creature or some super-monster etc. I guess it could be
> achieved by changing body object to different one, but how to do it
> when its already inherited by player? Is it possible to change
> inherited objecy "on the fly"? So if player is inheriting LIVING_BODY
> we change it for UNDEAD_BODY and he automatically receives proper
> methods changing his descriptions, behaviour etc? This must be done
> without relogging player of course.
>
> Any help is appreciated, I'm a bit "rusty" if it comes to designing
> these things nowdays, but I'm reading alot and trying to find best
> possible design solutions, but some things like the ones above are not
> covered too much in any documentation & manuals. So far most of
> discussions here covered more low-level things about mudlib design,
> and my problem lies more in that "higher" tier of programming mudlib
> where you code guilds, mounts, advanced changes to player behavior /
> body, things that affect combat etc.
>
> Thanks,
>
> KN
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>