Algodoo

umm none, cause cars don't friggin explode when they crash

2 things: the rounds have a horribly messed up force (make it much lower and more constant) and notarget is right, the barrel should be linked until all the way back

Yeah sure so you just chop the mobo in like 5 pieces, with huge ass ribbon cables connecting them all around?

Performance fans go faster than 3000 RPM actually. My FX6300's stock cooler got to 5300 RPM once that I forgot to open SpeedFan, after I opened it the cooler got to like 130% speed...

ye, they're selling 4-way HB sli bridges

That is extremely weird... usually wheels just vibrate back and forth, here you're achieving like 10kN

el problema es que las bolas pesan tanto que en vez de impulsarse, el motor se impulsa tambien.Pone thrusters apuntando para abajo arriba de cada cilindro, y que se activen con la tecla del acelerador. Ajusta la potencia hasta que no se note diferencia en la altura de la suspension cuando aceleras

The only thing I understood from this scene is... that your Windows is not activated

Always with the same dilemma...
I guess this qualifies for a report, but after the countless times Xray told me that this is a grey area (his scene is not the same, he has to ask for permission, etc etc) i guess i'll just tell Lucas so that he takes action

it's really bad, use high density for everything (50 or more on EVERYTHING) and use 120 Hz frequency

^^ so he's rating practically zero, right?

bad jokes aside, it looks good! as slo-mo as it looks anyways
I think you can tweak the script a bit so that the smoke disappears when the cannonball is maybe 6 meters away from the cannon, and the transition of color is not too noticeable (when timeToLive gets to 0.9 it really shows a change in brightness)
And maybe reduce the number of balls and give it more density

My FX6300 is suffering this... 0.3% when fired, 2% after the smoke clears and stays floating in the air

You're doing EXACTLY the same than what I'm doing right now, but you're still some time behind. I'll post my take later today, and maybe you'll be able to help me improve it

trampa
1/10

throttle

that timing is crap. you have to use a 2:1 reduction and make a cam that's half of the one you used

24 cylinders!? That's a V24 engine... Why don't you use 120 Hz and half the number of cylinders?

well, either you're not using the trueblowback cartridges for what they were designed (blowback ceases before the shell gets de-chambered) or my computer is once again behaving like crap... You managed to get a nice firerate though.
Also I'm seeing a gas system there, is it just for looks? (you emulate the gas action with blowback?)

Well from what I'm seeing your wheel is better than the K-Wheel, as it only spawns 1 entity per step and seems to work okay. But it drifts uncontrollably and you didn't add any handbrake. Also what type of traction does it have?
I'll explain how my scene works on my scene's comment section

My method is measuring the X and Y forces relative to the wheel, and the wheel will slip if the forces surpass a given threshold, and it will stop drifting after it goes below a MUCH smaller threshold. So if the wheel is doing 90k N to the side (totally unrealistic I know) it wil start slipping, and it will be in Drift mode until it goes below 200 N. The problem of this method is that I need to calculate forces using totImp3 on the axle and then transmit that to the wheel. But I can get how much force the wheel does to push the car too

it spawns when the pistons are at bore, that's why i said that

this seems a little bit unreasonable tho

tell you what, it won't reach 100 downloads

What I meant with that picture is that the shell is having a backwards force acting on it even after it hits the ejector

Just start over, put

bend = true
bendConstant = +inf and
bendTarget = 0.0

and write this in the postStep of the axle:

(e)=>{
g0 := Scene.entityByGeomID((readable(owner)).geom0);
bendTarget = math.atan2(g0.pos(1) - app.mousePos(1), g0.pos(0) - app.mousePos(0))
}

You should open this from a web browser and just copy it to be sure that there are no mistakes

Initially the idea of using dynamic and static friction for a scene like this started when faytree wanted to improve drifting scenes. The idea that I had was using a heavily modified K-Wing (or scripting one myself for that matter) to simulate side forces, and a thruster pointing up front for traction. i couldn't figure out how to calculate the side forces to simulate zero slip so i just scrapped it.

I noticed that your method and mine have the same amount of lag. Do you use vel instead of totImp3?

Also, "The code assumes that tire side friction is 10% of the friction force when "peeling out". This is because the relative velocity between the spinning tire and the road is unknown." How would you calculate the maximum side force in real life, then? I searched some but i couldn't find anything concrete about this

...but torque is constant...
And even if it decreased in every "gear" it still wouldn't be accurate because an engine has a torque curve

OH MY GOD THEY IGNORE ME I'M QUITTING ALGODOO

There are very little "false" 4 stroke engines... Most engines in the Algobox are either spring (0 stroke as i call it), spawn (2 stroke) or collision (most people make 1 stroke engines). The problem is not the lack of true 4 stroke engines, it's the lack of 4 strokers in general, and the little care that everyone has about them. My Caddy has a 4 stroke lengthspring engine, and I have a 3 cyl, 30hp 4stroke buggy stashed somewhere, a FORKLIFT with an i6, and plans for a 4x4 4stroke someday...
And all thosr engines don't use fuel but they have proper cycles.


Also I haven't seen the scene since i'm pretty far away from a computer, so, do you use normal gears for the 2:1? Kilinich has a C-Gear generator. Those gears are way better. Just look for it in his 3rd or 4th page, or just search

Well, here the wheel will detect that it is not slipping if the angle is more than 15º. This actually gave me an idea, but since i won't do it, you probably can:

What if you use e.pos to detect collision with the ground? First you make a variable _upd and make it be equal to e.pos, then somehow make onCollide update each step, so that it writes e.pos each step to that variable


onCollide = (e)=>{_upd = e.pos}

Then on update or postStep you compare the present _upd with the last value of _upd: if they are equal, either the wheel is completely, totally still in one point (which, even if not possible without fixates, would do the trick) and if they are not, then the wheel has moved. This is based on the idea that onCollide only works when colliding... so if it stops colliding _upd will not be updated and you'll see that it isn't colliding

That is to avoid the laser and fix the 30º issue (try a 30º slope)

Also, phunlet-safe is the opposite of simple

Te dije como 10 veces como mejorarlos, nunca usaste mas de 5 de densidad... usa 50 o mas