Bug #198: Shocks / shocks2 boundary limit spring&damp values - Rigs of Rods - Redmine

Bug #198

Shocks / shocks2 boundary limit spring&damp values

Added by Lifter about 2 years ago. Updated about 1 year ago.

Status:

Merged

Start date:

03/20/2010

Priority:

Normal

Due date:

Assignee:

tdev

% Done:

100%

Category:

RoR - Physics

Target version:

0.38

Operating System:

All

Operating System Bits:

Description

This is a bugfix for shocks and shocks2, they used the wrong values when calculating boundary limit spring and damping ratios

Old version: DEFAULT_SPING & DEFAULT_DAMP used when a boundary was hit
Patched version: shocks & shocks2 use sbd settings instead of ror default ones.
Tested with various setups, works good. Interaction with estamas softbump feature for shocks is good too.
This does not brake any existing truck afaik, but i am not able to test them all.
I can make it optionable if needed, just let me know.

All info you need: http://forum.rigsofrods.com/index.php?topic=32635.msg307297#msg307297

sbd-for-shocks-1-0.patch (3.5 kB) Lifter, 03/20/2010 04:45 pm

History

#1 Updated by tdev about 2 years ago

Status changed from New to Researching
% Done changed from 0 to 20

was estama's suggestion integrated into the patch?

#2 Updated by tdev about 2 years ago

Status changed from Researching to requires improvement
Assignee changed from tdev to Aperion
% Done changed from 20 to 30

tdev wrote:

was estama's suggestion integrated into the patch?

seems not to be the case... :-/
needs to be done, then it can be mreged

#3 Updated by Aperion almost 2 years ago

Status changed from requires improvement to requires testing

investigating this, but when implementing what estama suggested results in segmentation faults due to beams[i].shock being null... no idea why this would happen, investigating.

Rereading Lifters comments show what the problem is, there are some beams that use SHOCK1 bounds but do not use a shock struct. Honestly this whole section needs to be reworks, it's ugly, hard to read an very branchy.I'm inclined to say merge lifters version as is, at least that way correct behaviour is present when this code is refactored.