Abandoned Codex Forum Index Abandoned Codex
The Abandoned Codex Forum
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problems with mobprogs
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Abandoned Codex Forum Index -> Building
View previous topic :: View next topic  
Author Message
Gareth
Admin 2


Joined: 26 Mar 2003
Posts: 522
Location: Singapore

PostPosted: Tue Apr 13, 2004 4:26 pm    Post subject: Problems with mobprogs Reply with quote

I'm interested in compiling a checklist of common mistakes people make with their mob/obj/roomprogs. This is a serious issue, since an alarming majority of builders test their programs once under sterile best-case correct-use conditions and declare hideously bad code to be 'working'. I've even had builders submit code that caused bugs that showed up on the Log channel (some of them then trying to excuse themselves because they'd done a "channel -log" to stop themselves 'getting spammed').

The main cause of bad mobprogs is because the smaug mudprog system encourages what's known in software engineering terminology as 'unsafe assumptions'.
Here are some common unsafe assumptions that I'd like y'all to ponder and see if you can think of any more.

- mpforce on a player will NOT always make that player succesfully do whatever they're forced to. (e.g. mpforce $n give 1 coins monster will fail in at least three different circumstances)
- $n or any other string-based name get will NOT necessarily get the player triggering the program. This one comes up a lot when a player has the same name as a mob.
- act 'p gives you a ...' will NOT guarantee that '...' is the one you want. You need to check the vnums too!
- just because mobs, objects, or exits exist in the room when you built it, does NOT mean they will exist always. This is more a point of policy than anything else; it's not reasonable to expect me (or the admin of any other mud you build on) to intimately know the contents of each and every mobprog on the mud when making changes. Make sure that if your mobprog relies on something else existing in the area, that it is capable of failing safely.
- don't assume that once a player has triggered your program, he won't decide to try triggering it another 50 times. Consider what consequences such an act would have.

There's plenty more, but those are the first ones off the top of my head. Any others?
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Waldo



Joined: 26 Mar 2003
Posts: 79

PostPosted: Thu Apr 15, 2004 1:18 am    Post subject: Reply with quote

I would like to add that if you want your mob to give an item or interact someother way with a player, keep in mind that many players walk around hidden/invisible. So if you would like the outcome to happen to hidden and invisible players too, make sure the mob can see them.
Back to top
View user's profile Send private message
Gareth
Admin 2


Joined: 26 Mar 2003
Posts: 522
Location: Singapore

PostPosted: Thu Apr 15, 2004 1:58 pm    Post subject: Reply with quote

Yeah, well remembered.
I've thought of another example of getting by name failing: objprogs to simulate antirace flags by mpforcing the player to remove an item. This will fail if the player qpbuy renames the item, or if the player manages to find (or qpbuy rename) another item for a different location with the same keyword.

Also: don't use mpoload on death progs unless you've got a good reason to. The levels of mobs can change, and you can't pop an item that's of a higher level than the mob doing it.

On a side-note rant, it's sad to see how few mobs actually wear any equipment - I for one would rather see a really well done 15 room area where the mobs all wore fully described eq (even if the stats on them are 10ac and nothing else), every room had at least one extradesc, the mobs themselves were described, and the exits were described, to a 60 room area half-assedly made with a load of repeating filler and a token set of mobs to have the same-old-same-old fights with.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Wedge



Joined: 31 Mar 2003
Posts: 89
Location: Hendrix College

PostPosted: Fri Apr 16, 2004 6:50 am    Post subject: Yay! Reply with quote

10 points for Wedge and his highly detailed 14 room area Sludig's Keep! Check it out, east of Ofcol : )
_________________
-Wedge
Back to top
View user's profile Send private message Send e-mail AIM Address MSN Messenger
Nightblade
Mud Admin


Joined: 06 Apr 2003
Posts: 343
Location: Cuyahoga Falls, Ohio

PostPosted: Fri Apr 23, 2004 7:43 am    Post subject: Reply with quote

I've noticed in general a lack of understanding on what 'p' actually does in the trigger of the prog. If you use 'p' before your triggering words, let us say the trigger is on a speech prog, 'p yes yea please' the prog will only trigger if the person says EXACTLY, "yes yea please". 'p' should not be used when you're just listing keywords in the phrase you wish the player to speak. This of course holds true in all manner of progs.

I can't think of any mistakes off the top of my head atm, but i'll go play around somewhere and see what dumb things i screw up.

Not so much a mistake as a suggestion: When doing mpechos, mer, mea, etc. try adding color to the messages. I prefer seeing some pretty colors as opposed to the normal white messages Razz
_________________
"Eye level for a kender is door-lock height for the same reason a chipmunk has extra cheek space."

"A kender will take anything that's not nailed down, and a kender with a good claw hammer will get those things too"
Back to top
View user's profile Send private message AIM Address
Palermo



Joined: 07 Jun 2003
Posts: 87
Location: Conway, AR

PostPosted: Sat Jun 19, 2004 8:18 am    Post subject: Reply with quote

Another tip is to test any mobprog many times... and with any set of certain circumstances... that way it reduces problems..

also, I'm not completely sure, but I _think_ that if you use the opvnum(whateverthevnumis) != 1 on give progs it will make it so a renamed item won't work.. like when I got busted for renaming eq to get nails.. I think that it will stop any of that if someone else tries to rename something for a give prog.. I don't think that it will work for wearprogs tho...
Back to top
View user's profile Send private message Send e-mail
Alucard
Avatar 2


Joined: 28 Apr 2003
Posts: 28
Location: Canada, eh

PostPosted: Wed Oct 13, 2004 9:13 pm    Post subject: Fixes for Gareth's problems Reply with quote

Using the form "mpforce 0.$n will make it the player. 0. is the default player identification.

mpforce 0.$n remove $o will avoid any of the rename issues as well.
It takes $o as the items name and removes it rather than "mpforce $n remove gloves"

ovnuminv, ovnumhere are what Pal is trying to say. "help ifchecks2" gives a proper listing.

Only issue with this is that it will NOT allow you to identify items from a different area. It's kinda sketchy that way, so be sure to only set it to check items in your area.
Back to top
View user's profile Send private message
Nightblade
Mud Admin


Joined: 06 Apr 2003
Posts: 343
Location: Cuyahoga Falls, Ohio

PostPosted: Thu Oct 14, 2004 2:57 am    Post subject: Reply with quote

Uh oh, Alucard is wrooooong. I've successfully made ovnuminv work on vnums outside my area. It DID seem to only work occasionally tho...in fact, lots of stuff annoys me with inconsistency.

For example, maybe you can help me out here Alu since you've been building longer than I have. I've done rand progs, within rand progs, and a LOT of times I have issues where it ALWAYS succeeds, even at 1 percent. Thus, I'm never able to check if the rest works. Any clues as to why this happens? Immortal luck? I mean, it's not so much a critical issue as it is pure annoyance, since it seems to work alright on the main port, but damn....so annoying. Just like with the blindness on removal thing.
_________________
"Eye level for a kender is door-lock height for the same reason a chipmunk has extra cheek space."

"A kender will take anything that's not nailed down, and a kender with a good claw hammer will get those things too"
Back to top
View user's profile Send private message AIM Address
Alucard
Avatar 2


Joined: 28 Apr 2003
Posts: 28
Location: Canada, eh

PostPosted: Thu Oct 14, 2004 2:08 pm    Post subject: Reply with quote

Well, you'll have to show me how you did it, Nightblade.

Now, as to random progs within random progs:

If I were to do this for example:

rand_prog 50
if rand(1)
pop this item
endif
if rand(3)
pop a different item
endif

That would run the program based off a d100 percentile and if it was 50 or lower it would run the program. Now, within the program it would run another percentile and if it ended up being 1 it would "pop this item" after that finishes, it would do a percentile AGAIN and if it ended up being 3 or lower it would "pop a different item".

Now, you can make it one percentile role within the program by the use of elseifs or else commands. The two if checks within the program do not run off the initial percentile that decides if it's going to run the random program or not.
Back to top
View user's profile Send private message
Alucard
Avatar 2


Joined: 28 Apr 2003
Posts: 28
Location: Canada, eh

PostPosted: Thu Oct 14, 2004 2:11 pm    Post subject: Reply with quote

Also, if you're doing it like this:

rand_prog 50

if rand(1)
if rand(50)
pop this item
else
pop this item
endif
endif

basically as you look at it it goes "Well, if you make this 1% chance, 50% of the time within that field I want it to pop this item, the other 50% I want it to pop this other item. It won't do this. It will consider each if check as a different check. You need to add a ; after the first if check. That basically says "if I roll a 1 AND I roll a 50 make this spawn, otherwise if I roll a 1 AND I do not roll a 50 spawn this item."

Hope i'm fairly clear.

The ";" is the coding term for AND
Back to top
View user's profile Send private message
Nightblade
Mud Admin


Joined: 06 Apr 2003
Posts: 343
Location: Cuyahoga Falls, Ohio

PostPosted: Thu Oct 14, 2004 5:22 pm    Post subject: Reply with quote

I think actually I did something like so:

all_greet_prog 100
if rand(10)
say this
else
if rand(10)
say that
else
if rand(10)
say twat
endif
endif
endif

But like, the rand(10) was acting as if it were rand(100) cause it would ALWAYS work and never drop down to the others. Problem with the syntax?
_________________
"Eye level for a kender is door-lock height for the same reason a chipmunk has extra cheek space."

"A kender will take anything that's not nailed down, and a kender with a good claw hammer will get those things too"
Back to top
View user's profile Send private message AIM Address
Alucard
Avatar 2


Joined: 28 Apr 2003
Posts: 28
Location: Canada, eh

PostPosted: Thu Oct 14, 2004 5:42 pm    Post subject: Reply with quote

Change it to elseif and try.
Back to top
View user's profile Send private message
Gareth
Admin 2


Joined: 26 Mar 2003
Posts: 522
Location: Singapore

PostPosted: Thu Oct 14, 2004 8:40 pm    Post subject: Reply with quote

oh, and never EVER abbreviate a command on a mobprog.
Things like
g item player
or
mpe A message appears!
might work when you test them, but that doesn't mean that 'g' will always expand to 'give' (and so forth) in future!
If I ever add a new skill or command that starts with 'g', there's every possibility that the parser will interpret it the new way - it's happened before now.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Alucard
Avatar 2


Joined: 28 Apr 2003
Posts: 28
Location: Canada, eh

PostPosted: Fri Oct 15, 2004 4:49 pm    Post subject: Reply with quote

I was reading into mob programs a little more and I came across a cool little explaination on how nesting checks within a program work.

Example: rand_prog 100
if rand(20) (20% of the original program percentile. In this case, 20%)
say hi
endif
if rand(20) (20% of the remaining amount. so 20% of 80 is 16%)
say bye
endif
if rand(50) (50% of the remaining amount. So 50% of 64 is 32%)
say hibye
endif
Back to top
View user's profile Send private message
Nightblade
Mud Admin


Joined: 06 Apr 2003
Posts: 343
Location: Cuyahoga Falls, Ohio

PostPosted: Sat Oct 16, 2004 12:55 am    Post subject: Reply with quote

In my mind...that doesn't seem like a logical construction.

Mainly, this opinion spawns from the endifs. When I see an endif, that's it for the ifcheck, and yet here we have an example where the ifcheck which previously ended is having a direct effect on what follows. THAT doesn't seem logical in my eyes.
By saying this is true, we also have another problem. Say I want the program to not follow these rules you describe. Say I want it to be exactly what it appears to be. 20% chance for 'say hi' 20% chance for 'say bye' and 50% chance to 'say hibye'. If that is what I wanted the program to do, I'd have to create a total of three different progs just to execute that. That also doesn't seem logical.
Would you mind letting slip where you found this info cause like....I don't trust it.
_________________
"Eye level for a kender is door-lock height for the same reason a chipmunk has extra cheek space."

"A kender will take anything that's not nailed down, and a kender with a good claw hammer will get those things too"
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    Abandoned Codex Forum Index -> Building All times are GMT
Goto page 1, 2  Next
Page 1 of 2

Jump to:  

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


Powered by phpBB © 2001 phpBB Group

Chronicles phpBB2 theme by Jakob Persson (http://www.eddingschronicles.com). Stone textures by Patty Herford.