Algodoo

One other thing I'm curious about - I found this comment:

Stormstar- 2018/03/12 16:48:51
This now has a rating of 4.4.
That's because a bunch of TTG thought this is to blame for Algobox going down so a bunch of them came over and rated this a 1.:(


Why did you think we did that? Like, we don't even downvote your scenes anymore


p.p.s. that forum statement was from a bunch of years ago. you guys can't even read a forum properly

I dearly hope someone gets that last scene out of the most commented section after/if Algoryx assigns the new mod. you know, for aesthetic reasons

Thank God, you guys are starting to quit Algodoo! In a year's time this will be spam-free.

Just take some time to see how pathetic your comments are. You can't spend more than a day making a scene. I have scene projects going on for over a month...

and Stormstar, you really need to find out how the world works. If a) you make a bet you will obviously win, and b) nobody cares about it, then there is no bet active. That will NOT happen. Either Algobox gets a mod (NOT an admin, there's an admin already) (I hope they take their time) and we all stay (except for half of you whiny marble racers) or it doesn't and we are all outta here.

P.s. Half of the guys that said "i'll abandon algobox" will return after it's fixed. I can actually make a bet with that one.

You have to tell me your google+ username for that

first, i was saying that to stormstar, not you

second, i don't care about your self esteem, that's yours to handle. you are one of the marble racers, as i'm one of the non-half-assed-scene maker unofficially known as ttg, that's how things are.

second-and-a-half, do you think the whole camper community won't come back? I'd celebrate if it was like that, but they'll come back as soon as this is operational again. Everyone whines and says that they won't come back but they always end up coming

third, sorry, but you ARE whiny. While you are waving goodbye to Algobox we (technical guys) are making scenes

and last. algodoo doesn't depend on algobox to share scenes. someone up there said that algodoo "is borining" because he can't share scenes

Lol no, your google+ username. You need to make a google account and send me the google+ username, not an email

well, since it's phunlettable, it's made for being used on other scenes. But I'll get rid of the clouds anyways - don't tell anyone, but i've always admired marble racers. i have a marble race folder with 4 gb of marble races on it

Is this necessary? I guess it's pretty easy to make, but it'll confuse the hell out of people. plus i think one of the gears need to be rotated or the spur teeth will overlap. Let me try...

I'll add it as a third, "Hybrid" mode or something on those lines

alright i just found a rather huge flaw in the c-gear code. But I've been able to spawn one of these somehow

Well, I've been able to spawn them without too much hassle (For the external gears, that is. The internal c-gears are broken [if you could help me on how to make better ones, please do] and the rack gears are in progress).
I basically adapted the c-gear script to use the pitch radius as an initial variable, then i simply used the same formula that you use to calculate the pitch circle on the spur gears. There are two overlapped pitch circles, but it's not much of a problem.

The problem came with the spur gear angle. I found out that the problem was much simpler than expected: if the side of the spur gear tooth touched the c-gear tooth center, you could spawn any other hybrid gear (i call them that for now, since i'll probably enable collisions for both) made with the same concept, and they would mesh perfectly.
So, on with the formula needed for this: The tooth profile changes so much from a 4-tooth to a 30-tooth that the angle needed to keep the spur tooth to the c-gear tooth center was "almost" linear.
So, on to making a function that gives me those angle values for each Z0. I ended up making a cubic function with regression, but it's only good up to 30 teeth gears. good enough for now

So, I want to improve internal c-gears before adding the transparent spur gear upon it. It's already working, but my internal gears are flawed. Could you help me with that? i'm looking for an internal c-gear profile that has as much contact as possible with any tooth count. if you can at least make a scene with the concept, i'll add it into the generator

Pretty nice!
I found out that my way of generating the c-gears always changed the tooth size, so it's basically broken.

I guess I'll see if I can integrate this into the generator later. The new scene.my's are getPhaseAngle and a modified drawExtGear, right?

Also, what's the difference between reflection.executecode() and eval()? I've used eval before and i don't really find any difference between both, but i want to know just in case

No, I meant external too. If you made two hybrid gears of different tooth count and made their pitch circles touch, they would not spin effortlessly because even though they [should] have the same "module" the circle tooth size was different (slightly smaller on the smaller gear, as if it was scaled down).

And the internal hybrid gears and racks were just tests, not really finished at all. I'll try to integrate this if I have any time, and maybe try my luck with the internal gears, but as soon as i have some time

nice speed. you should add on the description that it's T to fire though

construction-wise, it's pretty good, but you got the densities wrong. Try to use density higher than 50 on objects that collide, this way you'll be able to lower the frequency a lot

If I was the owner of this scene, the title would've been "Message to all marble race/algothon/bfdi/etc scene makers". And there wouldn't be water down in the video.

Since when is 7.5 rad/s pretty dang fast though

that's literally the worst way to make a chain. The physics will be all funky. Better to just copy the chain links manually by holding ctrl and dragging, this way you'll double the copied length each time and you'll make a very good chain

So this is mostly a K-Wing?

just use entityByGeomID() or entityByID()

As of the scene, that's a nice find. I guess it'd be better (performance-wise) to update the position every x seconds, since this has huge overhead when there are lots of objects on the scene and frequencies around 120-240 hz

only leave the killable bar and write this on its onDie:

onDie = (e)=>{
For(50, (x)=>{
scene.addCircle({
pos := pos;
collideSet := 1;
radius := 0.2;
color := [1.0, 0.91666669, 0.0, 0.71];
zDepth := 0;
density := 10;
drawCake := false;
restitution := 0.0;
friction := 0;
timeToLive := 0.08;
edgeBlur := 0
})
})
}

such attention to detail, wild bill

what's wrong with the suspension?

Actually you're wrong about the scene, it's simply all about the engine - it's the first useable 7000 RPM engine with power on the top RPM band, and packs 650 HP - all of that while having a total weight of 29 freaking kilos

And you're still bad at thyme? To make an onboard HP dyno you just have to take the value that the torque dyno gives and do

HP = torque * RPM / 7121

For example:

Scene.my.hp = scene.my.trqToGB * scene.my.RPM / 7121

And be impressed.

dyno says 4440 Nm @ 800 RPM, 883 HP @ 1900 RPM

Hmm, it is sorta true, but not entirely. Measuring by hand will get the engine to higher RPMs without you noticing, since it spikes. Configuring the dyno for [1000, 2000] gives you 30 points that have been properly averaged, and it reports 880 HP at 1700 RPM and peak slightly higher. Even if you use a simplified, positional dyno you'll get lower readings

But yeah that's been my point all along lol. My approach was to reach realistic speeds and it's been accomplished with the V4 at 240 Hz (It's a V4 to keep parts count at a minimum, since it was going to run at 240 all along). I'll try a V6 60º at 120 Hz and see how much speed I can get from it for now.

since hp/kg is no longer a problem, the challenge is elsewhere

nice as a start, but it can be improved a lot on the frequency front. At least in my case I prioritized sim time rather than actual gun performance, and my guns worked with 200 Hz. you might want to check out the gunpowder to see how it works, the best config was making it ignite after considerable time

The shotgun was the best one imo:
http://www.algodoo.com/al … ?id=102353

well i've never stopped doing stuff, i just don't upload anything. I have a couple projects that I could finish and upload but for some reason i can't get myself to do it and end up making yet another scene

MasterGamer: No, at least not in my case. I just like coding, so I always start from scratch.


Xray, yep. only the green circle. I'll clarify that later.
Honestly I don't think it's too understandable, i'll have to rewrite most of it

do you honestly think this couldn't have been thought by anybody else, over the 10 years that this program and its antecessor were around?
i invented something like this, probably one of my first scenes, but at least it used pistons instead of just being a circle with springs

no it's not a new type of engine. hell i'd argue that it isn't even worth doing because of how obviously simple it is to make and to achieve watever power output you desire.

Try making span engines, those actually present a challenge

hey Xray, I was wondering if you could help me with a very specific script. I would like to be able to read an entity's ID (could be an entity or an object, i.e. laser, box, axle...) just by selecting on it, without it having any special code on it, and from sim paused. maybe there's some obscure Thyme function that shows which entity is selected?
Otherwise would it be possible to at least read the clipboard via Thyme? This way I could extract the entityID from doing ctrl-C on the selected object with some dedication, it'd be harder to use but maybe more plausible than the other way

The really challenging part about this is that i need it to work without having any special properties on the selected entity. plus sim has to be paused, but that shouldn't be much of a problem. Not sure if it's possible at all. If you have any ideas i'd definitely like to hear them!

as for the scene: maybe try to unbind the key on keys.isDown, then rebind a couple frames later (or once you release the key)? Or maybe start the sim on onKey (i.e. on any key press) and use lasers for each key? That would be cumbersome but would probably be perfect

this desperately needs a spawn or at least collision engine, the kind with the extremely long bore so that it's slow. also use 120 Hz and make the legs heavier and with more friction

it's nice though. i like it. just that an axle is 200% cheating