DaVikingCode/Citrus-Engine

Potential bug - MediatorState, input issue

Opened this issue · 4 comments

Snky commented

Something in the newest MediatorState.as is causing input to be cut off of 1-2/3 'players' on screen when a completely different object is killed off(this being my XML level loader via 'kill = true', this is called a bit later after 2/3 of the players are created, one is created by the loader, IF I do not call 'kill = true', all three have input).

I've just confirmed this by un-doing my CE update (well I just reverted to the old MediatorState.as ..... and changed _realState = new MediatorState( this ); back to _realState = new MediatorState(); to fix the errors that go with reverting back)

Anyway, input works in all three players when I reverted back.
private var _istate:IState;
private var _garbage:Array = [];
private var _numObjects:uint = 0;
These are not present in the working MediatorState.as for me, just as an indication as to which version I may be using.

The "destroying" logic has changed in MediatorState but it should work the same and not affect the input system, but perhaps there's a case where this new logic doesn't work and something gets destroyed when it shouldn't. Have you debugged input by checking in a state update's for example if the actions on the right channels are really gone? Can you send us a little something to try your configuration exactly? send me something at gsynuh@gmail.com

Snky commented

Yeah I'll send something(and restore the newest MediatorState.as class), I tried some traces in the update function, all three update functions are being called, but nothing got inside of the _ce.input.isdoing.... only 1/3 made it into that, but if I removed the 'kill = true', on the XML loader it was fine.

--edit--
It wouldn't let me attach a file to your gmail,
so I sent another email with the project link.

you should have a multiline textfield on your stage (flash) and change the text on every update to be : _ce.input.getActionsSnapshot().toString();

very heavy... but you can monitor exactly what's inside the input system this way.

Hey @SnkyGames ,

Do you agree that the project you've sent me contains, and uses, a framework you built yourself on top of Citrus Engine?.

This makes it hard to navigate and understand, really. And I don't actually have the time to get used to it.

So I tried creating a little CE project from scratch, one state and one custom citrus object, a very basic CE project just to test various scenarios or object destruction, state restart, objects destroying other objects when they themselves are destroyed, I couldn't find any issue with input. Right now it seems that the changes to MediatorState did not affect "normal use" of Citrus Engine.

I understand you had trouble explaining what was going on now that I have the code, but I actually have the same problem understanding what can be going on too. There's CE and then your structure on top of it, unfortunately you're probably the only master of that additional structure here, and I may be part of a group that best understands CE so I can help for the CE part, but only if I'm being show a CE level problem, that's where you might actually have to reveal the bug at a CE level, without your framework- and that should be best done by you anyway.

I tried generating problems at CE levels hoping to get your results unfortunately I couldn't, do you think you can try to do the same - with your understanding of the additional structure you have it should be easier to do - and make a 'pure ce' problem for me that I could really understand , test and fix, in much less time that analyzing your entire project requires?