Algodoo

Pretty nice. I like the belt lift mechanism.

One thing you should do is chamfer the rectangular hole on the bolt (the bolt face) where the casing fits. You should cut the sides at an angle so that the round fits easier. Without doing this the gun has a small delay on most rounds or it downright jams

THE CAKE IS A LIE
Nice scene. Perhaps the best scene we've had in a very long time here.

The only thing I think can be improved is the jump. I believe it'd be best if there was a short delay between pressing W and jumping, so that you can direct the jump accurately. The acid jump is pretty hard really.

The scene is nice, but it has the fundamental problem of these kind of scenes (and Algodoo itself) which is the lack of dynamic/static friction. In all these scenes it seems that you're driving a hovercar, since it always drifts. I tried to emulate static friction and it somewhat worked, but it was a total nightmare to tune so I finally left it semi-working... I guess it'd be nice if you or anyone else would try to retake from there. I'd really like to see a somewhat realistic vertical car scene thingy...

Also it's pretty weird that you can't steer while you're not accelerating, but that can be fixed real easy... Just make the steering thrusters' force proportional to the (module of the) car speed when you are not holding W. Maybe you'll need it to be non-linear, i don't know

Some of us are still here making scenes... I wonder for how long!

I guess that's all related to different PCs. In mine it almost never jams, sometimes after spending the belt about 3 times one of the rollers will bug and the bolt will chamber but not fire. But for me bullets often bug out of the barrel and the spring doesn't get killed...

Xray, could you try resetting your Algodoo? I usually have to reset it every two months, or it starts getting laggy and physics get worse

I'll keep it at 240 Hz, maybe try making it field strippable or something. We'll see i guess


@wild bill Lol for some reason I read that the barrel fell off... You had me really worried there! I'll add a fixjoint and it'll be good to go
I just looked at the barrel when I was about to upload it and felt that there was something missing. Didn't even play the sim

Do you have enough hardware?

it does exist though, but with a locking mechanism instead of the lever. Notarget1337 has made one

Well I like the idea but it's a little bit too bad since you used stock densities... Use density higher than 100 on everything that collides! This way you can bring the sim frequency down to maybe 300 Hz. It will fire slower of course.

Good, I'd like some help on it. I've been tuning the timing to make the reaction envelope actually mean something, but I've only upped the firerate...

I have no idea how the trigger group works

Thanks

Good...

Lol somebody rated 1. nice.

Use 200 Hz and really high densities (more than 100/200) plus no restitution to make your guns much more sturdy. otherwise just trying to drag something breaks stuff

@articiceberg97 ot you can just select them and delete them xd

@me11 it's a feeding port and it's the protruding thing that's on the lower part of the gun. it is pretty intuitive anyways

I guess I have some explaining. But yes, the concept is basically backwards of what you would expect, but in Algodoo, with engines being much rougher and with sudden spikes of torque instead of something more consistent, measuring by brake is much harder and really imprecise. What we do in Algodoo is:

totImp3(2)*sim.frequency (i'll call it _force) shows the rotational force being made by the axle. Let's say that the axle is a brake (By using a motor we can also find out about engine brake force, but that's for later on). If you use a crank and exert, say, 1 N at 1 meter, _force will output 1. Now, if you make that axle a motor, opposed to the direction of the crank force, the crank will still make 1 Nm and _force will still be 1. So, by the conventional approach, if you brake an engine with 100 Nm and it goes to 3000 RPM, you have the torque at a given speed.

But in Algodoo, if you make the axle run at 3000 RPM, the engine will make a certain force to try and spin it faster than that, and that will be the power at a given speed. If the engine was off and without any friction/compression, it would generate 0 Nm, therefore the reading on the dyno is 0. If the engine is off and has friction, then the dyno should report negative values (i think this one doesn't but the Dyno2 did, and it was handy). And if the engine is running and at full tilt, it will try to spin the axle faster, and _force will report it.

Now that we have 5K/7K RPM engines it might be feasible to make a brake dyno. But before, when an engine gave huge torque (around 3000/5000 Nm) to compensate the RPMs for the same amount of HP than a real one, the torque would be pulsating so much that the engine fluctuated between like 500 and 900 RPM for a given brake.



Anyways: The main idea of this dyno is to cut entirely the lag generated by smoothing on graphs. The graph that is printed out at the end only has the same amount of datapoints that are calculated by averaging measurements on the test, and that allows for using smoothing 3.0 which smooths everything maybe excessively with no performance impact. plus the scripts are as modular as possible so that the majority of the code is ran only at a given time, for example the display driver is ran every time that one full measurement is taken (around 1 second) and the output script is run for as long as printing the graph takes, which is usually 30 steps

Well. I've always liked this kind of slow engine with a lot of piston travel, but at the same time... I've dynoed your engine, and this is probably the closest you can get to an electric engine The max torque of it would me MUCH higher (i'd bet around 35000) if you could get it to speeds lower than 300 RPM without it popping half of its pistons. Which gets me to my point: It'd be better if you used scripts to limit low speed torque and make a realistic, non-exploding curve (which is really easy if you know how to manipulate functions - i've baked that into my 5k engines). or made it fast, but that takes a lot of work.
in any case, you can use the new dyno3 if you want to tune it. i guess it'd be nice because you would be able to stall it somehow...

Beside that the scene is a 10. i'll rate r n

About the dyno, it's literally the last scene that i uploaded, pretty straightforward. In this case you would have to program the RPM range from about 300 to 1000 so that the engine doesn't blow up...
You can tune the torque curve by making density of the spawned balls a function of RPMs. For example, since the spawner RPMs will be the same as the crank:
spawnCircle{(
randomStuff:=x
density:= clamp(3 * Scene.my.throttle* e.other.angVel, 0, 100)

for example in that case your torque would be limited until (3 * e.other.angVel) reaches 100, which would be about 33 rad/s. That would be a linear limit, so you might find the curve weird, if that's the case just try curves for example quadratic or root functions, maybe also log()...

I was thinking a curve like this for a normal, slow car engine, and for this kind of engine you should put the peak torque earlier, about less than 1/3 of the max RPMs, but that's as simple as using a higher multiplier on the script above (instead of 3 use 4 for example)

About constructive details:Well, that's wrong in Algodoo. Longer piston travel means more torque, but it also means EXPONENTIALLY less RPMs. Therefore the power generated by the engine is pretty low. but it's usually all about finding the exact point. usually it's square, maybe slightly less, but never undersquare.
Rod length isn't too important but you might as well keep it like that.
The size of the spawned balls should be no more than the cylinder's size if your engine is square or oversquare. Of course you may need bigger ones for undersquare like here, but for oversquare it just makes no sense and breaks the engine more often than not.

Also two tricks:
I see that you use braked axles for the pistons (i'd recommend constant 1e-30 but i guess 1 does the job), but there is also something more to basically make pistons popping to the sides impossible. Put adhesion -0.1 on the pistons, but nowhere else. This will allow you to use incredibly stupid ball densities, at least until the engine starts to levitate.

Also negative adhesion on the balls. It's insane. I've been making a 120 Hz engine and could get 250 HP out of a 20 kg V4. But I guess you should try it for other kind of engines instead. the trick is adding many V-shapes and horizontal cylinder lids overlapping (about 10 each) but making them very light, less than 10 density. also the balls should have max radius and low density, and very high (low) negative adhesion, like -7000. you control throttle with the adhesion, idle would be maybe 0

And another idea for the torque limiter would be this
https://www.desmos.com/ca … 3gfbrcfwlm
in this case you just have to put the function in clamp, and it will give 0 below 16 rad/s (eliminating the need for the speed limiter). also, just replace the X's with "(- e.other.angVel)" and you won't have to use any scene.my.

Xray is right, but I guess what's needed is PD, actually using angle as P and angVel as D.

But it's nice, i like how simple it is

Those wings have too much of a paper plane feeling... Maybe it'd be best if you could tune down the force. I believe it works beautifully with airForceMult 50 and no air friction. though you need more speed to be able to achieve sustentation
also the front wing should have more torque to be able to get more angle. i used 250
but the concept is really nice. there you have a 10

Yes, but since i made the analogy of the force at 1 meter, i just called it _force. Don't read into it

Until about a year I thought that scene.my's, lasers, and all that kind of stuff was horrible for sim.time and created a bunch of lag, so I started doing everything with keys.isDown and a bunch of postStep stuff. Now I found out that using those is much better as long as less steps have to run scripts. A laser as a key trigger (with onHitByLaser) is much better than a keys.isDown on postStep, and modularizing scripts and running them at, say, 10 steps per second is much better than just using postStep or update and running them 60/120/240 times/s. I guess you know that, but for anyone who comes around, it's good advice.

Select everything, go to Material, put density to MUCH higher values. Everything you do in Algodoo has to be very heavy, otherwise it will glitch out. It's not because "you have a bad computer"

-scene.my.rpm doesn't necessarily work better. but you might as well use it. The problem with it is that you are writing to it in every step. If you read from the other object you will only read from it for 1 step on each engine revolution.
-Oops. Well anyways I was expectiog something like the graph that my demo engine on the dyno scene outputs, but with more torque at lower RPM.
-Maybe a little bit more is better. But not excessively
-i don't get it, but if you mean braking the engine, then absolutely not. Pistons will pop everywhere... Just put that script that i told you up there on the other comment and dyno the engine
-Not only a bit, but just less than z/d. Try with different ratios starting from square.
-Hahahaha sure. Pretty stable... Try to dyno the engine with range [100,1000]
If you fix the ratio you will be able to use higher density (or lower density and negative adhesion) balls and you won't need higher radius circles
-whatever
-no. negative. Positive will stick the piston, you want the opposite. Negative adhesion makes the hitbox slightly bigger though, so be careful
Also, I think that you are lacking an incredibly important part. The cylinder lid. i'm not sure but it seems that you only used V shapes... If that's the case then you'll have to put about 5 one above the other that span the entire engine length. This is what gives adhesion engines the boatload of power
-Everything light up to a point. Keep the pistons around density 100-150. Don't layer the pistons, layer the CYLINDER LIDS AND V SHAPES. And those two can be about density 5 or 10

I measured it with the "-" and "*" key. Those give you frametimes and how much time is needed to process each thing. While a complex script running in postStep would give me about 20-50% processing time, I found out that using those old boxes that flickered between transparent and opaque so that a laser could pass through them were perfect for the job (basically: the boxes have refractiveIndex 1 and change color from transparent to black via onHitByLaser. Stacking many of them one after the other give sort of a binary effect. After the last box would go the object with the script, and the script would be in onHitByLaser instead of postStep. hence the 1 step every x steps).
I also tried a counter on postStep (if less than X add 1, if X or higher run _script and X = 0) and it was more or less the same, but curiously it gave me slightly more overhead (using the "Sleep" percentage under the "-" key, since obviously the laser and boxes would use the draw process, so I needed something that would add up both.). While the laser gave me 70% sleep, the postStep script gave about 66-67% avg.

I haven't tried sim.tick but maybe it works better

well you can't just set maxRays to 1 in this case because the laser has to pass through the transparent boxes. so the ray that comes out of the box would be the 3rd one. What I do is limit maxRays to, say, 10 or 15 as needed just in case

Alright, that's a lot to talk about. If you have Hangouts we can add you to the algodoo chat (it's pnvv, faytree, fra32 and me) though I must warn you it's a total mess.

Just one thing - Don't ever try to use logic on adhesion engines. I believe that negative adhesion keeps the piston on the cylinder because the hitbox is bigger but doesn't bug everything, so the forces made to keep it inside may be huge. But positive adhesion doesn't do crap.

Also the piston works much better if it is light. You can use my Dyno2 (not the 3 yet) with an engine with ignition off and it'll tell you how much wasted power there is because of reciprocation and friction. It's usually huge for 5kg pistons but they are needed on non-adhesion anyways

The fun of algobox is already ruined actually - been like that for about 3 or 4 years.

In all honesty I hope Algobox actually dies completely so we are forced to use other sharing means - of course i mean Algoboards, but others could be used as well, f.e. the official algodoo forum.

Algobox has always been a mess since the heavily-cut-down-in-features integrated browser was made, but at the start of it there were just a few crap scenes and it was extremely easy to just ignore them. The sorting system made by Emanuel makes zero sense since you need to use a method that literally nobody from the huge kid community uses - an empty dropdown on the integrated scene upload system, that needs to have a group selected, would have been the perfect fix for the marble flood. but that requires an update to Algodoo, and holy God that seems impossible to Algoryx

And let's not even talk about the horrible featured & popular by rating or views or downloads system. It's so incredibly broken that scenes never even cycled through there... The featured scenes have a boatload of dl's and replaced the ones on the most downloaded...

so yeah, i'd be completely fine if Algobox just became a huge archive with no possibility to upload scenes. Hell it's probably the best way to end our trouble with the kids...

no such thing as waste of comments - they're free and off-topic doesn't exist here. In any case, your comment has a waste of capital letters

And it'd be nice if you guys actually changed the scene group, but nobody ever does that.

yep

The TTG will not do anything, because there's no TTG. You guys just named us like that, and you think that we're downvoting this scene, and all...

Big flash of reality: The only group we have is between 4 of us and we're just friends, not a super secret organization. We never talked about downvoting your scenes.

Stormstar: Algobox died as soon as Algodoo became free, maybe half a year later. All of you kids came here because of it. When it was paid, people tried to make meaningful stuff with it and tried to be accepted by the community, and when it became free that stopped being important for everyone (Especially Ultragamer, shout-out).

None of you will be mods, that's obvious. You need to be mature to be a moderator. And for you my dear Ultra, you were banned I just hope Algoryx just decides to repurpose the algodoo servers for something else so that we can go to fan-made servers with better handling.



algouserII: The impious camps must get out of our sight. Not end necessarily. That's why there's a Marble Races/Algothons category on Algoboards --> we would just ignore it and let you guys handle it


A bunch of kids are trying to take over the mod position. The mods are Kilinich and Xray, plus some like electronicboy and tatt - all way more mature than marble racer kids

I've been here for about 6 years, I know what I'm talking about

stormstar, grow up. that's not how the world works. Either algobox goes on just like this, or it disappears. If it goes on, it'll have a Phunbox mod or at least someone with some IQ left not to spam the algobox...

Algobox is dead, no question. Even if they find someone mad enough to moderate this it'll be dead as shit.


p.s "Marble/Camp Algodooers"? More like spamming kids?
I'd be very curious on what you guys would do if Algobox was closed. We have our backup forum already set up and tested...