I've made a module script containing info about each wave, and every wave has its own differences, like different zombies. I made use of a lot of functions. There is a seperate script that executes the waves/functions. However, when I was testing the spawning, only 5 of them appeared, when I clearly stated it in my module script to spawn 8. image of module script code
Heck, it even spawns 4 sometimes.
I'm relatively confused about this, I even added a barrier just so that they didnt fall off the map.
Is there any flaws with my code?
Try something like this
local trollanoidstospawn = 8
repeat
wait(1)
trollanoidsummon()
trollanoidstospawn = trollanoidstospawn-1
until trollanoidstospawn == 0
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.)
The project is to have 30 linear motors execute commands simultaneously. My question is about the best way to structure the subroutines and if there is a better way to call them.
Screenshot of the work space and structure of the Control subroutine
As you can see I have the Control subroutine. Each rung of this subroutine calls the other subroutines bellow it in order. The Drive_Status_1 and 2 are called automatically. The other subroutines are only called when an 'examine on' element is true.
This way requires the changing of all the tags for each subroutine for each driver. Having to retype multiple tags and making sure not to miss any has already led to some annoying mistakes and I can only imagine it will get worse with 30 drives. Is there a better way?
You are doing fine. Many ways to skin a cat.
Looks like your using a 1756-L82E, this processor has plenty of power to do what your asking. I just did a bottle filler/conveyor control project that is using 35 different drives. We're controlling them all via Ethernet i/P, I'm not even using a managed switch and we have no problems. They are all running at the same time. I rarely separate drives into subroutines, this example of 35 drives are all being controlled within one subroutine.
I do how ever limit the setup/parameter data within the logic. I try to keep the logic as simple as possible. Config your drive then only use the necessary parameters within the logic.
Cmd Examples: fwd/Rev, start/stop, fault reset, and speed cmd.
Feedback Examples: Active, Faulted
Below is link to an example of a bare bones drive control scheme.
Drive logic
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.
I've seen embedded boards before that have an LED that flashes like a heartbeat to show that the board is still executing code. I'd like to do something similar on an embedded Linux board I'm working on. Given that it's a fairly trivial bit of code, it seems likely to me that someone has already written a daemon for Linux that does this, but I haven't been able to find any evidence.
Note that OS X Server's heartbeatd and the High-Availability Linux heartbeat daemon are not what I'm looking for-- they both coordinate system availability over IP networks, or something like that.
Assuming what I'm looking for doesn't exist, I'm also interested in advice about how to write a daemon that toggles a pin while minimizing resource usage. At what update rate does cron become a stupid idea?
(I'd also rather not hear gushing about the LED on the sleeping MacBook Pro, if that seems relevant for some reason.)
Thanks.
The LED heartbeat is a built-in kernel function. Assuming you have a device driver for your LED, turning on the heartbeat is done thus:
$ echo "heartbeat" > /sys/class/leds/MyLed/trigger
To see the list of triggers (MMC activity, heartbeat, etc.)
$ cat /sys/class/leds/MyLed/trigger
See drivers/leds/ledtrig-heartbeat.c and http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/LEDs
The interesting thing about the heartbeat is that the pattern is dynamic. The basic pattern is thump-thump-pause, just like a human heartbeat. But the rate of the heartbeat is controlled by the load average! Light loads beat at about 50 beats per minute. Heavier loads cause faster beating until it maxes out at about 180 bpm.
I wouldn't use the cron. Its just not the right tool. A very simple solution is to just run a
shell script from your inittab.
Example:
#!/bin/sh
while [ true ];
do
logger "blink!" # to be replaced
sleep 1
done
Save this to /bin/blink.sh, add the following line to your inittab and have init reread the tab be running init q.
bl:2345:respawn:/bin/blink.sh
Of course you have to adjust the blink.sh script to your environment. Its highly depended on the
particular board how an LED can be toggled from user space (device driver file, sysfs entry, ....).
If you need something more efficient you might redo the while thing in C but it might not be worth the effort.
One thing to think about is what you want to signal with a pulsing LED. With the approach outlined above we can only show that the board is still alive (kernel is running, the process executing blink.sh is scheduled and blink.sh is doing what it is supposed to do). For some use cases this might be fine but more often you actually want to signal that the application running on an embedded board is still OK (doesn't hang, hasn't crashed, ...). To implement such functionality you need to integrate the code that toggles the LED into the main loop of your application.