Something is really wrong with Nimbatus' drag model right now. Pianos fly like feathers, feathers fly like pianos. How exactly is drag calculated right now? My best guess is per-part. In real life drag is per surface area.
Unintended Side Effects
Fixing drag should be a priority IMO. You still have a chance to change it right now, but wait too much longer and people will get attached to their designs. "Larger is better" in racing because the angular drag on large designs is ridiculous. Fidget spinners dominate in sumo because angular drag keeps their simple, barely controlled designs stable.
Quick Fix #1: Scale By Square Root
If drag right now is DRAG=sum(parts.drag), then DRAG = C * sqrt( sum(parts.drag) ); could be a quick fix. C is a large enough number that small drones still have significant drag. Weight will increase faster than drag, like it should.
Quick Fix #2: Scale By Radius
Even square rooted, the shape isn't taken into account. Twelve parts on the ends of long poles should have more drag than twelve parts closely packed. That could be included in the equation perhaps as DRAG=C * (RADIUS / sum(parts.mass) ) * sqrt(sum(parts.drag));
Less Quick Fix: Outermost Parts
If a part has parts further out connected to it, don't count its drag, only its children. If a part has parts closer in connected to it, don't count their drag, only its drag. This is as close to "surface area" as can be gotten cheaply.
Post
corona_wind
Something is really wrong with Nimbatus' drag model right now. Pianos fly like feathers, feathers fly like pianos. How exactly is drag calculated right now? My best guess is per-part. In real life drag is per surface area.
Unintended Side Effects
Fixing drag should be a priority IMO. You still have a chance to change it right now, but wait too much longer and people will get attached to their designs. "Larger is better" in racing because the angular drag on large designs is ridiculous. Fidget spinners dominate in sumo because angular drag keeps their simple, barely controlled designs stable.
Quick Fix #1: Scale By Square Root
If drag right now is DRAG=sum(parts.drag), then DRAG = C * sqrt( sum(parts.drag) ); could be a quick fix. C is a large enough number that small drones still have significant drag. Weight will increase faster than drag, like it should.
Quick Fix #2: Scale By Radius
Even square rooted, the shape isn't taken into account. Twelve parts on the ends of long poles should have more drag than twelve parts closely packed. That could be included in the equation perhaps as DRAG=C * (RADIUS / sum(parts.mass) ) * sqrt(sum(parts.drag));
Less Quick Fix: Outermost Parts
If a part has parts further out connected to it, don't count its drag, only its children. If a part has parts closer in connected to it, don't count their drag, only its drag. This is as close to "surface area" as can be gotten cheaply.
New Parts for Dynamic Control
High-drag blocks as suggested elsewhere in this forum will be important. Also the many uses of the gimbaled direction indicator.
Come On, It Will Be Fun
It's gonna be hilarious to watch fidget spinners going off like dynamite.
Link to comment
Share on other sites
1 reply to this post
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now