Nifty.fromXML concurrency issue

Hi all,

I have implemented a game where the main-menu and the game-menu is split into two separate nifty .xml files. I find this much easier than a teadious cleanup of GUI-elements between games.

When I start a new game from the main menu I do the following:

  • call nifty.getCurrentScreen().endScreen( … ) and wait for the EndNotify
  • Once the EndNotify is called I create the new game inside a callable enqueued on the app
  • During the game-init I create a new gui-system and call nifty.fromXML to load a new screen
  • I then call nifty.getCurrentScreen to get the current screen

I then get the Screen instance from the old GUI, that should have been long dead back when I called nifty.endScreen - a new screen has been loaded over it…

I can solve this issue by adding a .5 second delay after the EndNotify, but solutions like that make me want to cry.

Why is the currentScreen not set when I call fromXML…? It happens instantly when calling loadXML on a clean nifty and and not instantly when calling .loadXML on a dirty nifty…

I don’t think this is the right work flow to use nifty. Have you read this documentation? Do you know that you can actually add an Xml without clean all the other every time by using fromXml method?
Also the right way to change a screen would be nifty.gotoscreen(string id); method and use the current endScreenMethod as a callback :).

Yes, I have read the nifty bible, and I know about addXML. But my game is based around an entity system, since the Main menu is pretty ‘active’ it runs in an entity system too. The GUISystem is a system inside the entity system and since the game has a GUISystem and the main menu has a GUISystem, I would like to keep these separate.

Making the GUISystem persistent, while every other system is not would sort of require rewriting a large amount of my architecture.

Besides it takes about .5 seconds to reload the GUI, and players wouldn’t be jumping back and forwards between the game and the main menu, so I see no reason to optimize the game by using addXML instead of loadXML - actually I would rather keep the main-menu unloaded while the game is playing, since it is completely useless inside the game, which has it’s own menu-layout and controllers…

TL;DR, I know of addXML, but I have various reasons to want to use loadXML instead.

@nihal said: Yes, I have read the nifty bible, and I know about addXML. But my game is based around an entity system, since the Main menu is pretty 'active' it runs in an entity system too. The GUISystem is a system inside the entity system and since the game has a GUISystem and the main menu has a GUISystem, I would like to keep these separate.

Making the GUISystem persistent, while every other system is not would sort of require rewriting a large amount of my architecture.

Besides it takes about .5 seconds to reload the GUI, and players wouldn’t be jumping back and forwards between the game and the main menu, so I see no reason to optimize the game by using addXML instead of loadXML - actually I would rather keep the main-menu unloaded while the game is playing, since it is completely useless inside the game, which has it’s own menu-layout and controllers…

TL;DR, I know of addXML, but I have various reasons to want to use loadXML instead.

Nothing keeps you from using Nifty in the normal way with an ES, you just have to write your adapting classes accordingly. In this case you give each “System” a class that has a reference to the main Nifty instance. You wouldn’t start separate applications to have separate “Systems” for managing spatials either.

1 Like
@normen said: Nothing keeps you from using Nifty in the normal way with an ES, you just have to write your adapting classes accordingly. In this case you give each "System" a class that has a reference to the main Nifty instance. You wouldn't start separate applications to have separate "Systems" for managing spatials either.

Annoyingly you were right as usual @normen, it took only a 5 line method in my GUISystem to use addXML, and it works like a charm - not a single conflict. I guess I was just hellbend on not keeping both resources loaded - sometimes you just gotta kill your own “babies”… Thanks for knocking some sense into my head.

Thanks!

1 Like