Blocking Macros

ID:272251
 
May 16 2008, 6:09 am
Is there a way to stop a player from creating a custom macro, because currently players on my game are using the custom macro to sell items and I keep getting runtime errors because of it.

            Sell(var/obj/Equipment/O in usr)
                set src in oview(2)
                set category = null

                if(usr.sell == 0)
                    switch(alert("[src]: Are you sure you want to sell [O.name] for [O.value] PokeDollars?","Selling","Yes","No"))
    
                        if("Yes")
                            if(istype(O,/obj/Equipment))
                                if(O.equiped == 0)
                                    usr.PokeDollars += O.value
                                    del(O)
                                    usr.sell = 1
                                    sleep(7)
                                    usr.sell = 0
                                else
                                    usr << "<B>You need to unequip [O.name] first!"
                                    return
                            else
                                return
    
                        if("No")
                            return

                if(usr.sell == 1)
                    usr << "<font color = white><font face = 'Comic Sans MS'> Selling items will not work at this speed, it will crash the server, so this has been programmed in to stop that from happening."
                    return


Thats the code I am using for my sell verb, anyway to fix the runtime error or block the macros, all help appreciated.
May 16 2008, 6:15 am
Element Hero creator wrote:
Is there a way to stop a player from creating a custom macro,

No.

because currently players on my game are using the custom macro to sell items and I keep getting runtime errors because of it.

Then indeed, you should fix your code instead of trying to work around the problem. Basically, you need to validate the variables (arguments) on the beginning of the verb, to see if they're still valid. For more info, use the forum search. Or I'll dig up some older posts later if you do need it.
May 16 2008, 6:17 am
In response to Kaioken
K thanks. EDIT: I tried working around the code but I still get runtime errors, and when I get too many runtime errors the server crashes.
May 16 2008, 7:30 am
In response to Kaioken
Kaioken wrote:
Element Hero creator wrote:
Is there a way to stop a player from creating a custom macro,

No.

Oh, but there is. client.control_freak prevents this very behavior if it is set to 1.
May 16 2008, 7:41 am
In response to Devourer Of Souls
I see. I forgot it now includes macros as well. Regardless, it's possibly circumventable in some cases (and non-built-in macros could still be used, of course), and it's a bad idea anyway to entirely block macros for this reason. In fact, it is usually kind of a bad idea to use control_freak at all, until it's updated so you can manage individual control on each thing it limits.
May 16 2008, 9:18 am
In response to Element Hero creator
Whenever a proc sleeps, another proc has an opportunity to screw with that proc, by affecting any objects the first proc is working on. In this case, alert() is causing the proc to sleep, and then another instance of the same proc is deleting the object being sold. When the alert() finishes, the object no longer exists, so you need to verify its existence again before operating on it.
May 16 2008, 12:19 pm
In response to Garthor
Garthor wrote:
When the alert() finishes, the object no longer exists, so you need to verify its existence again before operating on it.

It's a good point, but his (admittedly misplaced) istype() check actually accounts for that here.
Again, especially considering his mention of macros here, I think the problem must be of delay before the verb is started (lag, queued commands) after which the object doesn't exist anymore. So checking if the object is valid in the beginning of the verb should fix this.
Something I forgot to mention in my previous post: for more information about this, check out Lummox' article about robust programming:
http://www.byond.com/members/ DreamMakers?command=view_post&post=37940
Look under the "bail-out" header.