-
- oversymbol
- Posts: 2
- Joined:
Intended architecture for a Noesis Studio + UE5.7 project
Good evening
I've just started tinkering with Noesis Studio in UE 5.7 and there's one main thing I'm wondering with regards to intended project architecture that I'd love hearing your thoughts about.
At the moment, the action phase of this game project I'm using Noesis for is built around an overworld level to which I've added an OverworldView (using the Level BP as showcased in the documentation). This points to an OverworldPage as its XAML and using data binding all its components are working great showing the right data, so this main HUD is now set.
Now planning to add both an Auxiliary UI (with Inventory, Progression, Quests, etc... all tabbed) and a Menu (with settings and so on, the usual stuff), I'm left wondering what is the right architecture for it.
- In order to follow the recommended MVVM architecture, should I be adding two other views, each pointing to specific pages as their XAML, and changing the active and shown NoesisView at runtime on Unreal's side triggering commands from Studio when the player engages the appropriate actions? Or should I be building it all under one View, and handling the showing or hiding of these other interfaces using sub-pages and visibility and event triggers within Noesis Studio?
- Is there a strong reason why the aforementioned Overworld HUD couldn't just be a component instead of a page i.e is it the intended approach for every Noesis View to have a page as its XAML, even if they have to be transparent and mere containers for components?
Thanks a lot in advance.
I've just started tinkering with Noesis Studio in UE 5.7 and there's one main thing I'm wondering with regards to intended project architecture that I'd love hearing your thoughts about.
At the moment, the action phase of this game project I'm using Noesis for is built around an overworld level to which I've added an OverworldView (using the Level BP as showcased in the documentation). This points to an OverworldPage as its XAML and using data binding all its components are working great showing the right data, so this main HUD is now set.
Now planning to add both an Auxiliary UI (with Inventory, Progression, Quests, etc... all tabbed) and a Menu (with settings and so on, the usual stuff), I'm left wondering what is the right architecture for it.
- In order to follow the recommended MVVM architecture, should I be adding two other views, each pointing to specific pages as their XAML, and changing the active and shown NoesisView at runtime on Unreal's side triggering commands from Studio when the player engages the appropriate actions? Or should I be building it all under one View, and handling the showing or hiding of these other interfaces using sub-pages and visibility and event triggers within Noesis Studio?
- Is there a strong reason why the aforementioned Overworld HUD couldn't just be a component instead of a page i.e is it the intended approach for every Noesis View to have a page as its XAML, even if they have to be transparent and mere containers for components?
Thanks a lot in advance.
Re: Intended architecture for a Noesis Studio + UE5.7 project
Hello! The recommended purest MVVM approach is always one View + Data Templates. We have an example of this on GitHub (LayeredUI Sample), and we definitely plan to create a more integrated Studio sample for this approach soon.
While Components were invented to let designers create UserControls without needing code-behind, feedback from our users suggests that Templates are often a more powerful and flexible way to handle reusability and dynamic content. I recommend using Templates instead of Components, but your feedback here is quite welcome.
A Page is perfectly fine as the standard root for your View. You can simply treat it as the main container that hosts these templates based on your ViewModel's state.
While Components were invented to let designers create UserControls without needing code-behind, feedback from our users suggests that Templates are often a more powerful and flexible way to handle reusability and dynamic content. I recommend using Templates instead of Components, but your feedback here is quite welcome.
A Page is perfectly fine as the standard root for your View. You can simply treat it as the main container that hosts these templates based on your ViewModel's state.
-
- oversymbol
- Posts: 2
- Joined:
Re: Intended architecture for a Noesis Studio + UE5.7 project
Thanks I think I´ve now figured it all out.
As a side note, whenever I´ve tried adding a string Property to my Data Set inside Studio that points to a UE5' Text variable I get crashes invariably, but adding String properties that are defined as Strings in the View in UE5 works well, dunno if I´m doing something wrong.
This is the log I get.
As a side note, whenever I´ve tried adding a string Property to my Data Set inside Studio that points to a UE5' Text variable I get crashes invariably, but adding String properties that are defined as Strings in the View in UE5 works well, dunno if I´m doing something wrong.
This is the log I get.
Code: Select all
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x000000000000000c
Noesis
Noesis
Noesis
Noesis
UnrealEditor_ApplicationCore!FTextStoreACP::GetStatus() [D:\Unreal\Anita\Engine\Source\Runtime\ApplicationCore\Private\Windows\TextStoreACP.cpp:252]
textinputframework
textinputframework
msctf
msctf
msctf
msctf
msctf
user32
ntdll
win32u
user32
user32
UnrealEditor_ApplicationCore!FWindowsApplication::ProcessMessage() [D:\Unreal\Anita\Engine\Source\Runtime\ApplicationCore\Private\Windows\WindowsApplication.cpp:3101]
UnrealEditor_ApplicationCore!FWindowsApplication::AppWndProc() [D:\Unreal\Anita\Engine\Source\Runtime\ApplicationCore\Private\Windows\WindowsApplication.cpp:2148]
user32
user32
user32
ntdll
win32u
UnrealEditor_Slate!FSlateApplication::PrivateDestroyWindow() [D:\Unreal\Anita\Engine\Source\Runtime\Slate\Private\Framework\Application\SlateApplication.cpp:7217]
UnrealEditor_Slate!FSlateApplication::DestroyWindowsImmediately() [D:\Unreal\Anita\Engine\Source\Runtime\Slate\Private\Framework\Application\SlateApplication.cpp:3234]
UnrealEditor_Slate!FSlateApplication::RequestDestroyWindow() [D:\Unreal\Anita\Engine\Source\Runtime\Slate\Private\Framework\Application\SlateApplication.cpp:2421]
UnrealEditor_SlateCore!SWindow::RequestDestroyWindow() [D:\Unreal\Anita\Engine\Source\Runtime\SlateCore\Private\Widgets\SWindow.cpp:1389]
UnrealEditor_UnrealEd!FFeedbackContextEditor::FinalizeSlowTask() [D:\Unreal\Anita\Engine\Source\Editor\UnrealEd\Private\FeedbackContextEditor.cpp:556]
UnrealEditor_Core!FSlowTask::Destroy() [D:\Unreal\Anita\Engine\Source\Runtime\Core\Private\Misc\SlowTask.cpp:135]
UnrealEditor_UnrealEd!InternalPromptForCheckoutAndSave() [D:\Unreal\Anita\Engine\Source\Editor\UnrealEd\Private\FileHelpers.cpp:4586]
UnrealEditor_UnrealEd!FEditorFileUtils::PromptForCheckoutAndSave() [D:\Unreal\Anita\Engine\Source\Editor\UnrealEd\Private\FileHelpers.cpp:4919]
UnrealEditor_UnrealEd!FEditorFileUtils::PromptForCheckoutAndSave() [D:\Unreal\Anita\Engine\Source\Editor\UnrealEd\Private\FileHelpers.cpp:5000]
UnrealEditor_UnrealEd!`FAutoReimportManager::FAutoReimportManager'::`2'::<lambda_9>::operator()() [D:\Unreal\Anita\Engine\Source\Editor\UnrealEd\Private\AutoReimport\AutoReimportManager.cpp:296]
UnrealEditor_UnrealEd!UE::Core::Private::Function::TFunctionRefCaller<`FAutoReimportManager::FAutoReimportManager'::`2'::<lambda_9>,TOptional<enum ECurrentState>,DirectoryWatcher::FTimeLimit const &>::Call() [D:\Unreal\Anita\Engine\Source\Runtime\Core\Public\Templates\Function.h:296]
UnrealEditor_UnrealEd!FAutoReimportManager::Tick() [D:\Unreal\Anita\Engine\Source\Editor\UnrealEd\Private\AutoReimport\AutoReimportManager.cpp:896]
UnrealEditor_UnrealEd!UE::Core::Private::Function::TFunctionRefCaller<`FTickableEditorObject::TickObjects'::`2'::<lambda_1>,void,FTickableObjectBase *>::Call() [D:\Unreal\Anita\Engine\Source\Runtime\Core\Public\Templates\Function.h:292]
UnrealEditor_Engine!FTickableObjectBase::SimpleTickObjects() [D:\Unreal\Anita\Engine\Source\Runtime\Engine\Private\Tickable.cpp:116]
UnrealEditor_UnrealEd!UEditorEngine::Tick() [D:\Unreal\Anita\Engine\Source\Editor\UnrealEd\Private\EditorEngine.cpp:1929]
UnrealEditor_UnrealEd!UUnrealEdEngine::Tick() [D:\Unreal\Anita\Engine\Source\Editor\UnrealEd\Private\UnrealEdEngine.cpp:537]
UnrealEditor!FEngineLoop::Tick() [D:\Unreal\Anita\Engine\Source\Runtime\Launch\Private\LaunchEngineLoop.cpp:5828]
UnrealEditor!GuardedMain() [D:\Unreal\Anita\Engine\Source\Runtime\Launch\Private\Launch.cpp:190]
UnrealEditor!GuardedMainWrapper() [D:\Unreal\Anita\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:123]
UnrealEditor!LaunchWindowsStartup() [D:\Unreal\Anita\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:277]
UnrealEditor!WinMain() [D:\Unreal\Anita\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:334]
UnrealEditor!__scrt_common_main_seh() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
kernel32
ntdll-
-
sfernandez
Site Admin
- Posts: 3363
- Joined:
Re: Intended architecture for a Noesis Studio + UE5.7 project
The crash is happening when you play the UI inside Unreal viewport not in Studio, right?
Could you please create a ticket in our bugtracker and we will fix it.
Could you please create a ticket in our bugtracker and we will fix it.
Re: Intended architecture for a Noesis Studio + UE5.7 project
It's hard to tell without symbols on our stack, but looking at the code on FTextStoreACP::GetStatus I can't see how it can be calling into Noesis.dll.
Who is online
Users browsing this forum: No registered users and 0 guests