Search results

That's awesome. Are you developing this like an API/header that could be added to any vessel?

@GLS: I've resolved the merge conflict, and created an amalgamated branch of both commits, rebased on top of the current orbitersim/main. I can't get the MikTex part of teh equation to work for me right now, so double check that. https://github.com/n7275/orbiter/tree/latex_doc_update_fixd You...

Let me see if I can untangle this one with a combination of rebasing and cherry-picking. Documentation is the only thing left for the release so hopefully this isn't too hard.

I briefly looked through the code and it doesn't look like the celestial sphere markers use the quad-tree format, unless I'm missing something not obvious. Regarding keeping branches up to date, this is why I keep my own fork of projects I work on--not that this is the only way to do it. I...

@GLS, list of new features: probably needs some cleanup

Ahh you are correct, I'm forever stuck in cis-lunar mode haha. This is more brainstorming than advice. Realistically, the only way I think you could do this would be to add some relativistic functionality into the Orbiter core. Orbiter runs on a Barycentric Dynamic Time clock, internally. I...

Direct link to paper.

You might want to take a look at how we do this in NASSP. The Omni and HGA classes have examples: https://github.com/orbiternassp/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_csm/csm_telecom.cpp On a simple level the two antennas have pointing vectors, and if they point at each...

That would be in the atmospheric controls for d3d9 client. in the f4 menu. There are several "profiles". it's a challenge to make something that works in all cases.

Hello and welcome, The wiki largely hasn't been updated since 2007ish and is very out of date in a lot of ways. We actually rescued it from its old sourceforge-hosted site a few years ago, so we're lucky we have it at all. I have tried to update some parts of it here and there, but it's an...

The upcoming release will be 32 bit only. Future versions will transition to 64 bit once we work out some issues with it.

You could change changeing the emissivity/difuse color of the mesh. or change the alpha chanel of a "light" texture, on the actual light mesh.

If you're using the OpenOrbiter builds off of github, there is no need to install D3D9 client, it comes prebundled with Orbiter, same for XRSound.

This is a known problem. I am making this post here (hopefully we can sticky it), as both a notice, and someplace we can link people to when they run across this issue. For developers: the issue and the fix are known, so hopefully this saves someone a few hours of troubleshooting. 64 bit Builds...

The issue should occur with 64 bit only. The moons of Mars, Uranus, and Neptune, do not have source code, and so when orbiter "builds", them the build process is just copying them to a release folder. these were written circa 2005 by (I believe, not 100% sure) someone other than Martin, and...

If you have Intel IRIS Xe integrated graphics, Orbiter 2016 and prior will not work. We are very close to releasing the next version of Orbiter. So, hold out for the 2024 release.

Agreed. Not a 2024 feature. This is already technically possible and NASSP already has a "free cam". This should have its own thread before we get too far off topic though.

Radians would be the natural unit of angle to work in. My opinion is that anything in degrees should specify that usage as part of the function name, just to be super obvious.

Could you post a screenshot with antialiasing enabled?

Ostensibly, nothing. If there is anything that doesn't work it would be due to the fact that AMSO was originally linked against the Orbiter 2016 libraries. afaik no virtual functions changed, so it  should be okay, no guarantees though.