View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001051 | FSSCP | physics | public | 2006-09-16 00:50 | 2007-03-14 12:36 |
| Reporter | Backslash | Assigned To | Backslash | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.6.10 | ||||
| Summary | 0001051: $Damp does not work as it should -- high values cause cumulative sideways speed increase | ||||
| Description | ...You know what, I'm not sure what to put for the severity of this bug. It affects everyone, yet only the mods that want a higher value are going to notice. Long explanation, bear with me! First, I explain the problem. It sounds complicated but isn't really, so hang in there. It is sort of a bug, and yet afaik has been around since retail. First, change a ship's $Damp to around 4 or higher. Now, fly it around and turn. Watch your speed, and also your motion debris. Actually, the Velocity Indicator script ( http://www.hard-light.net/wiki/index.php/Script_-_Velocity_Indicator ) would help show the problem more clearly. As you turn, your horizontal (or vertical) speed continues to increase, until you are going well over your maximum velocity (and eventually, thousands and higher). This is because of this line in physics.cpp: vm_vec_make( &damp, pi->side_slip_time_const, pi->side_slip_time_const, 0.0f ); line 747 or so. I say 0.0f needs to be replaced with pi->side_slip_time_const. If you need me to explain mathematically WHY this 0.0 causes the ever-increasing speed, let me know. | ||||
| Additional Information | Along the lines of the previous bug I posted, I first mentioned this at http://www.hard-light.net/forums/index.php/topic,41832.0.html As far as I can tell from my testing, this change does not break the retail feel... Z acceleration/deceleration damping in the table already tends to be way more than regular damping, so either the acceleration/deceleration is overriding it, or damping is being added to the acceleration/deceleration damping, which is a very small change (being 0.2 or so). If the former, I see no problem with implementing this, and I hope this is the case (but need your input). If the latter, I'm guessing this would mean that for a $Damp 0.2 ship, $Forward accel would become the equivalent of 2.2 and $Forward decel 1.7. Is there a better way I could test to see which is happening? Some script or something? Some debug magic I don't know? So, I need some input from anyone who knows about this stuff, and/or some testing for whether the acceleration/deceleration 'feel' is any different from retail, for retail ships with default levels of damping (~0.1-0.35). Some members of both WCSaga and BtRL have tested the change and they report no problems with their ships. I've got a test build at http://myhome.spu.edu/calebjackson/FSO/fs2_open_physics.exe if that will help. I'll gladly commit this if nobody has a problem with it, but I first have to be sure it's not changing retail behavior (or if it is, the change is SO small as to be unnoticable). As you can see, I've put a lot of thought into this, so now I need a second opinion. To summarize: High values of $Damp cause weird unnatural sideslipping, with ever-increasing speed. Changing the 0.0f to pi->side_slip_time_const fixes the problem by applying to all three axes instead of ignoring Z. The result of this change is PROPER momentum... I think [V] intended this originally, then changed the Z's pi->side_slip_const to 0.0f to try and fix something else without realizing the problem. Also, very high values of $Damp now are nearly Newtonian, which is awesome. I mean seriously, you've got to try it to see the potential. | ||||
| Tags | No tags attached. | ||||
|
|
No really, don't be scared off by all my text! :-D Ask questions if you don't understand, please. I just thought of a problem -- would such a change affect multiplayer compatibility, since ships would be using $Damp differently? Or is that handled by the server? On the other hand, I also noticed physics_predict_pos (and vel) already applies pi->side_slip_time_const (damp) to X, Y, _and_ Z... so my change would bring behavior in line with what AI predicts (I think). |
|
|
Woo, finally on a different ISP that can connect to Mantis again! This issue is resolved, I committed the fix to HEAD a month ago. Wasn't sure if I should do it to 3.6.9 branch as it's only SORT of a bug, so I haven't. Fortunately nobody has gone "holy crap you broke it all." Properly working $Damp using high values is awesome. It's no Independence War, but it's about as close as FreeSpace can get using existing table options, and still it remains flyable by the sort of people who didn't like fully-newtonian physics. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-09-16 00:50 | Backslash | New Issue | |
| 2006-09-20 07:50 | Backslash | Note Added: 0006655 | |
| 2007-03-14 12:36 | Backslash | Status | new => resolved |
| 2007-03-14 12:36 | Backslash | Fixed in Version | => 3.6.10 |
| 2007-03-14 12:36 | Backslash | Resolution | open => fixed |
| 2007-03-14 12:36 | Backslash | Assigned To | => Backslash |
| 2007-03-14 12:36 | Backslash | Note Added: 0007845 |
