I've been trying to make my code work for some time, but I can't seem to find a way to make it work, specifically, I can't find a way to make an object wait in an if statement or find a viable alternative to one.
Essentially, I've been trying to make a game object move to the right for 2 seconds, and then go back to it's original coordinates once that movement is finished.
I'm pretty new to GML, but I figured something such as x += 2 was what i was searching for in terms of moving the object to the right. However, I can't find a way to make said object execute x +=2 only once once pressing the control button (because it keeps sliding to the right as long as I press it, it doesn't just make a swift movement to the right), then wait in place for 2 seconds. I've tried making if statements as intricate as I could make them, but to no avail.
If anyone has any idea, i'm excitedly open to it.
Have a good day.
You are probably looking for a timer, to let the object wait before an action. In that case, this question may help: Delay time in GMS2
I would not recommend your current approach (using a while loop to wait until the timer is finished), as that will put all the code and actions in the object event on hold until that while function is done.
You should also look up the difference between a button 'press', and a button 'pressed'.
When it's press, it'll do the action as long as the button is hold.
when it's pressed, it'll only do the action once when the button is pressed and released.
I found a way to swiftly do it by creating a timer thanks to a while statement, yes they exist; even though it's not written in the game maker manual, which is a relief but also a pain to deduce how it works in there sometimes.
while (timer > 0 && timer < numberofframesyouwanttheactiontogoonfor)
{
timer++
break;
}
Related
When the player character goes into the Staffroom at the orphanage/boarding school they live at, said player has two turns before they hear the manager's footsteps coming down the hall and they are urged to hide. I've done this through use of number variables. At this point I have another number variable (set up like a true/false thingy by only using 0 and 1) to govern whether or not trying to do anything except 'hiding' or 'hiding wrongly' gives the response 'There's no time for that, just hide!'. The problem is this: Whenever I start the game, ANY ACTION is rejected and met by 'There's no time for that, just hide!'.
Code:
NOTSITS is a number variable.
When play begins:
now NOTSITS is 0.
Every turn when the location is the Staffroom:
increase NOTSITS by 1.
Every turn when the location is the Staffroom:
if NOTSITS is 2:
now HYF is 1;
say "From the hall outside, you hear footsteps... Shit, that sounds like Rodger![paragraph break]HIDE!".
HYF is a number variable.
When play begins:
now HYF is 0.
Every turn :
if HYF is 1:
instead of doing anything other than hiding or hiding wrongly:
say "There's no time for that, just hide!".
Hiding is an action applying to nothing.
Understand "hide" as hiding.
Hiding wrongly is an action applying to one thing.
Understand "hide in [something]" as hiding wrongly.
Instead of hiding:
try entering the empty cupboard;
now HYF is 0.
Instead of hiding wrongly, say "Don't waste time with stupidity, just hide!"
Please don't suggest using Inform 7's own time system to solve this. I tried that and it was a far bigger shizztorm of problems than this has been.
I think the problem is that you're relying too much on every turn rules, but they run after the actions have all been processed, so it's too late for them to do what you want them too. I also defined hiding as a synonym for entering, because that action already exists, and it's what you want to happen. So try this instead:
First turn is a truth state variable. First turn is true.
The staffroom is a room.
In the staffroom is an enterable container called the empty cupboard.
Understand "hide" as entering.
Carry out entering when first turn is true:
now first turn is false;
Understand "hide in [something]" as a mistake ("Don't waste time with stupidity, just hide!").
Instead of doing something other than looking or entering when first turn is true:
say "There's no time for that, just hide!";
(Also in the future it will help if you provide the full source code, or at least all that's relevant. This time you left out the staffroom and cupboard.)
You can specify an action and its time of appearance after entering a room:
After going to Staffroom for the first time:
manager comes in three turns from now.
At the time when manager comes:
YOUR STUFF
I have a QtreeView that is displaying file lists (using a model derived from QFileSystemModel). As the building of the file list needs a lot of time (I must read the content of each file to determine if the file is visible or not) I want to display the wait cursor during the analysis process. The wait cursor must starts when the user select an item (directory), and stays as long as all the list is not displayed.
For this I did a lot of tries:
using the expanded signal. But this signal is not related to drawing. Hence it arrves almost immediately,
managing the cursor in data() function of my model. But in this case I have an horrible blinking cursor,
managing the cursor by overridding the painEvent. In this case I have a small blinking, and the cursor appears lately
...
So, none of my "solutions" is perfect. Hence, do you have a way to do what I want?
Thanks a lot.
One more idea, but i did't try it:
Try to check QAbstractItemView::State in a timer after QTreeView::expanded() signal.
I am trying to add a gtkProgressBar to a little interface I created for an R script (using the RGtk2 package).
If I do something simple, as:
for (i in 1:50)
{
gtkProgressBarSetFraction(progress, i/50)
Sys.sleep(1)
}
everything runs smoothly and the bar is updated every second.
However, when I go to my actual code, I have a loop in which I do something like
for(i in 1:1000)
{
gtkProgressBarSetFraction(progress, i/1000)
#do some heavy computation here
}
The problem here is that the interface "freezes" and the progress bar is only updated at the end of the loop, therefore defeating completely its use...
Am I missing something here? How can I periodically "wake up" the interface so that it refreshes?
Thank you
nico
EDIT: OK, I solved the problem, but I still don't understand what is going on. I added a Sys.sleep call after the gtkProgressBarSetFraction and now the interface updates happily. To reduce "wasted time" I just did Sys.sleep(0.0001) (so for 1000 cycles I would only have ~0.1-1s more computing time, which is acceptable). Anyone could explain why is this happening?
To process one event: gtkMainIterationDo(FALSE). To process all pending events: while(gtkEventsPending()) gtkMainIteration().
This code is needed because of the way that the R and Gtk event loops interact - at every point, either R or Gtk is in control, and needs to manually hand off control to the other. Sys.sleep is one way of doing that, and these RGtk2 specific functions are another.
Almost all GUIs are made using concept called event loop. The program has some queue of messages and is itself infinitely looped in a process of picking new messages from the queue and executing them. The queue is populated by some events received from OS, like key strokes, mouse clicks, resizing windows, etc., and by the messages thrown by the program itself.
It doesn't seem like this, but R also has its own event loop (for graphics, but not only, and it is somewhat extended by RGtk, and while it is generally complicated I won't go into details).
Now when you call gtkProgressBarSetFraction, the progress bar is not directly updated, but a message requesting redraw is created and pushed to the queue. So, it makes no effect till it will be picked by the event loop iteration, but this won't happen until R will finish execution of your script OR when the loop will be fired exceptionally (by an internal timeout or by some functions, like Sys.sleep()).
I have an application which makes use of 20 different classes. The program execution starts in mainwindow. I start a progress dialog. I will make use of different classes for different purposes. After each function call which the execution goes to the particular class and does the required and come back to the mainwindow class, I will update the progress dialog. Now, the issue is the progress dialog freezes when the execution goes away from the mainwindow class. The cancel button is unable to accessed and so, the execution could not be stopped at the required time.
mainclass::mainclass()
{
ProgressDialog->exec();
x->add();
updateProgressDialog();
y->do();
updateProgressDialog();
zz->bring();
updateProgressDialog();
}
// x, y, z are three different classes.
This is how the execution goes. As soon as I enter the function in the main class, I will start the progress dialog. and call functions from different classes. The functions take considerable amount of time. I have invoked a thread to do the execution part, but I am unable to cancel the progress diaolog. I want the program execution to be stopped as and when the cancel button is pressed on the proggress dialog.
Please let me know how to get away with this issue. Hope I am clear here.
Without knowing exactly what calculations are being preformed in your threads its hard to isolate the problem. Maybe this can help: Keeping the GUI Responsive
Excerpt from: Performing Long Operations (by: Witold Wysota)
During long calculations (regardless of any usage of signals and slots) all event processing gets halted. As a result, the GUI is not refreshed, user input is not processed, network activity stops and timers don't fire—the application looks like it's frozen and, in fact, the part of it not related to the time-intensive task is frozen.
The functions you are calling are not processing the Qt events loop. You are using a modal progress bar, since you are calling exec(). This means that Qt only gets control at the times where you update the dialog.
The only way that I know of to work around this is to code the dialog as modeless, but you will also have to provide an opportunity for the events loop to process.
This is explained in a fair amount of detail in the Qt docs: QProgressDialog
In our game project we did have a timer loop set to fire about 20 times a second (the same as the application framerate). We use this to move some sprites around.
I'm wondering if this could cause problems and we should instead do our updates using an EnterFrame event handler?
I get the impression that having a timer loop run faster than the application framerate is likely to cause problems... is this the case?
As an update, trying to do it on EnterFrame caused very weird problems. Instead of a frame every 75ms, suddenly it jumped to 25ms. Note, it wasn't just our calculation claimed the framerate was different, suddenly the animations sped up to a crazy rate.
I'd go for the Enter frame, in some special cases it can be useful to have two "loops" one for logic and one for the visuals, but for most games I make I stick to the Enter frame-event listener. Having a separate timer for moving your stuff around is a bit unnecessary since having it set to anything except the framerate would make the motion either jerky or just not visible (since the frame is not redrawn).
One thing to consider however is to decouple your logic from the framerate, this is most easily accomplished by using getTimer (available in both as2 and as3) to calculate the time that has expired since the last frame and adjusting the motions or whatever accordingly.
A timer is no more reliable than the enter frame event, flash will try to keep up with whatever rate you've set, but if you're doing heavy processing or complex graphics it will slow down, both timers and framerate.
Here's a rundown of how Flash handles framerates and why you saw your content play faster.
At the deepest level, whatever host application that Flash is running in (the browser usually) polls flash at some interval. That interval might be every 10ms in one browser, or 50ms in another. Every time time that poll occurs, Flash does something like this:
Have (1000/framerate) miliseconds passed since the last frame update?
If no: do nothing and return
If yes: Execute a frame update:
Advance all (playing) timelines one frame
Dispatch all events (including an ENTER_FRAME event
Execute all frame scripts and event handlers with pending events
Draw screen updates
return
However, certain kinds of external events (such as keypresses, mouse events, and timer events) are handled asynchronously to the above process. So if you have an event handler that fires when a key is pressed, the code in that handler might be executed several times between frame updates. The screen will still only be redrawn once per frame update, unless you use the updateAfterEvent() method (global in AS2, attached to events in AS3).
Note that the asynchronous behavior of these events does not affect the timing of frame updates. Even if you use timer events to, for example, redraw the screen 50 times per second, frame animations will still occur at the published framerate, and scripted animations will not execute any faster if they're driven by the enterFrame event (rather than the timer).
The nice thing about using enter frame events, is your processing will degrade at the same pace as the rendering and you'll get a screen update right after the code block finishes.
Either method isn't guaranteed to occur at a specific time interval. So your event handler should be determining how long it's been since it last executed, and making decisions off of that instead of purely how many times it's run.
I think timerEvent and Enter Frame are both good options, I have used both of them in my games. ( Did you mean timerEvent by timer loop? )
PS: notice that in slow machines the timer may not refresh quick enough, so you may need to adjust your code to make game work "faster" in slow machines.
I would suggest using a class such as TweenLite ( http://blog.greensock.com/tweenliteas3/ ) which is lightweight at about 3kb or if you need more power you can use TweenMax, which i believe is 11kb. There are many advantages here. First off, this "engine" has been thoroughly tested and benchmarked and is well known as one of the most resource friendly ways to animate few or even many things. I have seen a benchmark, where in AS3, 1,500 sprites are being animated with TweenLite and it holds a strong 20 fps, as where competitors like Tweener would bog down to 9 fps http://blog.greensock.com/tweening-speed-test/. The next advantage is the ease of use as I will demonstrate below.
//Make sure you have a class path pointed at a folder that contains the following.
import gs.TweenLite;
import gs.easing.*;
var ball_mc:MovieClip = new MovieClip();
var g:Graphics = ball_mc.graphics;
g.beginFill(0xFF0000,1);
g.drawCircle(0,0,10);
g.endFill();
//Now we animate ball_mc
//Example: TweenLite.to(displayObjectName, totalTweeningTime, {someProperty:someValue,anotherProperty:anotherValue,onComplete:aFunctionCalledWhenComplete});
TweenLite.to(ball_mc, 1,{x:400,alpha:0.5});
So this takes ball_mc and moves it to 400 from its current position on the x axis and during that same Tween it reduces or increases the alpha from its current value to 0.5.
After importing the needed class, it is really only 1 line of code to animate each object, which is really nice. We can a also affect the ease, which I believe by default is Expo.easeOut(Strong easeOut). If you wanted it to bounce or be elastic such effects are available just by adding a property to the object as follows.
TweenLite.to(ball_mc, 1,{x:400,alpha:0.5,ease:Bounce.easeOut});
TweenLite.to(ball_mc, 1,{x:400,alpha:0.5,ease:Elastic.easeOut});
The easing all comes from the gs.easing.* import which I believe is Penner's Easing Equations utilized through TweenLite.
In the end we have no polling (Open loops) to manage such as Timer and we have very readable code that can be amended or removed with ease.
It is also important to note that TweenLite and TweenMax offer far more than I have displayed here and it is safe to say that I use one of the two classes in every single project. The animations are custom, they have functionality attached to them (onComplete: functionCall), and again, they are optimal and resource friendly.