Well, I can give you the way of dooing so, since learning is better than letting do.
to make such an engine, you need a trigger. This is usually a collision with the topper engine wall, or a laser. that trigger spawns circles using
scene.addCircle{
pos := e.pos;
radius := [insert about 1/10 of the width of the engine in here];
colorHSVA := [10,1,1,1]; (play around with that value, the first number is the hue, the rest can stay about how it is)
density := [not sure about what INH and co. usually pick, but play around with it at areas around 2-1];
timetolive := 0.1;
};
Play around with the vars, since you can easily add other variables too in a similar manner. Remember to use := instead of = to prevent the triggering object to inherit the variables too(:= forces the creation of a new variable and denies any change in existing variables, while = allows both, resulting in the original stats. to also change)
you use ; to tell the code that you are now defining a new task. Theoretically one can write value1 = X; value2 = Y etc. but it's recommendet to write in multiple lines(the code does this on it's own) by pressing shift+return.
One can also use other variables for assignment, so you can easily write something like this:
the (0) and (1) of size are to access the 2 values inside the [] of a typical size variable (0 is first index, 1 is second and so on)
math.vec.len in this example is a typical function of algodoo. Most of them can be found in the Thyme subforum on the algodoo forum.
the _kineticEnergy has a _ in front of it's name to tell algodoo that this custom variable should be stored in the object instead of beeing discarded once the script ends(like all the standart variables i.e. density,size,angle etc.)
Remember to write numbers as numbers(if you use division, at least 1 number must own a digit, else they will left as integers, i.e. 6/4 = 1, 6.0/4 = 1.5, 6/4.0 = 1.5, 6.0/4.0 = 1.5), while writing any type of literal text inside "" i.e. materialname = "blablabla"
About your second Comment: For loops are unstable. It has occured to me that they sometimes work, and sometimes they won't execute, which seems to change every now and then(every couple of days). Usually one can take postStep to make for-loop-like structures(look at my JuliaSet- and Mandelbrot-Set-calculators for an example with 3 variables controlling 3 loops), but in your case we can use a custom variable to contain the script. Type this inside the blank black box in the top left of the script menu:
_spawnFire = {}
Variables can store nearly anything, including executable code, even as functions. once the _spawnFire variable has appeared in your trigger, enter the code for spawning 1 circle inside it. Then, after you did that, go to the script area that later triggers the circle spawn, and then simply type:
_spawnFire;
_spawnFire;
_spawnFire;
...
as many times as you need Circles. As an example, look in my RubeGoldberg scene at the final exploding ball, which is a good example for such a process.
Well, the drones themself have been invented by dugrel, not me. What I did was hooking into their artificial intelligence and modifying it so that they act more advanced, as well as adding the objects to the game that were neccessary to make these codes work(the healers)
Well, prob: 4 layers to the spawners, 4 layers to the fire. = 8 layers consumed, which is quite a lot, and the piston itself has to collide both with the fire as with the trigger.
It jams any script if it collides with the fire, and only triggers in case of the piston. You could also use a materialname called "piston" and only name the pistons after that, while leaving the fire with no name. All in all, it will make a brilliant filter
that's not even slightly 5D, heck it's not even a real polygon. You just bunched together a few springs and made them have very low force and length, and then watch what happens. If you want to see some REAL multi-dimension(4D), look at my Tesseract-Scene, it displays how a real 4D cube looks like
It's becauswe THEY DONT CARE. It's absolutely pasta for them if we go or not, all they want and need are their stupid little stickman friends! Even if all of algobox would fall apart and everyone except them was gone, they would still continue!
Well, it's not me you have to appologice to, you broke the rules of the algobox, and since it's not me who executes the rules here, you need to apologice to the admins. Next time just keep the rules in mind
A: If they're finished, or
B: If they will be really large and I need ideas from others(and even then, only in developement version to see the concept and not a playable beta-version)
woooahahh so awesome that you have to spam useless exclamation marks across the description which totally make's you look like an adult person along with your incredibru scenes. Totally...
*sigh* the whole problem started 2 years ago, when algodoo went free, instead of beeing paid for about 3$ up to 20$ (no idea what the prices were, I got it for 3€). Once it went free, the small childs had nothing in their way to get the program, and quickly started emerging with their cheap products. Once ultragamer showed up, the whole thing manifested into a single steadily growing plague that later evolved into the now known camps once ultra was banned. If we would want to return to "Algodoo classic", we would have to get rid of every camp, voting,signup and contest related scene(unless it's a real contest to truly challenge other people, but then they should be posted in the forum). As long as that self-looping spam exists, there is no chance that algodoo returns to the way it used to be, and even if everything suddently vanished, it would take time to heal the wounds that have been ripped in the community, including users that left the algobox a long time ago. Since I joined the algobox, I've always been trying to make scenes that are somewhat unique so I don't look like someone who is to lazy and just knocks some booring junk together or copies from others. I witnessed the times when algodoo was normal, and still remember when it suddently started during an inactivity phase of mine. Thinking of these times can actually cause nostalgis because they seem so distant now that the algobox has turned into a playground. That'S also why I often comment on your scenes, not to annoy you or "get rid" of you, but to give you frequent reminders of how everything would be better. And if you truly want to learn how to code and do cool stuff, you need to work and learn. Fortunally, many people(including me) would be glad to teach you a bit, but most of the time, you need to do research yourself, like I did, and let go of what's actually destroying the algobox...
It's no perpetual motion machine, it's just a rotating wheel, and in real life, the magnets would just sustain the kinetic energy until friction stops everything. Could just as well have used ball-bearings
So you uploaded the results before uploading the actual day. Brilliant plan, dude.
And why do you have to start that rubbish too! It's garbage! That scene name has been used at least 50 times by now, so why do you repeat the spam!
uh, this is cheap, you barely made a few killers and a buttload of little boxes, without ANY of agar.io's features. neither do they grow, nor can they collide with each other without instantly killing both of them. They don't even split ._.
Everytime, you upload ANYTHING related to stickmen or "objects", we instantly HATE it because it's spam, and, without any joke here, over 4000 similar scenes already EXIST! THAT is what annoys us! You barely do ANYTHING, you never face any problems in your scenes, never use physics or proper thyme code, you don't even put ANY work in your scenes! I could make such garbage in 3 minutes, while my real scenes take up to 3 MONTHS!
Seriously, put some proper WORK in your scenes, stop dooing the same stuff OVER AND OVER again, and take some proper time for your scenes
Why don't you just say "hey make the game of live in algodoo because I am not good enough for it" ._. And honestly: Such code is nearly impossible on proper scale, since there is no way of inspecting the surroundings of an object without using dozens of lasers.
I also faced the problem that my drone scenes with DugRel's dronse sometimes work, and sometimes they just shut down, without any change to them
We really need some way of preventing that, because I always need to use custom vars and poststep to make the for functions(like in my mandelbrot scene) so I don't encounter the problem.