CreateDefaultInstance is broken

[tomgiagtz]

Had a bit of a headache trying to troubleshoot the new Data Binding feature, but finally found what was plaguing me. Using "Create Default Instance" returned a ViewModelInstance that I used everywhere, but was not properly bound to the view model I was rendering. By replacing it with Create Instance, everything began to work.

I'm not sure what's going on with this, but hopefully this can be changed to either work, or have a clearer name!

Thanks!

[Tod-Rive]

Thanks for the feedback and sorry for the trouble you had. We've been discussing the API names and they're still subject to change. I've also been going back and forth on having an "autobind" feature. Something that the other runtimes have implemented but I wasn't sure it fit the Unreal paradigm. Also, as a separate heads up, the API will likely change in an upcoming release; you'll bind to state machines rather than artboards.

Any thoughts on names that would make more sense here?

[tomgiagtz]

Thanks for the response! I'm actually still having issues with this. Using this Create Instance node allows me to bind to values in my ViewModel, but Nested ViewModels seem to be initialized with the wrong instances. Create Default Instance correctly creates the nested instances, but I can't bind to anything on that ViewModel (or it's Nested ViewModels).

This results in a pretty big discrepancy between what I'm seeing in the Editor and what happens when I set up a Rive Widget, at least while using Create Instance.

In regard to naming, I'll put on my System Design hat for a sec here:

One confusion for me here is that CreateInstance has exec pins but CreateDefaultInstance (and also CreateInstanceFromName) are pure functions (no exec pins). This hints that something happens for CreateInstance that isn't happening with the others.

I just looked at this in the Source and have no idea why this is the case, the signatures and functions are nearly identical ¯\(ツ)/¯

Is CreateInstance intended to use the default instance? If not what data is being used for that?
I'm just not clear on why I would ever use CreateInstance, when I can non-specifically use the default instance, or choose an instance by name. That would cover 100% of the ways I would want to set an instance, but maybe there's some use case I'm not aware of.

This is a bit more of a tangent, but some additional thoughts regarding my issues:

The SetViewModelInstance function implies to me that I should be able to do this for nested instances as well. In my case I have three Buttons that share a ViewModel. Those instances are set on the Instance of the parent ViewModel, but there's no clear way to change to a different instance from the .riv file, or create a new one at runtime and set it on the parent. I can only modify the ViewModel Instance that is created when I set the parent ViewModel.

Ideally I'd be able to get the nested artboard, create it's ViewModel instance, bind everything I need and then set that instance on the parent ViewModel

This isn't a huge issue right now, but since Lists are going to be added, I assume this functionality will be required for that, as I would want to add/remove Instances on a list to create something like a leaderboard.

I'm definitely still learning here, so if any of my assumptions are wrong, or if I need to reframe how I think about this, please let me know.

[Tod-Rive]

1. I did find a bug in the API that was preventing some of the CreateInstance calls from working. Version 0.3.7 of the plugin has the fix in place.

2. Swapping ViewModelInstances is in the works. I need to expose it in the plugin but it is on the way.

[tomgiagtz]

Fantastic, thanks for the update. I will close this, thanks for the hard work!