View previous topic :: View next topic |
Author |
Message |
Gareth Admin 2

Joined: 26 Mar 2003 Posts: 525
|
Posted: Tue Apr 13, 2004 4:26 pm Post subject: Problems with mobprogs |
|
|
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 |
|
 |
Waldo

Joined: 26 Mar 2003 Posts: 79
|
Posted: Thu Apr 15, 2004 1:18 am Post subject: |
|
|
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 |
|
 |
Gareth Admin 2

Joined: 26 Mar 2003 Posts: 525
|
Posted: Thu Apr 15, 2004 1:58 pm Post subject: |
|
|
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 |
|
 |
Wedge
Joined: 31 Mar 2003 Posts: 89 Location: Hendrix College
|
Posted: Fri Apr 16, 2004 6:50 am Post subject: Yay! |
|
|
10 points for Wedge and his highly detailed 14 room area Sludig's Keep! Check it out, east of Ofcol : ) _________________ -Wedge |
|
Back to top |
|
 |
Nightblade Mud Admin

Joined: 06 Apr 2003 Posts: 343 Location: Cuyahoga Falls, Ohio
|
Posted: Fri Apr 23, 2004 7:43 am Post subject: |
|
|
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  _________________ "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 |
|
 |
Palermo

Joined: 07 Jun 2003 Posts: 87 Location: Conway, AR
|
Posted: Sat Jun 19, 2004 8:18 am Post subject: |
|
|
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 |
|
 |
Alucard Avatar 2
Joined: 28 Apr 2003 Posts: 28 Location: Canada, eh
|
Posted: Wed Oct 13, 2004 9:13 pm Post subject: Fixes for Gareth's problems |
|
|
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 |
|
 |
Nightblade Mud Admin

Joined: 06 Apr 2003 Posts: 343 Location: Cuyahoga Falls, Ohio
|
Posted: Thu Oct 14, 2004 2:57 am Post subject: |
|
|
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 |
|
 |
Alucard Avatar 2
Joined: 28 Apr 2003 Posts: 28 Location: Canada, eh
|
Posted: Thu Oct 14, 2004 2:08 pm Post subject: |
|
|
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 |
|
 |
Alucard Avatar 2
Joined: 28 Apr 2003 Posts: 28 Location: Canada, eh
|
Posted: Thu Oct 14, 2004 2:11 pm Post subject: |
|
|
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 |
|
 |
Nightblade Mud Admin

Joined: 06 Apr 2003 Posts: 343 Location: Cuyahoga Falls, Ohio
|
Posted: Thu Oct 14, 2004 5:22 pm Post subject: |
|
|
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 |
|
 |
Alucard Avatar 2
Joined: 28 Apr 2003 Posts: 28 Location: Canada, eh
|
Posted: Thu Oct 14, 2004 5:42 pm Post subject: |
|
|
Change it to elseif and try. |
|
Back to top |
|
 |
Gareth Admin 2

Joined: 26 Mar 2003 Posts: 525
|
Posted: Thu Oct 14, 2004 8:40 pm Post subject: |
|
|
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 |
|
 |
Alucard Avatar 2
Joined: 28 Apr 2003 Posts: 28 Location: Canada, eh
|
Posted: Fri Oct 15, 2004 4:49 pm Post subject: |
|
|
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 |
|
 |
Nightblade Mud Admin

Joined: 06 Apr 2003 Posts: 343 Location: Cuyahoga Falls, Ohio
|
Posted: Sat Oct 16, 2004 12:55 am Post subject: |
|
|
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 |
|
 |
|