For Defer, it'd be whichever one you called

.borrow()

on first, get's the lock, and then if you called

.borrow()

on the second one without dropping the first one, it'd panic.

So it'd be kind of a lazy, runtime checked version of

ParamSets

.

Syncing manually is how we have it today.

It's that think where you have to call

collision_world.set_pos(entity, pos)

or whatever the function was called.

Which is a little annoying/easy to miss, and I'm pretty sure you actually ran into that when working the Musket or something.

Yes I actually did lol I was thinking we have a continuous system that auto updates for us, but that might be harder

Yeah, I don't think that quite works, because it can't quite be truly continuous ( it'd have to run at some point while other systems aren't running ), and you might change the transform of a component in your system, and then immediately check if it it's new position causes it to have a collision, without any chance to sync in between.

not familiar with bones codebase yet but is it possible to add a sync point after all movements are applied then have the collision world do its collision detection stuff after that so you are guaranteed that there has been a sync?

Yeah, you could stick a sync point in a stage, similar to the

GlobalTransform

sync in Bevy, and also have the freedom to insert that sync system wherever you wanted to do it extra times before certain systems.

Which, you can do in Bevy, too. So I guess it's really just the same as

GlobalTransform

in bevy.

I think if we treat it as global transform and sync then it could resolve itself. The issue might be finding the correct stage to do the sync.

I'll try that out. I'll add a new stage for syncing the collision positions, while still allowing you to manually update the cached collider position if desired.

I think I've almost solved it, I just needed to apply the "if velocity drops below a certain value, and the item is on the ground, just set it's ( y ) velocity to zero".

friction worked??

Not friction exactly, but the movement threshold. And it was your friction suggestion that pointed me in the right direction. :)

Awesome possum!

Collective imagination at work! ✨

zick i pushed up the from world changes you requested. ATM we cant return

self.resources.get().borrow

because its returning a reference to a field. I am about to head to dinner so i didnt have time to really dive in, but it might not be possible with how we are doing resources

Cool, I'll merge what we've got now, then if I get the chance I'll take a peek at the issues returning a borrow.

docs should be fixed now: https://github.com/fishfolk/bones/pull/92

https://assetstore.unity.com/packages/tools/particles-effects/feel-183370 https://feel.moremountains.com This kind of thing would be a very natural extension of Bones, based on the work of @legendiguess and other juicers.

> Feel is a solution to provide on-demand game feel to your Unity game, with as little friction or setup as possible. It's modular, user friendly, and very easy to extend and build upon. > > Packed with more than 100 feedbacks, it'll let you easily trigger screenshakes, animate transforms, play with sounds, cameras, particles, physics, post processing, text, shaders, time, UI, and so much more.

Ah, yeah.

@Zick do you want the sync time system to exist within bones_bevy_renderer?

Yep, that seems right.

So that logically the rendering backends are responsible both for providing the inputs defined in

bevy_input

and rendering the output types from

bevy_render

.

I think it makes sense, but let me know if you ever have different ideas. :D

Okay merged bones_time into input and then moved the system into bevy_renderer. https://github.com/fishfolk/bones/pull/95

Thanks! I left just a few minor comments.

It's really nice feeling like we can invest in bones, and know that we can use it in other games, not just Jumpy. :)