Yellow-Dog-Man
Cloud Spawning with Protoflux Node
Is your feature request related to a problem? Please describe.
Lack of a method for dynamic object spawning from the cloud.
Describe the solution you'd like
Introduce a "Protoflux Node" with the following specifications:
Inputs: Impulse: Triggers object spawn, Record URL, Parent Slot
Outputs: Spawned Impulse: Indicates successful object spawn. Failed Impulse: Indicates unsuccessful spawn attempt. Object Slot: Reference to the spawned object for further interactions.
Describe alternatives you've considered
Currently, objects must be kept inactive in the World/Avatar and activated/dublicated as needed. This approach is less efficient and flexible compared to dynamic spawning.
Additional Context
No response
Would likely pair well with #417, allowing to spawn small objects dynamically / keeping them linked together somehow
Just FYI, this is already possible, albeit a bit difficult to setup. However you can simply copy an existing setup like the one Ukilop created for redprint cloud spawning: resrec:///U-ukilop/R-84c8f0ed-203d-43a8-b199-a6d42eae4d1f
Don't know why there isn't more attention on this, but I want to note, @ProbablePrime said something to the effect that this is a planned feature.
It would probably be good to talk a bit more about this right now.
Currently, the workaround (which uses ref hacking to proxy a user's menu input) is not advised by the developers, and presents a problem where the object spawns in front of whoever triggered the code and doesn't have a way to grab the slot or otherwise mess with the location. If I were to give outputs for this, the most important one would be the slot itself, so that it can be moved and reparented when it gets spawned. At that point the only input necessary would be the URI.
That said, I would also appreciate the ability to give it a slot to initially parent under.
I also think this may have to be an asynchronous node, seeing as it involves looking up an item URI within the cloud DB, though it's also possible this can be done by just making a slot, giving the slot ID, and letting the load process run in the background, then putting whatever needs to be put in that slot into it.
You can read about why it might not be getting more attention here: https://github.com/Yellow-Dog-Man/Resonite-Issues/blob/main/HOW_WE_PRIORITIZE.md
From my perspective, there are hundreds of issues that Im trying to tackle simultaneously right now.
Don't know why there isn't more attention on this, but I want to note, @ProbablePrime said something to the effect that this is a planned feature.
It would probably be good to talk a bit more about this right now.
Currently, the workaround (which uses ref hacking to proxy a user's menu input) is not advised by the developers, and presents a problem where the object spawns in front of whoever triggered the code and doesn't have a way to grab the slot or otherwise mess with the location. If I were to give outputs for this, the most important one would be the slot itself, so that it can be moved and reparented when it gets spawned. At that point the only input necessary would be the URI.
That said, I would also appreciate the ability to give it a slot to initially parent under.
I also think this may have to be an asynchronous node, seeing as it involves looking up an item URI within the cloud DB, though it's also possible this can be done by just making a slot, giving the slot ID, and letting the load process run in the background, then putting whatever needs to be put in that slot into it.
How does the refhacking method even work. Ive never heard of anyone using refhacking to cloudspawn
Putting my vote here for officially supported cloudspawning, or at least inventory spawning (to support our protected asset spawning)
Im not smart enough to understand the complexity of programming, but if there was a way to cloudspawn something locked only through your userID, and it checks if that userID is present in the world - would that help with security? So literally only the person who saved it is the person who can spawn it? Kinda like a SimpleAvatarProtection addon?
The mechanism is likely going to be based around records - those are the way stuff is saved and loaded in Resonite from the cloud. They provide security mechanisms on access and other metadata, so we can build around them.
I'm happy to use records if it works with protoflux. The resdb think is only workaround i would love to get ride of.
This would be a very useful feature. For avatar modularity for performance reasons and other things. Such as initial load of an avatar and download.
cloudspawning with records and components and protoflux would be nice yea lots of things alredy use it like devtips and avatar auto equips etc
Considering the current use of resdb and resrec links, having an official implementation to cloudspawn items does sounds great
One of the things that's missing from the current cloudspawn workaround is an easy way to get a reference of the spawned item. For proper cloudspawning, if it's not already being considered, I'd like to add that to the list of proposed features.
I use cloud spawn to spawn the default Resonite tools, since we can somewhat do that in desktop mode, being able to do that in VR would be nice from my context menu.
Also something when working to pop out of your avatar into a Head and Hands avatar to work on it, then when you jump back into your avatar the cloud spawned avatar is destroyed.
And other random stuff instead of needing to dig around my inventory trying to find something:
I use cloud spawn to spawn the default Resonite tools, since we can somewhat do that in desktop mode, being able to do that in VR would be nice from my context menu.
Also something when working to pop out of your avatar into a Head and Hands avatar to work on it, then when you jump back into your avatar the cloud spawned avatar is destroyed.
And other random stuff instead of needing to dig around my inventory trying to find something:
for anyone wondering you can get this sytem from Zaravi's Public (resrec:///U-Zaravi/R-c6a1fd6a-58d3-4805-8ace-96f435bceb15) Under Zaravi's Tool -> Cloud Spawn
one other thing to be concidered is that i feel having a component would also be needed. cause having to have a button event then cloudspawn node in protoflux for every one of your like 20 buttons would just be an absolute pain in the arse. having a button event cloudspawn would be hella good for the sake of simplicity in most peoples case as 9 time out of 10 i think most people are just throwing them on context menus
one other thing to be concidered is that i feel having a component would also be needed. cause having to have a button event then cloudspawn node in protoflux for every one of your like 20 buttons would just be an absolute pain in the arse. having a button event cloudspawn would be hella good for the sake of simplicity in most peoples case as 9 time out of 10 i think most people are just throwing them on context menus
Radial menu buttons are the baseline, but often people do "simmon action" events. (Example: IfOnGround False > FireOnTrue > Spawn 'Wings'. Or another being ThumbpadPress > FireOnTrue > Spawn 'Tool'.) So having both abilities would be good, because being limited to radial menu only would bulk up the menus fast. I hope we get both.
Oh yeah, I'm not saying do only a component in saying do a component and node like dynamic impulses
I want to note that, currently, one of the biggest problems with cloud spawning is that if The person who shared the item deletes it from their inventory, it breaks every instance of trying to spawn it. This is obviously intended behavior, because it shouldn't even be held on the servers at that point, but it creates a problem in places like the avatar station.
Currently, the method in the Avatar Station is to find it in a public folder, use the link to the item in the public folder to spawn it, and leave the public folder there as a backup. This works pretty well, but the spawn button breaks whenever an avatar Creator uploads a new version of the Avatar and deletes the old one: there is a copy of it there, but it's not The one that's being linked to.
The immediate solution I would give is being able to name items with some sort of custom ID, So if the item is replaced with a different one and deleted, changing that ID to point to that other one fix all of the references to that ID. This would also mitigate the security concern of people spawning items out of other people's inventory when they aren't supposed to, simply because only the person who owns an item should be able to point an ID they made at it. It also gets rid of the main drawback of the currently possible method of just using cloud variables to point at the URI, because that quickly becomes unfeasible with larger sets like in the Avatar Station, because you simply don't have enough cloud variables for it.
Using an ID system, where things are spawned using IDs that have been explicitly pointed at them by the owner, might be the best way to go with this.
That's not really a problem we'd be addressing with the cloud spawning itself - at least I strongly discourage from linking it to this, because it makes the issue "bigger", meaning it'll now have a whole bunch of other features associated with it, making it harder to prioritize. These should be separate problems.
In a way, that's mostly to do with lifecycle management of whatever you're spawning. If you don't own what you're spawning, then you're at whims of whoever does - if they delete it, it's gone. If you don't want it deleted - save your own copy that you control. We can't control what people do with their own data.
The system already has ID's - each item/world is represented by a record, which has an ID that's used to spawn it - it's all about who owns the ID and what they do with it. Introducing yet another ID doesn't solve that problem - it just moves it to it. If that person replaces or deletes that ID - you're back when you started.
There's already mechanisms to prevent spawning stuff that people shouldn't - you can only do that if the record is set to public. Setting it to Private will prevent the spawning from happening. I don't think we need to be introducing another system for that - people need to utilize existing tools if they run into that problem.
ive heard rumors that the backend can version inventory items like worlds, if true could we maybe get one more incrimental edit to the inventory before the full rework to add the ability to update inventory items? that way cloudspawning could just continue working with the new nodes and such without having to update url's (tho most of the time i use a cloudvar Uri type so i dont have to tell everyone i made an incrimental change to one of my items)
Yes, both worlds and items use the exact same mechanism. It's just matter of UI.
That's why this should be separate issue - with inventory UI rework you could update items in-place.
If you really want cloud spawning to come with this functionality, it means we need to prioritize Inventory UI rework first. Which means it'll take a lot longer. So I don't think it's a good idea to tie it into this.
for those wondering https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1119
If cloud the spawning node could take advantage of being able to perform lookup by name with resrecs that already exists that would probably be good enough imo
That might be a good approach. We already use that for certain spawn things, so they're not tied to particular ID.
for anyone wondering you can get this sytem from Zaravi's Public (resrec:///U-Zaravi/R-c6a1fd6a-58d3-4805-8ace-96f435bceb15) Under Zaravi's Tool -> Cloud Spawn
I've updated mine so it spawns the new tools from the Resonite Essentials, as the one in Zaravi has some older resdb links.