Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SCRIPTING: setObserverLocation REQUIRES core.wait #3821

Open
roohif opened this issue Jul 22, 2024 · 4 comments
Open

SCRIPTING: setObserverLocation REQUIRES core.wait #3821

roohif opened this issue Jul 22, 2024 · 4 comments
Labels
enhancement Improve existing functionality

Comments

@roohif
Copy link

roohif commented Jul 22, 2024

I am using Stellarium to extract data in a "batch" fashion, if you know what I mean. So I am changing location, and then grabbinhg some attributes for the Sun/Moon, and then changing location again.

For example:

core.setObserverLocation("Sydney, Australia", 0)
var thisMoonAlt = core.getObjectInfo("Moon")["altitude"]

core.setObserverLocation("Perth, Australia", 0)
var thatMoonAlt = core.getObjectInfo("Moon")["altitude"]

What I'm seeing a lot is thisMoonAlt == thatMoonAlt. It's like Stellarium hasn't yet processed the move of the observer, and is giving me the old value. I've seen a lot of code online that says I need to add core.wait() to give it time to catch up, but I guess I was hoping that there was some way to force it to block until the location has been processed .. ?

@gzotti
Copy link
Member

gzotti commented Jul 22, 2024

No, that lot of code online and in our own documentation does what we recommend for such cases. Add a core.wait(0.1) or so to give it time to catch up, i.e., allow one frame drawing cycle, else you are updating the location without actually computing anything. If there was an alternative, it would have been documented.

@10110111
Copy link
Contributor

Would it be possible to emit some kind of signal like frameStarted for the JS code to connect to?

@gzotti
Copy link
Member

gzotti commented Jul 22, 2024

You mean, adding core.wait(SignalName) instead of just waiting a short time? Maybe. This might be helpful to minimize the waiting delay. Such signal could be emitted after all computations are done and drawing begins. However, some computations are done during drawing, so maybe rather add and connect to a signal 'nextFrameComplete' (hard to foresee intermixed frame counters?) or use a counter initialized with 2 and counting down, to compute&draw 2 frames before returning the numbers. The core.wait(smallDelay) is a solution that at least works now and has worked since 2012 or so. Feel free to optimize! I think some command to be given manually to yield processing to the main loop is unavoidable.

@alex-w alex-w added the enhancement Improve existing functionality label Aug 21, 2024
Copy link

Hello @roohif!

Thank you for suggesting this enhancement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve existing functionality
Development

No branches or pull requests

4 participants