Room Verb Functionality Lost

ID:78202
 
Aug 1 2009, 11:25 am (Edited on Aug 1 2009, 11:30 am)
Resolved
Fixed in 448
BYOND Version:446
Operating System:Windows Vista Home Premium
Web Browser:Firefox 3.0.12
Status: Resolved (448)
This issue has been resolved.
Descriptive Problem Summary:

(In BYOND terminology, rooms are areas that have no turfs assigned to them.)

If you look at the room example, it seems that verbs will function for anything in that room by default.

Yet, in my recent attempt, it seems that room verb functionality was lost. Nothing happened when I tried to use the verb, it produced no text output and didn't move the player.

Numbered Steps to Reproduce Problem:

The following code seemed to reproduce the problem for a player located in that area.

Code Snippet (if applicable) to Reproduce Problem:
area/selectfaction
    verb/btnJoinNativeFaction()
    
        // set src in world.contents // Removing this line breaks it.
        
        var/mob/player/thisPlayer = usr
        
        if (thisPlayer in contents)     
            thisPlayer.faction = "native"
            thisPlayer.Move(locate(/area/nativefaction))
        else
            usr << "You will need to quit your existing faction before you can join a new one."



/area/nativefaction
    Entered(var/mob/player/thisEntered)
        if (!(istype(thisEntered,/mob/player)))
            DebugMsg("[type].Entered(): [thisEntered.name][thisEntered.type] entered area/selectfaction.  Deleting offender.")
            del thisEntered
            return()
        else
            thisEntered << "You have joined the Native faction."
            winset (thisEntered,"childView","left=paneViewNativeFaction")
            winset (thisEntered,"lblViewNativeStory","text=\"[GenerateNativeStory(thisEntered)]\"")


mob/player

    density = 0

    var/faction // Simple text string to describe faction.  Should be native, terran, or pirate

    New()

        Move(locate(/area/selectfaction))




Expected Results:

The player is moved to /area/nativefaction, which produces obvious results.

Actual Results:

Nothing happens. There's not even a 'invalid verb' message. It's an identical result for the verb simply not being accessible.

Does the problem occur:

Every time

When does the problem NOT occur?

Outside of using a workaround, never.

Workarounds:

There are various workarounds involving verb arithmetic or, as in this case, simply making the verb accessible to world and doing the access checks manually. Still, in terms of usability, it would be nice if verbs would work for rooms.
Aug 1 2009, 11:50 am
Try changing if(thisPlayer in contents) to if(thisPlayer.loc in contents), as I don't think players are actually propagated to area.contents just because their location is in it.
Aug 1 2009, 11:58 am
Actually, that part works fine. The verb doesn't activate, at all, so it never gets there.
Aug 3 2009, 2:26 am (Edited on Aug 3 2009, 2:38 am)
Change
return()

to
return ..()


and

if (!(istype(thisEntered,/mob/player)))

to
if (!istype(thisEntered,/mob/player))


Try using some correct syntax in your code before reporting bugs?

Aug 3 2009, 4:16 am
DarkCampainger wrote:
Try changing if(thisPlayer in contents) to if(thisPlayer.loc in contents), as I don't think players are actually propagated to area.contents just because their location is in it.

The area.contents var contains not only the turfs in an area, but also any of the objs or mobs directly within those turfs. This behavior serves two purpses, in that 1) it makes it easy to loop through them, and 2) it probably exists to enable the turfless behavior that is currently broken.
Aug 3 2009, 4:46 am
Nielz wrote:
if (!(istype(thisEntered,/mob/player)))
to
if (!istype(thisEntered,/mob/player))

Try using some correct syntax in your code before reporting bugs?

That would make no difference at all.
Aug 3 2009, 5:53 am
Nielz wrote:
Change
return()

to
return ..()

These don't do the same thing.

return() just returns nothing (funny enough, it seemed to return a 0 the other day because a return() triggered a switch; if (0) - or maybe it was a lack of a return - but that's another story). Using return in this way is useful for simply terminating the flow of a procedure then and there.

return ..() executes the parent proc in order to return the value appropriate of that parent proc. As I've no interest in doing that, because I want it to return nothing instead, it's a bit of unnecessary CPU time spent.

The later could be considered good from an object oriented practice perspective, but it's unnecessary and irrelevant to this particular bug.
Aug 3 2009, 6:28 am
Geldonyetich wrote:
Nielz wrote:
Change
return()

to
return ..()

These don't do the same thing.

return() just returns nothing (funny enough, it seemed to return a 0 the other day because a return() triggered a switch; if (0) - or maybe it was a lack of a return - but that's another story). Using return in this way is useful for simply terminating the flow of a procedure then and there.

return ..() executes the parent proc in order to return the value appropriate of that parent proc. As I've no interest in doing that, because I want it to return nothing instead, it's a bit of unnecessary CPU time spent.

The later could be considered good from an object oriented practice perspective, but it's unnecessary and irrelevant to this particular bug.


Well... in that case, it isn't needed to put anything after return at all.
Aug 3 2009, 6:35 am
Nielz wrote:

Well... in that case, it isn't needed to put anything after return at all.

That's true - I'm just doing so because I'm used to using return that way in other programming languages/compilers.

In some I've used, return is interpreted as a proc, so not putting in the parenthesis will generate a compiler error.

An extra set of () is probably completely stripped out by the BYOND's compiler. Using it that way forces an order of precedence which is ignored because no operation is occuring.
Aug 3 2009, 6:46 am
Nielz, this kind of nitpicking is not what the bug tracker comments are intended for. That kind of thing can be done on the forums, although it would be well to first be correct oneself before doing so.

Your criticism of the return statement is unfounded since this is an Entered() call, and in a clean environment Entered() has no default behavior for ..() to have any use. The parentheses around the istype() call are merely redundant, not wrong. In neither case was there a violation of syntax, and the code would function identically regardless of your changes. If a real syntax or logic issue had been present and had some bearing on the bug report (e.g., some other syntax made it function differently or fixed the problem) that would be a good reason to leave a comment.
Aug 3 2009, 7:12 am
Confirmed in BYOND 446.1027 on Windows XP SP3 using the snippet below:

area/testArea/verb/Test_Direct()
. set src in oview(0)
. world<<"If you can read this, everything is A-OK."
. usr<<"If you can read this, everything is A-OK."

mob/Login()
. var/area/testArea/T = new()
. T.contents+=src
. world<<"Mob.loc: [loc]"
. world<<"Area.contents: [T.contents[1]]"
. world<<"Area.verbs: [T.verbs[1]]"
mob/verb/Test_Indirect()
. var/area/testArea/T = loc
. T.Test_Direct()

A user will be unable to execute certain verbs, despite them appearing in their verb panel, when they are received from a /area functioning as a "room" and the verb is using set src in [view/oview/range/orange].


(Also, sorry for my earlier response. It was late, and I must have glazed over the whole "room" concept.)
Aug 4 2009, 12:18 pm
This is actually two bug fixes:

Fix 1: Area verbs had stopped working in projects that did not use turfs.

Fix 2: view(), range(), etc. did not include the viewer's loc if the loc was an area instead of a turf. This has been changed to be consistent with the reference.
Aug 4 2009, 12:19 pm (Edited on Aug 4 2009, 12:25 pm)
Cool beans, I look forward to it. The usability tied to using rooms for verb access control is very handy, in my opinion.