Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Episode 3] When COMs use Teleporters, they can attack as if they were still standing on the entrance's tile #127

Open
SparkeeLecaro opened this issue Sep 15, 2023 · 1 comment

Comments

@SparkeeLecaro
Copy link

As a forewarning: I haven't properly tested this offline, so this could actually be official behavior, but I wanted to post this as I continued testing in case the solution winds up being something very simple.

image

In this picture, Guykild took the purple teleporter (on the left), which moved him to the exit on the other side of the fences. He then attacked a Hildebear with a Handgun, as if he hadn't taken the teleporter and was still adjacent to the enemy. Another active player and I were initially blindsided by this quirk a few days ago on the Simulator map, but weren't sure what caused it until we noticed it happen again here.

We experimented with the map a bit in the same match (the Guykild COM wasn't attacking us much anyway) and were able to find that players can't perform the odd behavior; only COMs can. As of now, my current file doesn't have all of the maps unlocked in Free Battle, so I'm going to push on through the story until I unlock Dolor Odor, which should serve as a decent and controllable testing ground. I don't think this is map-specific, because I've seen it happen on both Molae Venti and Simulator, but I haven't tested it elsewhere as of now.

@fuzziqersoftware
Copy link
Owner

This is an interesting find, and due to only COMs being able to do it, it seems hard to reliably reproduce the issue. (This wouldn't be the only time COMs send invalid requests though - they often try to move into occupied tiles or play item/creature cards when they already have too many on the field.) I looked over the logic, and it seems that there are no range checks at all when the server accepts an attack request from the client; it just trusts that the target IDs sent by the client are all within the appropriate range. I suspect this bug also occurs offline; I'm still going to fix it, but I'll leave an option to disable the fix since it looks like that would be closer to the original behavior.

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

No branches or pull requests

2 participants