[DGD] FLS

[Raymond Jennings]

It's generally a bad idea to rely on any solution that requires tweaks to
DGD itself.  If you can do it in LPC, you should.

Especially with something as abstract as a player or a user that DGD itself
has no concept of.

That said, if you want to override call_other, in my opinion that would be
the cleanest way to catch when you need to manipulate the "this_plaeyr" or
"this_user" stack to index the proper FLV

On Wed, Oct 4, 2017 at 3:45 PM, Blain <blain20 at gmail.com> wrote:

> I implemented the this_user idea in the kernellib's TLS implementation, but
> there was no easy way to tell if the setting corresponding to a given frame
> is expired.  So thus the FLS idea was born.
>
> If DGD could supply a null element before the first arg, all else could be
> handled by the lib.  The current klib's implementation of TLS could also be
> made to use this instead of having to create wrappers for entry-level
> functions in driver.c to basically do the same thing (except with only
> frame 0).
>
> On Oct 4, 2017 17:01, "Blain" <blain20 at gmail.com> wrote:
>
> > I envisioned looping backward to find the latest setting for implementing
> > something like this_player(). Obviously not all uses of something like
> this
> > would need to do that, though.  Another possible use is to let a frame
> > store unique data that later frames can query, such as stack-based
> security.
> >
> > On Oct 4, 2017 16:10, "Felix A. Croes" <felix at dworkin.nl> wrote:
> >
> >> Blain <blain20 at gmail.com> wrote:
> >>
> >> > I'm talking about one for each frame so that it goes away
> automatically
> >> > when that frame goes away.  An example use is a variable for the
> current
> >> > user/player/body in a given frame that is automatically rolled back
> when
> >> > the frame ends and focus goes back to a previous frame, who's current
> >> > user/player/body variable will then be on top.
> >>
> >> This is more than what you called FLS, since it also involves setting a
> >> new value for each frame, or else falling back to a value provided by a
> >> previous frame.  I would describe that as stack-based, rather than
> >> frame-based.
> >>
> >> If you're looking for a this_player() equivalent, there is an example
> >> implementation in the LP 2.4.5 mudlib simulation.  It doesn't use, but
> >> could be done with, thread-local storage.
> >>
> >> Regards,
> >> Felix Croes
> >> ____________________________________________
> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>