Skip to content
This repository has been archived by the owner on Jan 2, 2022. It is now read-only.

Conflicts with other mods using /locraw #72

Open
robere2 opened this issue Dec 30, 2020 · 8 comments
Open

Conflicts with other mods using /locraw #72

robere2 opened this issue Dec 30, 2020 · 8 comments

Comments

@robere2
Copy link

robere2 commented Dec 30, 2020

Looking at these lines:

if (!this.playerSentCommand) {
event.setCanceled(true);
}

It appears that the /locraw message is always captured and cancelled unless the player sent it. This causes conflicts with other mods. that use /locraw if they do not set their priority higher. A higher priority would result in a never-ending war of who comes first.

The best solution to this in my opinion would be, instead of not cancelling when the message is player-sent, only cancel if the message is mod-sent.

@ImRodry
Copy link

ImRodry commented Dec 30, 2020

It appears that the /locraw message is always captured and cancelled unless the player sent it.

The command is also canceled when the player runs it but this seems to be caused by something else in the code, not sure what though

@Sk1er
Copy link
Member

Sk1er commented Dec 30, 2020

Not that this is the only solution but I believe forge has a tag where you can have canceled events still flow into your event handler

@ImRodry
Copy link

ImRodry commented Dec 30, 2020

Not that this is the only solution but I believe forge has a tag where you can have canceled events still flow into your event handler

This could fix other mods not being able to access the command but it still doesn't fix it being removed when the player executes it. I believe this is because the "listening" variable is set to true after 20 ticks and, therefore, playerSentCommand is set to false so it cancels the event either way. May be wrong but that's my best guess from looking at the code on the file bugfroggy linked

@DevBefell
Copy link
Contributor

DevBefell commented Dec 30, 2020

Not that this is the only solution but I believe forge has a tag where you can have canceled events still flow into your event handler

This could fix other mods not being able to access the command but it still doesn't fix it being removed when the player executes it. I believe this is because the "listening" variable is set to true after 20 ticks and, therefore, playerSentCommand is set to false so it cancels the event either way. May be wrong but that's my best guess from looking at the code on the file bugfroggy linked

I was the one that did the playerSendCommand, and it works, but because onMessageSend activates when the mod sends /locraw, sometimes it doesn't cancel the event, and I have yet to fix that correctly, which means that if other mods send the command, it should execute as a player had done it. I used it with DiscordRP and it doesn't seem to have any conflicts, I am not sure if DiscordRP set their priority higher, but it works as it should. And for the listening, I used it to try to make sure that it was the player sending it and not the mod sending it, which didn't work perfectly, not sure what was the original use of it as I am not the one that put that.

@vickensemerdjian
Copy link

Not that this is the only solution but I believe forge has a tag where you can have canceled events still flow into your event handler

This could fix other mods not being able to access the command but it still doesn't fix it being removed when the player executes it. I believe this is because the "listening" variable is set to true after 20 ticks and, therefore, playerSentCommand is set to false so it cancels the event either way. May be wrong but that's my best guess from looking at the code on the file bugfroggy linked

I was the one that did the playerSendCommand, and it works, but because onMessageSend activates when the mod sends /locraw, sometimes it doesn't cancel the event, and I have yet to fix that correctly, which means that if other mods send the command, it should execute as a player had done it. I used it with DiscordRP and it doesn't seem to have any conflicts, I am not sure if DiscordRP set their priority higher, but it works as it should. And for the listening, I used it to try to make sure that it was the player sending it and not the mod sending it, which didn't work perfectly, not sure what was the original use of it as I am not the one that put that.

Is it possible to have different parts of a mod (uncompiled) send different priorities to
forge (compiled)? So if a mod needed locraw it could have a higher priority; or the cancelation feature could have a low priority

@ImRodry
Copy link

ImRodry commented Apr 7, 2021

That’s not needed, they just need to fix their checks which are already implemented

@vickensemerdjian
Copy link

That’s not needed, they just need to fix their checks which are already implemented

Why is it their problem?

@ImRodry
Copy link

ImRodry commented Apr 7, 2021

Because the check they tried to implement is broken and cancels the command completely, even if it’s ran by the user

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants