Oset and mset tips and tricks
This page contains tips and tricks for the commands oset and mset, it is not a fully detailed, exhaustive guide. These commands are considered to be more advanced and a good grasp of mobprogs should be obtained before attempting to utilize most of the applications written below. Oset and mset were only implemented to a certain degree. Any information herein may become inaccurate if either command are updated or changed in some way.
GENERAL
There are a lot of things to keep in mind for all potential applications of mset and oset.
Oset does not work on vnums and must specifically target a name keyword (or variable, as in event item progs). If the name keyword is too vague and shared by other items in the room or the player's or mob's inventory, oset could set the wrong item. Oset typically smartly targets the "closest" item to the mob using it, I.e. if the item is in the mob's inventory (and is the only item in existence with that name keyword) it will probably definitely oset the right item. You can also use "mob mforce ($n or $q) mob oset <item name>" as this will target the "closest" item to the player, as they are the one osetting the item. Alternately, if the item can be dropped, it can be given to the mob to oset and given back. Remember these oset item keywords will share keywords with identical items carried by separate players!
If the item will need to be "mob remove"'d, remember mob remove must work with a vnum! If you have multiple of the same vnum item, mob remove can (and probably will) remove the wrong item! If you want to create a variety of "material" type items using the same vnum, you'll need to have the player be forced to give those items using the unique name keywords. If you want them to be able to use multiple of the same item, this is doable by allowing the player the give the items to the mob and having the mob check itself for "5.(item name)" on its give and bribe progs, or whatever type prog activates the "crafting" of the item. Obviously many other precautions must be taken with this method. It is also important to remember this to never have a quest item or token or important mob counter type item share a vnum with another item that must be mob removed. If you want to make a quest token that will be mob removed, it may be best to make a unique vnum! Consider and test all the possibilities before using oset to reduce the number of quest tokens you have to make!
Use "help oset" and "help mset" to remember which fields can be oset and mset. Remember unlike string, oset and mset replaces the variable entirely. If the object name it started with is not repeated in the oset command, it will lose that name keyword. Typically I use a temporary name on the base item with "osetitem" or some variation, to both indicate to anyone looking at the item in the obj editor that the item's final intended form is oset in the prog that creates it, as well as ensuring there are no other items in the game with that name keyword to be accidentally oset. Make sure to keep track of your oset item's name keywords - if you oset the name before you're done osetting other parts, you'll need to change the target name keyword for the remaining commands, as well as any following commands (give, wear, etc.).
The "type" of an item cannot be oset! You cannot turn a potion into a sword, for example.
When using mset, mobs can only mset themselves. This is easily bypassed by using "mob force" commands i.e. "mob force (target mob) mob mset (target mob)" if a separate mob is the one running the prog. Obviously if the target mob is msetting itself it can just mob mset $i.
VARIOUS CREATIVE APPLICATIONS
Oset and mset allow a lot of creativity and new types of mechanics! Here are some of the things you can do with them.
UPGRADING EXISTING ITEMS
Allow players to add strong, meaningful upgrades their existing items, including not only additional stats but upgrading the base values (and level) of the item itself. This could be through event type items or quest rewards.
When using oset to upgrade existing items: if using an event item, ensure that the object being upgraded is represented by the 'target object' variable. The player will need to use the event item on the target upgrade item. When using oset on an item forcibly, as in occurring through a prog as a quest reward or what not, ensure that the item being oset has a unique name keyword. Remember other players may have this same item keyword! When upgrading existing items that may share keywords with objs other players in the room may be carrying (if players quest together and are grouped etc) it is safest to give the item to the mob (use an owned flag if you don't want the item to be able to be given away) to have them oset it to avoid osetting the wrong item.
RANDOM CHANCE TO UPGRADE ITEMS
Create varied and random drops of the same item without creating a different object vnum for each variation. For example, using 'if rand' commands to give a weapon a chance to have a poison weapon flag or a leaf weapon flag. It is even possible to make event items with stronger or weaker uses by utilizing the name field of the item combined with "if name" checks.
When using oset to make random attributes, remember the details of the base object. You can reduce the amount of characters in your prog if there is a stat you want to be on all of the potential variations, just make the base item as complete as possible. You may want to add a name keyword identifier that indicates the item is oset or that that specific item was randomly generated to be better, for example "broadsword sword _osetupgraded" so that when the item is stat'd or searched, you can tell it benefited from an RNG upgrade. This is also necessary if you're making an upgraded event type item that you want to have a better chance to work well, or have a chance to do something that the non-upgraded version doesn't, by using this keyword in the manner of "if name $p _osetupgraded" before your special application within the event's prog.
Example:
if rand 25 mob oset =osetdagger v4 vorpal endif
The above example creates an if rand 25 chance to make the weapon add the special weapon flag of 'vorpal'.
Mpdump 8461 for an example of an event item that becomes oset to be better or worse.
SCALE MOBS/PETS TO PLAYER'S LEVEL
Make mobs that scale with the player's level. This can require very long progs depending on how wide of a scale you want. This would be valuable for special event or arena type areas where you want a large number of players to be able to participate regardless of their level, or if you don't want a player to be able to muscle through a combat oriented quest with a valuable reward by over leveling it (or making harder, remort versions of existing fights!) This is also good for making pets scale with their master's level. This level scaling potential includes the stats of the mobs as well, so they scale realistically! This is an advanced application, be mindful!
There are a large number of things to consider and know in regards to making mobs scale with level or "level up".
First of all, note that any mob that scales any significant number of levels will have enormous, many-times-nested progs. It may not be feasible to have it scale level to level, as in 15 -> 16 -> 17 -> 18 etc. Every single increment will have its own set of oset and mset commands, making the prog very large very quickly. Every level scale, if the mob is scaling to the player's level, must have its own "if level ($n or $q) == x" meaning if you had it scale from 1 to 20 at every level you'd have 20 individual "sets" of mset and oset scaling commands. It is more feasible to scale every 5 or every 10 levels depending on how wide of a level range you'd like. Alternately, you can still add "cheap" scaling every level by making it actually level each time, but only change its stats every 5 or 10 levels. Remember that spells scale with level, but custom mob damecho/damage attacks do not. If you want them to use a mob damecho/damage command and also scale, that mob damecho/damage command will have to if level $i == xx check each time to make it better according to the mob's level, meaning a mob that levels up a lot will have a very long fight prog!
Mset itself cannot add all of the stats typically considered necessary for a realistic scale, and oset cannot change the level or maxhp of a mob, thus making mset and oset both necessary for detailed, advanced scaling. For pets, this is easily accomplished by giving the mob a nodrop, nouncurse, noremove, etc. item that will be oset each time, coupled with mset commands for its health and mana. For bosses, having it oload the item already wearing it and ensuring the item is removed upon the mob's death is also easily accomplished. Unless the item seems relevant to the boss fight, perhaps a warrior swapping weapons, you may want the item to be inert so that the player will not see it when looking at the mob in question.
It does not appear that "oset add armor -xx" oset commands on already worn armor actually apply any benefit to the mob. It may work if the armor is removed and reworn, but the echoes from this may be undesireable. If desired, it is possible to have the mob goto a new room for a moment, remove and re-equip the item, and then return in order to avoid any armor removing/wearing echoes. Alternately, you may want to oset each v# value of a piece of already worn armor instead. This means, if you wish to oset their armor and damdice, they will need both a weapon and at least one piece of armor. It may be easier to just add/remove damroll if that is what you prefer, allowing it to be added to the armor item, removing the need for the weapon. This is mostly up to you as you see fit. If the mob having a weapon makes sense, do both! Also, you may want to consider having a "dropped" version of those items for the player to receive upon defeating said mob, if they are visible to the player. Be aware of how disarm and pry abilities will interact with these items.
For an example of this application with a pet that scales from 1 to 100, mpdump 7917. For an example of this application with a boss that scales from 50 to 100, but only gains stats at three different intervals, mpdump 8495.
COMPLEX BOSS PHASES
Allow bosses (or any mob!) to change their stats on the fly for phases. It was already possible to add and remove affects, shields, and extra flags, but now you can also change their mana pools, health pools, damroll, magroll, hitroll, etc. without having to make new mob vnums for each phase.
You can reliably and forcibly heal your mob by using mset maxhp and mset hp. If you wish to increase the total HP of the mob for a phase swap, but still keep it "damaged", simple mset the maxhp and then determine how much they should have left for the mset hp line. Obviously ensure this doesn't happen over and over, so that the mob is actually defeatable (unless it's not supposed to be!). The information under "mob scaling" in relation to setting different stats for a phase swap apply the same way.
For an example of a boss phase swap using oset and mset, mpdump 8496 (8496 is called from fight prog 8490 for a more complete picture). Note this example is also a scaling boss.
BETTER EFFICIENCY USING SKILLS
Allow pets or mobs to temporarily increase their level to be more successful at using skills. It was previously possible to use different leveled spells by utilizing scrolls and artifice, but since skills could not be put into scrolls, it was not possible to use them at greater efficiency.
This is simply done by temporarily msetting the mob's level before the use of the skill, then returning it back immediately after the skill is executed. If the mob ALSO scales, you will need to make an individual 'if level $i == xx" check for each possible level of the mob before this sequence in order to return it to the accurate level!
For an example of this application on a pet, mpdump 8430. This example pet is also a scaling pet.
SAVE ON VNUMS
One of the simplest applications is using oset to make a wide variety of similar items without needing to use a large number of vnums. Be wary of overusing this application, as each type of osetted item will not appear in a vnum (name) search, making your osetted items hard for other immortals to find in case of potential problems! I would recommend making batches of similar items, and using new vnums for different areas or different applications of items. The vnum of the object will still be visible when the item is stat'd, but it may be a decent idea to add a name keyword into the object referencing the mprog where it is created.
Mobs cannot mset their progs, but they can mset their name keywords. It's possible to make a prog do different things for "different" mobs of the same vnum by msetting unique name keywords and "if name $i" checking for them within a prog. This is a more advanced application so be careful!!
For an example of this oset application, mpdump 8445.
MAKE THINGS OWNED
It is also possible to utilize another new item flag, "owned", with oset: when osetting the name field of the item you'd like to be "owned", ensure the variable representing the name of the player (either $n or $q) is present. Ex: mob oset (item) name (desired name keywords) $n Owned means only that player can equip it, allowing you to make strong quest items that can be dropped without worrying about someone who did not complete the quest picking it up and using it. You can also make unique items for unique pets as well, that even the owner can't wear! It also functions as an ID for the item if it gets dropped by accident!
The owned flag is an extra3 flag.
This does mean the item will be stat obj and searchable using the name of the player, so any owned equipment will show up in an "owhere (player name)" search.