Minecraftforge: [1.14] Cannot get sending modid from IMC

[williewillus]

This is very useful for the receiving mod to know who exactly it's interacting with.

[williewillus]

Specifically, the IMCMessage class stores the receiving modId in its modId field, but the sending mod is not saved anywhere.

[cpw]

How are we supposed to know? IMC can be sent from anywhere - and we typically don't track that context everywhere for the massive performance impact it causes. If you need to know how to call someone back, specify a callback type interface?

[williewillus]

IMC can be sent from anywhere

if I understand correctly, it's only supposed to be during IMCEnqueueEvent, which has perfect context on the currently running mod.

Either way, it's a regression from 1.12 -- I'm not sure what you mean by callback-type interface, the imc system is useful for just sending dumb data types over the wire, registering things, etc. It's really hard to do that without sender info, which we used to have.

[darty11]

Can't you just require that they send a Pair if you really wanted the modId?

[blay09]

@darty11 The problem with doing that is that existing compatibility established through IMC cannot be simply ported from 1.12 to 1.13, meaning all crossmod support that was built up over the past versions and depended on the sender being available would be lost and have to be re-introduced.

[loordgek]

i need it to.
can we do
` /**
* @param from the modID the message was send from
* @param to the modID the message was send to
* @param method the method that receives the message
* @param thing the message content
* @return true if the mod you sent to is loaded
*/

public static boolean sendTo(final String from, final String to, final String method, final Supplier<?> thing)`

and in the IMCMessage a field holding the sender modID.

???

[cpw]

You guys are all aware that the "old" IMC interface is in no way compatible with the new one? Every mod updating to 1.14 will need to change slightly for the new system. Changing to an alternative structure seems to me to not be a particularly big hardship. I could break the entire IMC API, and mandate an origin modid (which would have to be supplied by the mod sending, and wouldn't be reliable in any way). That seems like a really poor solution to a problem that shouldn't exist.

[blay09]

There's a difference between adapting all IMC code to match the new classes and adapting each individual mod support to new IMC protocols.

Reliability is not needed (as it wasn't pre-1.13, where we had a good compromise of sendIMC when the mod container was active, and sendRuntimeIMC outside of that); if any mod wanted to spoof being another they could find other means to do that.

This is a regression which broke the one protocol that was thought to be long-term compatible by abstracting inter-mod-compat to just fixed structures of data being passed around mods - that's not a "problem that shouldn't exist".

I understand the damage is done now since some mods will have already updated to new IMC sending methods and thus will not be sending a mod id, but with people only now starting to settle over, it could still be a good time to just make getSender() return an Optional<String> until 1.15, reintroduce the previous sending methods, and deprecate the sender-less ones.