Skip to content
This repository has been archived by the owner on Jul 1, 2020. It is now read-only.

Walking + Firing = Self Shooting #37

Open
9joshua opened this issue Jun 16, 2020 · 4 comments
Open

Walking + Firing = Self Shooting #37

9joshua opened this issue Jun 16, 2020 · 4 comments
Labels
Milestone

Comments

@9joshua
Copy link

9joshua commented Jun 16, 2020

If you walk forward and fire a weapon at the same time you shoot yourself. Is it possible to ignore the shooter when checking for hit objects or can the ray begin a bit further in front of the shooter?...

opt

@9joshua 9joshua changed the title Sprint + Firing = Self Shooting Walk + Firing = Self Shooting Jun 16, 2020
@9joshua 9joshua changed the title Walk + Firing = Self Shooting Walking + Firing = Self Shooting Jun 16, 2020
@ClobberXD ClobberXD added ⚙️ Mechanics Bug 🪲 Something isn't working properly High priority ❗ labels Jun 16, 2020
@ClobberXD ClobberXD added this to the v1.0.0 milestone Jun 16, 2020
@ClobberXD
Copy link
Owner

gunslinger/api.lua

Lines 61 to 67 in d20130a

-- pointer.intersection_normal is a zero vector
-- if ray originates from inside pointed_thing
if avoid_self and pthing and
vector.equals(pthing.intersection_normal, vector.new(0, 0, 0)) then
pthing = ray:next()
end
return pthing

The code already avoids the first pointed thing if the ray originates from within the pointed thing. Might it be possible that the ray encounters the same object again after skipping? That's highly unlikely...

Are you using the latest version (v0.24-pre) of Gunslinger?

@9joshua
Copy link
Author

9joshua commented Jun 16, 2020

I cloned from the master branch 3 days ago. My version contains the code you pasted above.
It only happens when walking forward so maybe due to lag from the time the check is done to when it continues to trace?

@ClobberXD
Copy link
Owner

ClobberXD commented Jun 17, 2020

From the API docs:

The map is loaded as the ray advances. If the map is modified after the
Raycast is created, the changes may or may not have an effect on the object.

This means that unless the Raycast object is re-created, it shouldn't detect the same player again and again. But there is a possibility of the ray originating from outside of the shooter's collision box due to lag (is this what you were saying?), which means the code linked in the previous post will not detect the player properly. Ideally, it's better to explicitly check for the player; I wanted to avoid string comparisons as they're computationally expensive. I'll see if there's a better way to check if an object corresponds to the shooter themselves.

@9joshua
Copy link
Author

9joshua commented Jun 18, 2020

Yes, I think it could be due to lag from the time the ray is initiated to when the player moves forward and the ray progresses.

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

No branches or pull requests

2 participants