Add SnapPath

[squidt]

Extends from SnapZone and allows the user to specify a Path3D to which PickableObjects will be snapped. Snapping is done by creating a temporary SnapZone in-script along the closest point of the Path3D node. This temporary SnapZone is freed once the PickableObject is taken from the rail. Make snapping discrete with the "snap_interval", the distance between snaps in Meters.

[DigitalN8m4r3]

hmm, this looks really interesting... most def gotta check this out, i wonder at the same time if this could be adapted for more usecases such as slideable grabpoints which go along the line of the path and slideable magazines for firearms etc. aynways, needs testing and as i can see there is no actual demo that comes with it? you may want to add that so that the idea and functionality can be tested

[DigitalN8m4r3]

Extends from SnapZone and allows the user to specify a Path3D to which PickableObjects will be snapped. Snapping is done by creating a temporary SnapZone in-script along the closest point of the Path3D node. This temporary SnapZone is freed once the PickableObject is taken from the rail. Make snapping discrete with the "snap_interval", the distance between snaps in Meters.

sorry but i just fail to get this working, could it be that something is missing or am i just not figuring this out the way its supposed to be...

[squidt]

sorry but i just fail to get this working, could it be that something is missing or am i just not figuring this out the way its supposed to be...

I'll work on adding a demo right away

[DigitalN8m4r3]

just tested the updated version, lookin good for me @Malcolmnixon you might want to give it a spin, it is a nice addition @squidt not sure if you are interested but maybe you can follow up on my initial message regarding the expansion of this, anyways good work there!

[squidt]

I accidentally made all these commits using 4.3.stable and I just noticed the repo is using 4.2 in the .project so they might not work for that version. "Parse Error: Saved with newer project format version". I'll try to fix that. @DigitalN8m4r3 I have been interested in making an InteractablePath for objects like sniper bolts. I might work on that or something like a SnapArea that Pickables can 'float' in like many VR games have for backpacks.

[squidt]

XRToolsPathGuide uses a Marker3D to define a length for XRToolsSnapPath to use so it can place the object fully on the path with no overhanging. Example added to the PicatinnyScope. The next feature I plan on adding would be using a pickable's existing collision shape as the shape used to pick it up off the rail instead of a circle that might be offset or wrongly sized. I believe there is a way to do that in-code, I'll try it later.

[DigitalN8m4r3]

XRToolsPathGuide uses a Marker3D to define a length for XRToolsSnapPath to use so it can place the object fully on the path with no overhanging. Example added to the PicatinnyScope. The next feature I plan on adding would be using a pickable's existing collision shape as the shape used to pick it up off the rail instead of a circle that might be offset or wrongly sized. I believe there is a way to do that in-code, I'll try it later.

any Chance of expqndong this to a optional enforcing to use the furthest point along a predefined axis/ selectable from x,y,z and if not reaching the closest point(closest to the pickable) = drop instead of snap. This could be useful for snapable mags.

[squidt]

any Chance of expqndong this to a optional enforcing to use the furthest point along a predefined axis/ selectable from x,y,z and if not reaching the closest point(closest to the pickable) = drop instead of snap. This could be useful for snapable mags.

Sorry I don't understand the question. I would like to make a solution for all the different types of magazines but that would be more appropriate to the 'interactable' classes where the user is driving a motion, then upon reaching the end the magazine is inserted. Examples such as an AK magazine where you have to rock it in, or a bolt handle you have to pull up to unlock before pulling back. I'll try to come up with a solution for that but it'll likely end up in a different pull request using a new class, where the final example may combine classes in the node tree to get a desired effect.

[DigitalN8m4r3]

any Chance of expqndong this to a optional enforcing to use the furthest point along a predefined axis/ selectable from x,y,z and if not reaching the closest point(closest to the pickable) = drop instead of snap. This could be useful for snapable mags.

Sorry I don't understand the question. I would like to make a solution for all the different types of magazines but that would be more appropriate to the 'interactable' classes where the user is driving a motion, then upon reaching the end the magazine is inserted. Examples such as an AK magazine where you have to rock it in, or a bolt handle you have to pull up to unlock before pulling back. I'll try to come up with a solution for that but it'll likely end up in a different pull request using a new class, where the final example may combine classes in the node tree to get a desired effect.

Aah this is true, sorry that i bothered you but indeed your theoretical approach would be way better. Anyways thanks for sharing your work and am lookin forward to testing it 😀

[squidt]

Aah this is true, sorry that i bothered you but indeed your theoretical approach would be way better. Anyways thanks for sharing your work and am lookin forward to testing it 😀

No worries you didn't bother me at all! It's gonna be fun seeing what can be done.

[squidt]

I just found out about gdlint and installed it. I'll make a commit to fix whatever it brings up.

[squidt]

any Chance of expqndong this to a optional enforcing to use the furthest point along a predefined axis/ selectable from x,y,z and if not reaching the closest point(closest to the pickable) = drop instead of snap. This could be useful for snapable mags.

I think I know what you mean by this now. Something like: A magazine path where the user brings a magazine close and it attaches to the path while close enough and still grabbed. The user then has to insert it fully to snap it or else 'when dropped' it will slide out/ fall. It sounds possible with the current classes I might work on making an example.

I'm experimenting more with the 'interactable' classes. I was able to make a charging handle that can be slid back until the end then tilted up to be locked. I could make a PR request implementing that for the sniper rifle but I did it with a custom slider class and a couple changes to the source of those classes.

It'll just depend on what I work on next, I've been prototyping a game with this plugin and I'll be trying to bring back any improvements or examples I find useful.

[DigitalN8m4r3]

any Chance of expqndong this to a optional enforcing to use the furthest point along a predefined axis/ selectable from x,y,z and if not reaching the closest point(closest to the pickable) = drop instead of snap. This could be useful for snapable mags.

I think I know what you mean by this now. Something like: A magazine path where the user brings a magazine close and it attaches to the path while close enough and still grabbed. The user then has to insert it fully to snap it or else 'when dropped' it will slide out/ fall. It sounds possible with the current classes I might work on making an example.

I'm experimenting more with the 'interactable' classes. I was able to make a charging handle that can be slid back until the end then tilted up to be locked. I could make a PR request implementing that for the sniper rifle but I did it with a custom slider class and a couple changes to the source of those classes.

It'll just depend on what I work on next, I've been prototyping a game with this plugin and I'll be trying to bring back any improvements or examples I find useful.

Am sure this would be welcome, especialy since we are approaching the end of xr tools 1, v2 most probably wont include much thirdparty game specific stuff (i might be wrong but thats what i imagined from reading about it)

So yes, please go ahead if your solution works better then mine, am happy with mine getting ditched in favor of something more robust

[squidt]

So yes, please go ahead if your solution works better then mine, am happy with mine getting ditched in favor of something more robust

Thanks! it will be a breaking change but hopefully it ends up working better. The idea behind the custom slider is that the user can rotate the slider node with the Editor's rotation gizmos and using a 'private Transform3D' we save an origin point and rotation whenever there is a transform change from non-interactable-driven-behavior. Then the slider always slides 'back' from however its been rotated. So far I have it working for the slider and hinge.

The benefits are that there's no more SliderOrigin HingeOrigin nodes required, and the setup feels more intuitive from a user perspective, rotating the slider node into place rather than changing the surrounding nodes to line up with slider behavior. I'll make a branch later this week and a PR when it's got all the parts together.

[DigitalN8m4r3]

So yes, please go ahead if your solution works better then mine, am happy with mine getting ditched in favor of something more robust

Thanks! it will be a breaking change but hopefully it ends up working better. The idea behind the custom slider is that the user can rotate the slider node with the Editor's rotation gizmos and using a 'private Transform3D' we save an origin point and rotation whenever there is a transform change from non-interactable-driven-behavior. Then the slider always slides 'back' from however its been rotated. So far I have it working for the slider and hinge.

The benefits are that there's no more SliderOrigin HingeOrigin nodes required, and the setup feels more intuitive from a user perspective, rotating the slider node into place rather than changing the surrounding nodes to line up with slider behavior. I'll make a branch later this week and a PR when it's got all the parts together.

cant wait to check it out, its possible that it will need readjustment after the following pr get merged #585

[DigitalN8m4r3]

@squidt this one has like nothing to do with the above but would be a interesting thing.

So bare with me as this is all just smoke and mirror theory about Stabbing, as in moving an object forcefully towards a body. Upon impact , taking the velocity into account and the bodys physical attributes as in is it heavy/medium/soft to determine how much force/Power = velocity is needed to penetrate the body.

Am thinking about using a path based solution to snap the pickable upon penetration inside the body while still being able to hold the pickable but using the physical attributes to determine how easy or hard it is to move the pickable out/further out/in the body. Now the last part might be earliest possible once we get weight feel implemented into xr tools but the rest might verry well be already doable.

Not sure when but i would love to try my hands at it just thought i would ask you about your opinion and maybe its something you already have thought about. Btw you should be on the discord, would make it easier to annoy you! 😉

[squidt]

@DigitalN8m4r3 Yea I could see that, we just need some way to keep a grab active while attaching to a path or an interactable then you can do so much including that. I'm in the mux213 discord in general chat as 'squid' if you wanna bother feel free, or the official godot discord.

[BastiaanOlij]

Malcolm unfortunately is currently swamped with work, I don't want to leave this as this is good work. We can always improve on it later. So I am merging this.