Vehicles experiencing difficulty with room-scoped command props

[blightbow]

Original issue 23 created by ZetaMUCK on 2014-07-14T20:59:05.000Z:

Reported by Noda. There is an extremely obscure bug with how objects with the VEHICLE flag interact with command props.

I've managed to isolate this to behavior in the getparent() function of db.c, specifically the following lines of code:

    if (Typeof(obj) == TYPE_THING && (FLAGS(obj) & VEHICLE) && limit-- > 0) {
        obj = DBFETCH(obj)->sp.thing.home;
        if (obj == NIL)
            obj = GLOBAL_ENVIRONMENT;
        if (obj != NOTHING && Typeof(obj) == TYPE_PLAYER)
            obj = DBFETCH(obj)->sp.player.home;
    } else {
        obj = getloc(obj);
    }

This is largely a consequence of envprop_cmds() being a copy and paste job of envprop(), both defined in property.c. The end result is that vehicles most commonly look for their command props off of the object's home, or the home of the player that object is homed to. This means that can use global command props reliably (as all environments eventually hit # 0), but almost never be able to use command props defined within the same room.

[blightbow]

Comment #1 originally posted by ZetaMUCK on 2014-10-21T21:13:59.000Z:

getparent is used by: @sweep (identifying listeners up the environment) {select:} MPI (whatever) has_property() (used with lock_envcheck @tune) regenvprop() (searching up the environment) envprop() (same, searching for command props up the environment...this is the bug) envpropqueue()...which is best just pasted.

void envpropqueue(int descr, dbref player, dbref where, dbref trigger, dbref what, dbref xclude, const char propname, const char toparg, int mlev, int mt) { while (what != NOTHING) { propqueue(descr, player, where, trigger, what, xclude, propname, toparg, mlev, mt); what = getparent(what); } }

Given that this is a completely undocumented behavior in help.txt, and neither Akari, Noda, or myself can come up with a good reason for keeping it this way, I'm just going to gut the entire exception. This can be re-added if good justification is found later.

[blightbow]

Comment #2 originally posted by ZetaMUCK on 2014-10-21T21:21:38.000Z:

This issue was closed by revision r121.

[blightbow]

Comment #3 originally posted by ZetaMUCK on 2014-11-08T03:17:24.000Z:

Rika was able to dredge this conversation up:

https://groups.yahoo.com/neo/groups/protomuck/conversations/topics/515

In short, the behavior was implemented by Revar to prevent exit availability from shifting on players inside the vehicle as the object moved around the grid. I can see where this would make sense if the behavior was limited to objects inside of a vehicle, but influencing the parenting of the vehicle object itself is a no-no. (as the command prop bug highlights)

This /does/ point out an issue with my fix though: typing the name of an exit that is in the same room as the vehicle will result in the user being loaded into a torpedo tube and fired in that direction, leaving the vehicle behind. As entertaining (read: annoying) as that would be, it's sub-optimal.

I think I'll bring the old behavior back, but change it to only apply to objects inside of a vehicle. This achieves the desired outcome without influencing the environment of the vehicle itself.

[blightbow]

Comment #4 originally posted by ZetaMUCK on 2014-11-15T11:36:29.000Z:

My last comment was dead wrong due to a bit of confusion: the URL was talking about a completely /different/ bypass inside of match_all_exits(), as opposed to the getparent() bypass I was discussing above.

On further review, there were numerous inconsistencies between the approach used in these two functions, even though they were trying to implement the same thing.

• getparent() conditionally applies its maximum recursion counter. match_all_exits() does not.
• If a vehicle is @linked to a player, getparent() will use the player's home instead. match_all_exits() makes no attempt to avoid this case. This means that the commands of occupants will not only follow the environment of the @linked player around the grid, but are also capable of matching exits located directly on the player. (normally impossible) Fortunately this bug is rarely experienced, as players can't enter a vehicle that is @linked to them (paradox), and owners usually want to ride in their own vehicles.
• getparent() implements its "is this a vehicle" check inside of a loop. match_all_exits() implements it outside of its loop. This creates diverging results in nested vehicle scenarios: environment will go in one direction, exits will go in another. An absurdly unlikely scenario, to be fair.

[blightbow]

Comment #5 originally posted by ZetaMUCK on 2014-11-15T11:36:43.000Z:

This issue was closed by revision r126.

[blightbow]

Comment #6 originally posted by ZetaMUCK on 2014-11-15T21:12:32.000Z:

Additional discrepencies:

• match_all_exits() traces objects @linked to NIL up to tp_player_home as documented. getparent() traces objects @linked to NIL up to GLOBAL_ENVIRONMENT. After my fix the latter behavior is being used and this is wrong.
• getparent() looks to see if the environment is being traced from inside of a THING set VEHICLE. match_all_exits() only checks for whether or not the object is a THING. For the sake of being able to document this in a sane user facing fashion, I'm using the getparent() behavior for both. (action and environment both follow the normal path unless started from inside of a THING set VEHICLE)