-
-
Notifications
You must be signed in to change notification settings - Fork 140
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
Add and integrate bone scanning for visibility checking and Implement the visibility check for non-silent Aimbot #75
Comments
Hi all, great news! It's done. 1. I finished implementing and testing a fast visibility check that is very accurate - I added the following to the CameraExtensions (Note the importance of the layer mask here):
2. And then I wrote a nearly perfect method for scanning and returning the best bone to target out of only the parts of the Player that is currently visible:
3. The above method uses a translation class I wrote that can accept the different Transform types (This is necessary because Transform and BifacialTransform do not share an interface or inheritance). So, this just simplifies the work needed to use the different types which represent the bones. Please note the comment about C# dynamic type, as it was tried and found not to be supported with the current EFT/AKI binaries - even with CSharp and ReflectionType libraries provided - which is why this simple class is so convoluted.
@sailro, I would very much appreciate if this could be implemented in the master branch. Also, if anyone would like please feel free to optimize these methods if you find a faster/simpler way to do something, I gave it my best effort. Lastly, you may notice how I strongly type all of my variables, I prefer it this way for readability but it has no runtime impact either way AFAIK. |
Could you show how you integrate this with the current code? |
Sure thing! Here is how my Update method looks like for the Aimbot class, which acquires the Vec3 target position 'target_pos' through usage of #GetBestVisibleBone. I'm still in the process of adding a FOV calculation so this will surely change, but I will document that as another enhancement soon:
Also, on another note, I like your improvement to the #NormalizeAngle that was included in the Aim smoothing enhancement! Looks good 👍 I'll try to get a fork up soon and keep it up to date w/ your Master branch since I plan on supporting only latest version EFT/AKI - making proper pull requests where applicable - and then that fork can act as an experimental features test bed if we'd like. |
I made some significant improvements to the visibility check that I will get up on Github here in the next few days. Basically I added another visibility check method that does as I originally planned - casts a ray with a magnitude of 90% - instead of line casting. I kept the original visibility check because it can be useful in other circumstances. Anyway, please disregard the above code and maybe I'll do an official pull request this time ;) |
Since it's been 8 days I think that's longer than ""in the next few days"" lol, so here is my complete source on visibility checks. I reconstructed IsPlayerBoneVisibile3 from looking at EFT source in dnSpy, it is too accurate sometimes and I think the layer masks need adjusted, otherwise it could be better than IsPlayerBoneVisible2...
|
So the best way is to avoid depending on those generated names (perhaps next time it will be Like I did here: https://github.com/sailro/EscapeFromTarkov-Trainer/blob/master/Features/Commands.cs#L138 |
Ah thanks for the tip, I'll look into this. |
Silent-aim is now using visibility check |
I updated this issue's title with respect to your latest additions. Now the two goals of this enhancement are as follows:
Example snippet of bone-scanning for visible transform, implemented and tested in earlier versions: PlayerBones bones = player.PlayerBones;
//Make a collection of target bones ordered by vitality (Head, Neck, Body, Pelvis, Upper Arms, Upper Legs)
IEnumerable<AimBone> target_bones = new AimBone[8] {
new AimBone(bones.Head),
new AimBone(bones.Neck),
new AimBone(bones.Spine1),
new AimBone(bones.Pelvis),
new AimBone(bones.Upperarms[0]),
new AimBone(bones.Upperarms[1]),
new AimBone(bones.LeftThigh1),
new AimBone(bones.RightThigh1)
}; //Used a hybrid AimBone class due to differing bone transform types with no mutual interface/inheritance
//LINQ is short and sweet but slows down execution due to the added overhead
//return target_bones.FirstOrDefault(bone => _camera.IsTransformVisible(bone.Position));
//Use foreach here instead since it is faster than LINQ and Aimbot needs to be optimized for speed
foreach (AimBone bone in target_bones)
if (_camera.IsTransformVisible(bone.Position))
return bone.Position; |
Updated this enhancement in respect to latest code changes and documented the current goals in comment #75.
Goals reference, as described in my update comment:
Old description:
The Aimbot should only acquire targets that are visible from your camera and not behind geometry. We already have a way to verify if a world position is within your viewport so now we need a way to verify the player is physically visible. The visibility check for a player object should ideally consider the best bone position but in the event that only part of the player is visible, such as a limb, then the visibility method should be capable of returning the best bone out of what is visible...If only a right arm and right leg are visible of a given player, the visibility check will return the best bone out of those visibly available which would be in this order as a general example : right upper arm > right thigh > right forearm.So, in conclusion the visibility check would return the upper arm first in this visibility case.
The visibility check should do a physics raycast check from the player's camera position (in the main thread) to the provided bone position to determine if there is any blocking geometry. If the raycast fails, then there is no geometry in the way. The distance the ray cast travels should be limited by a small degree so as to not collide with the geometry of armor or items that the potential target player is wearing (such as armor, weapon, backpack, vests, etc) since understandably this geometry will always be present.This design should suffice in 99% of cases to check for visibility, however the best 1:1 approach would be not to limit the ray cast's travel distance for checking geometry collision, and instead include player equipped items/armor as part of the potentially visible player component.I started working on this enhancement and still need to test/debug - I will be sure to post in this thread with any updates or successes.The text was updated successfully, but these errors were encountered: