Proposal for new speech based pet control command

ForeverFun

@Kyronix

Here's a proposal for a new speech based pet control command: "action".

In a nutshell, this will "disable" usage of spells and/or actions that are trained on the pet.  It won't remove the trained items from the pet.

This could be implemented any number of ways, but example info is below.  See also this (link) for an example where this type of control has some precedent.

Others feel to weigh in too;  I know there are plenty of examples of wanting more control over pet behavior.

Useful for at least:

1. Cases where training skills is very frustrating and time consuming due to inherent ability "bloat" (can take a year+ to train up bushido on sabre-tooth tiger).
2. Cases where using area effect spells and abilities is not desirable.
3. Cases where using certain spells or abilities is not suitable for the tactical situation.
4. a.          frost mite using cold wind against unsuitable targets.
5. b.          put pet in offensive vs. defensive posture.
6. c.          Prevent usage e.g. of Enemy of One with pets involved with multiple targets.
7. d.          Inappropriate usage of conduit or other mastery spells.  
   
8. Provides an alternative to significant revamp of existing pet AI.

Key points:

1. Does not a) change animal taming / lore gumps, b) change the taming process.
2. Does not allow enabling spells/abilities that are otherwise not part of the pets trained capabilities.
3. Provides the ability to disable usage of specific spell(s) and/or abilities.

Examples relative to existing speech based pet command syntax:

{all|pet_name} {kill|follow|guard|stop|stay} [...]

add "action" command, and associated subcommands:

{all|pet_name} action {disable|clear} {spell|ability|...}  (spell or ability number/name)

disable = set a single disable bit, corresponding to the ID (other existing disable bits untouched)
clear = clear a single disable bit, corresponding to the ID (other existing disable bits untouched)

spell = individual spells numbers associated with a magic school.  (could also use friendly names?)

0-64 magery

101-117 necromancy

... (chiv, spellweaving, mystic, etc)

701-744 mastery spells.

ability = individual ability ID numbers associated with pet abilities. (*)

Real world "say" speech command usage examples:

disable usage of conduit on any pets that have access to it:

all action disable spell 712

disable usage of Enemy Of one, affecting chivalry pets:

all action disable spell 206

disable usage of bleed on a Cu that has bleed (*):

all action disable ability 1234

disable usage of poisoning magic school (*):

all action disable ability 555

1. not specified as to whether it's persisted to pet.
2. not specified as to whether it's persisted to player (lifetime can be game per-login session, etc).
3. could be implemented as a bitmask of disable bits (disable bit set to 1, for given spells/ability).
4. disable bits checked when a spell/abiity is about to be used by a pet.

(*) I don't know how abilities are indexed/identified, just making up an id of 555 and 1234.  uo-cah calls out 4 buckets, so those may need different/additional keywords beyond "ability".

Magical Abilities       
Special Abilities
Special Moves
Area of Effects

Lord_Frodo

Please do NOT break the pet command spaghetti code, that code is as old as UO

keven2002

Lord_Frodo said:

Please do NOT break the pet command spaghetti code, that code is as old as UO

No need to worry, the Dev team isn't going to make any sort of major changes to anything in UO that isn't NL anytime soon. 

We have the pirate hats for another month, then "summer break" where we get nothing new, then supposedly NL, then a repeat of Halloween/Krampus/Artisan Festival, then nothing for at least the first 3 months of next year.

Pawain

Yup ∆ correct.  Bladeweave pets have offense and defense modes.  But we can not easily access the gump to click.

Kyronix

Thanks for the suggestion.  The practicality of giving this much granular control to pet abilities is pretty limited from a development perspective.  Nothing is theoretically impossible, but this would require a massive amount of auditing since unfortunately all the spell schools and special abilities are not uniformly implemented. 

Pawain

Kyronix said:

Thanks for the suggestion.  The practicality of giving this much granular control to pet abilities is pretty limited from a development perspective.  Nothing is theoretically impossible, but this would require a massive amount of auditing since unfortunately all the spell schools and special abilities are not uniformly implemented. 

Allow us to put bladeweave pets in their mode. Make the gump so we can use it.  That is already in the game but too difficult to do the trick to see the modes.

username

keven2002 said:

No need to worry, the Dev team isn't going to make any sort of major changes to anything in UO that isn't NL anytime soon. 

We have the pirate hats for another month, then "summer break" where we get nothing new, then supposedly NL, then a repeat of Halloween/Krampus/Artisan Festival, then nothing for at least the first 3 months of next year.

It's hard to believe they've gotten away with this for 4-5 years and the bootlickers cheer each time we get a new ToT copy/paste event. Then again, I have seen several major guilds across most shards collapse due to lack of online players so in the end they're paying the price for it. 

IF NL does get released somewhere in your timeline there (I doubt it) it will be either devoid of content and/or a major flop and we'll see a big shift in the staff for Ultima... how will they explain something they announced ~5 years ago and have been working on for the best part of that time failing? Remember, this was something NO ONE ASKED FOR and what in my opinion was direct announcement after people had been asking for a classic server forever and WoW released it's classic server. Mesanna will retire/be fired (I believe she's in her mid/late 60's as it is) and the staff 'shuffle' could either be the end of the game or the best thing that'll ever happen. If I were Broadsword, I'd hire people that develop for the free shards/3rd party clients. I hear more people leaving for Outlands weekly than I've heard looking forward to NL in the last 3+ years.

ForeverFun

Kyronix said:

Thanks for the suggestion.  The practicality of giving this much granular control to pet abilities is pretty limited from a development perspective.  Nothing is theoretically impossible, but this would require a massive amount of auditing since unfortunately all the spell schools and special abilities are not uniformly implemented. 

Perhaps an incremental approach would work well, where these capabilities phase in over time?

e.g. start with "specialmoves", two in particular:

all action disable specialmove bleed_id
all action disable specialmove coldwind_id

Where "bleed_id" and "coldwind_id" correspond to a string or number identifying the moves.

Just adding controls over those 2 special moves would likely be celebrated.

(note this should only influence when the pet code determines whether to execute a specific move).    If the disable bits are never set, no behavior changes.

Some posters on this forum raise the game code age as a reason why changes aren't happening.  Hopefully, that isn't true.  The developers associated with common operating systems today would likely disagree with that logic.

Pawain

The difficulty of a change is irrelevant.  Look at NL.
Maybe like many other things, the devs Don't want to change this.  Do pets kill stuff now?  Yes. Remember when Mesanna promised the complaining GD owners that the new pets would not make their GDs obsolete? 

Well they are, maybe they want to stop the power at this point.

Kyronix

ForeverFun said:

Kyronix said:

Thanks for the suggestion.  The practicality of giving this much granular control to pet abilities is pretty limited from a development perspective.  Nothing is theoretically impossible, but this would require a massive amount of auditing since unfortunately all the spell schools and special abilities are not uniformly implemented. 

Perhaps an incremental approach would work well, where these capabilities phase in over time?

e.g. start with "specialmoves", two in particular:

all action disable specialmove bleed_id
all action disable specialmove coldwind_id

Where "bleed_id" and "coldwind_id" correspond to a string or number identifying the moves.

Just adding controls over those 2 special moves would likely be celebrated.

(note this should only influence when the pet code determines whether to execute a specific move).    If the disable bits are never set, no behavior changes.

Some posters on this forum raise the game code age as a reason why changes aren't happening.  Hopefully, that isn't true.  The developers associated with common operating systems today would likely disagree with that logic.

There's definitely more feasibility in a specific change to address a single issue you may be facing.  Incremental change is much more efficient then entire system audits.  So if you can boil it down into a digestible user story, we can take a look. 

The age of the code base isn't necessarily the problem - it's more so how many hands have been in the repository over the years.  Sometimes systems were implemented in haste, sometimes before functionality was available (Fun fact: before there was a (-) many operations to get -1 were written as 0-1) and sometimes without efficiency at the forefront.  Anyone who has spent a while on project will no doubt evolve their thinking and methodology.  Some of the original stuff I wrote 10+ years ago I look at and go...who wrote this?!...oh...right.  But that's part of learning and growing.

Anyway, we have to take that into consideration when we are looking at major overhauls because it's an obvious risk that impacts practicality. 

keven2002

Kyronix said:

Anyone who has spent a while on project will no doubt evolve their thinking and methodology.  Some of the original stuff I wrote 10+ years ago I look at and go...who wrote this?!...oh...right.  But that's part of learning and growing.

Anyway, we have to take that into consideration when we are looking at major overhauls because it's an obvious risk that impacts practicality. 

Props to you Kyronix for this post. Appreciate the candor and transparency of what you are saying; and more importantly I appreciate the response.

Skett

ForeverFun

Kyronix said:

ForeverFun said:

Kyronix said:

Thanks for the suggestion.  The practicality of giving this much granular control to pet abilities is pretty limited from a development perspective.  Nothing is theoretically impossible, but this would require a massive amount of auditing since unfortunately all the spell schools and special abilities are not uniformly implemented. 

Perhaps an incremental approach would work well, where these capabilities phase in over time?

e.g. start with "specialmoves", two in particular:

all action disable specialmove bleed_id
all action disable specialmove coldwind_id

Where "bleed_id" and "coldwind_id" correspond to a string or number identifying the moves.

Just adding controls over those 2 special moves would likely be celebrated.

(note this should only influence when the pet code determines whether to execute a specific move).    If the disable bits are never set, no behavior changes.

Some posters on this forum raise the game code age as a reason why changes aren't happening.  Hopefully, that isn't true.  The developers associated with common operating systems today would likely disagree with that logic.

There's definitely more feasibility in a specific change to address a single issue you may be facing.  Incremental change is much more efficient then entire system audits.  So if you can boil it down into a digestible user story, we can take a look. 

The age of the code base isn't necessarily the problem - it's more so how many hands have been in the repository over the years.  Sometimes systems were implemented in haste, sometimes before functionality was available (Fun fact: before there was a (-) many operations to get -1 were written as 0-1) and sometimes without efficiency at the forefront.  Anyone who has spent a while on project will no doubt evolve their thinking and methodology.  Some of the original stuff I wrote 10+ years ago I look at and go...who wrote this?!...oh...right.  But that's part of learning and growing.

The section "Useful for at least" may tell a story from a user perspective.  You could boil it down to providing more control over the pet to suit the tactical environment (don't waste moves or mana) and providing a more efficient way of training pet abilities (by avoiding time spent on areas that don't need training).  From a story/lore perspective, most pets are rated greater than superhumanly intelligent, so they should provide more control.  Watch "Absolutely Anything" if you want a funny take on this (the ending).

Pets with poisoining would be much more useful if this could be disabled, as magery using targets just cure in a hard-loop.  That leads to a frustrating cycle of the pet continuing to re-poison (wasting mana and moves).  You could have it enabled when the fight calls for it.  This would likely be a very popular change.  Slightly different say command syntax just for thought.

-- disable usage of poisoning on melee hit
all disable poisoning
-- re-enable usage of poisoning on melee hit
all enable poisoning

Devils advocate:

Code age, code size and complexity, variations in environrments where it runs, number of people in the code, bug backlog, turn-over in the staff and institutional knowledge, non-technical complexity, etc may not deter developers on common operating systems today.  I suspect you can pull off changes like this

Pawain

@ForeverFun ; I think the magics that are not working correctly should be fixed first.  Magery Mastery pets cast some spells on the wrong target.  They do not even cast some damaging magery spells that they should.

Necro pets cast conduit, make the skull circle, but it does not do any damage.

So, until we see all the damage spells work, why are we trying to disable some of them?

Playerskill and players from Cah can tell you which work and do not work.

I think that would be a better place to begin rather than trying to disable spells to get the result you want, on a MM I would disable all the non damaging spells and end up with a pet that does very little damage from spells.  (little damage from spells is what we have now.)

Like I have said before Even with all spells working and choosing to remove some spells a player does not like.  Magery pets would still be in 4th place in the magics category and only be used by players who prefer not to kill things fast.

A better magery pet could be made,  These used to stand away from the target and cast. But tamers did not like that  because the mob would target them. So that was changed to make all pets go to melee range on targets, then use their rotation.

IMO we are at a point where we could make a warrior/tamer where they could use a magery pet that stands back and casts all the spells and they all work correctly. While the player tanks the mob.

When everything works, then modify which spells are cast.

To see what max damage a magery pet can do with spells,  take off all your SDI items (no slayer book) and see how long it takes to kill a Balron or Dread Pirate.  That would be using only the spells you choose,  it will be a very unpleasant experience.  (to get the full experience of a Magery pets damage, cast your spells randomly)

ForeverFun

You can see some posts from me in the bugs subforum. There's one that recaps the mastery issues on pets.  I'd rather have some way to just turn those on/off, instead of tweaking what they do.  For instance, you'd want a player bard using the discord mastery, not a pet.  Same is true for death ray.  Correct usage of conduit on a pet would also require coordination of the necro spells the pet uses (see the "spells" proposal above).

The main reason magery pets don't do much damage, compared to players, is pets can't have slayers applied (there have been separate proposals on posible slayer mechanics for pets).

The mixture of spells used is a secondary reason, though my proposal above addresses that simply by allowing unwanted spells to not be used.

If you wanted to propose a mechanic for adding SDI to a pet, have at it.

I got the sense from Kyronix reply that touching the "spells" area may be more tricky.

With most pets today, you can get the most total damage output by having the pet tank (even a 125 STR pet), with a mage/warrior dishing most of the damage.

Adding more control would add some more fun, etc, too.

Pawain

I think the best slayer for pets idea would be adding a set of either:

Food from plants
Food from rare fish
Food from another source

Each variety would have its own slayer.  Each would last X amount of time then wear off.

Gonna have to convince me a working Magery pet is good enough to ask for SDI.


Personally I do not think pets need a slayer ability.

PlayerSkillFTW

Pets with Arcane Magic skills (Magery/Necromancy/SW/Mysticism) should have the damage of their spells significantly impacted by their INT, similar to how heavily STR impacts melee damage. This would give reason to make a pet with 700 INT and an Arcane Magic ability, rather than the typical pet with 700 STR and Chiv+AI.

I suspect the devs are leery of implementing that change though, because it might also affect wild monsters and creatures, making them much more dangerous with magic. Imagine getting spell comboed by an Ancient Lich with 1,045 INT and 130 Eval.

Pawain

    Truth.

You just want everyone to have that ugly Serpentine Dragon.

ForeverFun

PlayerSkillFTW said:

Pets with Arcane Magic skills (Magery/Necromancy/SW/Mysticism) should have the damage of their spells significantly impacted by their INT...

I suspect the devs are leery of implementing that change though, because it might also affect wild monsters and creatures, making them much more dangerous with magic. ...

I'd be fine with this change, even if it didn't apply to tamed pets.

Once upon a time, mere lich lords were feared. Power creep should work for monsters too, not just players, their equipment, and pets.

p.s. if you're talking about non Chiv/AI pets. many may be better off with 645 (or less) STR, 700 INT...

shootgun

@Kyronix

Fixing the current pet mastery bugs might be a better start than adding new functionality. Here is the list I put together back in the day: https://forum.uo.com/discussion/13771/attn-devs-list-of-bugs-with-pets-please-respond

There were more items I was going to add before I got banned from the forum. Now I got banned from the game and decided to quit UO I am not interested to take a look at it anymore. May be someone else can take over and keep reporting remaining pet bugs.

Lord_Nythrax

ForeverFun said:

Once upon a time, mere lich lords were feared. Power creep should work for monsters too, not just players, their equipment, and pets.

Once upon a time the strongest monster in the game was an ancient wyrm or something. If you're so hungry for a challenge maybe try fighting something that's been in the game for less than 25 years.

ForeverFun

Some additional notes:

1. If a mage with 120 eval int, 120 magery blesses a magery based pet, the magery based pet will fizzle (and waste "moves") casting bless on itself.  it strength of the bless spell may be more desirable to have originating from a player, vs. a pet.
   
2. If a pet with necromancy uses "wither", the side effects of the area effect spell may not be desirable (fel, hitting positive karma targets, etc).
3. If a pet with necromancy uses "wither", the (cold) damage is effectively reduced if the target(s) are under the effects of "Corpse skin", another necromancy spell.

More reasons that disable controls would be valuable.

sibble

ForeverFun said:

Once upon a time, mere lich lords were feared. Power creep should work for monsters too, not just players, their equipment, and pets.

Covetous Level 4 Lich Lords can be spooky

Norry

I like the idea of more crafted pet foods, maybe ones that need alvhemy and cooking to craft lesser or super slayer petfoods, ones that add SDI. Give a new craftable. The item is already there from khaldun.