Algodoo

Oh well... really nice quality!
I noticed some things though:
-Sometimes a round gets chambered and the ejector doesn't go up, so you effectively have a jam. this happened to me with the last round
-The hammer has no limit, so after you field strip it just starts to oscillate there
-The firing pin is WAY too loose, fires with just a slight inertia push, and the gun becomes an out-of-control open bolt thingy
-750 Hz
-You forgot to put a proper title

Well I like it, kinda... but it doesn't really look like a rocket. Try adding a tracer on them, with really low trace time, like less than 0.1

your thyme is broken, because you used non scene.my.variables. It will probably only work for you, maybe not even for you after you download the scene. Do this:
Press F10, write

scene.my.length = 1.18

on the console. this will declare a variable called scene.my.length, and it will put it the initial number of 1.18. Global variables (a.k.a easily accessed) are stored within the simulation, this means that if you copy the 'box and paste it on another scene it will stop working. Now press F10 again to close the console

Now, on the spring's length property, write

{scene.my.length}

this will make the length equal to scene.my.length. Now go to each laser and write
(e)=>{scene.my.length= whatevernumbercomeshere}
a.k.a lengths of the springs at different gears
You don't really need the second variable. Make a cam out of some circles and make it rotate when you need the clutch, so that the whole thing goes up. Keep it as simple and variable-free as possible if you can

It's not [1], [2], [3], [4], [5] but 1, 2, 3 4 and 5. Numbers in between [] are numpad numbers. Try it on an axle and you'll see: numpad nums pop up as [4] for ex.
But don't use numpad numbers since some people don't have a numpad (laptop people)

It doesn't fire though. what's the problem with it?

p.s some of your scenes are broken, for example the car with fuel: you have to sue _power instead of power, because variables without a _ in front of them disappear when saved

The scripting is actually very good, I kinda like it. You can use arrays where you measure 2 things in one place though, like

Scene.my.crank = [angle, angVel]
so when you want to know the angle you just use scene.my.crank(0) for angle and scene.my.crank(1) for angVel, and I guess that's a way to optimize the scripting

Another thing, the density is WAY too low on everything. Total mass is not really important in Algodoo, but we found out that engines actually end up with realistic weight when you use high densities. Here you're using density 8 on the pistons... use 250 or even more! Also crank the density up on the balls (be advised: on some engine designs, more than 600 on the balls generates uplift so you have to use a thruster to balance the whole thing). And I don't know if this applies anymore, but the optimal thing is to spawn a ball the size of the cylinder (40% in this case) with a lot of density.
Also select everything and put restitution to 0 on everything. it makes collisions worse

The timetoLive way to kill balls is kinda crude. pnvv used a better way using it long before, calculating with crank angVel how long the stroke will be (pretty easy: how many [milli]seconds the crank needed to do 1/2 rotation) and the ball got deleted after that. I don't know how good that was when you got a fast angvel variation, but it worked, and it was easier than the rotating killer technique and I guess more precise than the fixed killer. Try to implement that, maybe?
Oh, I see that you calculate time per 1/4 rotation, well calculate time by 1/2 rotation and use it for this

Laser spawning is always WAY worse than collision spawning. Collision spawning almost never fails as long as it's built right, and it's much easier to make. Also you can use a stretched axle and use variable ignition time to give some extra HP at high RPMs! I haven't seen variable timing on your engine but i guess it works somewhat like that

And if you use much higher densities you'll be able to get sim frequency down a lot. you know, helps with lag and stuff. 120 Hz may seem too little but I've built a 4 stroke V6 with 260 HP a 120 Hz, so you can make the engine work anyways...


One more thing: gun tech! that is pretty much what makes new engines worthwhile... use an inverted V shape made of 8 boxes (2 boxes, 4 of those for each piston) kinda where the timing thing is, that only collides with the balls. This will give you INSANE everything, RPM, torque, HP at high RPM, everything!

After you added density to the pistons, you should make the flywheel heavier. Also you can make a ring, make the flywheel light, and the ring heavy, then fixate the ring to the flywheel. this will have MUCH more inertia than just a heavy wheel

Well it's better having domeone bring you up to speed on algo engines instead of having to look mostly by yourself in the Algotrashbin... I learnt that the hard way in the first 4 years in here.

Variable spawn timing changes the angle of the spawner assembly so that it fires slightly before the piston gets to stroke. Actually this would destroy the engine when at low RPM or high sim frequencies, but if yoir sim freq is like 120 Hz (preferred!) and you script it so that it engages at mid-to-high rpm, it gives a noticeable boost. This is because high RPMs tend to make the ball spawn one or two steps later (a step is like a frame on a game) and you lose powar. so you compensate there

For the variable spawn timing you have to make the usual circle with little circles that rotate, and each collides with a fixed circle that is a spawner. I really didn't upload many engines so i haven't got a clear example of that I think. Just look at any of pnvv's engines if you don't get me on that one.

Okay, so the circle that rotates is connected to the crankshaft (or 2:1 gear, if you want a 4stroke) with a stretched axle. Be very careful with the circles where the axle is connected: both gotta have angle 0° or at least the same angle. To avoid slipping and unsyncing you HAVE TO use bend, NOT brake (+inf brake actually slips a little after some time). In case you didn't know, bend works with radians, so you'll either have to calculate or just try numbers (which is what I do ). So use hingeConstant = 1e-30 (a little bit too excessive i know, but works), bend = true, bendConstant = +inf, bendTarget = {scene.my.whateveryouuseforangVel > something ? 0.5:0 }

The something number is the num where the VTEC kicks in. At 120 Hz you'd use probably 60 or 70. If angVel is negative then you have to use something like < -70 obviously

To get rid of the spawn drag and avoid making a 1 stroke engine (I hate those, too unrealistic ) just make a Boxer... Or you can point a thruster downwards and make it activate with the acceleration key, then turning force view on (this only if your engine is mounted on a vehicle with suspension) ticking only the spring forces, and tuning the thruster so that the forces on the suspension are the same when accelerating and on idle.

Also you can use keys.isDown("w") for the accelerator. keys.isDown("") outputs true when you press the key, and false when you don't. you can use up, down, right, and left too. That way you can make an easy throttle where the spawner is, like:

density := keys.isDown("w") ? 400:5;

on the spawn script of course. This puts density 400 when holding W and 5 when not holding it


And I got carried away again...

It's actually one of the scenes we've been needing for quite a lot of time. But as a frequency nutjob, I understood that you might need to use a high frequency, but what for? The machine looks really simple on the mechanical side (I didn't find any mechanisms anyways). Particles would be a nice addition (spawn long boxes for excess material, or maybe different polygons with a slight curve?) but seeing how the scene goes already it will probably be a really bad idea. Also you could make it mill with Kilinich's Laser Manipulator if you play with thyme a bit (on his scene he melts a block of ice)

For the milling head you can make 3 or 4 pictures of different states of it and use them for the spinning effect

But seriously, what is the intensive part of the scene?? i'm really curious

I didn't want to do that because the wheels would lose traction if they go up suddenly (like a bump on the road: the velocity would be added but the wheel's velocity would be the same) or if they are in the air (but this probably would make them slip if you keep accelerating in the air anyways). But I think I'll do some tests anyways

lethalsquirl - "Idea from The Linkage" lol

No, this is not my idea, it's called Long Recoil. It keeps the barrel connected to the bolt until it reaches battery, then locks the bolt until the barrel resets its position and the casing is ejected. Honestly, I'm not sure if the actual ejection mechanism is like that in real life, but it works, and doesn't seem impossible to make irl. The design for that was made by yuras12 but his scene was very outdated and used 60 Hz, so I gave it a shot

This reminded me of a touristic attraction here in Argentina. We had a huge granite rock balancing on a hill, until in ~1910 it fell and broke to pieces. After that they made a fake one and put it there like the original
There are photos of it, like this one

Does this scene have anything in particular, or is it really balanced? I couldn't find anything Thyme-related though I noticed a strange behaviour when dragging

Select everything and put "No self collision"
You simply have parts overlapping and they collide with each other... But try to do something different, not a crashable car, because cars do not disintegrate like that. Think about metal. A sheet of iron will crumple upon impact, not break apart...

Hmm, i have no idea how. It'd be nearly impossible if the rocks were simply auto-generated from a texture though

I noticed that the upmost rock of the second pile rotates slowly, shifting the center of mass and making the rock below it fall. Then the other pile also comes crashing down. weird behavior on 1200 Hz...

I liked your bananana scene more squirl.

Okay now seriously... this is really good! I've seen a bunch of scenes like this one but none actually solved the shell thing. The only solution to the cycle fire issue would be to use timeToLive on the killable thing instead of a killer, set by a laser that gets activated when the firing pin gets hit (like, the laser is covered by a box that goes back or whatever)

But I can see uses for it already. My long recoil scene has a lot of issues with cycling after i made some improvements, maybe this is key. And for gas operated guns, a single thruster on the killable primer thingy would be enough as you don't need a force on the shell. unrealistic but logical to some extent

Just don't try. A computer scene should be something a little bit more civilized, like an ALU

An improvement to this would be making all the pieces' collideSet 0 by default, with no visual feedback to show if they're colliding or not. I forgot to click on the second piece that I tried to place, and it was one of the farthest away... disaster

Another way would be having a very high air friction to avoid pieces going to orbit the Sun...

Okay, finally finished! I wrote the last comment right when I started. Using max air friction multiplier and linear term is perfect

I hope no one joins. Even more, hope that it's like that on everyone's camps...
All you do is spam, so, less load

Actually Xray, the thing I don't like about that method is that it just jumps to the next slide. I wanted an animated, smoother feel to it, like I did with the balance tutorial, but that one was overcomplicated

Xray and s_noonan: I implemented all of your suggestions except for the gravity thing. It is not really needed as I couldn't restrain pan without having to use 2 entityByGeomIDs on the axle, something that I hate because of the massive lag it produces. So you can pan, and the person that makes the tutorial will be able to turn off gravity if he wants to anyways

Throttle no thorttle xd

Hice unas pruebas, y tu motor tiene mas potencia cuanto mas rpm, pero el mismo motor sin la transmision 2:1 tiene mas potencia maxima y se queda sin potencia antes

1.6 HP máx contra 2.2 HP máx

lol no one here works at the company. Only Emmanuel works there, but he doesn't really use Algodoo

You need advanced scripting knowledge to make one of this just some thrusters aren't gonna make it work

I did one, you can see how complex the scripts are

umm no... it's 160 meters long, and makes a lot of lag by itself, while a simple spring and beam would do the job with 0 collisions

I don't want smooth operation, I want it to be usable on scenes with higher complexity. For example I have a car scene with this engine, and it baerly runs at 40% sim time in 120 Hz. Imagine 200.

This is pretty much like Cell Lab on android. good job!

Jaja no habia visto tu ultima scene... si le pones densidad 100 a las bolas que se spawnean el motor va a ser bastante mas rapido

Lol I've never seen something like this... at this level of sim frequency you have to start using leaner tolerances! I wondered why the cartridges almost never got chambered properly, thought it was friction. It wasn't friction.

But I guess you can do this with less bullet speed for more reliability. 2 of the rounds I fired just bypassed the barrel killer. And it's full auto xd
I like the idea but maybe it should be more foldable, as in with a thinner grip. if it doesn't work just go full me and try to make a different mag mechanism even if it packs less ammo. This way it doesn't really seem smaller and you have to unfold the gun if you need it

Also, maybe adding a couple of springs to make it automatically unfold (at least to the point where you have to snap it into place) would be nice. faster operation and stuff y'kno

and i can't resist myself... 600 Hz