New Orbiter Beta Released (r.44, Dec 5 2015)

[STS]

I think that issues related with Orbiter Sound should not be reported here, because this issues are related with the addon.

 

[Blake]

I did some searching but came up empty. Is the missing runway at Cape Canaveral a known issue? Or am I missing something.

I have the latest beta and the EarthLo.zip textures.

 

[DaveS]

I did some searching but came up empty. Is the missing runway at Cape Canaveral a known issue? Or am I missing something.

I have the latest beta and the EarthLo.zip textures.

The SLF runway base object has been deleted and the texture is now part of the hi-res KSC/CCAFS textures.

 

[martins]

Committed r.38

Change log:

1. DeltaGlider: light controls moved into light subsystem, airlock controls moved into pressure control subsystem
2. Default reentry plasma particle stream: parameters tweaked for onset at higher altitudes
3. Enceladus: config file now references format-2 texture set. Enceladus textures removed from repository (instead included in external MinorBodies pack)

Notes:

• This beta references a new texture set for Enceladus, no longer included in the repository. You need to download and install the updated MinorBodies texture pack from here for this beta. No other texture packs have been modified.
• There is a new OVP commit (41) to go with this beta. It includes the modifications for the reentry stream parameters.

Martin, is ticket 601 of any priority? I believe this one dates all the way back to the Dec. '02 build as that was the first build that this was implemented in.

Please let me know if the behaviour in the new beta is an improvement. The reentry effects should now kick in above 80km for a reentry from LEO, and terminate earlier than before. The parameters are pretty ad-hoc, so I can't really say if this bears any resemblance to reality.

 

[Ripley]

...There is a new OVP commit (41) to go with this beta...

How do I download it?

I have this link but looking at the date I guess it's an old one:
http://sourceforge.net/projects/orbitervis/

 

[martins]

Ho do I download it?

I have this link but looking at the date I guess it's an old one:
http://sourceforge.net/projects/orbitervis/

No, this is correct. Why do you think it's old?

 

[Ripley]

Because download button says "141222", and "Last update" says 2015-02-28.

 

[DaveS]

Because download button says "141222", and "Last update" says 2015-02-28.

OVP is just an SDK for the external graphics clients. It isn't intended for end-users.

 

[martins]

Because download button says "141222", and "Last update" says 2015-02-28.

Ah yes, sorry. The compiled package hasn't been updated for a while. I'll fix that once the next release is out. For now, you have to check out the sources from the SVN repository and compile yourself. But as Dave said, unless you are writing a graphics client, that shouldn't be necessary.

 

[Ripley]

Ok, I'm not writing a graphics client.

It was a few years back (and it was just for the sake of doing it), but I remember I tried the default D3D7 external client via orbiter_ng.exe, and I didn't compile anything.

It is this I was thinking about.

 

[AssemblyLanguage]

The SLF runway base object has been deleted and the texture is now part of the hi-res KSC/CCAFS textures.

Are the KSC/CCAFS textures separate from EarthHi_10_08.zip from the Map Picker? Earlier there was a mention of making a KSC textures subset for the Orbiter2015 Beta. Has that happened?

 

[Blake]

Are the KSC/CCAFS textures separate from EarthHi_10_08.zip from the Map Picker? Earlier there was a mention of making a KSC textures subset for the Orbiter2015 Beta. Has that happened?

It is part of EarthHi_10_08.zip, I just downloaded it and it works.

Is it the intent to have the KSC runways in the 'base' version? And I recognize that 'base' version is probably not really defined at this point. I would like to publish scenarios that don't require downloading hi-res textures if possible.

 

[martins]

Yes, the plan is to package in the basic installation a set of moderate resolution Earth textures (similar to what is bundled in the default 2010-P1 package), but also to include the KSC area at maximum resolution.

 

[fred18]

Hello,

I am very sorry to get back to the touchdown points but this thing is driving me crazy...

I used the parameters of Atlantis, I defined a convex hull and at least the rocket does not sink into terrain anymore and does not gets flipped inside the terrain.

I still have two major issues that I really don't know how to solve, I've been trying and trying...

First: when I start to fire the engines the rocket makes a bounce and start to lean on it's side, even if the touchdown points are defined some 100 meters laterally to have maximum stability... so even if it still not in flight it starts to move around and not stay in vertical.

Then when engines reach the maximum the rocket lifts off. I then cutoff the engines immediatly to see how it will land. It gets back on the ground, bounce for a bit and then stop bouncing and start to slowly drift around on the ground, like it was on an big ice plate and never never gets back to idle status. I've left it there for a long while to be sure... it moved some kilometers away from the landing point, but never got back to idle...

I increase surface friction, I gave 3 as isotropic friction coefficient but still looks like there is nothing I can do to stop it from being in "active" status.

I also made a test with default atlantis: press + to just raise it, then cutoff the engines and jettison boosters to let them and to let the shuttle fall down. It got to idle one time out of 5, and in the other 4 I got very absurd behaviour, like jumping as high as 100 km and then back down, or got threw in deep space faster than light :idk:

I think that to avoid all these I'll create a ghost module landed on earth to which the rocket attaches when landed, but it's a hack, not the solution

Help

 

[DaveS]

I have done some testing on ticket 601, the re-entry plasma and things are a bit better now. Only thing really is to move the particle stream further behind to create the plasma trail.

Here's a video of Atlantis overflying Mexico for the final time:

To really improve the default Atlantis, I would suggest that you update this old add-on: [ame="http://www.orbithangar.com/searchid.php?ID=1804"]Atlantis Mod 15a[/ame]

 

[Zach121k]

The one thing simulators lack is a google earth like texture pack... Only some areas are accurate... hoping the hi res makes some things better

 

[fred18]

To give a better explanation of some of the difficulties I am encountering:

I have a function in my module that resets the vehicle, it is fairly simple, I'll simply describe it because various sections of the code are involved:

- I have a Vesselstatus2 declared in my class.
- I GetStatusEx to that vesselstatus in clbkPostCreation in order to have euler angles, fuel status etc available
- I set the touchdownpoints in a functions called "VehicleSetup" which is basically the clbkSetClassCaps but called in late clbkLoadStateEx since I need to read info from the .ini file so I cannot do it earlier.
- When the reset function is called:
1) Everything gets cleared, mesh, thrusters etc.
2) ini file is parsed again
3) vehicle setup is run again (SetTouchDownPoints is called again)
4) clbkSetStateEx is run to set the status as the status saved earlier in clbkPostCreation

So touchdown points are reset to the same values, vessel status gets restored with relevant rotation matrix etc, so it needs to get back exactly where it was right? (it works in 2010P1 perfectly)

but this is what I get each time I call the reset: a progressive turn of about 45 deg. This are just the first frames, but it goes all the way around the clock if keep resetting.

I even tried to force the SetRotationMatrix and the SetGlobalOrientation, and I see the vehicle at least pointing the sky for a fraction of second but then it instantaneously gets down again.

Even the "old style" call SetTouchDownPoints generates something like this.

I don't know if it is a bug or if I am missing something, I'm sorry to bother, it's just that I've tried everything to solve it but without success. Even the idea of creating a launchpad vehicle generates the same issue, but this time from the very beginning, without the needing of reset

Thanks in advance for any help. If it is a bug I'm happy to report so it is possible to work on it, if it is my fault I apologize in advance!

Fred

 

[Zach121k]

Any way we could add more maneuverability to the camera... using all three axis... 2D rotation would help a lot...

 

[martins]

- I have a Vesselstatus2 declared in my class.
- I GetStatusEx to that vesselstatus in clbkPostCreation in order to have euler angles, fuel status etc available
- I set the touchdownpoints in a functions called "VehicleSetup" which is basically the clbkSetClassCaps but called in late clbkLoadStateEx since I need to read info from the .ini file so I cannot do it earlier.
- When the reset function is called:
1) Everything gets cleared, mesh, thrusters etc.
2) ini file is parsed again
3) vehicle setup is run again (SetTouchDownPoints is called again)
4) clbkSetStateEx is run to set the status as the status saved earlier in clbkPostCreation

I am not really entirely sure I understand the program flow applied here, but from your description of the problem it seems that there is an inherent numerical instability somewhere.

One possible cause of the problem you describe could arise if you recalculate the touchdown points according to the rotation matrix for your vessel you retrieve from Orbiter. Note that due to the compressibility of the touchdown points, the touchdown points you define in the code do not coincide exactly with the surface in the vessel frame, but will end up slightly below the surface. And if the mass distribution is not exactly symmetrical with respect to the arrangement of the touchdown points (which it will never be in practice), then this will also result in a small tilt (i.e. some touchdown points more compressed than others.)

If you now recompute the touchdown points according to the vessel rotation matrix to place them exactly back onto the surface (i.e. undoing the compression), Orbiter will then reapply the touchdown point compression, including the resulting tilt. If you do this repeatedly, the touchdown points will be displaced further and further, until the rocket topples over. Is it possible that this is what happens?

 

[Loru]

The one thing simulators lack is a google earth like texture pack... Only some areas are accurate... hoping the hi res makes some things better

That issue has been already discussed. Earth imagery would take much more disk space. Can you provide hosting for 200TB?

martins' quote from Texture thread

Florida in general, and KSC in particular use higher texture resolutions in the current texture pack than the rest of Earth's surface. For the global Earth textures, I generated textures based on Landsat-7 scenes. Landsat 7 support 30m resolution (15m with pan-sharpening). I am currently not using the full resolution potential. I could probably go still one level higher (without having to use pan-sharpening) or two (with sharpening), resulting in a global texture package of 200GB or 800GB, respectively (zipped). However, processing the raw Landsat images is quite processor-intensive, and based on current experience, it might take me several months of full-time number-crunching to generate those textures. Since the resulting download size might be prohibitive for most users (not to mention the cost of hosting the downloads), it won't happen very soon.

For Florida, the textures are based on aerial imagery (digital orthoimage quarter quads) available for most of the USA at varying quality, but not for the rest of the world. Global high-resolution imagery is very expensive (typically > $10^5) so not really an option here. If you have a source for royalty-free high-resolution textures, you are very welcome to generate (and hopefully share) a texture set from it. Be warned though: a global texture set at the resolution of the current KSC textures would take up roughly 200TB (zipped) and several PB (after installation), at a crude estimate.

So in short: yes, NY is not supported at the same resolution as Florida in the current texture pack, and this isn't likely to change.