wanting to loose this_player()

[beren]

I have come up with a situation where I want to loose this_player()
ie I don't want it to return the player object that has caused this particular function to have been called (it can return zero)

Is there a way to actually cause this ?
I have  this_player_in_call_out defined so that little trick can't work.

[beren]

OKs maybe I should explain a bit better what I am trying to do :

I have enabled GMCP and when a player enters a room I send through GMCP info about that room including the exits and an id of the destination of room of each exit so as to build a map in our custom GUI.
In most cases that is not a problem but some exits are defined as
set_exits([ "north" : "@@some_function@@" ])

The function may do a check on lvl/guild/whatever and return a valid exit or deny but in most cases it just gives some message to the player when he moves in that direction or it might do some action on the player.

If I use something like process_string(some_function)  (to get the room id to send through GMCP) because this_player is defined whatever message, or more worryingly, action is defined in there will be performed on the player object even before he moves towards that exit.
At the moment I just ignore exits like that but it causes the mapper to fail in some rather popular areas and I would like to try and find a solution for this.

[quixadhal]

Make some_function() not use this_player(), but instead use this_object()?

Don't subvert the functionality of something that's used throughout the entire mudlib with a known and expected result to work around a local issue.  If your issue is with the way your exit check functions are working, change your exit check functions to be more predictable for your use case... don't change this_player() so it now doesn't perform its intended function.

[beren]

Changing how exits work is easier said than done.
With 10k+ unique rooms a lot of them do have such functions so we would need to go through them one by one.
Not practical at all.

That is why I was asking if there was this particular solution achievable some how.
I have a couple more ideas how to circumvent the problem
but all of them have their own unique problems.

[beren]

Also you seem to misunderstood.
My problem is not how the exit functions are working. They are working as they should for play.

My problem is that I actually want to evaluate those functions to send the proper data to the mapper through GMCP.
Otherwise ofcourse this_player() should be actually defined.

Anyways it was a long shot.

[quixadhal]

Well, the mapper is just an NPC that walks around the rooms to map them.  So, of course it won't have a valid this_player(), but it does have a valid this_object(), and can certainly use enviornment() to see things about where it is.  So, to me, it seems like the solution is to not make your various exit checking routines rely on using this_player(), and if you want them to treat players and npc's differently, put the PC only code behind a check to see if this_player() is valid.

And you shouldn't be making 10,000 copies of almost identical functions.

Put your exit check functions into a small handful of objects (likely one for each domain), and have them inherited by the rooms, so the code isn't duplicated.  I seriously doubt you have 10K room exit functions that ALL do different things, they likely just do the same thing with different rooms and exits in their checks.

[beren]

No that won't work. We don't give players the whole map.
The map for each player is updated in their GUI when they actually enter the room.
So they start with a blank and they slowly build it up.
It is even a "quest" and a very sought after ranking for which player has actually mapped or explored most of the world and has found most of the hidden places.

As for the custom exits you misunderstand. Most rooms use a standard mechanism that they inherit from a base room object.
That is only overriden when a coder wants to do something special with that exit.
I would guess only something like 5-7% of rooms have such overrides but we would still need to actually lookup every single room file (that is where the 10.000+ number comes in)
if we attempted to standardize how the override is done to accomodate how we update the mapper.
That was one of the solutions I considered but has the downside of actually having to search through 10.000 files and update a few hundred.

[quixadhal]

Well, if you're not using the built-in map code, but some custom stuff, that's even easier.

You put a general function in the reset() routine for every room that updates the player's map data.  reset() is called when something causes the room to be loaded, and if this_player() isn't set, that bit of code doesn't need to do anything.

Use the pre-exit hooks for your various security checking things, which shouldn't need to load the room itself, unless your check involves the contents of the room.  In any case, you can always ensure that you're only updating map data for environment(this_player()), even if they do trigger something.

As for finding all those things... assuming you used some kind of semi-standard thing like SetExit() or SetExits(), grep should find occasions where there's happy code nearby.  I forget the flags, but I know GNU grep has flags to check context so it can find things within N lines of the actual thing you look for.

[beren]

We are using a custom mudlib (none of the standard DS/LPUNi etc mudlibs since we are pretty old from 1991 and at that time I think only TMI existed) so have no idea what is the build-in map code you are referring tο
(even though I am curious so would not mind if you point me to the right direction)
And as I said from the very beginning it is a mapper for a GUI (MUDlet) not ingame.

As for the reset idea. Reset is not called every time a player enters a room and I want the mapper to update in real time as a player walks through the game.
At the moment I call the code through init() but that obviously carries the this_player() definition which is causing me the problems.

[Nilrin]

Could you call the code through something else other than init(), perhaps move_object()? Doesn't move_object() only return a 0 or 1 depending on success or failure?