Project Bases to Land Planet Hopper Class star ships

[garyw]

Ok then. Is it possible to build a space craft as the dome and give it atmosphericParameters? Don't answer that.

I'm reading the spacecraft.pdf right now to help with the space craft. And I'm going to have to re-disign the bridge from what I've read.

paramiters = Parameters
disign = design

You shouldn't start a new sentence with "and".

 

[tblaxland]

Ok then. Is it possible to build a space craft as the dome and give it atmospheric paramiters? Don't answer that.

I'm reading the spacecraft.pdf right now to help with the space craft. And I'm going to have to re-disign the bridge from what I've read.

OK, here is a potential, albeit flawed, solution: as far as I can tell, the volume inside another vessel will inherit the atmospheric parameters of the planet it is on. So, potentially you could write a vessel-base that would, when another vessel crosses some threshold, turns on the planet's atmosphere. The down sides:
1. Any other vessels outside the base will also then be effected by the newly created atmosphere.
2. It will require a custom planet module and a DLL dependency between the vessel-base and the planet module. KeyComm won't work because planet modules don't have a callback for key presses as far as I can tell.

Another option is to use the vessel-base to simulate the effects of an enclosed atmosphere on the vessel. So, once the vessel enters the vessel-base the module, at every time step, gets attitude and velocity info on the vessel and then adds appropriate forces to that vessel. To do that would require your own atmospheric simulation, which is no small task.

Anyway, reading spacecraft.pdf will do you no good for these since Spacecraft3 will not be able to do the job. You need you own custom vessel DLLs. Disclaimer: these are just brain-fart concepts - you are on your own with regard to implementation.

You shouldn't start a new sentence with "and".

Plenty would disagree with you: http://www.google.com.au/search?hl=...sentence+with+a+conjunction&btnG=Search&meta=. For starters, it gives the gives the second independent clause additional weight with respect to the first (compared to including it in the same sentence as the first independent clause) yet it retains all the benefits of connecting the two together :speakcool:.

 

[ex-orbinaut]

Slightly related to an issue of standards previously seen on this thread;

I have been listening to the shuttle STS-125 news on NASA, and it dawns on me that they are reporting everything as statute miles and pounds. Should not they be the first to "educate" the public to use metric system in reference to space topics? I am not being facecious asking this; it is a legitimate question on my part.

Thanks in advance...

 

[Hielor]

Slightly related to an issue of standards previously seen on this thread;

I have been listening to the shuttle STS-125 news on NASA, and it dawns on me that they are reporting everything as statute miles and pounds. Should not they be the first to "educate" the public to use metric system in reference to space topics? I am not being facecious asking this; it is a legitimate question on my part.

Thanks in advance...

NASA TV reports everything in the format that the US public would understand most--statute miles.

Internally, they use nautical miles. Some data comes in as metric (it was either S-band or C-band, low-speed or high-speed...I worked on the C version of an old Pascal converter, don't remember which it was for though), but is converted before being displayed.

 

[TCR_500]

Well, I have an idea. Something like this.

<BASEFILE>.<CFG>
// Opening Code
BEGIN_PRESSUREDOME
Position = <X> <Y> <Z>
Radius = <VALUE>
Pressure = <VALUE>
END
// Closing Code

Not sure if it'll work, but it might. It's more of adding something to the config.

 

[tblaxland]

I have been listening to the shuttle STS-125 news on NASA, and it dawns on me that they are reporting everything as statute miles and pounds. Should not they be the first to "educate" the public to use metric system in reference to space topics?

Yes, they should. Internally a mix of metric and traditional units are used (I think all the unmanned stuff is metric). Their policy is here: http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPD&c=8010&s=2E. There is a lot of resistance to using metric in manned operations because of the potential confusion for pilots who have honed their instincts on the traditional units - even parts of Constellation are still using traditional units. See here for example http://www.nasaspaceflight.com/2009...s-roadmap-2015-hanley-proposes-major-changes/, Jeff Hanley proposes not using metric to save money:

Do not implement SI units

As far as reporting to the public, I understand reporting things in "common" units to make it accessible to the public. Even "football fields" is acceptable IMHO (although I still chuckle at it) as long as it is reported with the actual measurement in SI units beside it.

---------- Post added at 09:57 ---------- Previous post was at 09:55 ----------

Well, I have an idea. Something like this.

<BASEFILE>.<CFG>
// Opening Code
BEGIN_PRESSUREDOME
Position = <X> <Y> <Z>
Radius = <VALUE>
Pressure = <VALUE>
END
// Closing Code

Not sure if it'll work, but it might. It's more of adding something to the config.

But what is going to read those things in and turn them into something useful in the actual simulation?

 

[TCR_500]

A module might be able to do that.

 

[tblaxland]

A module might be able to do that.

Like the one I suggested six posts up

 

[TCR_500]

Yes. Sence my idea of a pressurized dome has an object inside the config file of the base, we'll need to modify how the bases are read. Unfortunatly, I'm only up to input for a consol application in my C++ book. I wonder what would happen if I just skipped to the DLL section. Another problem that I just thought of, is that the module might have to be activated.

 

[ex-orbinaut]

NASA TV reports everything in the format that the US public would understand most--statute miles.

Internally, they use nautical miles. Some data comes in as metric (it was either S-band or C-band, low-speed or high-speed...I worked on the C version of an old Pascal converter, don't remember which it was for though), but is converted before being displayed.

Yes, they should. Internally a mix of metric and traditional units are used (I think all the unmanned stuff is metric). Their policy is here: http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPD&c=8010&s=2E. There is a lot of resistance to using metric in manned operations because of the potential confusion for pilots who have honed their instincts on the traditional units - even parts of Constellation are still using traditional units. See here for example http://www.nasaspaceflight.com/2009...s-roadmap-2015-hanley-proposes-major-changes/, Jeff Hanley proposes not using metric to save money: As far as reporting to the public, I understand reporting things in "common" units to make it accessible to the public. Even "football fields" is acceptable IMHO (although I still chuckle at it) as long as it is reported with the actual measurement in SI units beside it.

Thank you for those answers and links. So it appears that aviation's continued insistence - with few exceptions in some countries or areas of operation - on using traditional imperial navigation units of measurement is also partly to blame, as well as the GP's unswerving support of them. I always considered standardization one of the top achievements of the 20th Century, but it seems there is still a way to go with it in many spheres.

Thanks again for the answers!

 

[TCR_500]

Ok, I just ran right into another problem. The sdk documents don't seem to cover adding an object type to surface bases. And I just found out that skipping through the book wasn't a good idea. I do have another idea. Simular to the one I listed, except, I'm going to replace the variable "radius" with "rotation". And make an extension of DOME. In the file will be something like this.

<VERTEX_X> <VERTEX_Y> <VERTEX_Z>
<VERTEX_X> <VERTEX_Y> <VERTEX_Z>
<VERTEX_X> <VERTEX_Y> <VERTEX_Z>
// One polygon, vertexts are in a clockwise listing order.
// Don't forget the floor and make sure all of the polygons are facing inwards. Otherwise, you'll pressurize the entire universe.

Ok, I know that pressurizing the entire universe isn't very realistic, but the DOME file seems to be a better way of doing things. You have more control over the shape of the object. But I wish it didn't require extra modules.

 

[Artlav]

Unfortunatly, I'm only up to input for a consol application in my C++ book. I wonder what would happen if I just skipped to the DLL section.

Programming is about making algorithms and creating solutions to the problems.
If you have this skill, you can skip safely to any chapter of interest in C++ book, following the problem you have at hand.

If, however, this "C++ book" is the only thing you got about programming so far, skipping will likely be a bad idea, depending on chapter sequence.

Which book do you use, btw?

The sdk documents don't seem to cover adding an object type to surface bases.

There are none. You can't add static logic to the bases, only model it with vessels.

 

[escapetomsfate]

TCR, just make a VESSEL2 class DLL for your "dome" and tell it to simulate air effects on all vessels in a given distance (AKA the dome's radius).

Try something like this in the vessel's clbkPreStep:

#include <math.h>
using namespace std;

//clbkPreStep is called each timestep.
void Dome::clbkPreStep (double SimT, double SimDT, double mjd){
//Iterate through all vessels and simulate air drag on any vessels that are 'inside' the dome.

for(int i=0;i<oapiGetVesselCount();++i) {
        OBJHANDLE oVessel = oapiGetObjectByIndex(i);
        VESSEL* hVessel = oapiGetVesselInterface(oVessel);

//Get distance between centre of dome and hVessel.
VECTOR3 v3;
   GetRelativePos(hVessel,v3);
    double Distance = sqrt((v3.x * v3.x) + (v3.y * v3.y) + (v3.z * v3.z));
   
if(Distance<DomeRadius) SimulateAirDrag(oVessel);

}
}

Use Dome->AddForce() to simulate the drag.

 

[TCR_500]

Thanks for the code, but I don't realy understand what to do with it or where to put it. But I'll see what I can do. Do I make an H file or CPP file for the code to go into?

 

[garyw]

CPP file. The H file is the header - READ the code, you can see the includes that pulls in math.h

I can't program in C and even I know that.... Maybe C isn't for you?

 

[TCR_500]

Thanks for the help.

 

[ex-orbinaut]

TCR, just make a VESSEL2 class DLL for your "dome" and tell it to simulate air effects on all vessels in a given distance (AKA the dome's radius).

Try something like this in the vessel's clbkPreStep:

#include <math.h>
using namespace std;
 
//clbkPreStep is called each timestep.
void Dome::clbkPreStep (double SimT, double SimDT, double mjd){
//Iterate through all vessels and simulate air drag on any vessels that are 'inside' the dome.
 
for(int i=0;i<oapiGetVesselCount();++i) {
        OBJHANDLE oVessel = oapiGetObjectByIndex(i);
        VESSEL* hVessel = oapiGetVesselInterface(oVessel);
 
//Get distance between centre of dome and hVessel.
VECTOR3 v3;
   GetRelativePos(hVessel,v3);
    double Distance = sqrt((v3.x * v3.x) + (v3.y * v3.y) + (v3.z * v3.z));
 
if(Distance<DomeRadius) SimulateAirDrag(oVessel);
 
}
}

Use Dome->AddForce() to simulate the drag.

Thank you so much, escapetomsfate! Just to let you know that your snippet was not in vain. It helped me, at any rate, with something I am doing. Nothing too sophisticated, just simple refuelling off docks, but it pointed me in the right direction in getting the "mate" OBJHANDLE I needed. Thank you again!!!
:thankyou:

TCR 500, you can do a simple "ship" without an H file, derived from the intrinsic VESSEL2 class (look at the ShuttlePB sample), but you can't make a ship ONLY with an H file. In orbiter API the H(header) file is used for declaring constants, UINT, DWORD, etc variables and callbacks that your cpp file is going to use. Your actual coding goes in the cpp. A header is essential if you are going to do animations (because of the callback definitions required). Don't forget to #include your h file at the beginning of your cpp. I am no C++ expert, and frequently need help myself, but this is pretty elementary stuff.

Good luck, and have fun, above everything else!

 

[TCR_500]

Ok then. I'll see what I can do. This is getting quite annoying. I can't compile the thing! Here's a screenshot explaining the details. Did I miss anything or do anything wrong?

 

[insane_alien]

i think you need to learn the differnece between code and pseudocode.

 

[Artlav]

Did I miss anything or do anything wrong?

The problem is simple - you don't understand the meaning of any line of text in that screenshot.
Prove otherwise, if you can, and the problem will be solved.