View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0001818 | Spring engine | General | public | 2010-02-02 10:03 | 2010-02-10 00:24 | ||||
Reporter | tvo | ||||||||
Assigned To | tvo | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Product Version | 0.81.1.3 | ||||||||
Target Version | 0.81.2 | Fixed in Version | 0.81.2 | ||||||
Summary | 0001818: XTA hovercraft are broken | ||||||||
Description | For some reason XTA hovercraft behave completely broken in new engine version: when steering, they make almost full barrel rolls etc. How to reproduce: - Create hoverlab - Create e.g. a construction hovercraft - Move it around in circles - Notice how it sometimes even hovers upside down (may have to do with 'upright' not getting set by engine?) May be mod bug but since it used to work in 0.80.5 I'm reporting it anyway. | ||||||||
Tags | No tags attached. | ||||||||
Checked infolog.txt for Errors | |||||||||
Attached Files |
|
![]() |
|
Kloot (developer) 2010-02-03 16:18 Last edited: 2010-02-03 16:19 |
I tracked updir for arm_construction_hovercraft and arm_anaconda and it never deviated from <0, 1, 0> even on sloped terrain (as expected, engines forces upright to true for all units with hovercraft movetypes). Seems more like the COB code responsible for their "wobbling" (probably just some z-rotate calls applied to the root piece) is interpreted differently. |
tvo (reporter) 2010-02-07 11:26 |
See also: http://springrts.com/phpbb/viewtopic.php?p=411787#p411787 |
tvo (reporter) 2010-02-09 09:54 |
See also: http://springrts.com/phpbb/viewtopic.php?f=12&t=22085 |
Kloot (developer) 2010-02-09 15:41 Last edited: 2010-02-09 15:51 |
Adding the following line right at the start of CUnitScript::TurnToward (before delta is calculated) ... dest = ClampRad(dest); ... restores old rolling behavior. Seems that the turn destination angle can lie way outside the range [0, 2PI] due to scripting bugs; tracking the value of dest throughout the animation scheduler showed values of +10 radians when hovercraft starting doing barrel rolls, whereas sane values (~[-1, 1] radians) appeared only when they were upright again. Probably this regression just resulted from the removal of a clamp call somewhere that was masking such bugs until now. |
tvo (reporter) 2010-02-09 20:52 |
Hmm interesting. The strange thing tho, is that this is the _complete_ diff between 0.80.5 and 0.81.3 of the Units/COB directory: $ git diff 0.80.5..0.81.1.3 -- rts/Sim/Units/COB/ diff --git a/rts/Sim/Units/COB/CobThread.cpp b/rts/Sim/Units/COB/CobThread.cpp index 23a111f..ad389ed 100644 --- a/rts/Sim/Units/COB/CobThread.cpp +++ b/rts/Sim/Units/COB/CobThread.cpp @@ -47,6 +47,7 @@ void CCobThread::SetCallback(CBCobThreadFinish cb, void *p1, void *p2) //it is expected that the starter is responsible for ticking it. void CCobThread::Start(int functionId, const vector<int> &args, bool schedule) { + wakeTime = 0; state = Run; PC = script.scriptOffsets[functionId]; |
tvo (reporter) 2010-02-09 21:20 |
There are only 'skip'ped commits left to test. The first bad commit could be any of: a1c92dfe9d2aafc1e9f44439ad530f758faeac98 65a8593768a2e35801403091bb217daa167b5971 We cannot bisect more! Those commits are: 'some additional gcc const & pure attribute flags in myMath.h' 'double underscore is reserved for compiler vendor! fixes compilation on GCC 4.4' So, this is caused also by the __attribute__((const)) commit. Must have been the most breaking commit between 0.80.5 and 0.81.1.3 :-) |
Kloot (developer) 2010-02-09 21:46 Last edited: 2010-02-09 21:46 |
O_O "Interesting" that this bug happens for both gcc 4.3 and 4.4 though, since the desync was only between 4.3 + O2 + const versus 4.4 + O2 + const (and not 4.3 + O2 alone). In any case I think we can consider __attribute__(const) thoroughly broken ;) |
tvo (reporter) 2010-02-10 00:24 |
Not necessarily (not because of this particular bug at least). In this case __attribute__(const) was applied to a function having a pointer argument (i.e. ClampRad(float*)), and gcc manual says explicitly: "Note that a function that has pointer arguments and examines the data pointed to must not be declared const." Nevertheless it is obvious __attribute__(const) and __attribute__(pure) must be applied with care (and lots of testing) ;-) |
![]() |
|||
Date Modified | Username | Field | Change |
---|---|---|---|
2010-02-02 10:03 | tvo | New Issue | |
2010-02-03 16:18 | Kloot | Note Added: 0004593 | |
2010-02-03 16:19 | Kloot | Note Edited: 0004593 | |
2010-02-07 11:26 | tvo | Note Added: 0004613 | |
2010-02-07 11:38 | tvo | Target Version | => 0.81.2 |
2010-02-09 09:54 | tvo | Note Added: 0004620 | |
2010-02-09 15:41 | Kloot | Note Added: 0004623 | |
2010-02-09 15:41 | Kloot | Status | new => feedback |
2010-02-09 15:42 | Kloot | Note Edited: 0004623 | |
2010-02-09 15:47 | Kloot | Note Edited: 0004623 | |
2010-02-09 15:51 | Kloot | Note Edited: 0004623 | |
2010-02-09 15:51 | Kloot | Note Edited: 0004623 | |
2010-02-09 20:52 | tvo | Note Added: 0004628 | |
2010-02-09 21:20 | tvo | Note Added: 0004629 | |
2010-02-09 21:26 | tvo | Status | feedback => assigned |
2010-02-09 21:26 | tvo | Assigned To | => tvo |
2010-02-09 21:46 | Kloot | Note Added: 0004630 | |
2010-02-09 21:46 | Kloot | Note Edited: 0004630 | |
2010-02-09 21:52 | tvo | Status | assigned => resolved |
2010-02-09 21:52 | tvo | Fixed in Version | => 0.81.2 |
2010-02-09 21:52 | tvo | Resolution | open => fixed |
2010-02-10 00:24 | tvo | Note Added: 0004631 |