Good CVT, but the gearing breaks after some time. You can't fixate something to an object that changes its size, the position of the fixate will drift with time. To fix that there's a very simple method, just hinge the input CVT gear (the one that is fixated to the dark circle) and the output fixed size gear (the one that is fixated to the CVT output) to the chassis, and use a stretched axle (hingeConstant 1e-30, brake +inf) to connect the two circles that you want "fixated". You have to use low hingeConstant or it'll start flapping around at less than 100 rad/s
-It doesn't work. You didn't even care to download the scene and check the console.
-Instead of ranting about your obsession with number types and stuff, why didn't you find a way around it? There are lots of ways I'm thinking of right now, which would give you more than enough (3.4e38 ^ 2 is enough for you I guess? Or ^3?) The easiest one would be continuously asking if the total number is above a certain number (for example you could use 1e38) and subtracting 1e38 to it if it is, then adding 1 to another variable. Like:
(use any object's postStep or update)
postStep = (e)=>{scene.my.total > 1e38? {
scene.my.total = scene.my.total - 1e38;
scene.my.totalx = scene.my.totalx + 1
}:{}
}
Then just find a way to let your code know.
-You use scene.my everywhere... You can use much less and make a much better code if you actually use local values on the cookie. Just write
_total = 0
and as many variables as you can use to do internal calculations, on the blank textbox below the title of the cookie's script menu and use that instead of the scene.my on the code. Then put the text script on the cookie, and output the text via one scene.my. For the upgrades you can use a scene.my variable that outputs true once you click the box (onclick scene.my.c=true), and when the cookie receives it (sc.my.c ? {sc.my.c = false; whatever code you need}) it executes code. THis way you cramp all of the code on the cookie and only get data from local variables.
Also you can sue functions if you want to reduce the code size on postStep or onClick, but I didn't find much code where you could use functions
Okay, I guess I'll cool down a bit. but you seemingly didn't get my suggestion about bigger numbers
If I write a novel it's because there are lots of things to correct in your scene. More so when you claim that it will overflow and stuff like that... if you are working with numbers this big, instead of putting limits and thinking there's no other possibility, you can fix this with just a minute of thought:
Think about an old 7-segment calculator screen. The minimum number it can display is 0 and the maximum, 9. yet the whole screen can show numbers much bigger, say, 99999999 for an 8 digit screeen. So how is this possible, when the maximum number is 9? Sending a 10 to the screen would not make sense...
So you can separate your number in, say, 8 parts if you have an 8 digit screen, so that 12345678 will be distributed between all 8 screens. Here you can do something similar but much easier:
Say you have 1e10, that's 10000000000. Imagine that the maximum number Algodoo can handle is that one. When you get to that number, you can simply separate it into two parts: you just make a variable that will hold values above 1e10, and you put the ones below 1e10 on the one you already had. So if you want to save the number 4237992450, you can do:
_value = 237992450
_value10 = 4
For the number 132534534543254354 you can do:
_value = 543254354
_value10 = 132534534
Maybe now you'll notice that if you save two numbers you can get double the exponent, so if you had a maximum of 1e10, now you can save numbers with 1e20 size. But you can't do operations directly because they would overflow. Just find workarounds, it's not hard in any way
The scene in its entirety is good, but the mechanical part is somewhat questionable. your way of making the engine simply gets the fun out of it, and probably behaves linearly, so it would be like an electric motor. And all of the gears slip. This is because you're running the scene at 60 Hz, and because the gearbox is composed of two smaller gearboxes. Use 120 and it may work better, but the thing that will really fix this is making it have only one contact point, i.e. only two gears.
Also, now that we have the negative adhesion concept, I guess you should try that. They run at like 5 or 6 times the speed than the engines we use right now, so they have like 5 or 6 times less torque too, which is perfect since you can add a 10:1 gearing made of C-gears or something like that on the output of the gearbox, and the gearbox itself would not slip.
no, since you can do the same with much less overhead if you use a circle with two axles...
You still don't get the point of making engines in Algodoo do you?
I think the scene ran ok, but still, your slipping problems come mainly from there
The engine is not bad, it's just too simple for an engine, and at the same time too overcomplicated for what it actually is. The point of making engines in Algodoo is to give the scene another challenge, otherwise you just drive a car through a 2d terrain thingy... for example I seemingly invented that type of engine with the springs that change length (my 5th scene I think [Don't look please]) but at least I used pistons.
And now that we have adhesion I have the theory that you can simply make a 5k RPM engine and hook it up to a low torque gearbox like the one I made, then add a fixed reduction at the output of the gearbox made of torque-withstanding gears like C-Gears. This way the gearbox is withstanding roughly 5 to 8 times less torque than before.
This is the best gun I've seen here in a long time. the interruptor is awesome, nuff said.
I've always hated blowback, open bolt included, since getting regular recoil, decent ejection, and consistent bolt catching is hideous, even more so at the ~300 Hz that I (at least try to) use for my guns... Gas all the way. but this approach seems awesome
actually the whole point of the gun was to be single shot, otherwise the mechanism would've been somewhat like the Z-Rotating Bolt Pistol. If you want one with a mag I guess that's what you should be looking after.
I believe that loading this gun would be the same than loading a double-barrel shotgun, since you're inserting the round there anyways.
Adding a mag to this gun would be hell since the only way to load it is by inserting the round, so it would be slow and not too good. If it actually had a bolt instead of a weird cupholder thingy, I could add a mag right before the barrel but the spring ejection system would not make any sense
I think you're missing the most important part about these engines. While my single piston engine vibrates like heck on light bodies and runs at 240 Hz, what makes it deliver 135 HP while only weighing 33 kg is that there are many cylinder lids and V-shapes stacked on top of each other. this doesn't do anything with normal spawn engines but adhesion actually accelerates the balls when there are many boxes. this is a tradeoff anyways, since too much speed means some thrust is gonna get generated, but still if you use my engine on a 200 kg body there's no problem with it.
I guess you can still make it a little bit better power-wise if you add more thingies there. The maximum self-sustaining engine speed you can achieve at 240 Hz without actually helping the engine yourself is about 4700 RPM (1 turn every 3 steps) (i thought that my engine actually ran at 5000 for some reason lol). if you help it it'll get to 7200 RPM (1 turn every 2 steps) but it'll generate just a little power to stay there, then it'll just return to 4700. With the same logic, you can get at 120 Hz:
So it somehow runs faster than the 1/3 limit. I guess it's because of the staggered pistons?
I also hooked it to my 10K dyno and found out that:
-you left my torque limiter script there unchanged (which actually limits torque up to 2K, so you should just get rid of it entirely. just write "adhesion := -7000" instead)
-there are some points where the ignition might have some trouble spawning. namely: 1200 to 1400 RPM, 1920 to 2100 RPM, a point at 2800 RPM. this is not that important but you might be able to tune your ignition/make it spawn before
-the peak power without the torque limiter is actually 450 Nm at 1500 RPM and peak power is around 120 HP at 2000 RPM
You need to rotate the ignition depending on the angle. the best way to do this is with a scene.my.angle or whatever name you wanna put it. On my engine I added a circle connected by a hinge with bend to the flywheel, so that the circle rotated with the flywheel but I could change angle. If the engine is completely stopped (with the flywheel fixed) and you turn it around you should see that the circle doesn't change its angle.
Then I added another circle upon it but which was connected to the flywheel, so that nobody fixated anything to the circle that is below. If you delete it you'll find the one with bend below. just look at the way it works.
I meant density 5, not mass 5. Density 5 is pretty low (I got to use 3000 on my older Lambda linkage spawn engines lol) but i never tested if it was really better or worse than eanayayo's. The only thing I tested was if the engine ran better if I used higher density (20, 50, 100) but it didn't run better at all.
and i have no idea why your engines have thrust, maybe you could try using lower density?
I kind of already did that, since it's the same thing that my dyno uses lol. It has an infinite torque motor, and the axle has something called totImp3, which outputs the forces that are acting on it, but divided by sim.frequency for some reason. The layout is:
totImp3 = [x,y,m]
where x is the total force in the X direction, y is the total force but in Y, and m is the total torque it is generating.
For example, if it outputs [0.0, 0.0, 8.0], this means that it is making (8 * frequency) Nm of torque. At 120 Hz that's 960 Nm. If the motor is spinning at 200 RPM, and the totImp3(2) is 8, this means that the engine generates 960 Nm at 200 RPM.
The problem with this is that the measurement is incredibly noisy. Especially on 4 stroke engines (take my V6 for example). So if the engine is doing 960 Nm at 200 RPM, the dyno will output 100 Nm, then 600 Nm, then 1900 Nm, then 1200 Nm... This roughly averages 960 Nm. If you plot this on a graph and use smoothing 50, you'll see 960 Nm.
Try it yourself: Hook my 10k dyno up to any 2 stroke engine. Put the speed limits on the dyno, and start the test. When the graph appears, put smoothing to 0
If we make a realistic dyno we have to make a script that averages the values that the dyno outputs. so, we put the dyno speed at 100 RPM for 1 second, then 150 RPM, then 200, and do the average every time. I tried doing that and it failed most of the times. I'll try but I don't know if that will work...
Btw we're hanging out, well, on Hangouts. That's the only place where we talk about algodoo anymore. If you want we can add you to the group, or maybe we could dm through there?
Algoboards has very little activity, because nobody uploads stuff there. The idea of it was to:
-upload a scene to Algobox really fast (with a very simple description and through the integrated browser)
-take the scene number from the URL (in this case it's 172478)
-go to Algoboards and create a post, then use the
[scene]172478[/scene]
tag to create a download box, and make your description there. This way we just talk about the scenes in algoboards, not here, and there's no broken "Featured" or "Popular" pages. (although we could make our own featured scenes page)
And HP = torque (Nm) * RPM / 7121, so it isn't hard to calculate it if you use a constant RPM (either by braking the engine, or by using an axle to make it spin at that speed)
That's a pretty weird engine. I couldn't get the balls to stay in the chamber with adhesion below -8000, but I see it's best to just kill the balls early with timeToLive
The new dyno I've been working on outputs this graph. https://puu.sh/ye748/3ec15200e2.png
So, about 19 KNm @ 1700 RPM and 7000 HP @ 3000 RPM
well the RPM's are fake too, But it's a nice car nonetheless. I just managed to get 6500 RPM so maybe slower engined cars can be made more realistic. Would be pretty nice if you could get it working at least at 5000 RPM @ 240 Hz before going dark
Awesome! I tried to make a CVT out of this concept, and I believe it is possible but it needs a bunch of tweaking. Simply rotating the fixed pieces that collide with the oil changes the ratio slightly
and yeah, it should have a gas locking mechanism. It had one. For some reason it had even more rate of fire but was prone to jamming (rounds would jump)
The weirdest part of the rifle is the loading shuttle, which is the part that somewhat chambers a round while the other one is getting ejected. It uses a pulley in real life. A pulley on a firearm...
Explanation of why:
The AN94 is designed this way to be armor-piercing. You could say that the receiver + barrel are free-floating (carrier), while the body of the gun itself is disconnected from it (the body is the "reaction envelope"). The receiver, bolt, load shuttle, pulley and barrel are able to slide backwards. There's a spring calibrated to allow the gun to fire two shots before the firing assembly touches the back of the reaction envelope. This allows for firing 1 bullet WITHOUT ANY RECOIL, so the second bullet will get fired completely aligned with the first, and the pulley and shuttle system allow for around 1800 RPM on a 2 shot burst. So you basically shoot two rounds that will hit roughly on the same spot, and the recoil will hit after the second round is fired
In full auto mode it simply waits until the carrier returns to its resting position so it fires at 600 RPM
In this case there is some recoil, but I think that calibrating weights and moving the springs will fix that some. Maybe I can improve the fire rate a bit too.
