UI skin inheritance not working across modules #1621

Open
msteiger opened this Issue Mar 1, 2015 · 10 comments

Projects

None yet

4 participants

@msteiger
Contributor
msteiger commented Mar 1, 2015 edited

I've moved all UI-related textures to a new module to allow for custom skins. All references to these textures were updated to a virtual module named "skin" that just redirects to a real module (skin-default) in this case. Engine has a dependency on that virtual module (I had that part cut out, but it didn't help).

This works perfectly when the game starts up. However, it breaks at the loading screen, which is where the module environment is updated. In all but one screen (minichat console), the moved textures are missing.

It seems like the skins do not inherit from "default" anymore and thus do not even define the textures. The minichat works, because it doesn't rely on the inherited skin properties.

I can fix the missing textures with:

reloadSkin engine:default
reloadSkin engine:pauseMenu (and all the others)

Strangely enough, when I return back to the main menu, the textures are missing there, too.

The code can be found here: 452b981

@Cervator
Member
Cervator commented Mar 2, 2015

I wonder how @immortius' work on https://github.com/MovingBlocks/gestalt-assets-core relates to this - maybe it would help that issue?

@immortius
Member

I don't really follow why a virtual module is needed - you should be able
to override the skin even if it is in engine. Although reloading of assets
on environment change is hit and miss in the current framework. I doubt
engine depending on modules is supported in the current framework.

gestalt-asset-core may help address the issue. But I would like to
understand better what you are trying to achieve.
On 02/03/2015 4:40 PM, "Rasmus Praestholm" notifications@github.com wrote:

I wonder how @immortius https://github.com/immortius' work on
https://github.com/MovingBlocks/gestalt-assets-core relates to this -
maybe it would help that issue?


Reply to this email directly or view it on GitHub
#1621 (comment)
.

@immortius
Member
@msteiger
Contributor
msteiger commented Mar 4, 2015

Thanks for the info. The overall goals behind this experiment were:

  • Better separation of concerns (engine core code vs. pretty background pictures). Imho there are two groups of assets in engine: General UI-related elements and game assets. Having the assets separate would also allow for using engine code without them (e.g. in WorldViewer). Doing that for UI elements was my primary objective.
  • Skinable menu GUI (not sure if that has any value though). UI elements could refer to static (texture) names. With a simple change in the virtual module's name, the names would refer to a different real module and thus a different skin. Overriding textures works already now, but only in-game.

It sounds like the infrastructure for that is changing in some time, so it might not be worth putting a lot of effort into debugging this. Is that right?

@immortius
Member

It is certainly true that gestalt-asset-core will address some issues and shake things up a bit.

Otherwise, the way I would probably approach this is allow the user to declare (via command line or config) the module(s) to run in the main menu... or that run the main menu. That would make the main menu a standard game state just with no world or character. I feel layering these modules on top of engine is cleaner than trying slotting in a module under engine.

I would still say the engine (or rather NUI if we ever split it out) should contain some default assets for the UI elements at least, along with a few default or test assets of other types.

@msteiger
Contributor

One funny bug that is most probably related: configuring a world generator triggers the loading of the module including overrides. These overrides can change the background image, for example. Closing the menu does not "unload" the overriden images.

@immortius
Member

That's caused by assetManager.setEnvironment(environment); called from TempWorldGeneratorPluginLibrary. Are assets from modules required for the world config screen? If not this could be removed. Alternatively the assetManager's environment should be restored back to the primary one afterwards.

@Cervator
Member

Bump - with gestalt-asset-core merged is this still an issue? Leaving it in the v1.0.0 milestone just in case for review

@Cervator Cervator added this to the v1.0.0 milestone Oct 12, 2015
@skaldarnar
Member

We arived at v1.0.0 and it's still not answered 😉 Any news on this one?

@msteiger
Contributor

Need to dig a bit deeper for this one. I still have it on my list, but not high prio atm.

@Cervator Cervator modified the milestone: Alpha 1 - v1.0.0 Oct 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment