Win-1.3.1Final-CEL - Chase, Follow, Synchronous broken

[don]

Windows, ver. 1.3.1 Final, CEL Scripting

It appears that Chase, Follow, and Synchronous are all broken. They result in the display of the object immediately being placed 200+ au away, regardless of the current distance.

Would someone please verify this by running the following script, un-commenting each of the commented lines and testing, one at a time (re-commenting when done with the previous command)?

Interestingly enough, if either of the 3 commands are placed between the select and goto commands, they DO work properly. But, adding a select command before any of the 3 commands in their current location does NOT work. A cancel must be included <sigh>.

Thank you.

-Don G.

Code: Select all

{
 cancel {}
 select { object "Sol/Earth" }
 goto { time 5 }
 wait { duration 5 }
 #chase {}
 #follow {}
 #synchronous {}
}


[selden]

Don,

1. I can confirm that your script jumps to 206.22 AU if it is used to launch Celestia.

2. Your script jumps to 206.22 AU if the script is invoked by clicking while Celestia is already running looking at Io.

3. If you increase the wait duration to 6

3a. your script jumps to 206.22 AU if it is used to launch Celestia.

3b. Your script works if the script is invoked by clicking while Celestia is already running -- looking at Io or at 206.22 AU.

[Harry]

3. If you increase the wait duration to 6

3a. your script jumps to 206.22 AU if it is used to launch Celestia.

3b. Your script works if the script is invoked by clicking while Celestia is already running -- looking at Io or at 206.22 AU.

I can confirm the bug with a duration of 5s, but can't confirm it for wait duration > 5 on Linux. The behaviour you see is probably due to a problem in the windows-version (don knows what I am talking about .

Harald

[don]

Howdy Gents,

Thank you for your testing!

Further information...

If the wait duration is equal to or less than the goto duration, this bug happens.

However, if the wait duration is greater than the goto duration (even by only 0.1), then the bug does not happen.

Can you confirm this also? Especially on Linux, since it does not seem to be a "start-up delay" problem.

Thanks again!

-Don G.

[Harry]

Can you confirm this also? Especially on Linux, since it does not seem to be a "start-up delay" problem.

Yes, that's exactly what I am seeing.

Harald

[Harry]

Found bug & got possible fix:

Celestia isn't updating the journey.from & journey.to positions when changing frames of reference. You start with Universal frame (due to cancel { }), and finish using Ecliptical (follow), but the positions are still those needed for universal frame, sending you 206 au away. The same bug has following effect:

Select Earth
goto Earth: Press g
Select other planet (say mars).
follow Mars: press f, while still travelling to earth

celestia will go to mars instead of earth (you may notice a sudden jump when changing frame-of-reference to mars).

Possible fix:
Replace Observer::setFrame by:

Code: Select all

void Observer::setFrame(const FrameOfReference& _frame)
{
    RigidTransform transform = frame.toUniversal(situation, getTime());
    RigidTransform from, to;
    if (observerMode == Travelling)
    {
        from = frame.toUniversal(RigidTransform(journey.from, journey.initialOrientation), getTime());
        to = frame.toUniversal(RigidTransform(journey.to, journey.finalOrientation), getTime());
    }
    frame = _frame;
    situation = frame.fromUniversal(transform, getTime());
    if (observerMode == Travelling)
    {
        from = frame.fromUniversal(from, getTime());
        journey.from = from.translation;
        journey.initialOrientation = Quatf((float) from.rotation.w,
                                           (float) from.rotation.x,
                                           (float) from.rotation.y,
                                           (float) from.rotation.z);
        to = frame.fromUniversal(to, getTime());
        journey.to = to.translation;
        journey.finalOrientation = Quatf((float) to.rotation.w,
                                         (float) to.rotation.x,
                                         (float) to.rotation.y,
                                         (float) to.rotation.z);
    }
}


Don, can you add this to the bugracker, until chris (or anybody else who knows more about this) says it's ok? I think it is, but don't want to mess around with this code without being sure

Harald

[don]

Thank you very much Harald. It's now in the Bug Tracker.

-Don G.