Add compatibility with LWM's Deep Storage

[lilwhitemouse]

Currently, LWM's Deep Storage has compatibility with RSA by disabling hauling hysteresis entirely for Deep Storage units. Full compatibility would be better:

IHoldMultipleThings is a helper mod Mehni put together for Pick Up and Haul, but its interface allows compatibility between other mods as well.

These changes allowed Satisfied Storage to work seamlessly with Deep Storage, and should allow RSA to as well.

[DoctorVanGogh]

Yeah.... great idea.... 💯 👍

But I don't like it 😢 It adds a binary dependency to RSA... And I don't like dependencies (at least if they are only there for some semi-obscure edge case).

I'll probably still merge some equivalent logic, but it needs some refactoring to eliminate the dependency.
I'm thinking reflection with some cached type analysis here (so as to not totally kill performance).

[lilwhitemouse]

Yeah, I thought about that a lot with Satisfied Storage, but kept coming back to "this wheel has already been invented". I don't know if you were to build your own version of IHoldMultipleThings, if it would work to link against? My instinct would be "it'll be fine!" but maybe there's some underlying signature or something.

Mehni's code is here, by the way: https://github.com/Mehni/PickUpAndHaul/tree/master/Source/IHoldMultipleThings

If you need it, I can add some static compatibility method, or whatever?

[DoctorVanGogh]

Yeah, I'm aware of IHoldMultipleThings 😁

I'll probably slap together some dynamic method vodoo based on reflection.

That should

• not add a dependency
• still be fast (enough)

Also.. I vaguely remember tripping over IHoldMultipleThings/ Deep Storage in the context of ExtendedStorage... but that's a discussion for elsewhere

[DoctorVanGogh]

Take a look at my test branch and see if it does what you want.

I refactored your logic a bit but it should do exactly the same.

If you say it's all good I'll merge & push those changes.

[lilwhitemouse]

Okay, I have not done much with assemblies, so don't know a whole lot here, but you specify

private const string Guid_IHoldMultipleThings = "e1536a54-d289-41fa-9d0b-8a2f6812c7fa";

In some ways, that still adds a hard dependency to the logic. Is it possible to get the type without specifying the assembly that strictly? Asking for a friend.

Still reading through; I may have more questions if you have answers

[DoctorVanGogh]

I mean, yes, you will always need some datum to identify something if you want to enable logic or not.

But I dont have to include a binary assembly
I dont have to compile my project against some assembly
I dont have to pray someone doesnt fiddle with assembly versions on their release
I dont have to pray they dont fiddle with the public interfaces

I just have to rely on pure developer lazyness someone not changing the Guid that's been slapped onto their assembly.

And if I should ever catch Mehni actually changing his assemblies' guid willy-nilly... I'd be very tempted so personally send him a bag of glitter... erm... "ducks" 🦆

So yeah... the guid is (almost) about as specific and error proof as it can get. Because some 3rd party modder could have renamed the actual assembly filename and it would still work in their mod. Would still be the same types under the hood as far as the runtime is concerned.
Or someone could have included some other assembly in their project which has a "foo.bar" type... But I would not want to enable any special logic for that.

So yeah....

Ask away :D

[lilwhitemouse]

Okay, so question, then: if I wanted to do something similar, grabbing a type from someone else's assembly, is there a way to do it that would grab ANY instance of that type in that namespace? In case someone DID change the GUID?

[DoctorVanGogh]

You maybe want to poke me (DoctorVanGogh#8103) on Discord? This is getting semi offtopic :D

[lilwhitemouse]

Excellent.

[lilwhitemouse]

Tested test branch, works very well! Thank you