Oset and mset tips and tricks - Revision history

Pascal: /* GENERAL */

2019-11-20T14:55:21Z

GENERAL

← Older revision		Revision as of 07:55, 20 November 2019
Line 9:		Line 9:
	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!		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!		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.).		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.).
Line 16:		Line 16:

	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.		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 ==		== VARIOUS CREATIVE APPLICATIONS ==

Pascal at 15:02, 18 March 2018

2018-03-18T15:02:23Z

← Older revision		Revision as of 08:02, 18 March 2018
Line 56:		Line 56:
	There are a large number of things to consider and know in regards to making mobs scale with level or "level up".		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!		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.		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.

Admin: /* SCALE MOBS/PETS TO PLAYER'S LEVEL */

2018-01-17T03:16:17Z

SCALE MOBS/PETS TO PLAYER'S LEVEL

← Older revision		Revision as of 20:16, 16 January 2018
Line 58:		Line 58:
	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!		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.		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.

	~~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~~.		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 pet that scales from 1 to 100, mpdump 7917.

Admin: /* SAVE ON VNUMS */

2018-01-07T22:08:19Z

SAVE ON VNUMS

← Older revision		Revision as of 15:08, 7 January 2018
Line 87:		Line 87:

	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.		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.		For an example of this oset application, mpdump 8445.

Admin: /* RANDOM CHANCE TO UPGRADE ITEMS */

2017-12-30T03:44:22Z

RANDOM CHANCE TO UPGRADE ITEMS

← Older revision		Revision as of 20:44, 29 December 2017
Line 41:		Line 41:
	''Example:''		''Example:''

	if rand 25		if rand 25
	mob oset =osetdagger v4 vorpal		mob oset =osetdagger v4 vorpal
	endif		endif

	The above example creates an if rand 25 chance to make the weapon add the special weapon flag of 'vorpal'.		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.		Mpdump 8461 for an example of an event item that becomes oset to be better or worse.


	== SCALE MOBS/PETS TO PLAYER'S LEVEL ==		== SCALE MOBS/PETS TO PLAYER'S LEVEL ==

Admin at 03:43, 30 December 2017

2017-12-30T03:43:54Z

← Older revision		Revision as of 20:43, 29 December 2017
Line 38:		Line 38:

	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.		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.


Line 53:		Line 63:
	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.		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, ~~view mobprog~~ 7917 ~~in game~~.		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 ==		== COMPLEX BOSS PHASES ==
Line 62:		Line 73:
	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.		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 ==		== BETTER EFFICIENCY USING SKILLS ==
Line 70:		Line 82:
	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!		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 ==		== SAVE ON VNUMS ==
Line 78:		Line 91:
	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!!		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 ==		== 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. 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!		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.		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.		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.

Admin: /* SCALE MOBS/PETS TO PLAYER'S LEVEL */

2017-12-29T16:14:36Z

SCALE MOBS/PETS TO PLAYER'S LEVEL

← Older revision		Revision as of 09:14, 29 December 2017
Line 49:		Line 49:
	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!		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 ~~proper~~ 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.		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 ~~you want~~ to ~~increase~~ the mob's armor, you may ~~need~~ to oset each v# value 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.		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, view mobprog 7917 in game.

	== COMPLEX BOSS PHASES ==		== COMPLEX BOSS PHASES ==

Admin: Created page with "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 g..."

2017-12-29T15:53:34Z

Created page with "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 g..."

New page

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.

== 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 proper 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 you want to increase the mob's armor, you may need to oset each v# value 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.

== 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.

== 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!

== 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!!

== 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. 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.