Closed JackTheFoxOtter closed 1 month ago
Given that slot is automatically created / managed, it would probably be better that for your personal systems you provide your own non-persistent slot to store things as-needed, @JackTheFoxOtter.
I'm curious what the benefit of this is over creating your own slot.
The __TEMP slot is mostly used by stuff that the game manages behind the scenes, so it doesn't make a lot of sense to me why you'd want to put things in there and mix them with stuff that's managed by the game.
To me it seems that the opposite would be more desired. Having each creation use its own temporary slot means you can more easily identify what temporary items are being created in the world through the inspector if need-be. Since that slot would still be non-persistent, the management of it is very simple.
I mean, I don't mind creating one myself, I just though that's what the temp slot is intended for. Temporary effects. Like I could just create my own, but that adds a small bit of extra work on the creation's side. I feel like this would just be easier and fit into the systems more elegantly. Instead of managing my own temp slot, I can just copy it to the existing one that's guaranteed to always exist.
The big thing is that the world's temp slot is stationary, where if I would just create one inside of a creation it would move with the creation. So I'd have to make the creation create it's own temporary slot in a stationary place. It's not much extra work, but it feels unnecessary since the temp slot already exists on world level. If this not what it's intended for?
I don't think the __temp slot is always there, is it? I think it is dynamically created when needed.
Why not just make your own temp slot in root? It would be less prone to being randomly deleted / manipulated by the engine code.
As Cyro, and I previously mentioned above- it's a slot that's created and managed by Resonite when it's needed- if we want to talk about intent- it is prefaced by an underscore, which is the same naming convention we see on components that have managed properties that users aren't really expected to control / modify themselves, @JackTheFoxOtter.
But again- per previous questioning- what problem does that solution solve that couldn't just be solved just as well by purposefully making your own non-persistant storage slot for temporary effects from your system?
But again- per previous questioning- what problem does that solution solve that couldn't just be solved just as well by purposefully making your own non-persistant storage slot for temporary effects from your system?
It's less overhead on the creation's side. Otherwise you'd have to
And to do it robust, you'd probably also put in manual handling to ensure the slot gets checked for existance, if it doesn't exist recreate it, and that every time you want to parent an effect to it. You'd also need to make sure the slot is destroyed when you destroy the object that managed it, otherwise it would just be left behind as clutter.
What I've noticed many creations do is not bother and just make the effect itself non-persistent and parent it to user space. But then you end up with a lot of temporary effects potentially cluttering up the hierarchy, depending on how long they linger around.
I do think there's a lot of value in having a mechanism that simplifies this, and I think a good way would be a temporary slot that just gets created when it doesn't exist yet. For the engine that's the __temp
slot, so I was thinking of just re-using that for my own creations as well. If that's not allowed / intended, maybe a different way to provide a managed non-persistent slot reference that's auto-created when used somehow could be applicable here.
Seeking input from @Frooxius on the suitability of user-made systems making use of a world's existing temp slot as a scratch space for temporary effects, etc.
This isn't something I'd want to codify.
The "__temp" slot is not actually guaranteed to be in the world in the first place - it's just something that some systems add.
If we were to make it "official", we now have to worry about its usage and not breaking things that depend on it, which is a lot of additional burden to a system that wasn't designed for it from the ground up.
Generally you shouldn't worry super much about which slot you use - you can just mark any slot to be non-persistent - it doesn't even matter where it is. Simply marking it as non-persistent will effectively make it temporary.
Is your feature request related to a problem? Please describe.
Every world has a nonpersistent __temp slot that is very useful for parenting various temporary effects to them. There currently isn't a node to easily get a reference to that slot, the only way is using FindChildByName on the root slot.
Describe the solution you'd like
I'd like a node that outputs the slot reference of the current world's __temp slot, since that is often useful as a default parent for various temporary effects.
Describe alternatives you've considered
Searching for the slot, or parenting effects somewhere else. But since we have the __temp slot in every world already, why not use it?
Additional Context
No response
Requesters
Myself, Nordwick