Feature request: "'set' commands must be at start of verb"

ID:135670
 
Apr 16 2004, 1:17 am
It's quite confusing to some newbies that they can't do something like this:

mob/verb/hello() if (usr.display_hello_verb) set category="Greetings" else set hidden=1

The setup of that verb infers that the category will only be "Greetings" if usr.display_hello_verb is true; and that if it isn't, then the verb will be hidden. Of course, that's not the case, but it seems logical that it should.

So to combat such misunderstandings, would it be possible to make the compiler generate a warning if there are executable statements before "set" commands in verbs (and procs, for that matter)?
Apr 16 2004, 5:11 am
Maybe instead they should make it so that set can't be used anywhere but at the start. Once you've actually gone into the proc you have to use the "reset" command instead.
Apr 16 2004, 6:52 am
Crispy wrote:
So to combat such misunderstandings, would it be possible to make the compiler generate a warning if there are executable statements before "set" commands in verbs (and procs, for that matter)?

It allready does. When I try to compile something and set is not the first line of the code block it says something to that effect.

(edit)
Yes, I just tried it and this is what it says:

warning: assignment of procedural properties takes place at compile-time. Move this to the top of the procedure to avoid this warning.
Apr 16 2004, 9:36 am
There is a way to produce the effect you expect there, while still keeping the compiler happy. I do it in Chatters to show or hide the verb panels, while still keeping the commands accessible irregardless.

Basicly, I use two procedures for each command. The default, hidden, command contains all the code that makes the command work. The visible procedure just calls the hidden one, with optional arguments passed on.

Here is my forum command, which brings the user to my game's forum. Simple, but effective. This is the original hidden command. A simple mob verb accessible to players through the command line only. 
mob
    verb
        forum()
            set name = "forum"
            set hidden = 1
            src << link("http://maz.byond.com/forum/forum.cgi?action=message_list&forum=5")
Now, we want a visible version of this for the stat panels, but we don't want to rewrite the entire command. 
Help_Panel
    verb
        vis_forum()
            set name = "Forum "
            set category = "Help"
            usr.forum()

Notice that this verb belongs to a datum called Help_Panel. This makes it simpler for me to give or take the entire Help stat panel away. I suppose I could have made these mob procs instead.

The biggest thing to note is that the names of the two commands, the hidden one and the visible one, must not be the same! If you name both verbs "Forum", then only one will show up. More than likely, the hidden one. But I want my commands names to be the same so players don't have to learn another set of command names. How do I resolve this? Simple: I name the hidden command "forum" while the visible one is named "Forum". This small differnece in capitalization will keep your commands distinct, but will appear to the player as being the same command.

Now we have our two commands, we need a way for the players to show or hide the visible command, while still retaining access to the, real, hidden one. I use two more commands to add and remove the visible procedures. 
mob
    verb
        show_commands()
            set name = "showcommands"
            set hidden = 1
            usr.verbs += typesof(/Help_Panel/verb/)
            commands = 1

        hide_commands()
            set name = "hidecommands"
            set hidden = 1
            usr.verbs -= typesof(/Help_Panel/verb/)
            commands = 0
These two commands deal with adding and removing all the verbs defined under the Help_Panel datum to and from the player's list of verbs. Don't worry about conflicts between the player's forum() verb and the vis_forum() verb added from the Help_Panel. Becuase the names differ (if only by one letter's capitalization), the program will only run one command, depending on what the player inputs. If they type "forum" at the command line, then the hidden verb will execute, if they click "Fourm" in the help panel, or type "Forum" in the command line, then the visible verb will execute, which in turn wil call the hidden forum() verb.

Of course, I have more stat panels than this one, and many more commands. But, for simplicity, I only show these. My showcommands() and hidecommands() verbs show and hide all the panels, not just Help. And I have other commands for hiding and showing individual panels, but they work similar to this, so it would be redundant to include them.

That's just how I accomplish this. I am sure there are many other ways. ;)

~X
Apr 16 2004, 2:40 pm
In response to Loduwijk
Hmm. The newbie I was talking to must have been ignoring the warnings, then. (Stupid newbie! Never, ever, ignore warnings! =\)

And yes, Xooxer, I know how to do that. I was just pointing out that some newbies don't. =)

In that case, maybe the warning should be upgraded to an error. =) Or alternatively, *all* warnings could be errors (in that it actually stops you from running it if there are warnings, like it does with errors now). Or alternatively, it needs to be made clear somehow that warnings are very important!
Apr 17 2004, 12:16 am
In response to Crispy
Crispy wrote:
And yes, Xooxer, I know how to do that.

This is one of those cases where checking to see who I am replying to might be of some benefit. I didn't realize you wrote that until after I posted my reply. Seemed a waste to delete, though. I kind of figured you'd know how to do that, but left it up for those newbies we here so much about.

~X
Apr 17 2004, 3:28 am
In response to Crispy
Not being able to compile while warnings are present would be annoying - I sometimes create a var at the beginning of my proc, then test it half way through, before I use the var.
Apr 17 2004, 8:55 am
In response to Crispy

In that case, maybe the warning should be upgraded to an error. =) Or alternatively, *all* warnings could be errors (in that it actually stops you from running it if there are warnings, like it does with errors now). Or alternatively, it needs to be made clear somehow that warnings are very important!

I disagree. But, maybe a option to turn on and of "all warning errors" wood be OK

Apr 17 2004, 3:34 pm
In response to Hazman
True, I often do that myself. It just annoys me that some people don't pay attention to them. Perhaps it could be a Build->Preferences option that's enabled by default, but can be turned off?
Apr 17 2004, 8:29 pm
In response to Crispy
In that case, maybe the warning should be upgraded to an error. =) Or alternatively, *all* warnings could be errors (in that it actually stops you from running it if there are warnings, like it does with errors now). Or alternatively, it needs to be made clear somehow that warnings are very important!

Yeah, it'd definitely have to be an option, though. I have a few warnings (primarily "if statement has no effect") in an unused portion of code which is loaded with TODO items; if I had to fill in that code it'd take forever (it's not a particularly high priority), and if I had to comment out that code (to remove the errors) it'd take substantial modifications to the rest of my code to temporarily comment out all calls to it.