Search results

I wanted to mention something on the subject of reaching out to Coolhand. I'm a bit hesitant to share this, but here goes. About a year ago, I was able to find an old email address from his website (archived) and emailed him. I got a pretty prompt response, but it wasn't really what I was...

That looks awesome!

Could you share some details on your hardware and your orbiter.log file. 2006 is quite old at this point, and is 100% DX7, so your hardware needs to support that.

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?