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 to give it a unique name keyword and to not use the vnum, as you may mob remove the wrong item.
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, for a mob to actually realistically scale, you will need to do more than set its level to the level of the target/master. Setting the level of the mob to the player/targets level is done by making the mob remember the intended scale target and using 'mob mset $i level $B', $B being the level of the mob remember target. You can also only scale it at certain intervals if desired, with if level $n >= xx etc. checks.
You can just make the mob level up, which will do some things, but not increase its health, mana, moves, stats or increase any 'mob damage' or 'mob damecho' numbers. It WILL make any spells it uses increase in power, it will fair better against higher level foes in melee combat in regards to dodge/parry, and obviously allow it to use higher level armor. It is more feasible to scale every 5 or every 10 levels for stats on the mob, depending on how wide of a level range you'd like. If you want them to use a mob damecho/damage command that also scales, that mob damecho/damage command will have to have if level $i >= xx checks each time to make it better according to the mob's level, meaning a mob that levels up a lot could 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 bosses, having it oload the item 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.
There are two very important things to keep in mind when using this application. First of all, when osetting a piece of equipment, the changes do not affect the mob until the item is removed and re-equipped. This does not apply to VALUES but does apply to any affects (added with 'add' or 'apply'). Second of all, if you mset the maxhp, maxmana, or maxmove of a mob that is currently wearing armor that affects the hp, mana, or move of that mob, the result is NOT a total of (new maxhp/mana/move) + (benefit from armor), but rather the the benefit from the armor becomes part of the maxhp/mana/move of the mob. This means that if you have a piece of armor that increases hp by 500 and you mset the maxhp to be 1000, removing that piece of armor will result in 500 hp. ALSO NOTE: This can cause removal of armor to put the mob's HP below 0, putting it into a "dead" stasis that can only be fixed by immortal intervention. In practice, this means, don't mset the maxhp/mana/move of a mob that has any chance of wearing armor, i.e., a pet.
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.
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.