UI skin inheritance not working across modules

[msteiger]

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]

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

[immortius]

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 https://github.com/MovingBlocks/Terasology/issues/1621#issuecomment-76661267 .

[immortius]

On further though I believe this is cause by the current framework's handling of asset disposal. When the environment is changed, all non-engine assets are disposed and some engine assets are reloaded. If UI elements are already loaded and not reloaded they will be left with references to disposed skins and textures, etc. I'm not sure why the ingame UI would be loaded before environment switch though.

[msteiger]

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]

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]

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]

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]

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

[skaldarnar]

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

[msteiger]

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