Hi there.
I am in one of those logic-dark-hole that as been creeping me my whole programers life. Must be a missing piece in my brain. So I'm going to try to explain.
- I make an Intro Menu where I will have 2 buttons.
- Built a Button Class and a IntroMenu Class, and I call the IntroMenu Class from draw, when I am in Intro STATE
- the thing is, I want my Buttons to be animated, like slidding into the screen when appearing, and slidding of the screen when the choice as been done.
Here is my problem:
- Everything works fine but when my Buttons have finished their slidding out... THEY COME BACK !!
- Of course I can prevent that by initiating a "change State" as the result of the IntroMenu action, and therefor not calling my IntroMenu instance anymore, but I don't want that (because my "change state" thing is animated too).
- So I need my IntroMenu to be "ON" when I call it, "OFF" when I have done my choice and the Buttons are gone, BUT ready anyway for the next time I will call It !
ps: do you guys have logic-dark-holes too ? Is there a group I can join ? ;)
pps: I have the code, I can post it but I'm so afraid it would make it even more confusing
Answers
You should try to boil your problem down to an MCVE. Don't post your whole code, but try to create a small self-contained example that demonstrates the problem.
Most people that ask questions have their own logic-dark-holes so you have already joined the right group. ;)
It seems to me that you are already on the right track with using states. I can see the need for 4 states
1) Menu OFF
2) Buttons slide ON
3) Menu ON
4) Buttons slide OFF
State changes
1 > 2 under program control
2 > 3 sliding buttons reach final display position
3 > 4 user makes selection from available buttons
4 > 1 sliding buttons reach final off-screen positions
you have states of the program IntroMenu, Game and so on
and in the class Button you can have another set of state which is standStill, isMoving, hasDissapeared
both states are totally independent
Thank you for answering :) and specially for making me feel that I'm not alone in those darks holes :]
So I read all your answers and, it looks like what I have been doing so far. And my brain is so much saturated that I just feel like showing you this.
use final
Just some little tips:
final
. And it's advisable asstatic
as well.static final int ZEROSTATE = 0, MENUSTATE = 1;
I guess this is causing you headache
only one of them can be true at a time
so just make a state out of it like
ah, I see I have written this above already
;-)
guys, is it possible to turn crazy by giving everything you have at a stupid logic problem ? Because if yes, then this is about to happen to me :( please HELP
this code is too long for us to read
what is your question?
what does happen now, what do you want it to happen?
About which line numbers are we talking approx.?
like here
if you run the code you will see:
on the other side,
What I want is
calling the UI (introMn.run();)
but beside that, what I want is just to make the most obvious/common/normal UI in the world. Launch a menu, the menu appears, you select or escape, the menu disappears ! I've seen this 10 000 times. What is the mystery behind that ? (I might sound a bit hard but I've been banging my head on this for like 5 days now :( )
also in the button constr say
to reset X and Y as well
also, when going back, say
this
new IntroUI()
is time consuming. Alternatively, check which var you forgot to reset in the class introMn when restarting withstate = ZEROSTATE;
The fact that
is necessary atm shows that you need to reset comething in that class.
keyPressed
also
keyPressed
: in the long run: make it state-sensitive as wellswitch
I'd also recommend to use
switch(state)
where you haveif...else if....
nowor
switch(buttonState)
as well;-)
core idea
the core idea is that you need to reset everything when entering a state, especially when this state (or this button) has been used already
Mouse
also you run clickTracker from run in the button class.
it could be better to clickTracker from the main func (in the sense that it is outside the class like setup and draw) and call it from mousePressed or mouseClicked.
I just read your comment
you wrote
if you run the code..... yes, that's what takes so long, therefore it's better to write which line numbers you want....
but that I've solved
you wrote
look into what happens:
wipe gets called, wiped gets true and never resetted (!!!)
but wiped is treated like clicked in if ( clicked || wiped ) {
so finally
IntroMenuOutPut = "cancel";
happens in runyou have to clear that up. Not sure what you want there. When the button wipes... it moves out of the screen and results in
IntroMenuOutPut = "cancel";
?I don't know what wipe means or what you want with it
why not ignore key "0" ?
Hi Chrisir and thank you for your efforts
Is it supposed to be that complicated ? I mean what is more generic in programming than making a button ? I'll try (like for the hundredth time) to brake it down again.
A button as 5 states:
then, when I will call my button again, I will need it to be in READY state, not OUT state
--
So in the constr of the class say state=READY;
Or make a method reset and call it when you enter the state intromenu in draw()
You know, we have to tell a Computer step by step what to do
It all comes with practice
You're almost there
And why do you have wiped??
This violates your clean Button States?
boolean wiped; is like boolean clicked; when I have a UI with more than 1 button, the buttons goes away if:
ps: I took a week of this very piece of code to calm down on this, but now I get back to it and still I miss the trick
What feature are you missing, it's working now.
The missing feature is this:
but also
I need this because if I need to switch out of the BUTTONSTATE to stop the UI to come on screen, I will get problems.
I think wiped is currently the main problem since it is the same as
buttonState = MOVINGOUT;
ok but MOUVINGOUT is a state, wiped is a trigger
can you post your entire code with my changes
ok, you don't use click and clicked....
I think it's the same as wiped
it's pretty much the same, I tried putting state=READY in the constructor, didn't change a thing, then I tried using a reset(); methode... didn't get better.
here is where I'm at:
when I am in BUTTONSTATE
and press 0
what do you want to happen? Button moves out, go back to ZEROSTATE, correct?
nop !
when I am in BUTTONSTATE and press 0, the UI (buttons) is wiped out... and that's it.
I'm still in BUTTONSTATE, the buttons are gone (because I did wipe them out) and that's it. Of course I did send the message that the UI was cleared ("cancel") but I didn't YET decide what I want to do.
What I don't want is to tigh the end of my UI process to something out of it (like state switch)
how do you like my version?
It's almost perfect now except for the zero part (when I am in BUTTONSTATE and press 0)
remark
you wrote:
your explanation won't work.
Or I didn't get it.
Because you are still in state BUTTONSTATE but the buttons are gone, the user is stack in the BUTTONSTATE and can't ever leave it.....
bad.
or do you want the button to come back after it's been out (in this special case)?
I let my brain cool down a bit and get back at it you are really giving me energy, that is really cool :)
we'll hunt this one down...
;-)
:)
If I get back to the basic, this is how I though things should go (because I didn't find "the proper way" on the net:)
3 and to wait for an answer
4 So my IntroUI object does it's job: A) getting the buttons in B) activating the Button (to catch the click and run the rollover methode) C) getting the buttons out AND returning the answer (which button / key has been pushed)
5 when the answer comes in, the buttons are already out of the screen
6 then I act according to what the answer was, thanks to the code I wrote in the INTROSTATE
//
If the answer is "switch to Xstate", ok, the INTROSTATE code won't call the IntroUI Object anymore
if the answer is, "displayIntroInfo", then I'm still in INTROSTATE, so I don't want to have the UI coming back
I want the UI to come when I call it, not when I am in INTROSTATE
also I made it so that myIntro.run is called, only if a parameter "choiceIsDone" is false, but when my "choiceIsDone" , I need to know how to reset this parameter...
(my brain started to melt again at about the fifth line :S)
// I put the keyWaiter and mouseTracker inside UI because I'm afraid to get my main way to clutured once I write all the rest (keep in my that this is just like 5% of my code)
in my code you can call the UI again and again clicking start!!!!
also, I noticed you didn't use one of the things I said previously in your code!
Why?
do you test my code at all!?
Hello, back to the code after a day of other duties.
So yes, I did test your code and it does work very well
but if you comment the state change in line 50, the buttons are coming back if you push "0".
What about thinking of the IntroUI Class as some kind of "box" that I could:
and that would return
would it be the way to think about it ? I really wouldn't mind re starting that thing from the begining. specially since I already have all the pieces inside that are working
rewriting and restarting sounds good
introUI class represents a state / screen, right?
i wouldn't really switch a state off....
I mean you could switch off buttons but the state...?
but why not... sure....
you wrote the the buttons are coming back when you push 0
the point is that you are not clear here. when you push 0 you escape the state / disable the buttons but stay in the state. Can't work.....
Keep me up to date please
Either re start or serious cleaning up
restarting from scratch I'll keep you posted :)
Here we are Mr Chrisir
I think it works, at least it does what I need when implemented in my demo. I still have to make a lot of test but I feel somehow confident.
This is by far the hardest thing I've done in processing. It took me 2 weeks and it is only with the help of my girlfriend, who doesn't know anything about code but who accepted to spend 2 hours with me in front of the damned thing, that I could make it. I guess for you guys it might sound stupid simple but for me it was a case of give up the coding thing or passing through. I can't believe it is so hard for me.
I want to thank you Chrisir, specially for that "You're almost there" line you drooped me, it really help me :)
great
looks much cleaner now
but: introMn is a state (in a way) - we can't cancel state imho
either we stay in it OR we go to defined other state (how small it might be)
e.g. cancel high score screen, you go back to main menu
cancel help screen, you go back to game etc.
imho
I did test it, not thoroughly yet, but so far it does what I need it to do. I might all be connected to "transitions", things that are not talked about in this thread. In my demo, I like to have a smooth animation when switching states. Like "moving" from INTROSTATE to PLAYSTATE. I did wonder if transition itself should be a state but I came to the idea that I needed transitions to be "over" the states (like this I can fade out of a state into fading into another one, for instance) Therefore, once a change is made, I can only "launch" a transition that will drive me into another state, and that will take time. So I cannot have my IntroUI coming back all the time until the next state is launch...