Algodoo

well those are stretched axles. First, to be able to stretch them without them making force, you have to select the axle and change its hingeConstant value to 1e-30 (just write that on the hingeConstant value in the script menu). After that, your hinge will stretch without exerting force.
To transmit torque, you have two options: If you need to transmit high amounts of torque and don't care about slippage, you can simply use a brake with torque +inf.

If you need it for timings or that kind of stuff, you'll need to use bend. Bend cannot withstand too much torque, but it will work like a spring, it'll return to its previous position if it bends. To enable this you'll need to have brake off, then go to Script menu, and change these values:
bend = true
bendConstant = +inf
bendTarget = 0

it's actually much easier than i thought - you have a main array, which defines the entire geometry itself (i.e. it says "this is the polygon"). Inside of it there are smaller arrays, and inside of these, there are points, which are even smaller arrays, like this:
[ [ [x,y],[x,y],[x,y] ] , [ [x,y],[x,y],[x,y] ] , [ [x,y],[x,y],[x,y] ] ]

Let's imagine that the first one defines a box (our polygon will be a box with one small box cutout). We can define a box with 4 points like this:

[[0,0],[0,1],[1,1],[1,0]]

Now, a box cutout would just be a box that fits inside that other box. Algodoo will figure this out automatically.

[[0.2,0.2],[0.4,0.2],[0.4,0.4],[0.­2,0.4]]

Then just put both of these arrays side by side like this;

[ [[0,0],[0,1],[1,1],[1,0]] , [[0.2,0.2],[0.4,0.2],[0.4,0.4],[0.2,0.4]] ]

and you get the shape


I experimented by making a poly, exporting the surfaces to excel, then just plotting the points

thanks guys!

@Xray: Seems you can't run most of my scenes anyways... Did you reset your config after the other one failed too? (I think it was the belt fed mg)

I thought I hid that hinge! Also an unsightly counterweight circle popped up now that I moved some things. I'll try to add a timing chain later, fake or real, and i'll fix those minor problems there.
Maybe also an explanation of the cycle if I'm up for it, with scene speed manipulation and stuff. mainly to explain why so much air gets to the exhaust

why do you keep uploading scenes as phunlets? It's just annoying, try not to

The scene is pretty good anyways

reset your config then
Go to settings - reset - reset configuration

This is probably the best looking UI in Algobox, however i can't help but remark the usual problem here: This scene takes up about 45% of the step calculation time (took the value from the profiler [the "minus" key]) mainly because there's a lot of code on many objects' postStep. I found using only one object with postStep code to be much more forgiving in terms of sim time cost (or even better, no poststep code at all, or make it appear on click then delete it after you're done using it), and then you could use entityByID (or entityByGeomID) to refer to e.g. the four boxes from the sides of the buttons (by previously saving the entityID or geomID on a scene.my var, by using onSpawn so that the code only runs when the id changes).

The rifle with aim scene uses this technique (it needs one scene.my. variable per "muscle" axle) but has close to zero simulation time overhead when on idle.

Well, I just realized that you used scene.my's to store entityID's, nice

Honestly this is not exactly proven, but by experience I found out that having many scene.my variables doesn't really make any lag. The problem is reading and/or writing to them on every step, so for example if we have a box and we want to change its collideSet, doing
collideSet = {scene.my.collideSet}
or doing that from postStep as in
postStep = (e)=>{collideSet = scene.my.collideSet}
will read it every step, which is a small overhead on itself. Also writing with a laser, like we did 5 years ago, writes it every step, so it's basically code running unnecessarily. all of these end up piling up and they use up a rather big amount of step time.

I believe the first step in making the buttons less laggy would be improving the 3d effect boxes. right now all 4 of them per button are executing code on every step. I think the simplest way would be by using a texture, and you could probably just rotate it. Otherwise you can store each box's entityID in a scene.my.var via onSpawn and have no other code running, then change each box's color from the button itself, using scene.entityByID.

Do you avoid onClick code for some reason? I saw that in the Submit button, you check for the mouse being upon the button and for a click. is there any reason other than to change _isDown?

I think you could do this in a much simpler way. Just use something on the lines of this:

onClick = (e)=>{
scene.my.focusID = entityID;
_isDown = true;
postStep = (e)=>{
! Keys.isDown("mouse_left") ? {
_isDown = false;
postStep = (e)=>{}
} : {}
};
_onClick
}

also, one more thign about the sliders. you might have noticed that they will not stay attached to the cursor if you exit their area (i.e. move the cursor too fast to the sides or up). I think a good way of solving this would be saving the initial distance in the X axis between the center of the slider box and the mouse pos, then simply using the mouse position in the X axis minus the x distance (with the desired limits) as the slider pos while the left mouse button is pressed. this way you don't have to rely on the mouse staying inside of the slider box area

the cartridge/bullet instructions are very unclear: what measures 0.055x0.0762 and what is doubled? And why did you write it like that?
Couldn't you have just provided the boxes for us to use as size? Or can we use those?

not an engine because it doesn't generate any power, not a rotary because pretty much nothing rotates but the middle cam

well, its not a new concept but its very well done. It is a rotary collision engine, which just sounds much less complicated than over-embed engine

in my case it only works if sim speed is set lower, because the scene runs at about 25 FPS even though sim speed is 100%. otherwise it's all gibberish

lol no RPM limit? What's the point?
It's good, BUT - you could go much higher than just 1800 RPM with spring rods and spring axles. i have no idea what this is, but the max speed for a spawn engine at 240 Hz is about 6 times that - 12000 RPM

no i'm not. Tachometer shows 10x less speed (5 x 100 = 500) and legacyMode 0 axles are ancient lol, use spring axles (const 1e10, damping +inf, forceDirectSolve true)

just being nitpicky

also tf is FAT team

also, you shouldn't use braked axles for crankshaft connections (or any timing-sensitive usage for that matter). They slip and will drift overtime. It's not that much of a problem in your case but using springs as connecting rods (as in my latest 3cyl) is a much more reliable approach

Or use bend axles. Thing is, it won't work too well if your engine has high torque, and the circles to which the axles are connected have to be very heavy otherwise they have very bad torque

you really need to up the frequency on these things. use 120Hz

what's with that 2013 gear shifter? Lol

The scene is very good. I only found one issue, where you have no indication that the engine started (oil pressure and alternator lights just flicker slightly after like 10 seconds of holding the starter key)

I actually found a way to make much faster engines at much lower frequencies, for example the max speed you can get at 120 Hz is 6000 RPM. you might be able to lower frequency to 90 Hz (60 Hz gives you 3000 RPM, but it's rough) and limit speed to something on the lines of a kamaz engine (or just make it go full speed, 4500 RPM)

Takes some time and patience though, we could add you to our Telegram if you'd like to know

well in that case you might want to attempt this but at 120 Hz with the new tricks (and spring rods instead of axles) - if you make it right and possibly add timing offsets, you could get it to 6000 RPM while at half the sim frequency. 60 Hz engines are possible but run pretty rough.

it's fixed. Do tell me if you find any other error

That thing is not a transistor, and the scene is not a computer either

A transistor is not a strictly binary device, but you can use it like one. A normal BJT works roughly like this: you have an input (collector), a control pin (base) and an output (emitter). in a binary scenario (cutoff and saturation) it will not let anything pass through if the base is 0, but if it is 1 it will let current pass through.

In this case you should abandon this and simply try to make logic gates. If this "transistor" actually let the right ball pass if there was no input on the left, this'd be a NOR gate

no, FPS as in frames per second, which is separate from Hz. Frames per second can be lower than the amount of Hz in some cases, if there's lag

again, it's at most a cheap NOR. Transistors are analog devices, since the output is actually the sum of the current going through the base and the one that's allowed through the collector.

how would this be "computer-ready"? Any simple ALU is an array of different logic gates, each of these made with transistors or FETs and resistors

I'll shut up if you make the necessary logic gates with this

well, nobody is.
tell me your number somehow (maybe skype - i don't use it since like 4 yrs ago but i can fire it up again)

There is no code anywhere. You have to write this on the lasers' onLaserHit:

(e)=>{e.geom.airFrictionMult = 0}

and on the other one:

(e)=>{e.geom.airFrictionMult = whatever}

i guess 1000 would be an ok value, but maybe try 100


Worth noting that this is going to do absolutely nothing besides braking unless you turn wind on or make it so that it moves


Also there is no need to limit the speed to 300 RPM, you can use a higher sim frequency (120 Hz is preferred, 240 Hz is fine, more than that and you're causing lag if the scene is more complex). 120 Hz would duplicate the maximum speed.

There's another way, where you would have no speed limit at all: using no lasers; but since the segments are cut instead of rotated it'll be tedious

not your invention. these are going around since pre-Algodoo days (that is, Phun and Phunland)

Kilinich's old plane scenes used something similar but made with pistons instead, but there are some scenes with this kind of system. i think one is a helicopter

here's one from 10 years ago lol:

http://www.algodoo.com/al … p?id=17476

I think you're a little bit confused? The StG44 is a rifle already, and it uses tilting bolt, not roller-delayed
Hell I made one in Algodoo, take a peek if you think it's different:

http://www.algodoo.com/al … p?id=81335

As of the scene itself, you're on the right path, but 5000 Hz??? Lol

You have to use VERY high densities on everything that collides, usually (much) higher than 100 - for example 400 or 500. but try numbers until you find a balance for each thing, for example you can get away with lower densities on the bullet and much lower on the shell. Other things like the killable strip on the bullets can be density 2 as it'll be the same.

this way you can make the springs MUCH stronger (more firerate), and lower the frequency to something bearable (less than 500 Hz if possible), so that you can use simulation speed 1x and not kill everyone else with lag

The trigger group needs a limit for the trigger (i broke the interruptor by dragging the trigger) and one for the interruptor too, and the thruster is too weak to fire when on full auto. but it's functional which is nice

nice! Very snappy