OHM SR-71-R 1.2.1 (for Orbiter 2016)

[Abdullah Radwan]

Don't worry. Nothing will happen if XRSound isn't installed. XRSound handler inside the code won't be null even if XRSound isn't installed (Great thing from XRSound developers). I've tested the aircraft with XRSound disabled and it works without problems.

There are no external sound files, just using default sound files that come with XRSound installation.

 

[Kyle_E]

It doesn't work well. When I open the cargo door, the sound is still running even when the door is fully opened.

Sorry the config does not work with the latest version. I wasn't going to update it until the animations get sorted out; but if you have built the sound into the code that is even better!

 

[Blake]

I have updated github with the fixes for the animation issues. I also put the new version (1.2.1) on OrbitHanger.

Touchdown points: No change. With Orbiter 2016 these are now part of a larger 'mesh' that describes the shape of the vessel. Adjusting those points with the landing gear is on my todo list.

Sound: I'll look at the sound code, but I'm hesitant to put in anything that would be specific to any sound manager. I'll admit however, I have never looked at sound and I have no idea how that works. Happy to learn. Some type of generic sound event hook, or call would be nice.

Re-entry: The procedure in the manual is just something I came up with and I have not tried that with the 2016 version. I have also not tried any of the re-entry MFDs that are available, I don't know how they would work. A re-entry program in the flight computer is something that interests me from a development stand point, so that is on the list. As well as ascent.

Flight Computer: This is a work in progress and is were my current development interest is. It just does not do much at the moment.

Documentation: <insert template developer excuse here >

 

[Abdullah Radwan]

I've sent a pull request, based on the latest commit.

Sound: I'll look at the sound code, but I'm hesitant to put in anything that would be specific to any sound manager. I'll admit however, I have never looked at sound and I have no idea how that works. Happy to learn. Some type of generic sound event hook, or call would be nice.

I can understand your hesitant because if the sound engine is no longer supported, you will have to re-write the sound code.
However, using a sound engine will make your life much easier, you have default sound files that come with every installation (Prevent duplicates), an easy to use SDK with a lot of functions, advance memory management (Important if your project is big), etc. And we don't have a new Orbiter version every week :rofl: so it doesn't worth to use a generic solution.

If you still want a generic solution, you have Enjo MFDSound++ library. It's based on Windows SDK so the sound works without any need to external engines. But it's very limited and doesn't contain advanced functions.

Re-entry: The procedure in the manual is just something I came up with and I have not tried that with the 2016 version. I have also not tried any of the re-entry MFDs that are available, I don't know how they would work. A re-entry program in the flight computer is something that interests me from a development stand point, so that is on the list. As well as ascent.

To re-enter, you need BaseSyncMFD to align the base, and AerobrakeMFD to perform the actual re-entry. AerobrakeMFD shows the expected trajectory to the touchdown based on AoA, as well as many useful data. It needs a data file for each vessel class. The way to create a data file described in the manual.

Documentation: <insert template developer excuse here >

Documentation is very important. Without proper documentation, you are the only one who can use the vessel :lol:
I understand how bad writing a manual is, but it's really necessary for other users.

---------- Post added at 09:31 PM ---------- Previous post was at 09:12 PM ----------

Even with the updated, the gauges still not correctly displayed. Hover doors and airbrake are good.
Photos:
LH2 indicator doesn't appear.

LOX indicator is a little below the white dot (assuming it's the mounting point).

 

[Blake]

That is odd, I'm not seeing the gauge issue in D3D9 client, or inline. I may have an older client, let me update and try again.

 

[Abdullah Radwan]

The VC mesh in deploy folder isn't updated in the last commit. Don't forget to update it!

 

[Blake]

It appears to be correct in github. I created a new zip and updated Orbit Hanger with the latest, let me know if that helps. I still need to get the latest D3D9 client and test.

 

[Abdullah Radwan]

It appears to be correct in github. I created a new zip and updated Orbit Hanger with the latest, let me know if that helps. I still need to get the latest D3D9 client and test.

I'll re-clone and see if the bug is fixed.

Currently, I've noticed 2 bugs in save state:
1. Pitch trim isn't saved.
2. RCS isn't saved correctly. It always on LIN.

 

[Abdullah Radwan]

Also, something very odd happened. Suddenly all gauges show 0, and I can't move any switch. Scenario file is attached.

 

[Abdullah Radwan]

A more precise description: All gauges and switches move to their lowest position and it can't be moved. It happened suddenly while wrapping time in orbit. Photo:

Another bug: External supply status isn't saved.

 

[Abdullah Radwan]

I am currently implementing more sound stuff (such as crossfeed, fuel dump, filling tanks, etc).

I've noticed that when RCS tanks are depleted, transfer button still illuminating. It should be turned off since there is no fuel in the tank.

Any comment on the bug above? The vessel is unusable in orbit.

---------- Post added at 10:18 AM ---------- Previous post was at 09:52 AM ----------

I am currently testing the sound, once it's done, I'll send another pull request.

I've noticed another bug: Fuel cell draws electric power even if LOX is depleted. It should be turned off once the LOX and LH2 are depleted.

 

[Blake]

I have started creating some issues in github to look at these.

If the RCS tank is empty, you can transfer from Main back to RCS. That should work, but I'll take a look. This also may be a difference between inline and D3D9 graphics clients. I don't have the latter setup for debug just now.

Sound:
Thanks for your work on sound. I'm looking at your code, but would like to implement it in a different manner. I should have more time this coming weekend to take a closer look.

 

[Abdullah Radwan]

Thanks for your work.

Some notices:

1. LOX tank is too small or the consumption rate is too high. I ran out of LOX halfway between Moon and Earth. The 'unusable bug' didn't happen on a flight from Moon to Earth.

2. The battery has unlimited time. It should be limited to 2 hours for example.

3. Aileron is too slow. I am not an SR-71 pilot, but it's too hard to control the roll. I am not sure if it's mine or the plane.

4. The vessel is underground in Moon landed scenario.

Suggestions:

1. Add a parking brake. There is an empty slot in the lights panel. Label, for example, is PARK or PRK, and the shortcut is P. In VC it might be a handle. It should write to HUD as well.

2. Texture the untextured area in the cockpit. Just a brown or black texture is enough for now, much better than gray.

3. Add a docking RCS mode, such as XR-5. Currently, docking is too hard with docking port in the cargo bay.

Regarding the RCS tank:
I meant if you want to cross-feed from RCS to main and RCS tank is depleted, transfer button is still illuminated. It should be turned off as there is no fuel in RCS tank. Probably 'isTransfering_' is still true even the tank is depleted.

 

[AnakinSkyobiliviator]

Okay, I'm one notch less of a noob now and you'd be glad to hear your Chasing Down ISS scenario is my first ever dock with the ISS from the chasing stage from any craft ever!
That said, I've updated to the most current version and got a runtime error..it seems to be tied to the flight computer.

 

[Blake]

Okay, I'm one notch less of a noob now and you'd be glad to hear your Chasing Down ISS scenario is my first ever dock with the ISS from the chasing stage from any craft ever!
That said, I've updated to the most current version and got a runtime error..it seems to be tied to the flight computer.

I'm glad that scenario was helpful.

If you can post the error and what you were doing I can take a look.

 

[AnakinSkyobiliviator]

If you can post the error and what you were doing I can take a look.

That would be under Orbiter.log, right? If so the only error I have is

000000.000: ---------------------------------------------------------------
000000.000: >>> ERROR: DDraw error DDERR_BLTFASTCANTCLIP
000000.000: >>> [OrbiterGraphics::clbkBlt | .\OGraphics.cpp | 1633]
000000.000: ---------------------------------------------------------------

But that might not be it. To specify, everything is going fine until I hit enter on the flight computer.

 

[Blake]

But that might not be it. To specify, everything is going fine until I hit enter on the flight computer.

Thanks, I can duplicate on my system, so I'll take a look this weekend.

 

[AnakinSkyobiliviator]

Hi, it has been a while and it looks like Orbithangar looks significantly different from what it used to be, is this project still alive?

 

[Sbb1413]

The OHM had shown its age in many ways. We are fixing them step by step. Quoting @Xyon for why:

First, OHM is currently badly broken, most notably when you try to submit a new addon. Some of the reasons for why this is I have already been through, but the short version is, the site needed some intensive work and effort to bring it back to a point where it could function on the current technology platform (with noted security fixes), and then to improve some long-standing issues that have often been significantly limiting for end-users. The new site utilises Digital Ocean's geo-CDN caching for addon assets, meaning wherever you are in the world, the asset should be somewhere vaguely near to you - definitely closer to users in APAC than they have been up until this point.

The REST API is the central technology, and I've been writing it on and off in Rust for the best part of three years, if my git commit history is to be believed. It's an ongoing labour of love, but crucially is also licensed under the GNU GPL v3 license, and the source code is open to those who wish to view it. It's my hope this will encourage contribution, and perhaps in time to transform the project from a personal endeavour into a community project - to avoid the code languishing in the future, as the old site did.

 

[AnakinSkyobiliviator]

The OHM had shown its age in many ways. We are fixing them step by step. Quoting @Xyon for why:

I see! Good to know, thanks for the heads up! Though I still hope that this addon will see a continuation in the future after it gets fixed!