Completed (1.20.1.6) Triggers can't reference atoms if they are not in the same subscene
- Thread starter Spacedog
- Start date
Actually this may be a bug with VAM. I removed an atom from a subscene and it seemed to have broken VAM's ability to reference it. I will investigate and put in a bug report if needed.
After some further testing this seems to be a VAM limitation. I can set up a trigger in a subscene that references another atom not in the same subscene and it works fine, but it gives an error when I try to save the subscene.
This pretty much kills all my plans to use subscenes, I really hope this limitation can be resolved!
This pretty much kills all my plans to use subscenes, I really hope this limitation can be resolved!
As mentioned in our conversation, this is intentional. Having a SubScene reference that is outside of what is in the SubScene doesn't make a lot of sense otherwise that SubScene could only be used in other Scene/SubScenes that contain those exact references. If you tried to load that SubScene with an external reference it would result in the trigger not referencing anything.
Think of SubScenes as self-contained objects that you can build upon. They can be put into other SubScenes that "glue" pieces together using triggers/links/etc.
Think of SubScenes as self-contained objects that you can build upon. They can be put into other SubScenes that "glue" pieces together using triggers/links/etc.
Unfortunately I tried your suggestion of putting the subscene in a root subscene but it gave the same error.
I have my UI as a subscene so it can be modified without loading the rest of the scene but it won't let me trigger anything outside even if they share the same root subscene.
I understand why you'd want subscenes to be self contained but it really limits their potential, I know exactly what atoms will be in the scene when a trigger is called and if it isn't then that would be on me.
I have my UI as a subscene so it can be modified without loading the rest of the scene but it won't let me trigger anything outside even if they share the same root subscene.
I understand why you'd want subscenes to be self contained but it really limits their potential, I know exactly what atoms will be in the scene when a trigger is called and if it isn't then that would be on me.
I have added the ability to save triggers that have external refs. The warning will still be issued, and the triggers will only work if loaded into a compatible scene:
trello.com
Will be out in 1.20.1.6 (I might call it 1.20.2 as I added quite a bit of new features to the release)
Trello
Organize anything, together. Trello is a collaboration tool that organizes your projects into boards. In one glance, know what's being worked on, who's working on what, and where something is in a process.
Will be out in 1.20.1.6 (I might call it 1.20.2 as I added quite a bit of new features to the release)
Thank you Meshed, I really appreciate it!
@meshedvr I have made a discovery!
The tickbox in the SubScene atom "Auto load on parent subscene restore" is a bit confusingly named but this is what I was after, it lets my put my UI at the root of the scene to be parent of everything and independently update it and other SubScenes. I *think* I am able to do what I want now.
So long story short if you want to preserve the purity of the SubScene system then please feel free to revert this change.
In fact it may now be better that way as when I am porting my old scenes over it would wipe out unneeded entries as I go instead of leaving them.
The tickbox in the SubScene atom "Auto load on parent subscene restore" is a bit confusingly named but this is what I was after, it lets my put my UI at the root of the scene to be parent of everything and independently update it and other SubScenes. I *think* I am able to do what I want now.
So long story short if you want to preserve the purity of the SubScene system then please feel free to revert this change.
In fact it may now be better that way as when I am porting my old scenes over it would wipe out unneeded entries as I go instead of leaving them.
Glad you found a way to do what you want, but after consideration there is really no penalty to add the feature I added, and it could be pretty useful if you have a UI SubScene you want to automatically glue to any scene or SubScene that contains specific atom arrangement. I could see making a Person UI control panel that would work as long as the person atom was named Person.
For future SubScene stuff in 2.X I'll likely add more of this "glue" idea that was originally supposed to be part of the Scene Wizard. Basically glue was meant to connect SubScene pieces together to allow them to interact. Part of that may be connecting triggers and links from an abstract name to a specific name. There could also be auto-glue in the case where there is only 1 instance of an atom type.
For future SubScene stuff in 2.X I'll likely add more of this "glue" idea that was originally supposed to be part of the Scene Wizard. Basically glue was meant to connect SubScene pieces together to allow them to interact. Part of that may be connecting triggers and links from an abstract name to a specific name. There could also be auto-glue in the case where there is only 1 instance of an atom type.
Great!
Are you going to keep the warning message? It seems a bit redundant in that case.
Are you going to keep the warning message? It seems a bit redundant in that case.
Yes - the warning is important because it signals something in your SubScene is externally connected which in most cases is not desirable.
It seems I spoke too soon anyway, I thought the trigger issue was parenting but it seems to be anything outside the subscene regardless of parent. Looking forward to the next release 
