Unity advanced use: Loading all UI at runtime from external source
Posted: 21 Feb 2023, 00:34
Hi there,
We have a fairly advanced use case where, to enable robust mod support we're building our game using as close to the same process as we envision modders will also use (highly modular design, loading and converting assets at runtime from external locations, etc... etc...). The way we're planning for this is to not have any of these dynamic assets be directly assets in Unity itself, but probably streaming assets for our build (and subfolders in a /mods directory for modders).
Modders (and by extension us) should be able to modify existing UI via XAML manipulation (adding, editing, etc..) and/or add entirely new UI elements and their own custom user controls using blend or any other text editor, without having to use Unity itself in any way.
Modifying XML/XAML in memory before loading it is itself not a problem, generally speaking (there's a few different standards for manipulating XML based stuff in memory and then loading that). I have read here on the forums that things like dependencies won't work this way (using LoadXAML/ParseXAML) and am not sure if that's still the case, and if it is how that could be resolved.
My questions are,
Is this possible with Noesis?
If so what is the best way to go about reaching this goal using Noesis?
If dependencies can't be resolved automatically, is there some way to do this manually?
-----
Supplemental Info
It might make more sense if I give a use case for kind of how we expect to be able to do these things.
Modifying existing:
The user would create a diff XML file following https://www.rfc-editor.org/rfc/rfc5261, at runtime our app would load the original in memory (probably via System.XML) and then iterate through all mod folders, patching the XML/XAML as needed and then load that result as the final UI XAML. The existing might be our MainView.XAML of any of the user controls we're creating.
Creating New:
User would use blend or whatever other tools they desire to create their custom user controls, along with creating and compiling an assembly for the accompanying code (to be loaded at runtime by us). They would diff in (see above) their user control so that it appears where they want it (for example, appending their new user control to the end of a list view or whatever to have their new menu button appear in game).
We have a fairly advanced use case where, to enable robust mod support we're building our game using as close to the same process as we envision modders will also use (highly modular design, loading and converting assets at runtime from external locations, etc... etc...). The way we're planning for this is to not have any of these dynamic assets be directly assets in Unity itself, but probably streaming assets for our build (and subfolders in a /mods directory for modders).
Modders (and by extension us) should be able to modify existing UI via XAML manipulation (adding, editing, etc..) and/or add entirely new UI elements and their own custom user controls using blend or any other text editor, without having to use Unity itself in any way.
Modifying XML/XAML in memory before loading it is itself not a problem, generally speaking (there's a few different standards for manipulating XML based stuff in memory and then loading that). I have read here on the forums that things like dependencies won't work this way (using LoadXAML/ParseXAML) and am not sure if that's still the case, and if it is how that could be resolved.
My questions are,
Is this possible with Noesis?
If so what is the best way to go about reaching this goal using Noesis?
If dependencies can't be resolved automatically, is there some way to do this manually?
-----
Supplemental Info
It might make more sense if I give a use case for kind of how we expect to be able to do these things.
Modifying existing:
The user would create a diff XML file following https://www.rfc-editor.org/rfc/rfc5261, at runtime our app would load the original in memory (probably via System.XML) and then iterate through all mod folders, patching the XML/XAML as needed and then load that result as the final UI XAML. The existing might be our MainView.XAML of any of the user controls we're creating.
Creating New:
User would use blend or whatever other tools they desire to create their custom user controls, along with creating and compiling an assembly for the accompanying code (to be loaded at runtime by us). They would diff in (see above) their user control so that it appears where they want it (for example, appending their new user control to the end of a list view or whatever to have their new menu button appear in game).