But umm... no, there's not, nor do I believe there will ever be.
There's the ZMud equlivent of triggers... I think they're called something like 'automatic macros', er something?
I never used em. Never found a realistic IC use for them.
There may be one though...
Anyone ever used automatic macros to their advantage?
-Kevlar
P.S. Just to hazard a guess at what's to come: To draw your weapon when you enter combat, even though it's A) twinkish and B) handled with @default-weapon.
Client side macros aren't allowed under the SD rules, or frowned on, or somesuch... not that this is news to anyone, but that's kinda why the server side macros were coded. Enforcing the no macro rule would be nigh on impossible given that no-one really wants to spend hours monitoring players in realtime to be sure no macro naughtiness is in play. The idea was basically to give a level playing field under which macros could be used. It's also a nice way of handling the biggest problem with macros, the runaway loop of doom. Where-ever macros are in use you can guarentee some assclown will manage to write some wonderful time saving macro... only to find it's capable of triggering itself... and spamming the MOO to death. Server side macros have built in protection to prevent this happening. Go Johnny!
Meh... I'm sure I had a point to make...
Oh well.
Oh, heh... many years ago it was possible, with cunning macro use, to get through closed doors without anyone being able to follow you. By sending a stack of commands to unlock, open, move through, close and lock a door you could swing the door open and immediately shut again then after the usual movement pause (3-5 seconds after you closed the door) you'd walk through it, giving other people absolutely zero chance of following.
Ahh, the fun days of playing with the movement code, paralyzing players in the Drome... I should write my memoirs or something.
Hrm. Oh, yea, I didn't say this Bias, coz it'd be -real- naughty like, but if you set up a macro to unlock/open/move through your door, then write a seperate trigger/automatic macro to close the door when you receive some text that consistently relates to your arrival at the other side of it, that should do a decent job of simulating the time delay you need. Something from the movement message or even the desc of the room you're arriving in should do nicely.
Heh... which reminds me, wasn't it Timmy who wrote a client side macro that spammed doors with every possible combination from 0000 to 9999 in a matter of seconds, then went round popping all kinds of doors open around the MOO?
I really should write those memoirs.
so unless i�m told that the bug was an ill timed coincidence and had nothing to do with my poking the @macros command, as bias might say, i�m not touching nothins�!
*eyes TAFKAR�s suggestion warily* hrm.... why do i think if i tried something like that i'd be hurt by someone?
(Edited by Bias at 12:03 pm on May 8, 2003)
Quote: from Bias on 12:01 pm on May 8, 2003[br]*eyes TAFKAR�s suggestion warily* hrm…. why do i think if i tried something like that i'd be hurt by someone?
Because the admin are a bunch of ass-raping nazi bastards who've long since lost track of where the fine line between RP and fun belongs?
OMG… is Rastus being contraversial again?
When I was working I'd be going from my work machine (telnet no client). To my home machine (Vmoo). and setting my @edit-options +- local all the damn time was a paing. cause I'd forget then try looking at something from telnet and bam! wouldn't get the info cause it tried opening list +locally.
So I made a micro for
~quit which would
@edit-options -local
@quit
That's about it.
I really don't see anything that you could possibly use macros for. Waste of time if you ask me..
Finn tosses his 2 chyen into the mix.
Quote: from Tool on 6:53 am on May 13, 2003[br]What exactly is the local thingamabobber you were taling bout? Is that just a Vmoo thing?
i got confused.
editting stuff locally isn't exclusively a vmoo thing, but not many M* clients support it. Basically it just means you can send text (code, descs, properties, etc) to your client which will open an editor window exclusively for that data, allow you to tinker with it at will, then when you've got it all nice and peachy, send it back to the MOO. Compared to using inMOO editors, it's an absolute godsend.
Combine the various cool things vmoo does with code windows, auto-indenting code, colour coding variables, built-in functions, comments, etc and parsing the code for errors before allowing it to be saved to the MOO and, IMHO, you're looking at -the- MOO client for coders. Doesn't have much to offer the average player tho, so unless you have a prog bit somewhere, stick to what you like.
Player notes, histories, paste-to's, bugs, logs, searches… Anything that results in any sort of output which we want to read seperately from the scroll get's poped up in it's own window where we can minimize it, edit it locally, and send it back with the click of a button.
On top of the things TAFKAR mentioned, it also supports limited auto code-completion, just like an IDE would, so we don't have to type this:really_long_function_name_goes_here 20 times in our code. We just type 'this:rea' and hit Ctrl-Space, and it does the rest for us.
Eventually (in the distant future) I'm going to write a plug-in for Eclipse which will talk to the JavaDome framework, so Eclipse can be used as a full featured MOO IDE with live MOO code checking (for much improved auto-complete) and live debugging support. We will be able to browse/modify the object heirchary, add/modify/remove verbs and props, and do all kinds of fun things graphically in Eclipse without even opening VMOO and logging our char in. (OH! THE POWER!)
We've also talked about enabling multiple window/puppet support, but it turned out to be infeasable without a big monitor at 1600x1200 or bigger.
One of these days...
-Kevlar