Joined: Jun 18, 2006 Posts: 1685 Location: Halesowen, England
Posted: Wed Apr 11, 2007 4:43 am Post subject: Trigger Question (yes, another one)
OK, here is my trigger problem this time...
I would like to have an object turn into a mob when the player enters a room.
For example,
A pile of bones turns into an animated skeleton
A pile of rags turns into a zombie
A puddle turns into a water beast
How can this be done?
As a room entry trigger, how can I detect whether the object is in the room
As an object trigger, I can't have an 'entry' or 'greet' trigger type, so can't tell when someone enters the room that the object is in. _________________
I'm sure you could just use a room trigger, with the object being in the room. When an actor enters the room, the trigger echoes the object transforming into the mob, purges the object and loads the mob, or am I missing the point? I probably am, I have a simplistic way of viewing things
Joined: Mar 29, 2007 Posts: 89 Location: Virginia, USA
Posted: Wed Apr 11, 2007 1:27 pm Post subject:
amber wrote:
I'm sure you could just use a room trigger, with the object being in the room. When an actor enters the room, the trigger echoes the object transforming into the mob, purges the object and loads the mob, or am I missing the point? I probably am, I have a simplistic way of viewing things
That would work Amber, except he probably only wants the mob to load in the room once per each zone reset. Thus, if a person has already fought the mob and the object is gone, he doesn't want the mob to load again until the object is back. Additionally, if he made a room trig that would load the mob without checking for the object to be there, he would have to put some kind of global variable so that when a person enters the room again and again multiple mobs won't slow up at the same time. I have seen this basic idea done 2 main ways. What I usually see is that the object has a take trigger on it that loads the mob when the player tries to take it, or my way, which is quite a bit more rare because findobj is not a command used often by many people.
Joined: Jun 18, 2006 Posts: 1685 Location: Halesowen, England
Posted: Wed Apr 11, 2007 1:53 pm Post subject:
amber wrote:
When an actor enters the room, the trigger echoes the object transforming into the mob, purges the object and loads the mob
Problem with that method is that if the object isn't in the room, a player walks into an empty room and still gets a message saying 'A skeleton rises from the pile of bones.' and fights a skeleton.
This would lead picky players (like me) to say "what bones, I didn't see any bones" - I'd prefer to check that the bones are there before I purge them. _________________
Joined: Jun 18, 2006 Posts: 1685 Location: Halesowen, England
Posted: Wed Apr 11, 2007 5:40 pm Post subject:
Yep, this works...
Code:
Name: 'Bones to Skeleton on Room Entry', VNum: [ 6908], RNum: [ 586]
Trigger Intended Assignment: Rooms
Trigger Type: Enter , Numeric Arg: 100, Arg list: None
Commands:
* Trigger to convert a pile of bones (obj) to an animated skeleton (mob)
* Works on room entry
* Check the the bones (obj vnum 6901) are in this room (room vnum 6938)
if %findobj.6938(6901)% == 1
* Yes, the bones are loaded, purge them and create the mob
wait 3 s
%purge% bones
%send% %actor.name% The mouldy bones in the corner of the room suddenly rise up and attack you!
%echoaround% %actor.name% The mouldy bones in the corner of the room suddenly rise up and attack %actor.name%!
%load% mob 6900
end
Joined: Mar 29, 2007 Posts: 89 Location: Virginia, USA
Posted: Wed Apr 11, 2007 6:13 pm Post subject:
Looks good there Jamdog, but you forgot to add a force to make the mob attack the actor, at least in the one you posted. Oh and don't forget to put detect invis/hidden and infra on the mob so it can see the person (I've made that mistake way too many times).
Joined: Jan 09, 2004 Posts: 781 Location: Monterey, CA USA
Posted: Wed Apr 11, 2007 10:00 pm Post subject:
Quote:
Thanks for the tip about detect invis/sense life/infravision.
This happens a lot. To make your lives easier always do the following whenever someone has a problem with a trigger not working:
1. Make sure nohas is off.
2. Make sure < level 32 for command trigs (test with a mort).
3. If a mob trig, make sure the mob can see the player (switch into the mob).
4. Verify all variables by %echo%'ing them.
The above steps will take care of 95% of trigger problems _________________ Rumble
The Builder Academy
tbamud.com 9091
Joined: Mar 31, 2004 Posts: 316 Location: New Zealand
Posted: Thu Apr 12, 2007 12:40 am Post subject:
A good technique to learn is how to remove ambiguity from your code or scripts.
What is ambiguity?
Ambiguity happens when one thing (a name, or vnum, or alias, etc) it not unique, but it gets used as if it is unique.
Give me an example!
Okay, you have a room in your mud.
In the room is 5 objects.
A brass monkey
A brass sword
A steel sword
A monkey broach
A steel table
You go to pick up the steel sword, but the game may say.
A steel table: you can't take that!
The same is true for scripts.
On 4dimensions, we have for example a player called Lynx.
We also have a desert area, where wild lynx's run around in.
The game is based on the idea of time travel, so we do a lot of teleporting between time zones in scripts on 4D.
Many new scripters don't understand what the %actor% variable IS as such, and why it is different from %actor.name%.
So, in some of the older teleport scripts we have lines that look like this:
Code:
%teleport% %actor.name% 12334
Which work, but as i will point out are ambiguous.
Firstly, the problem that puzzled some of our builders was why some players, sometimes, wouldn't get teleported.
In Lynx's case, if she logged in to the game recently, then the teleport would work for her. Because she was pretty much first on the list of characters in the game that the script code would look at to find a match for the keyword provided 'lynx'.
Agter a while, if someone had gone through and killed a few desert lynx's, and they had reloaded in to the game.
These new freshly loaded lynx's would pretty much be 'top of the list', and when the player Lynx went to use a teleporter of some kind set up like the example above. She wouldn't go anywhere, since the game was trying to teleport a desert lynx, and in this case would fail, because the location of the desert lynx's was !TELEPORT.
How does this relate to this topic?!
well, take a look at the script Jamdog is using. What is ambiguous there?
Code:
Name: 'Bones to Skeleton on Room Entry', VNum: [ 6908], RNum: [ 586]
Trigger Intended Assignment: Rooms
Trigger Type: Enter , Numeric Arg: 100, Arg list: None
Commands:
* Trigger to convert a pile of bones (obj) to an animated skeleton (mob)
* Works on room entry
* Check the the bones (obj vnum 6901) are in this room (room vnum 6938)
if %findobj.6938(6901)% == 1
* Yes, the bones are loaded, purge them and create the mob
wait 3 s
%purge% bones
%send% %actor.name% The mouldy bones in the corner of the room suddenly rise up and attack you!
%echoaround% %actor.name% The mouldy bones in the corner of the room suddenly rise up and attack %actor.name%!
%load% mob 6900
end
I can see 3 immediate ambiguities here. The script will work, but there is a chance that it might be exploited, or not quite work as intended 100% of the time.
The first one is where this command is used.
Code:
%purge% bones
Bones is a generic key word, any item that the %purge% function finds first with that key word will be purged. Whether or not the designer of the script/zone wanted that to happen.
Some builders get around this issue by putting very unique keywords on their objects, for example: bones_1324522363 may have been added to the list of keywords.
And then that keyword would be used instead of just 'bones'.
This is fine, but still leaves the chance of multiple objects of the same vnum MIGHT possibly be in the game somehow, through no fault of the builder. (it happens, players are crafty, i know i was
What you REALLY want, is the object or the mobs' UNIQUE IDENTIFIER (UID).
That sounds a bit scary doesn't it?
Don't be afraid, the UID is first and formost, your friend. It wants to know you and would probably buy you a drink if it saw you at a bar.
The UID is unique, which is the opposite of ambiguous, and opposite of ambiguous is what we want!
Every player, mob, room, and object has a UID that is different from everything else.
When you can obtain a UID in a script, you can pinpoint that exact room/mob/player/object anywhere in the game, no matter what.
You are probably now thinking, how do i get a UID?
Well, first off, let me tell you, you have been working with UID's already.
Code:
%actor%
Is a UID.
NOTE:You may have used the STAT command on your admin character in the game, and seen the value: ID: 12345
That is your UID, it is perminant, and won't change ever, and saves when you log out.
In the script above, ideally you want to actually grab the UID of the bones with the vnum specified, in the room.
This works to do that:
Code:
set bones 0
set i %self.contents%
while %i%
if %i.vnum% == 6901
set bones %i%
* remove this break and add a counter if you want to purge/load multiple piles of bones/create multiple zombies
break
end
set i %i.next_in_list%
done
if %bones%
*here we SPECIFICLY purge the set of bones we found above
%purge% %bones%
%send% %actor% The mouldy bones in the corner of the room suddenly rise up and attack you!
%echoaround% %actor% The mouldy bones in the corner of the room suddenly rise up and attack %actor.name%!
%load% mob 6900
end
I believe that in the current dg_scripts code, we now have this function, making this task even better!
Code:
* this returns the UID of the first item found of this vnum in the room.
set bones %self.contents(6901)%
if %bones%
*here we SPECIFICLY purge the set of bones we found above
%purge% %bones%
%send% %actor% The mouldy bones in the corner of the room suddenly rise up and attack you!
%echoaround% %actor% The mouldy bones in the corner of the room suddenly rise up and attack %actor.name%!
%load% mob 6900
end
So, you may have noticed I also changed the %send% and %echoaround% targets, from %actor.name% to %actor%.
As i was saying about Lynx and the teleport targets earlier,
%send% and %echoaround% also can have the ambiguity removed by using the UID %actor% instead.
For the coders out there:
In the code on 4Dimensions I have updated the 'find target by name' functions used in the non dg_script parts of the game, such as the TELL command, to handle UID's as well as names.
So that when scripts use in game normal functions like TELL, and socials, and KILL, etc, scripts can use %actor% instead of %actor.name%
Joined: Jun 18, 2006 Posts: 1685 Location: Halesowen, England
Posted: Thu Apr 12, 2007 4:28 am Post subject:
Wow, thanks Mordecai - very helpful.
I wasn't happy about using "%purge% bones", but being a newbie scripter, it was the only way I knew. If I'd have coded this, I would have had a pointer the the actual object to work with, thus negating ambiguity.
Using %actor.name% for send and echoaround is purely because I've seen this done on TBA's Dg-Script examples, although these are somewhat inconsistent, and don't explain this difference:
Mobile Commands, echoaround example: Uses %actor.name%
Mobile Commands, send example: Uses %actor%
Room Commands, echoaround example: Uses %actor.name%
Room Commands, send example: Uses %actor.name%
This, and help/examples in tbaMUD are the only reference sources I have. Is there any other source? _________________
Joined: Mar 31, 2004 Posts: 316 Location: New Zealand
Posted: Thu Apr 12, 2007 4:52 am Post subject:
Think of those examples as work in progress. Rumble is a fantastic scripter in several ways.
1. Because he knows how to write a good script
2. Because he knows how the script he makes will affect and work in a mud as a whole. (Business logic)
However, examples get old, and outdated, easily.
I was going through some examples of scripts i had made in 2002 that (i thought) were amazing at the time, but these days, with the new code available, and new general knowledge of how a whole mud is run, can be improved in many ways.
The good thing about this forum, and this community is that we are all constantly improving.
The sad thing about this community, is that there is no way any of us can make money from what we love to do here.
Because there isn't any way that we can subsidise this hobby we can't have even one person to do this full time, and edit and update old entries (at the level we need it done at, if it was a professional product).
Still, there is still plenty of hope, we have some amazingly good and inteligent contributors here and most of the base work has been done.
It is just the examples that can always be updated.
Still, i like your enthusiasm, and I think as long as there is people like you needing help, there will people like us, providing it.
Joined: Jan 09, 2004 Posts: 781 Location: Monterey, CA USA
Posted: Thu Apr 12, 2007 11:15 am Post subject:
Quote:
Jamdog wrote:
I've seen this done on TBA's Dg-Script examples
Thanks, the webpage hasn't been updated in years and I know of no plans to update it. The latest information is in the help files. If you find anything wrong in there I will fix them. Some of these examples were written a while ago and need to be updated (which is a side benefit of all these posts
I know some people prefer a webpage to learn from but I prefer people on a MUD learning. We decided to focus our efforts on TBA and not a webpage a long time ago.
Just let me know of any mistakes in tbaMUD or the helpfiles and I'll correct them. _________________ Rumble
The Builder Academy
tbamud.com 9091
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
