Search results

I believe I have one. I can look in my Skylab folder tonight. You might try asking on the NASSP discord too. Someone may be able to get it to you quicker. It's in one of the handbooks/operational data book, iirc.

Isn't there an omnidirectional mode? Could save on your light budget a bit.

For actual flown missions, if you wanted saved scenerios by far the easiest solution would be to just fly from launch and save along the way. This is almost certianly less work (and probably more fun) than trying to propagate that with all possible perturbations.

The Orbiter.exe (non NG) version, is using dx7 still. Most likely your hardware can't support dx7, or can't support it at the resolution you're trying to run it at. The DX9 client is included in O2024, and is kind of the de facto standard now.

100% agree. I can't remember if we have github permissions to do this, but if we do, we should require reviews before merging. At least one reviewer should checkout and build the changes themselves, before approving and before the code gets merged into main. Every merge commit to main, should...

Please read: If you are in the middle of flying a mission, do not update NASSP without performing the fix listed below: This change: https://www.orbiter-forum.com/threads/v8-release-work-thread.36128/post-621001 intruduced IMU drift rates and PIPA bias/scale error. Recently we discovered a bug...

Given, that this fixed it. It seems like the cause could likely be Windows serving up the wrong zlib. I  believe https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer can show which DLLs which process is using.

I don't suspect you'll have much trouble with accuracy over time. The error source here will be in the round-off in simdt, and in the calculation. There's a good chance that this will be more accurate than the physical mechanism even with large time steps and a simpler Eüler's method incremental...

Any chance you copied Orbiter, rather than just making a shortcut to it? I am not aware of anyone else having this issue so far.

@diogom Could you post your code? clear; clc; function l = GlobusLong (t, inclination) l = 0; if(t >= 0.0 && t < 0.25) l = ((atan(cos(deg2rad(inclination)).*tan(2*pi.*t))))/(2*pi); elseif(t >= 0.25 && t < 0.75) l = ((atan(cos(deg2rad(inclination)).*tan(2*pi.*t)))+pi)/(2*pi)...

I think the error is between expected instrument output and the implimentation, not between Orbiter and the inplimentation.

I'm not a heavy user of Lua, so I may not be the best to weight in. However, part of the motivation in releasing Orbiter 2024, was to create one last, stable amalgamation of all the x86 fixes. Now that we've done that, I think we should move ahead with modernization and features.

I'm unable to replicate the crash on my end, however, this is what I get break-pointing ZTreeMgr::Inflate() on the first call. The only change I can see to ZTreeMgr.cpp in the git-blame since Orbiter was added to Git, was...

Actually, this too. An intermittent access violation is a smoking gun here. Uninitialized pointer math or something horrifying like that...

@CaptainSwag101 is this related in any way to the issue that /LARGEADDRESSAWARE fixes? It's happening for at least 3(?) people.

NASSP officially only supports Beta right now. Work is underway to support Orbiter 2024, but we don't officially support it yet. When we do, there will be a big announcement post.

Did you do: git submodule init After you cloned?

Did you, by any chance download the code from github, rather than the release? We're there any .dlls in the zip you downloaded?

could you post the log?

The very next thing it is going to try to load is moon.dll. If you remove the moon from your sol.cfg do you still get the crash?