2025-08-01 19:05 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001818Spring engineGeneralpublic2010-02-10 00:24
Reportertvo 
Assigned Totvo 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version0.81.1.3 
Target Version0.81.2Fixed in Version0.81.2 
Summary0001818: XTA hovercraft are broken
DescriptionFor 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.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0004593

Kloot (developer)

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.

~0004613

tvo (reporter)

See also: http://springrts.com/phpbb/viewtopic.php?p=411787#p411787

~0004620

tvo (reporter)

See also: http://springrts.com/phpbb/viewtopic.php?f=12&t=22085

~0004623

Kloot (developer)

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.

~0004628

tvo (reporter)

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];

~0004629

tvo (reporter)

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 :-)

~0004630

Kloot (developer)

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 ;)

~0004631

tvo (reporter)

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) ;-)
+Notes

-Issue History
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
+Issue History