HyperDart - A new spaceplane

[Woo482]

Your missing the "Universal Remote Manipulator System, release 3 " (URMS) addon, you can find it [ame="http://www.orbithangar.com/searchid.php?ID=3373"]here[/ame]

 

[CigDriver]

Thanks Woo.

I'll make the gear stronger, I've been meaning to do that. The better option, of course, is to see if I can query the HyperDart (or what ever is attached) and add a copy of its wings to the XL while it is attached. I figure that would lower the rotate speed significantly.

I've also decided to get off my lazy butt and rebuild the VC of the HyperDart. The modeling is easy, the part I was avoiding was rebuilding all the interactive areas. After thinking about it, it isn't as bad as I'm making myself think it is Since the current VC was built with only the MFD in mind (since that is all SC3 would allow) it is a mess, now that I've established what is in there I should be able to build a much better layout.

I'm not sure on when I'll get that done, but I will release the current version in a few days. I've changed the code to disable the controls when no one is on (or alive), and I noticed that the EVA button isn't EVAing the correct UMMU. I'm not sure if this is a legacy problem I didn't notice before or if my new code introduced it. Regardless, as soon as I figure out what is going on I'll release another update with those changes and the XL gear change.

 

[halcyon]

Your missing the "Universal Remote Manipulator System, release 3 " (URMS) addon, you can find it here

Doh.

 

[CigDriver]

Ok another Beta. Here are the changes:

1. XL-70 landing gear are 25% stronger.
2. Added UMMU action area at the front edge of the bay doors to externally operate them.
3. Bay door state now controls the UMMU airlock, when the doors are open so is the airlock
4. When the HyperDart is landed the EVA and airlock position change to be beside the HyperDart...no more dead UMMUs on EVA
5. The EVA button now EVAs the selected UMMU instead of the first in the list
6. Added "cabin air" that is depleted after the air tank runs out. Now UMMUs have an exponential chance of dieing over 45 minutes after air runs out
7. The check to disable control now checks both the captain is onboard and alive
8. All new airfoils for the HyperDart. I only did a bit of testing, but she seems to fly pretty sweet now. Load up the "Mission 2 - HyperDart Glide Test" scenario and try it out.

http://www.animatedexistence.com/orbiter/HyperDart/HyperDart_PB7.zip

For the new airfoils I used this great web app I found called JavaFoil:
http://www.mh-aerotools.de/airfoils/javafoil.htm

It lets you build an airfoil (and tells you what NACA foil it is), then you can run simulations on it and get cl and cm by AoA...fantastic for orbiter airfoils.

Next up is any final tweaks due to the new airfoils then off to build the new VC for what hopefully will be one or two more betas then final

Enjoy!

 

[garyw]

Looking pretty good! Have you thought about including Kulch's Payload manager? If I recall it's just a library that you include in the dll and gives a nice range of paylaod functionality.

 

[Urwumpe]

Looking pretty good! Have you thought about including Kulch's Payload manager? If I recall it's just a library that you include in the dll and gives a nice range of paylaod functionality.

I can recommend it, I have done some small tests here, and I quite like it. I just still doesn't have a good big project for it...

Would maybe be nice to have a payload manager implementation in a Jupiter LV...

 

[Woo482]

Yep, just a library and a few functions that need coding in, and it can really add new uses to an addon.

 

[CigDriver]

I looked into it before, but I had no idea what was going on now that I have a better grasp of C++ I'll check it out again.

 

[DarkEnergy]

This project is really turning out good and I'm excited for the finished product. It is really nice to fly and gives extra selections of ships for a LEO trip rather than just the Delta Glider variants.

I just have one question at the moment about one of the features:

Added "cabin air" that is depleted after the air tank runs out. Now UMMUs have an exponential chance of dieing over 45 minutes after air runs out

After the air supply runs out, does the crew breathe air from their suits during the 45 minutes or is it supposed to just be them living off what is left? If they are breathing the remaining air in the cockpit, will each remaining crew member after the others die have a longer probability of surviving slightly longer due to one less person breathing it?

If the probability of surviving increases, it would allow people to have the chance of rescuing at least 1 person if they can get there just over the 45 minutes.

 

[CigDriver]

Currently it is a strait 45 minute supply. It was a quick fix to everyone dieing once the main air supply ran out. I'll look into making it a bit more robust. Of course, if you carry one of Dan's lifeboats it doesn't matter

 

[preacherzero]

Getting CTD on all Hyperdart scenarios when I try to load them.
No problems adding the S3 or XL70 to other scenarios.

Other then that issue I love this thing, the VC is really cool too, can't wait for the offical release, the Hyperdart could be my new favourite vessel. :thumbup:

 

[Woo482]

Check you have URMS installed (you can find it [ame="http://www.orbithangar.com/searchid.php?ID=3373"]here[/ame]) that'll cause a CTD if it's missing.

 

[preacherzero]

Check you have URMS installed (you can find it here) that'll cause a CTD if it's missing.

Perfect now:thumbup:

 

[Chupacabra]

CigDriver, I have been enjoying testing your ships. I have a recommendation however.

The Bounce bug you mentioned earlier in the thread is ,unfortunately, a bug with the Orbiter core. The best way to correct this so far is to change the scenario date to the year 2001. 2100s lead to many errors with many aspects of Orbiter.

I have experienced some bouncing still after changing the scenario date, but my frame rate has been low (I'm on a laptop.)

That said, I don't mind if you want to keep the beefier landing gear on the XL70. :thumbup:

Keep up the great work, and thank you for the public betas, I can't wait to see how far this project goes.

 

[CigDriver]

Well, I went through and made some updates to the Dart's 'pit.

Problem is...the changes just don't really make any better. Sure I got rid of some of the useless stuff, added some cool new things like the functional nav radios (finally!) and actual temps on the display instead of just the graphs. But, like I said, it really doesn't make the 'pit any more useful, in fact, I think it highlights the badly used space Such as the panel text showing engine specs, lol. At one time that was going to be an APU control panel, but I ended up deciding that wasn't really a feature that would add much...make sure it has gas, then turn it on...not a lot added

So, I started working up a new pit. I haven't even touched the 3D yet, I'm starting with a drawing to make sure I can make effective use of the available space. So far I have everything the current cockpit does (I even added a speedbrake control) except the UCGO/UMMU panel. I think I'm going to move that back to the area behind the cockpit like I originally planned. It will live in one of the desks back there along with an MFD or two. Here is what I worked up in illustrator:

So now we are all glass Well almost, the RCS and Engine selectors are still rotary knobs on the top of the panel. The more I look at it the more I think I'll change the DynP and Temp display to be more like the version in the image at the top, including both the drawing with digital temps and the graphs for quick reference.

Comments?

Also, for the coders out there, is it better (frame per second wise) to do multiple draws in one area or define multiple areas that are the smallest possible? For example the fuel graphs, would I be better off making one update area that covers all three and then drawing the three separate lines on it, or is it better to define just the area that the bar moves for each of the three graphs and updating them independently?

It will be while before this hits the shelves, there is a ton of recoding I'll need to do, not to mention building the 3D model

 

[clickypens]

One thing: I think having a flight computer would be awesome as all get out. I understand it's also probably really difficult, so it's mostly just a pipedream. But really, I think the cockpit looks pretty good. I agree about putting the UCGO in the back (maybe with some other, secondary tasks), to give the mission specialist something to do. The new one you made up could work as a 2D cockpit. That'd be pretty cool for people who don't have the FPS for the real deal, but want more than just basic functionality. Either way, looking really great!

 

[Ark]

I love the idea of putting the UCGO controls in a second "mission specialist" area.

I would like to say that, in the process of reworking the cockpit, keep in mind how difficult it was to see things with the regular FOV, especially the engine selection switch. It's awkward to have to zoom in just to see the text on the switch.

 

[mc_]

Some gauges become more readable. Looks good, keep going this way :thumbup:

 

[eveningsky339]

One thing: I think having a flight computer would be awesome as all get out. I understand it's also probably really difficult, so it's mostly just a pipedream.

A flight computer would be very complicated indeed!

I think that a "Flight Computer MFD" would be better suited to the Orbiter community. We wouldn't want the hyperdart hogging the glory. :hail:

 

[Dambuster]

It's awkward to have to zoom in just to see the text on the switch.

That, and also I sometimes get 2 or 3 second-long freezes when zooming in beyond ~20 degrees - that's very difficult to work with when flying a sensitive spacecraft