I make sim shooters which use laser tracking equipment and software, so my problem is that the laser gun has a 100 millisecond delay from the laser gun to mouse click which is the raycast. So it makes it a little difficult when shooting moving targets as the lag will cause this to register the shot a few frames after(depending on fps). is there a way I can compensate this shot delay with a trailing hit collider with some code detecting where the transform of the collider was 100milseconds ago?
100ms seems way to long for that. Could you post the script?
Have you checked the profiler? Is there other stuff running at the same time?
Have you tried to work with different layer?
Sorry , I should of clarified ,the laser gun is a physical device that is linked to a laser tracking device that plugs into the users machine. So when the gun is shot it registers a mouse click but its 100 a millisecond from the trigger to mouse click so was wondering if there was a way to compensate the moving targets collider but seeing where the position was 100 milliseconds ago
If you have a consistent delay of 100ms, you could put in historical position tracking on the targets, and then instead of using their current position use their position enough frames ago to be 100ms or so. I would start with a simple 10 to 20 array of positions combined with time, then cycle through them round-robin fashion until you find the one that is 100ms old or so. Or you could just hard-wire it to an array of N of them, assuming your frame rate is steady enough.
Thanks for this, do you think this cause issues on physics based movement? As some targets are attached by joints and dictated by gravity, we have target stand with 6 arms if you shoot one target off the arm it will spin in the direction the weight is leaning towards
I’m suggesting simply recording the per-object positions in a historical position array, so if you are only copying out positions to that array, and using those copied positions for your hit comparison, it should not involve physics in any way. From the perspective of those positions, they don’t care how they came to be.
Before you go too far, have you checked the delay is constant on multiple pcs? Just in case the delay is only present on your pc due to an unrelated issue and that the delay is constant. If there is a varied delay on different machines, you may need to create a calibration method such as the audio delay calibration in some rhythm-based games.
Yep, its consistent with all machines. As the 100ms day is between the laser gun trigger being fired then sending that trigger to mouse click so I have to make that compensation due to it being a outside influence of unity
If you wanted to go crazy with this, you could come up with a system sort of like what @Kurt-Dekker was suggesting but go even further. Keep a historical list of previous positions but also rotations, of everything the player may shoot at. When someone fires the laser device you could then place a representation of all these objects in their 100ms old position/rotation with colliders attached but on a separate physics layer which won’t interact with the rest of the scene - I’d make these actually a separate object which the player can’t actually see in game but just has colliders attached. You’d have to configure everything correctly so they don’t interact. Then you do your raycast against just this 1 physics layer, so it should only hit objects where they were 100ms ago.
You could continually have these “phantom” 100ms behind objects always following the main objects each frame, or you could immediately place them when detecting the laser device firing. Not sure which way would perform better.
If the delay is really ONLY on the “click” and not on the laser’s position, then you wouldn’t need to save the locations of everything, you could just check every frame what the laser is pointing at and save that.
(But I have a hard time imagining why there would be a hardware delay on the click and not on the pointer…)
So customers set up are from laptop to projector and thats how they all set up because the laser driver receives & process all the information from the tracking and the gun it creates a 100ms delay to process then send to mouse click once the trigger is pulled
The solution that @Antistone is going to be a lot easier to implement, and computationally a hell of a lot cheaper. Check what the pointer is over every 100ms, and when you get the “mouse click”, check what the mouse was over 100ms ago.
It’s also going to give better results - you’ll be hitting what the player was pointing at when they hit the trigger, instead of hitting what was where they’re pointing right now 100 ms ago.
Unfortunately the laser is only fired off when the trigger is pulled so it teleports the mouse from its last position as I did ask my client who supplies and distributes confirmed that this was the case as I was thinking of this option.
Oh, you don’t get the position the laser is pointing in when it’s not getting fired?
That’s… bad! But you’ll have to work with it. In that case the “keep track of the positions of all the things you might hit” is the way to go.
