Nifty not loading next screen

Troubleshooting gui
1

Hey everyone,
I have a sequence of screens loaded from a single xml file
until recently the file was moderately sized however I added in some character creation areas that have significantly enlarged it now most of the time when I load my game it goes to the first screen and gets stuck forever

The first screen is just a label in a panel that echos “Connecting to game server” once a connection is established it calls the nifty screen controller to swap to the login screen
nifty.gotoScreen(“scrLogin”);
As I am running the server and client on the same machine this connection phase blinks by almost instantly or it used to at any rate

When I enable the nifty logging I see the following message
INFO: gotoScreen [scrLogin] aborted because still in gotoScreenInProgress phase

I think that since the GUI is now decently sized when it tries to go to the next screen it hasn’t finished loading the other screens yet and so fails silently then because my code has already told it to go to the next screen there is no check since the gotoScreen function doesn’t return success or failure I haven’t managed a quick workaround

Has anyone come across this issue? or have a suggestion on how to fix it

I have fade in effects for my different screens I assume this could also be because it is still in the process of fading a screen in and so cant switch to a new screen?

Thanks

1 Like
2

Just a thought, but can’t you break these into individual XML files and use loadFromXML() or whatever the Nifty method is for this? Or does this stop screen transitions or something else I’m not aware of?

EDIT: Hah! It might help if I explained why I say this… you’ll be able to narrow down at least which screen is the problem area, if nothing else

3
@duindain said: I have fade in effects for my different screens I assume this could also be because it is still in the process of fading a screen in and so cant switch to a new screen?

99% sure this is the problem.

I guess you will have to make sure that even when your connection is super fast that you don’t try to transition too quickly.

4

Thanks for replying :slight_smile:

I will most likely break them down to different screens at one point but the complexity isn’t too mind boggling yet and I want to get everything working before i spent time optimizing especially when hitting stuff like this

is there an easy way to que a transition to a new screen? otherwise do I have to do something horrible like create a thread with a sleep in it? then assume a set amount of time means ok to transition to the next screen?

awesome adding artificial lag into a network game heh

5
@duindain said: Thanks for replying :)

I will most likely break them down to different screens at one point but the complexity isn’t too mind boggling yet and I want to get everything working before i spent time optimizing especially when hitting stuff like this

is there an easy way to que a transition to a new screen? otherwise do I have to do something horrible like create a thread with a sleep in it? then assume a set amount of time means ok to transition to the next screen?

awesome adding artificial lag into a network game heh

That solution would be awfully drastic considering you get called once a frame with the “time passed since last frame”. The other option is to wait to try and connect until you’ve fully transitioned to the connecting screen.

6

Ive just tried using nifty functions to solve this but its not working
I’m now calling
nifty.executeEndOfFrameElementActions();
before any screen switch calls

then I set a string variable to the next screen to switch to and add a EndNotify listener and call endScreen on the current screen
nifty.getCurrentScreen().endScreen(new EndNotify()
{
public void perform()
{
if(nextScreen != null)
{
nifty.gotoScreen(nextScreen);
}
}
});

I would’ve thought this would solve the issue elegantly but it is not working

any ideas?

7

Wouldn’t endScreen be when it is done leaving a screen and not when it is done arriving?

I stopped using nifty a really long time ago so I’m just guessing at stuff now.

8

But i am calling endScreen on the current screen which anyone would presume would actually end the internal animations
Then when a callback occurs everything should be wound up so it should be good to go to the next screen

Ok I seem to have solved this it wasen’t easy in my main i loop through
Vector<ActionListener> listeners = AppState.getInstance().GetSimpleUpdateListeners();
for(int i = 0; i < listeners.size(); i++)
{
listeners.get(i).actionPerformed(ae);
}
In my screen controller after setting the string on what screen to swap to I create a new Actionlistener object which will remove itself once the screen is swapped

AppState.getInstance().AddSimpleUpdateListener(new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
if(nifty.getCurrentScreen().isEffectActive(EffectEventId.onStartScreen) == false)
{
if(nextScreen != null)
{
nifty.gotoScreen(nextScreen);

                    if(nextScreen.equals("scrLogin"))
                    {
                        if(passElement != null)
                        {
                            passElement.setFocus();
                        } 
                    }
                    Log.getInstance().logString("StartScreen: ChangeScreen to "+nextScreen.toString()+" performed", Log.LOG_TYPE.MENU);
                    AppState.getInstance().RemoveSimpleUpdateListener(this);
                }
            }
        }
    });</code>

Adding the check for the effect seems to allow me to detect when its ready to change screens

Thanks for your help :slight_smile:
9

Your use of the word AppState breaks my brain a little but I’m glad you got it working. What you are doing with your listeners you probably also could have done with a regular JME AppSstate if your screen controllers were also registered app states.

re: my previous post, I thought the problem was that the new screen wasn’t done being transitioned to… which would still be true while it is fading in, ie: arriving at the new screen, not leaving the old one. In that case, waiting for the end of the leaving screen doesn’t help you because you still haven’t arrived at the connecting screen… thus are still transitioning. You needed to know when you arrived at connecting so that you could safely move on.

10

I go into this in some detail in the herodex gui article:

http://hub.jmonkeyengine.org/2013/04/the-herodex-gui-working-in-jme3/