How do I halt the program while the question isn't answered (collision with stars)?
I've tried the stop all block from control, but it exterminates the program.
Scratch
If someone has this problem, I was able to get it done by making a variable set to 0 and if an event happened, when I needed to stop the game running, I set that variable 1, like in one of my Star sprites:
In the Rock sprite, I am checking every loop, if that variable is equals to 0, than the code can go on running:
Related
I'm new to Anylogic and created a simple traffic model. Only use 'carSource', 'CarMoveTo', 'Car Dispose' blocks to set the car routes. But After I ran the model, it worked for a while, then all the cars froze without any error occurring. ’Events‘ panel also stopped. How to solve it?
Most likely your model is running into an infinite loop somewhere in the logic. The first place to check would be all your loops that might become infinite,e.g Do loops, Do-while loops, iterator for loops where you perhaps change the counter variable manually...
If you have the professional version of AnyLogic the best option is to run the model in debug mode until you get this to the point where it freezes and then press pause. You will then see where in the code the model is getting stuck.
If this does not work you might need to start putting traceln in major functions and see ing you can spot the last traceln that gets printed and keep on adding more and more until you can find the point between two traceln where the model freezes
I had the same problem, that after a certain time, all cars froze and there wasn't a signle error.
The problem on my side was that the stop line was too close to the intersection, so I moved it a little bit farther.
When you are stepping through Swift code in Xcode (9/10?), there is a green bar on the right with something like:
You are supposed to be able to drag the partial-hamburger-menu upwards to rewind the statement pointer to re-run code. However, every time I try it it moves back as expected, but then 100% of the time I step from that point I get:
Is there a trick to this?
You can move the pointer to the next statement to be executed to either a previously executed statement or a not-yet-executed statement, but in order for that to work the stack needs to be in the correct state, and so do the variables in memory.
In my experience, the outcome is usually a crash.
You'd need to drop down to the assembler code and examine it in order to figure out what's really going on, and might need to patch variables and/or the contents of the stack in order for your code to survive the change of program counter. I've never invested the time to try to do that, however. As a result I find the feature pretty much useless, and have given up on it. (I've worked in assembler a LOT in years past, but never learned enough about ARM assembler to be able to read it well, much less hack registers, memory, and the stack to make moving the program counter work.)
I inherited some LabVIEW that has a time counter on it. Although I don't completely understand it because I am not familiar to LabVIEW and I have been successful to some extent.
What I couldn't make though, is to initialize this counter.
And this is my unsuccessful attempt (it just doesn't progress anymore).
I've seen this question that seems similar, but it didn't help me to solve my problem.
Also, my attempt was based on this NI help: http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/initializing_shift_registe/ after which I assumed it would work, but it doesn't.
This does what I believe you're going for. It now resets when first called or when the reset button is pressed. Also, I put a tiny wait in there to avoid unnecessary CPU loading.
The reason your attempt to fix it didn't work is because you were initializing the shift register of the timer every time it ran. That shift register has to be left uninitialized so it can retain the value from the previous run.
Here is example of timer, with reset functionallity. It is done as FGV - functional global variable.
Below are screenshots of the each state:
I have a strange problem. When pyglet app starts it just draws 1-2 frames then freezes. on_draw event just stops occuring. But everytime I move mouse or press keys, on_draw event dispatches as well. In short I have to move mouse to make my pyglet application basically work.
This is actually happens in Windows. In Ubuntu with compiz I've to move mouse just once then application starts working normally.
This is my code example:
#!/usr/bin/env python
import pyglet
win = pyglet.window.Window(width=800, height=600)
label = pyglet.text.Label('Abc', x=5, y=5)
#win.event
def on_draw():
win.clear()
label.x += 1
label.draw()
pyglet.app.run()
Here's a video explaining things.
I came across this last night while trying to figure out the same problem. I figured out what causes this.
I had used a decorator and put my updates in the on_draw method, and it would run okay for a little while, then it would freeze, only to start working again when I moved the mouse or hit the keyboard. I tried all sorts of tricks to figure it out, I finally thought that maybe things were just running too fast, and that putting them in a batch and letting pyglet decide when to update them would be better. It worked.
I also scheduled things so that they would run about twice as fast as my refresh rate, but not so fast it would bog anything down. This is more than enough for smooth animations.
needles_list = [gauges.speedometer.Needle(speedometer_data, needle, batch=batch, group=needles),
gauges.tachometer.Needle(tachometer_data, needle, batch=batch, group=needles)]
def update(dt):
for needle in needles_list:
needle.update(dt)
pyglet.clock.schedule_interval(update, 1/120.0)
gauges.speedometer.Needle and gauges.tachometer.Needle are subclasses of pyglet.sprite.Sprite, and I wrote an update method for each of them. I then called their draw method in on_draw as normal.
#window.event()
def on_draw():
window.clear()
batch.draw()
I know this question has been up for a while, and the asker may have given up already, but hopefully it will help anyone else that's having this problem.
I had a similar problem of update events not getting called (using pyglet from Cygwin on Windows), and it turned out there was a bug:
https://groups.google.com/forum/#!msg/pyglet-users/Qp1HzPHcUEQ/A9AFddycLSAJ
I'm not certain it's the same problem you're having, but it seemed worth mentioning. I ended up hacking the file mentioned (pyglet/app/win32.py) by hand (setting self._polling = True around line 105, in Win32EventLoop._timer_func) and all my updates started flowing just fine.
Earlier this month I asked this question 'What is a runloop?' After reading the answers and did some tries I got it to work, but still I do not understand it completely. If a runloop is just an loop that is associated with an thread and it don't spawn another thread behind the scenes how can any of the other code in my thread(mainthread to keep it simple) execute without getting "blocked"/not run because it somewhere make an infinite loop?
That was question number one. Then over to my second.
If I got something right about this after having worked with this, but not completely understood it a runloop is a loop where you attach 'flags' that notify the runloop that when it comes to the point where the flag is, it "stops" and execute whatever handler that is attached at that point? Then afterwards it keep running to the next in que.
So in this case no events is placed in que in connections, but when it comes to events it take whatever action associated with tap 1 and execute it before it runs to connections again and so on. Or am I as far as I can be from understanding the concept?
"Sort of."
Have you read this particular documentation?
It goes into considerable depth -- quite thorough depth -- into the architecture and operation of run loops.
A run loop will get blocked if it dispatches a method that takes too long or that loops forever.
That's the reason why an iPhone app will want to do everything which won't fit into 1 "tick" of the UI run loop (say at some animation frame rate or UI response rate), and with room to spare for any other event handlers that need to be done in that same "tick", either broken up asynchronously, on dispatched to another thread for execution.
Otherwise stuff will get blocked until control is returned to the run loop.