Algodoo

I would improve the mechanism inside a bit. Since the first piston is showing it's backside when fully extended, the boxes get stopped before being able to move further. After successfully sliding across the piston, they collide with that bit of solid wall, stopping them and sending them back to the slope. This would repeat indefinitely, so it would be best if you made the piston a bit longer, and the top surface sloped to keep the boxes to the right.

If you want to make it fly, try using some scripts on the wings to change their airfrictionmult while they "flap". This way, the thrust created in that process is increased. If you change the airfrictionmult back right after that, the downwards motion is reduced, resulting in an overall upwards drift. Try figuring out the period in which the outmost pieces move downwards, and during that period, increase their airfrictionmult.

I made it to 30

Scripting is really simple. Its just variables and the one or other tool. For example, you can just change air friction by typing airfrictionmult = 12345xyz. To change it depending on the period, first figure out how long it takes for the cycle to repeat(check the motor speed and divide 60 by it to get seconds per revolution). Then let the scene run slowly and when the wings start moving downwards, check the sim.time by pressing f10 and entering that name "sim.time". Check the time just as well for the moment the wings stop moving downwards properly. After you know both the period length and the moments that define the motion, you can use some mathematics and an if-statement to set your airfrictionmult in the box for postStep:
first cut the time to fit the period: time = sim.time-math.toint(sim.time/[period length here])*[period length here];
then check if the time lies within the downwards motion part:
time > [first sim.time here] && time < [second sim.time here] ? {airfrictionmult = 20} : {airfrictionmult = 1}

Put this code in every box of the wings, but with the [] replaced with the actual value you found out before. Remember to find out the FIRST occurence of the sim.times, in other words the first time the downwards motion of the wings begins/ends. If everything works correctly they should be able to create an increased upwards drift. If you have questions, just ask.

This happens because of the way numbers work in programs:
Every number consists of a certain size. This also applies to decimal numbers. Usually they have 8 to 24 so called bits for storage, which allow you to store really big number, but also numbers with a lot of digits. If you move really really far in algodoo, these bits(the storage) is occupied by the large numbers, so algodoo doesnt have any "space" left to store the digits properly. And you propably know what happens to things that you dont store properly in your room: It gets chaotic and some things get losts. This also happens in algodoo. As you move further, more and more data about the shapes is invalidated due to missing memory. This causes them to start sliding of each other, stretch and twist in shape and many other wierd things. Usually the program has nice space to focus on all the details, but out there it is drowned by large numbers, so algodoo cant focus anymore on good surfaces, precise linking and round shapes. And that is what you get in scenes like this.

I just write that because I always use a box as a preview image, and I write that on top so the smoll kids dont think I am presenting them an image scene
But it's propably just a habit of mine

Well you can make these gates by taking an OR gate, then putting a NOT gate before one of the inputs, or the NOR gate by attaching a NOT gate behind it. I'll include it nontheless ^^

@SuperMax16
That works too! In fact with the method you used now, the box flies really nicely. You can see how it's repeadly thrusted forward. I think you should experiment with scripts in your own scenes, and if you think you have a nice result, publish it! Best source for scripts is looking at scenes of other people that use scripts and find out how they work. Then you can try mimiking these scripts to create your own results.

The uncoiling is a feature added on purpose. Whenever you get closer to the center, the spring will coil up as far as possible before it is unable to reach your cursor. Vice-versa, when you move your mouse away from the center, it keeps on uncoiling to keep up. I added it as a bonus feature, since making an arm that just has 12 pieces arranged in a ^v^v^v^ fashion seemed too boring to me. Sorry if you dont like it.

@War Games
Thanks My Friend

@Kole1911Returns
Hoooow

@SuperMax16
If you move the magnet away during the rotation, thats totally fine. However, the moment you move it back in place, you force it closer to the magnet on the wheel, which would require energy once again, meaning no energy is gained in the process. If you use electrical energy from the wheel to move the magnet, you consume it for that process, and when the energy of the magnet is inserted into the wheel, it is equal or less to the amount you used as electricity. After all, something needs to hold the magnet in place, which needs energy.

It is true my friend. Even my scenes own mistakes that I often do not notice until RIGHT AFTER UPLOADING IT. However, I replay my scenes to see if everything works like I want it to, and if it doesnt, I find the error and fix it. And even then the downloading people notice errors that they tell me so I can fix them. This is how a good forum works. You upload your creation, and people tell you their opinion for you to consider, including noticed mistakes. Keep up your ideas, for every scene you upload and every error you fix gives you more knowledge.

check out my Bachistochrone Scene for more info on the fastest curve

@SuperMax16
When using an electromagnet, the energy of 2 magnets being close to each other is not stored as potential energy, but as electrical energy which would affect the current in the coil of the magnet. Usually, a completely resistance free electromagnet consists of a wire coil filled with electrons that move freely, but directionless. If you bring a magnet towards the electromagnet, the decreasing distance shifts the electrons, thus charging the power source and storing the energy. If you cut off the power source before this happens, the effects of the electromagnet cease due to no place for the electrons to go, meaning no repelling effect. However, if you decide to connect the powersource in the moment the other magnet moves away from the electromagnet, the electrons instantly shift, but CONSUME energy from the powersource in the process. If there is no energy left there, the magnets would not repell each other. So even in this case, the electromagnet acts as an energy battery, this time storing part of the rotation energy of the wheel as electrical energy instead of potential energy.

How to make a Rainbow ball:
Rightclick the circle,
Look at the Scriptmenu
go to PostStep
inside the (e)=>{...} write: colorhsva=colorhsva + [0.5,0,0,0];

Voila, a rainbow ball

This is a creative way of making an archimedic spiral. You could try drawing the outline using a box with a tracer and some maths if you want too, given you know the maths behind this spiral and thyme.

Then he should just Update algodoo?

Thanks for realizing that these camps really are a nuissance to this forum. Your gear contraption is quite fancy, and I bet you could make even more complex ones if you try using multiple different sized gears using 1 shared hinge to create a torque-momentum translation. Keep experimenting and show us your creative results. Maybe i'll be around and see your creation ^^

What is supposed to happen in this scene?

What is so cool about fidged spinners? The whole internet is about that stuff, but its nothing but a freaking cube with some sticks n stuff to play with. How is this toy so much more special than the usual stuff?

First of all you should just use google to find out how he is spelled, THEN upload the scene (a little efford please).
Second, I was not abel to find anything about an "einsteins pendulum" in the web, suggesting it does'nt even exist.
Third, what exactly is this scene supposed to showcase? All i see is a hinged rectangle with a fixed gear and another hinged gear, doing nothing but moving a bit

You shouldnt use sim.gravity to change objects gravity direction. Instead, change their poststep to apply artificial accelleration to them (I am using eval for inserting values):
eval("
e.other.poststep = (e)=>{
vel = vel + [0,sim.gravitystrength]/sim.frequency + [Math.cos("+GRAVITYANGLE+"),Math.sin("+GRAVITYANGLE+")]*sim.gravitystrength/sim.frequency
}
")
Replace Gravityangle as the angle of the box with the arrow(you may need to adjust it afterwards) and there you go. every object that collides with the box will have its poststep overwritten to fall in that specific direction until it collides again.

Hey, this is quite chaotic but funny. I think you should experiment with gears and mechanical components in offline scenes(not published) to find out more unique ways of working with them before uploading another scene of this type. I just want to note that you dont have to say that we should be glad its not a camp in every scene, we are that nontheless ^^
Since you have been using mechanical scenes up until now, how about trying to mess with "thyme" in the near future? It's that stuff in the Script menu that thyme works with, and if you want, I can help you learning some of it! Or just check my earlier scenes, they mostly consist of more "simple" codes.

I think your upload rate is quite okay. It will lower on it's own when you start working on more complex scenes, but that will take a while. I myself only upload ever 1 or 2 MONTHS since I often lack the content for a scene ^^

Im positively surprised people still comment on this scene ^^

God I missed the feeling of seeing people on algobox that actually know the rules and the likes. Copsicle is right jason, message scenes are not allowed on algobox. Use the forum instead, or not post them at all.

Sure, as long as you follow our simple rules and keep the topics reasonable, feel free to join

I like this scene for 2 reasons:
A: It contains script. Script is alwaysy good because it means you put in work to delevop an advanced and quality scene
B: It's smooth and looks nice. Blinking upgrades, sliding level, all those are things I usually dont come up with.

Here are some tips for your future ideas and the current state:
Something minor i noticed is that you write {} ? {} : {}. The first {} can be ommited if it's only 1 line: scene.my.bloc == 0 ? {} : {}.
For your mousecontrol, I allowed myself to develop some beta code that you could use. Insert it into the panels poststep and remove the driving engine in return:
angle = angvel = 0;
app.mouserpos(0) < pos-5 ? {
vel = vel + [-105-vel(0),0]/x (replace x with some number to adjust accelleration. The smaller the faster it accellerates)
} : {app.mouserpos(0) > pos+5 ? {
vel = vel + [105-vel(0),0]/x (same as above)
} : {
vel = vel - [vel(0),0]/x (same as above, but slows the panel down to 0 if its close to cursor)
}
}
One type of powerup that I know is Ball trippling, i.e. the ball thaat hits the powerup suddendly turns into 3 balls flying in a spreading fasion. When you loose them, you dont loose a life unless it's the last ball.
As for different block types: Indestructible blocks, blocks that require 2 hits, blocks that are invisible before being hit, and require a second hit afterwards, blocks that move a bit when hit(perhaps downwards), blocks that change ball velocity etc. etc. there are many options for such things.
I look forward how you will continue this scene. If you have questions about anything that I just suggested or about scripting in general, feel free to ask here.

you can just join?