At 10:33 AM 12/22/98 +1100, you wrote:
>Well I'm not sure about LPC, but I know quite a bit about MUSH/MUSE/MUX
>'softcoding'. There are some differences between DG Scripts and MUSE
>programming. I'll give you some examples:
>
>@va object $unhide:@switch has_flag(#2356, HIDDEN)=0,{@wait 1; pemote %# The
>purple septre us already unhidden!},1,{@wait 1; pemote %# You unhide the
>purple sceptre, which is located in room(#2356).; set_flag(#2356, HIDDEN)}
>
>You can simply type this at the prompt, exchanging 'object' for an object
>you want the command to attach itself. So now when anyone types the command
>'unhide', whilst this particluar object is in their inventory or in the
>same room as them, it runs the script. If object #2356 is visible, it
>sends you a message saying so, and if it isn't visible it unhides it.
>
>I'm not sure you can do this with DG_Scripts or not. But this is a fairly
>simple piece of code. You can also set variables or attributes on objects,
>so if you wish to save someone's vnum you would simply add '@vb object=%#'.
>This can be handy for hard-coded commands, such as eat and drink. You could
>add an @aeat variable on each mobile, so that when the mobile eats the
>information in @aeat is triggered. There would also be an @oeat, which is
>the information sent to the players in the room when that mobile eats.
>Eg.
>
>@aeat mobile=@wait 1; burp; say Excuse me!;
>@oeat mobile=Freddy the frog gobbles something down his throat.
>
>This would then save permenantly. Of course, this would be extremely hard
>to implement into circle because of the binary files you would need to
>store the information in (or plaintext files, which might work better),
>because your object files would soon become huge if you stored this type
>of information in them.
>
>In conclusion, I believe that there are some differences in style which
>make MUX/MUSE/MUSH code more powerful, although DG Scripts is not a
>long way off. Please feel free to disagree ;)
Though the interfaces are different, I believe what you've described can,
for the
most part, at least, be done with DG Scripts. First, a definition of what a
script
is: it is a collection of triggers assigned to a mobile, object, or room.
One type
of trigger is the command trigger, which is used ahead of the standard command
interface. A builder on my mud made, while learning, a drink trigger for a
can of
beer that had the drinker burp later.
DG Scripts and their triggers can have variables as well. A trigger may
have local
variables, and a script may have globals (global in the sense that all
triggers of the
script can access them). A shortcoming in pl6 (on my todo list for pl7) is
that in
order to have a variable, you must have a script. Pl6 brought in the
ability to see
and change variables of a target other than yourself, and I didn't think at
that time to
give variables to all targets. Another shortcoming is that variables are
not saved
when the game is reset. For mobiles and rooms, it will most likely remain this
way for a while, but objects should have this addressed by the time pl7 is
released.
The main difference I can see from your example is in the interface. To
assign (at
the command line) a trigger to 'object', you would type "attach otr 100
object", where
100 is the trigger vnum and object is your target to use the trigger.
Triggers must be
created in advance rather than on the command line. If triggers didn't have the
potential to have such large commands (I've seen a trigger whose command
list was
100+ lines) then I'd see more room in making them commandline definable. As it
is now, they can be created online in an OasisOLC-like menu.
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST