So I'm happy because I've solved the tricky internal coding of my project. Now to make it user friendly.
I would like to make the Timer"pause"/Interval user adjustable.
Any ideas?
How? 12/07/09
Moderator: Moderators
How? 12/07/09
- Attachments
-
- pauseTimer.jpg (20.52 KiB) Viewed 12745 times
Hmm,
There are a couple of factors you didn't describe that are of influence on such a decision.
Do you want to set the timer for each clone individually or globally from some sort of options screen. When globally, should you be able to change the value while clones are in play, and if yes .. should already spawned instances' timers change with it?
In the case you want to change each individual clone it depends on when you want this to happen. Right before they are spawned? Or should you be able to change the timer from each spawned instance by some sort of selection. Depending on what you're actually doing inside the Model State you might actually want to move the timer outside of the Model altogether and make it part of the Spawning mechanism instead.
Sorry to bombard you with questions instead of a answer .. but these deliberations are necessary for choosing your plan of action.
K
There are a couple of factors you didn't describe that are of influence on such a decision.
Do you want to set the timer for each clone individually or globally from some sort of options screen. When globally, should you be able to change the value while clones are in play, and if yes .. should already spawned instances' timers change with it?
In the case you want to change each individual clone it depends on when you want this to happen. Right before they are spawned? Or should you be able to change the timer from each spawned instance by some sort of selection. Depending on what you're actually doing inside the Model State you might actually want to move the timer outside of the Model altogether and make it part of the Spawning mechanism instead.
Sorry to bombard you with questions instead of a answer .. but these deliberations are necessary for choosing your plan of action.
K
Ahh yes. My ignorance shows. 
I have a "use tips" section I am building in the Docs, so you should only have to explain this once.
My case is fairly simple.
One instance of a single object
- globally from an options screen
- in play no
- before it is spawned
- the timer is just putting in a delay before moving to the next state in a repeating cycle.
I have a "use tips" section I am building in the Docs, so you should only have to explain this once. My case is fairly simple.
One instance of a single object
- globally from an options screen
- in play no
- before it is spawned
- the timer is just putting in a delay before moving to the next state in a repeating cycle.
In that case it couldn't be much simpler. Just set the value from your options screen using a ZExpression.
Code: Select all
pause.Interval = value;
K
Really! I tried a few combinations, imagining long file path contraptions, similar to app.(whatever component) use.
Yes, I would like some pointers on making the screen, thank you.
question - I've got an array that is only used in the running appState, so you might think it would be local. Yet, my project would cycle between options,running, and score appStates for as long as the user continues. So if the array is declared in the definitions of running, wouldn't it be "reDimmed" each time the running appState is called, and is that bad?
answering my own question - I would probably be writing in a memory leak, so I won't do it, and make some mention of this situation somewhere in the Docs.
Looking at the demos, there doesn't seem to be an example of an option screen that a user can enter values. This is usually done with GUI controls in programming languages. If you haven't invented a slider or spinner, I can make do with a read in text file.
Yes, I would like some pointers on making the screen, thank you.
question - I've got an array that is only used in the running appState, so you might think it would be local. Yet, my project would cycle between options,running, and score appStates for as long as the user continues. So if the array is declared in the definitions of running, wouldn't it be "reDimmed" each time the running appState is called, and is that bad?
answering my own question - I would probably be writing in a memory leak, so I won't do it, and make some mention of this situation somewhere in the Docs.
Looking at the demos, there doesn't seem to be an example of an option screen that a user can enter values. This is usually done with GUI controls in programming languages. If you haven't invented a slider or spinner, I can make do with a read in text file.
Change the expression to:
The problem is with floating point inaccuracies that makes things like (1.0 - (0.1*9)) not exactly (but almost) equal 0.1. This is a problem with floating point values in general, not only in ZGE. See for example this page.
Code: Select all
arrow.Y -= 0.1;
if(arrow.Y<= -0.9){arrow.Y = -0.4;}
When dealing with ( traditional ) menu's you always want to use integers instead of floats. Right now your selection variable range is -0.4 to -0.8, while you want this to be 0 to 4. Some benefits to this ..
- Array indices are integers, so this makes it easier to pull data rom arrays.
- By separating your structural data from your visual you're free to do whatever you want visually*
- Using a "standard" like this means that you can write a ZLibrary once, and simply re-use it on any other menu.
*When you'd make your menu behavior dependent on the -0.4 to -0.8 range, as soon as you reposition your menu ( and thus changing the range ) all of your conditions will be broken.
And in order to determine the position of the arrow, you do a additional calculation that converts the 0 to 4 range variable to -0.4 to -0.8.
K
There's something here I don't understand. I'm just trying to put in a delay before spawning.
- Attachments
-
- noSpawn.zip
- (962 Bytes) Downloaded 533 times