gear with pet mods applied via latent

[LBegnaud]

Was goin to make an issue, but figured it was more of a discussion topic.

Describe the feature

Latent-type gear with pet mods don't seem to be implemented. I.E.

• Fenrir's Crown
• Morana's Pigaches
• Fidelity Earring
• Affinity Earring

the idea behind item_mods_pets is interesting and definitely works for most situations. But in my mind a more general approach would be to allow item_mods to have the pet flag encoded somehow. Allowing modid to be negative could signify that an item's mod is for the pet instead of the owner. One could then apply the above latents easily. A workaround for the above would be to make new modids specifically for applying pet mods, like in this example. In my opinion both the current item_mods_pets and the wings solutions are different bandaids to the underlying problem.

Another approach would be to allow the mod value on an item_mod to be a flag. Something like higher than 10240 since judge's cape gives 9999 modvalues (Or perhaps change judge's cape to give the godmode flag and use a lower flag value?)

The flag approach could be done against the modid as well, just spitballing really.

[LBegnaud]

Another thing I didn't consider originally is gear that affects fellow stats. I assume there's similar gear for trusts? I don't know

This makes the flag approach on modid more generalized and cleaner for this purpose I think

[TeoTwawki]

iirc back in dsp there was a plan for an item_latents_pet sql table that never happened (same way we have a table for players mods and another for pets mods). this was because pets mods are the same as players, just added directly to the pet instead of the owner. Long back in the history all mods were player only, so anything applying to a pet had to be a new mod ID and added to the owner which meant tons of duplicate mods.

I think a latent pet table is likely the sanest way forward that doesn't require rewriting existing systems.

The only reasonable alternative to me is additional columns on the existing tables while merging the 2 mod tables back into one. which is a lot more work than a new table. negative mods or flags are not feasible or reasonable alterations and can even generate confusion or bugginess in other places that weren't designed with that in mind.

[TeoTwawki]

I'm not sure if there's gear that adds mods to other non-player entities, either.

there's some for trusts, but it's just one mod on the owner to implement for them - domain invasion gear adds levels to them at spawn time, so we'd be checking the "owner" anyway

[LBegnaud]

afaik pets and fellows can exist at the same time, not sure how that affects making fellows function as pets.

Sounds like maybe the easiest path forward is to just make player mods to handle latents for pets/fellows as in the original wings commit or my recent bandaid that I made as a workaround pending this discussion?

[TeoTwawki]

afaik pets and fellows can exist at the same time, not sure how that affects making fellows function as pets.

Doesn't matter at all. We're not checking if you have a different pet out, we're checking if you have a pet that matches the type specified. Type fellow = apply mod from table rows marked with type "fellow".

Sounds like maybe the easiest path forward is to just make player mods to handle latents for pets/fellows as in the original wings commit

I dunno how you get anywhere close to that from anything I have said. I have been trying to politely make you realize the wings method is the worst way in the history of bad ways without insulting any passerby that might love wings, you, your friends etc, and it's just becoming impossibly difficult to avoid saying it's horrible.

or my recent bandaid that I made as a workaround pending this discussion?

While I thank you for the offer, I'd rather not work around it at this time. A new table or additional columns on the existing table aren't that bad to do. A new table would be downright trivial.

[LBegnaud]

Suppose I was taking

we'd just make unique mods just for fellows

a little too far and assuming you meant for all latent mods.

I don't need you to be polite, just trying to get a clear idea of what path this project would like to take to handle latents for pet mods while also considering that there's other possible functions for the code that we choose (i.e. a column on item_mods to specify the entity type).

When the discussion is over I don't mind doing the PR

[LBegnaud]

Also I should apologize. I re-read your original reply and it clarifies everything I was confused about. Read it in the car and it just didn't click.

[DiscipleOfEris]

Would merging item_mods_pet into item_mods with an extra column or two be the ideal solution, or does that introduce too many potential problems for consumers of LSB to migrate? Or is that a non-issue?

[TeoTwawki]

it'd be a lot of busy work to do the upstream conversion, as for servers running off us it'd depend how many custom rows they created in either/both tables.

Theres also a risk of its being a highly difficult to read diff on the pr and reviewers missing things - thats happened in the past back in DSP and caused issues and then downstream users and devs alike were in polite terms "upset".

in the new table approach to things, only gotta care about the new rows of that table.

Side note, just for usability purposes: if you click below the individual message you reply to here, it threads your reply into it. if you use the bottom box, it starts a new thread off the OP at the top.