1. (and Edit) Cloning. I do all the show editing in create mode as opposed to play mode. Just Ctrl-Drag to clone as many balls as you need. I also use the Move tool as opposed to the finger so there is no rotating. The rotating doesn't really matter though. The only thing that matters is the color of the ball.
2. I actually had planned on doing that originally, but I decided it would be too much in the notes box and that trial and error would allow you to see what each does anyway. What I did was to leave the first time cue open while designing the shows until I was finished. That way, I could use that slot to try things out. Just play until that one fires and then Ctrl-Z. When I got the shot like I wanted, then I would move all the balls over to where I wanted it to happen later in the show.
3. You can do that by staggering time cues firing only one tube per time cue. It's not the best system I am sure, but it works. I originally had 64 cues and intended to run the show faster. However, with 64 cues, I was hitting the Out of Memory warning very quickly. So, I cut it back to 32 cues. Adding a timing variable would require another line of balls for each tube which would cause more memory issues. I seem to be pushing the limits of Algodoo with this one.
4. Look at the author's notes to the left of the scene.
Found the problem and fixed it. As the new description states, those asteroids floating around before you click start were supposed to go away. Somewhere in the last minute testing the game got confused and decided not to remove them on game start. So, I did away with them.
Why no onCollide? If I set a collideset on the asteroids to allow them to collide with the bullets or the ship, then they would collide with each other as well. In the original game, they didn't collide. I thought about different collidesets for each asteroid, but there can be more than 15 on the screen at a time so they would start to collide with each other. There should never be more than 15, but there can be. Lastly, the main reason I do these scenes is to amuse myself and learn new stuff. I found coding my own collision detection to be fun and I got to relearn some of that math I was supposed to have learned long ago.
That was the plan. Actually, the original plan was to make horizontal bars appear at different heights and come toward you like in the original Star Wars arcade game. The problem is, I could only have 1 on the screen at a time. I also tried small rotating objects to show off the 3D rendering, but again, I could only have 1 at a time to maintain a decent frame rate. If I made them come at you fast enough to be a challenge to avoid or hit, there wasn't enough time to see the 3d effect. If I made them slow enough to see the 3D good, then it wasn't challenging at all. So, I split the rendering engine off and I'm working on having it render an entire room with objects (my office). I can't do it in real time, but I can adjust the camera angle or the lighting then render again. We're talking a second or two to render each frame. Algodoo wasn't intended to do 3D?
Found it, fixed it. There was one scene.my variable missing after the reset and one actual bug that my Algodoo was apparently ignoring until the reset. It was an actual bug that should have caused an error no matter what. Wasn't doing it before the reset. Strange.
I did it just to see if it could be done. But, as I say in the Author's notes, the better question might have been should it be done. It does mostly what I want it to do, but is it useful, no, due to the lag. With a single spinning cube, i can hold 10 fps and a nice smooth rotation. Anything more than one cube and fps drops off quick. I have done everything I can do streamline the code and make it as efficient as possible, there is just a LOT of math to be done for each rendered frame and Algodoo was never intended to do that via the interpreted scripting language. The inability to modify individual array elements also slows it down because I have to constantly rebuild arrays instead of modifying existing ones. The limited ability to do recursion meant I had to use a horribly slow sorting routine. There are extra calls to routines to do things that would normally be built into the language.
Ok, there is one use I can see. If you wanted a stationary 3D object in a scene, you could use this to render it with the desired lighting and view, then copy the resulting polygons and paste them in the other scene. For that purpose, it would work (after you rearrange the ZDepth of the incorrectly placed polygons of course).
Thanx. Fixed. I ran through multiple games trying to beat the 2:04 mark just before hitting share. I don't remember changing anything between the last test run and clicking the save and share button. However, when I re-downloaded it the X position of the red station was different than what the cars were looking for and the orange station was off as well even though I tweaked that one during the testing. I guess I need to re-download and re-test immediately after hitting share.
I found the problem and fixed it. I should really learn to download my scenes and test them. Was working fine when I uploaded it, grrr.
As for the numpad, you're right, I didn't think of that. I'm just so used to using it for Orbiter that's what I used. I may change it later, for now back to woodworking...
I just downloaded it and played through, got to game over no problem, total burn time of 54 seconds and change. Are you going around the level 6 planet clockwise? I've never tried that but it should work. Level 6 is triggered when you get close enough to the landing platform. I go to the left of the planet near the surface then retro burn as I approach the platform. Do it right, and the ship will arc perfectly onto the platform tail first.
As for ctrl-Z, I have never had a problem with it. Resets the game just fine on this end.