Project Shuttle-D Development version 1.2

[BruceJohnJennerLawso]

Okay, so Ive been working on an addon vessel for about 3-ish months now. I have external/internal meshes, internal VC still being dveloped, a fairly good dll that contains all the flight characteristics, main/hover/rcs, gear and animations(big thanks to gattispilot for that), a payload bay, and orbiter sound being integrated right now. My goal would be to have this release-ready for the fall with a working VC, UMMU, and UCGO, but Im under some time pressure because I know theres no way I can afford to do orbiter development during first year university. So, I would appreciate any thoughts, help, ideas, etc.









---------- Post added at 06:21 PM ---------- Previous post was at 06:07 PM ----------

Okay, so Ive been using the Astromatiz II tutorial/example by keith on OHM in order to get a VC working with my ship. I copied across the code from his samples, edited it to fit the project, but one error keeps popping up whenever I try to compile, related to VC redraw events and the font it uses


1>------ Build started: Project: MyVessel, Configuration: Release Win32 ------
1> SHD.cpp
1>SHD.cpp(406): error C2664: 'TextOutW' : cannot convert parameter 4 from 'const char *' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>SHD.cpp(528): error C2664: 'CreateFontW' : cannot convert parameter 14 from 'const char [6]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

the issue seems to be that the 'LPCWSTR' parameter (representing the font Arial, I think) is incompatible with argument of type cons char? the tutorial is made for Orbiter 2006, but Im not sure what the issue really is.

 

[orb]

1>SHD.cpp(406): error C2664: 'TextOutW' : cannot convert parameter 4 from 'const char *' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>SHD.cpp(528): error C2664: 'CreateFontW' : cannot convert parameter 14 from 'const char [6]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

Change in the project properties "Configuration Properties -> General -> Character Set" to "Use Multi-Byte Character Set".

 

[BruceJohnJennerLawso]

Change in the project properties "Configuration Properties -> General -> Character Set" to "Use Multi-Byte Character Set".

Thankyou very much. could you explain how I can set the VC viewpoint, and the way to move it? (like in the DG's cockpit) :thumbup:

 

[Spacethingy]

Looks an interesting ship! A sort of "flying truss" if there is such thing...

But... erm... we've got a ShuttleA, so what happened to the ShuttleB and ShuttleC? :lol:

 

[BruceJohnJennerLawso]

Looks an interesting ship! A sort of "flying truss" if there is such thing...

But... erm... we've got a ShuttleA, so what happened to the ShuttleB and ShuttleC? :lol:

Well, jumping 2 letters, was such an easy way to make this sound more advanced than actually doing the work :lol:

Actually, I just thought, the Shuttle-PB takes the B slot, and Shuttle-C doesnt sound great to me for whatever reason. I did work on 2 stupid designs during concept development for this project, so maybe one of them is shuttle-C. Once this is done Im going to try to make a large scale transport, similar to the arrow, but using container modules, and various other features.

Yes I know its a flying truss, but when I did design, I based the concept around how I could make it vaguely feasible as a real ship. The cockpit/flight deck section at the front connects to the rear engine conpartment through the hab tunnel in the truss. The huge fuel tank on the back was because I realized after the first design, that there was nowhere to store fuel :lol:

 

[orb]

Actually, I just thought, the Shuttle-PB takes the B slot, and Shuttle-C doesnt sound great to me for whatever reason. I did work on 2 stupid designs during concept development for this project, so maybe one of them is shuttle-C.

The Shuttle-C already exists http://en.wikipedia.org/wiki/Shuttle-C and there is add-on based on it for Orbiter (on Simviation).

 

[BruceJohnJennerLawso]

The Shuttle-C already exists http://en.wikipedia.org/wiki/Shuttle-C and there is add-on based on it for Orbiter (on Simviation).

Oh, really, such a common name really makes it a context thing. SimAviation as in AvSim? I thought that site had gotten hacked or closed down no?

 

[orb]

SimAviation as in AvSim?

It's Simviation. I typed too fast.

 

[BruceJohnJennerLawso]

It's Simviation. I typed too fast.

Oh, cool Ive never found that site before, kinda interesting . So any word on VC camera position and moving it with Ctrl+arrow keys?

 

[orb]

Did you look at DeltaGlider sample?

 

[BruceJohnJennerLawso]

Did you look at DeltaGlider sample?

Yes, and I tried to adapt to my project without success. Sorry to abruptly change directions, but can you give any advice on how to get my MFD going with the Astromatiz II Template? Ive been able to integrate the code, but I cant get the display screen or its buttons to show properly, although the display buttons now appear to be displaying in tiny bits of script on each of the little boxes that the switches are attached to. Would you have a template for the MFD mesh groups that I will need to draw the MFD on? The data for my MFD meshes doesnt look like what the tutorial showed (too long, probably too many vertices?), and Im not quite sure how to model it properly.

 

[BruceJohnJennerLawso]

Okay, so I have the first MFD displaying on the mesh I wanted it on, but the display is wrapped around the front and back of the panel. Does anyone know what I need to do with the UV mapping to make the display only show on the front side?

 

[martins]

Okay, so I have the first MFD displaying on the mesh I wanted it on, but the display is wrapped around the front and back of the panel. Does anyone know what I need to do with the UV mapping to make the display only show on the front side?

Not sure I understand. Surely the panel should only be viewed from the front (or do you want to allow users to stick their head into the wiring?). So why does yours have a backside at all?
The MFD display is usually simply a mesh group with four nodes and two triangles. This arrangement has only one side. It's invisible from the back.

If you do want the display to have a back side for whatever reason (say a nifty futuristic free-standing display) that doesn't mirror the MFD on the back, you will need 8 vertices and 4 triangles. The positions of the back vertices correspond to those for the front, the normals are inverted. Generally you will need to put the front and back into two separate groups, because you need a different texture for the back.

 

[Notebook]

snip..
So why does yours have a backside at all?
snip...
.

Sorry, couldn't resist it.

http://www.orbiter-forum.com/showthread.php?t=1404&highlight=serious+butt+problem

N.

 

[martins]

If we are on the subject of backsides, here is a topical one:
http://www.guardian.co.uk/world/us-news-blog/2012/jul/26/mitt-romney-britain-gaffes

 

[Notebook]

Surprising that, politicians usually do well outside their own country no mattter what they are thought of at home. Margaret Thatcher and Tony Blair seemed to do well in the US.

Looks like poor breifing by his staff, unless he tries to ad-lib and fails. Some good ones there.

N.

 

[BruceJohnJennerLawso]

Okay, Im planning to adapt the Shuttle-A's aerodynamics model from the provided source code for my project. Im really not familiar with aerodynamics at this point, but I know the front profile is much narrower and smaller than the Shuttle-A's, and that the lift is also going to be much smaller for the same reasons

how do I adapt this

// ==============================================================
// Airfoil definition
// ==============================================================

void Shuttle_MomentCoeff (double aoa,double M,double Re,double *cl,double *cm,double *cd)
{
int i;
const int nabsc = 7;
static const double AOA[nabsc] = {-180*RAD, -90*RAD,-30*RAD, 0*RAD, 60*RAD,90*RAD,180*RAD};
static const double CL[nabsc] = { 0, 0, -0.004, 0, 0.008, 0, 0};
static const double CM[nabsc] = { 0, 0, 0.0014, 0,-0.0012, 0, 0};

for (i = 0; i < nabsc-1 && AOA[i+1] < aoa; i++);
double f = (aoa-AOA) / (AOA[i+1]-AOA);
*cl = CL + (CL[i+1]-CL) * f; // aoa-dependent lift coefficient
*cm = CM + (CM[i+1]-CM) * f; // aoa-dependent moment coefficient
double saoa = sin(aoa);
double pd = 0.045 + 0.4*saoa*saoa; // profile drag
*cd = pd + oapiGetInducedDrag (*cl, 0.1,0.7) + oapiGetWaveDrag (M, 0.75, 1.0, 1.1, 0.04);
// profile drag + (lift-)induced drag + transonic/supersonic wave (compressibility) drag
}

to my ships model

 

[BruceJohnJennerLawso]

Okay, working on orbitersound integration. Where should I place the playwav request in the code for a gearup/geardown callout?? I tried it under ClBKconsumebufferedkey, but that didntt work, & interfered with the gear animations and didn't work. Also, any idea how to create a conttact callout? Thanks for any help.

 

[martins]

Can't help with the orbitersound, but regarding the aerodynamic coefficients, please note that the Shuttle-A values are not necessarily very rigorous. They are simply meant to represent a "flying brick", with hardly any lift at all, and drag simply a function of AOA. You may want to look for something more sophisticated for your implementation.

Note that for lift and drag force computation, the returned coefficients are multiplied with the airfoil area, so if your vessel is smaller, it will produce less lift and drag anyway even with the same coefficients.

 

[BruceJohnJennerLawso]

Can't help with the orbitersound, but regarding the aerodynamic coefficients, please note that the Shuttle-A values are not necessarily very rigorous. They are simply meant to represent a "flying brick", with hardly any lift at all, and drag simply a function of AOA. You may want to look for something more sophisticated for your implementation.

Note that for lift and drag force computation, the returned coefficients are multiplied with the airfoil area, so if your vessel is smaller, it will produce less lift and drag anyway even with the same coefficients.

I guessed that the Shuttle-A had a fairly simple aerodynamics model, but I know alsmost nothing aboutt that field, so I figured that the Shuttle-A hadd to be fairly similar. I think the Shuttle-A example just defined it as one big wing along the bottom hull, and given that if I just adapt the SH-A model to have a narrower wing width and a smaller frontal cross section, it should be a reasonably accurate model for my ship. Any idea which parameters need to be adjusted to do thatt though? I can't make heads or tails of what any of it means in C++ code

---------- Post added at 09:14 PM ---------- Previous post was at 05:36 PM ----------

Okay, I have the gearup callout working by inserting it as a function in clbkPoststep, but it loops constantly while the gear is retracting, and I havent had any luck with a gear down callout. Any ideas on how to get this working properly? I havent been able to find any examples in the source other developers have included.