Jump to content
Stray Fawn Community

Steering and Stability


corona_wind

Recommended Posts

Before we continue, it might be fair to clarify what we mean by "bug" "exploit" and "abuse". This is my understanding of them:

-A bug is typically an unexpected detail, flaw, or imperfection. It's up to the developer whether a facet of their program is a bug, or simply a feature.

-An exploit is typically the use of an unexpected effect for an an advantage unforeseen by the developer. It's up to the developer whether or not an exploit exists.

-Abuse tends to be a less severe example of an exploit.   

-----------------

In my eye, this means:

-A feature remains a feature unless a developer announces that it is otherwise. It would be inaccurate for us to refer to features as anything else. 

-The situation is not a mess. That's your opinion, but, respectfully, you are not a Nimbatus developer. Their vision need not be our vision.

 

At any rate, I've been working with the in game physics for a while now. I find that various interactions create all kinds if unforeseen effects that can foil a design idea, but experimentation on those same effects have allowed me to create some really neat drones. I'm sitting at second place on drag races, and racing is fun, but there are so many more modes to play with that aren't as heavily effected by drag. Fluid dynamics is tough. I'd rather see more fun stuff added to the game to play with over the mountain of resources it would take to simulate physics more accurately. 

 

 

Link to comment
Share on other sites

12 hours ago, corona_wind said:

Could you adjust drag according to drone size just before launch?  Not by rewriting Unity, just by fudging numbers inside the parts themselves.

Unfortunately not :) Technically yes, but tweaking these values will alter the behaviour of the drones (most likely) completely - as it should be because that's what you want xD And changing these behaviour could potentially break the thousands of drones in the workshop & sumo tournament. Also the singleplayer would feel different and we're too far into the development as that we can change these things too much.

So ultimately we're stuck with the current behaviour of the drone and tweak the game modes to be fun, instead of tweaking the drone behaviour, as that could have too many unintended side-effects :) 

I'm sorry for that, but that's the trade-off we have to do as game developers :) 

Link to comment
Share on other sites

12 hours ago, Markus said:

Changing these behavior could potentially break the thousands of drones in the workshop & sumo tournament.

Could you add a high-drag part, then?  Tail fin, high-drag block, whatever you want to call it.  Something with linear drag without excessive weight.  I'm not the first to suggest this, but maybe the need is clearer now.

Link to comment
Share on other sites

20 hours ago, Garheardt the Black said:

Before we continue, it might be fair to clarify what we mean by "bug" "exploit" and "abuse". This is my understanding of them:

-A bug is typically an unexpected detail, flaw, or imperfection. It's up to the developer whether a facet of their program is a bug, or simply a feature.

If gravity went up instead of down, that would be a bug, whether the developers said so or not.

This is how big and blatant the problem is.

Quote

-A feature remains a feature unless a developer announces that it is otherwise. It would be inaccurate for us to refer to features as anything else. 

You're entitled to your own opinion.  Myself, if gravity goes "up", I'm calling it a bug, even if they decide to retroactively say gravity just works backwards in the nimbatus universe.  It's a model of a real life thing which does the complete opposite of what it's supposed to.

Quote

-The situation is not a mess. That's your opinion, but, respectfully, you are not a Nimbatus developer. Their vision need not be our vision.

Once again, I dare you to take my community challenge before saying the physics are fine.  We need a way to stabilize small drones.  Either fix the physics, or kludge something else.  Maybe a tail fin.

Quote

At any rate, I've been working with the in game physics for a while now. I find that various interactions create all kinds if unforeseen effects that can foil a design idea, but experimentation on those same effects have allowed me to create some really neat drones. I'm sitting at second place on drag races, and racing is fun, but there are so many more modes to play with that aren't as heavily effected by drag. Fluid dynamics is tough. I'd rather see more fun stuff added to the game to play with over the mountain of resources it would take to simulate physics more accurately.

I don't think it would take much, and the developers even agree.  They just don't want to break the racing scores.

Link to comment
Share on other sites

Your community challenge doesn't make you an authority, nor does relegating established word definitions to the realm of opinion. If gravity went up instead of down, that would still be a feature unless otherwise declared. Examples are meaningless. 

I'm not sure if your E-tone is intended to be as aggressive as it seems, so in the interest of forum peace, I'm excusing myself from this topic.  

Link to comment
Share on other sites

Flip it around - "it works fine for me, therefore nothing's wrong" is equal and opposite to the hostility you imagine.  The devs acknowledge the problem, and the #1 Nimbatus racewinner has no solution but "build large".  The issue is real.

I just want to discuss the nature of the bug and find solutions.

Link to comment
Share on other sites

I assume the game has every part contribute to drag at all times (no occlusion). This causes drag to scale linearly to mass. So bigger objects of the same density will stop at the same rate as smaller objects.

While in the real world drag usually scales at around mass^(2/3), since mass scales with volume (r^3), while drag scales with surface area (r^2). So bigger objects of the same density will stop at a slower rate as smaller objects.

--

So you might intuitively think "add drag occlusion!", but this suffers from the fact that we're in 2D space so we'd end up with drag that behaves like mass^(1/2). Larger objects slow down even slower than they would in the real world. In addition, you would have to partner this with thrust occlusion (no thrusters in front of thrusters), or large craft would go supersonic while small craft could barely move.

Then there's other issues like the computational intensity of figuring out at every frame what's occluded and what's not. Along with this there's the issue of how drone's are held together. Without crosslinking between parts, large drones are physically weaker and would readily tear themselves apart if they reached similar angular velocity as small drones.

--

I guess you could just do some cheaty physics hacking and just have drone drag behave as mass^(2/3), but this will likely have problems as well. You'd have to add a thrust = mass^(2/3), or you'd again see issues of top speed variance with size.

I'm struggling right now to envision how that would then work in an angular velocity case, but I suspect it would go weird. Assuming it didn't, we'd be back again at the weakness of large drones issue, which would upset countless people for marginal upside.

--

Personally, I don't see a problem with the current drag model that's more serious than the problems arising from trying to fix it.

That being said, maybe there's a way to thread that needle that I'm just not seeing.

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...