Team_P3DSpacePort

SpacePort actually works with FSX SP2, FSX Steam, P3D V4.x and P3D V5.x. All these can exist side by side, and upon installation, user has an option to select which platforms to enable SpacePort on. What platform were you trying to install for? Did you ever have FSX Steam Edition installed? The way FSX Steam dealt with installation was very convoluted - if it encountered a plain FSX installation, it called itself "FSX-SE", but if there was no "plain" FSX present, it "masked" itself as "plain" FSX - probably so that all the add-ons would be compatible. It may be that there are registry entries from the previous FSX-SE installation that weren't cleaned up properly. Mitch P3D SpacePort Team

FSX/P3D has a 30,000 KM altitude limit.

Certainly! Check out our YouTube channel: https://www.youtube.com/user/TBAdmin While we are busy with developing this sim, we'll periodically make promo videos showing the progress. Cheers, Misho

Not true, sir :wink: . Please check out my post here

Hello all, I've been working on this project for quite a while now, and as of a few months ago, I've overcame a major go-nogo hurdle, so I am extremely excited to announce this: I've coupled FSX with a SimConnect DLL that utilizes a third-party fully-featured physics library to create an add on that will allow FSX to simulate spaceflight through a high-fidelity ballistic astrodynamic flight model. The physics model has highly capable set of features which will allow FSX users to define launch "stack" architecture in minute details, utilizing existing FSX SDK tools to create content and expand on the FSX functionality to push FSX into Earth orbit and outer space. This is NOT slew-driven engine; this is a completely new flight model that overrides FSX's existing flight model and re-defines the object using astrodynamic properties. Major features of the spaceflight dynamics module: deterministic, non-iterative dynamics solver fully-featured, high-fidelity collision engine precise point-force modelling (not just torques applied over major axis) ability to assemble a launch "stack" and simulate launch, staging and orbit insertion ability to build (assemble) and maintain persistent orbital structures ability to dock with other objects in orbit, and to swap user control User will be able to design content with all the usual FSX SDK tools, and expand it with a set of spaceflight-specific features to define it as a spaceflight object, be it payload, manned capsule, cargo, booster, main lifter, mating adapter, or whatever. While the current FSX limitations prohibit venturing too far from Earth (but far enough to have fun :wink: ), I've been exploring ways on how to simulate trip form Earth to other solar system bodies and I've had a few promising results. That, however, is a long term plan. For now, I'll include a few screenshots of the test scenarios I've been running while developing this engine. Enjoy!

Thanks everyone. I started a week ago and covered quite a bit, but I need to at least reach the jungle so I can blend with the default textures. I am closely watching the size, now at 110Mb, because AVSIM has a 500Mb limit. That will also determine the extent of the reach.

Here are the first shots of the up and coming freebie PhotoReal scenery of Kilimanjaro, Tanzania. Tools used: TerraBuilder FSX, SBuilderX (road exclusion poly), FSX SDK. Cheers, Misho

Hi Everyone! We'd like to anounce a release of TerraBuilder FSX, an easy-to-use Photo Realistic scenery designer for FSX. It is geared towards assembly of pre-downloaded sequence of photo realistic images into one coherent scenery, as opposed to using one large image as a source. It is perfect for creating small, localised, high-resolution sceneries of airports, urban areas, landmarks etc. FSX is payware, but the unregistered version lets you create a single-image scenery (up to 2880x2880 pixels including water and blend masks) so you can freely try and decide for yourself. Also, unregistered app is fully featured, but it will save only a single image and its masks. Check it out at www.terrabuilder.com - there is a complete, clear manual and a tutorial available for download, to quickly get you started on photorealistic scenery design on FSX. Cheers, Misho

I am using FREEZE_... events to disable the flight model with SimConnect client controlling the positioning of my object. How does the surface interaction work in this case? Is it still active? For example, if I land my SimConnect-controlled helicopter on a slope, will the contact points still "sense" the slope and tilt the aircraft accordingly? or will it stay level, and just sense the ground underneath? Or, the worst case, will it ignore the ground and just keep falling towards the center of the earth?

Bill, I got tons of lines of VB/InstallShield code :) that reliably looks up the registry where FS is installed - I use it for Installation/Registration ops. Let me know if you need a snippet.

Well, it all comes down to having an artistic skill, and being on speaking terms with PhotoShop :). There is no one way of "teaching" you to create a panel if you don't have those skills.The best way (for me) is to design a "blank" (cockpit dashboard layout without gauge "holes") in 3D using 3DS MAX, render it with all the fancy shadow settings and convert it into an 8-bit bitmap. This yields a nice, realistic looking panel... If you have the right filters/materials, you can make it looking worn/new/modern/vintage etc. Also - the 3D model is also ready to be converted into a VC cockpit that would match perfectly to the 2D panel.

OK, I wrote some code to call KEY_ENGINE_AUTO_SHUTDOWN and shut down the engine when fuel is low but not completely gone. Now - when I try to re-start the engine (with next to nothing in the gas tanks) it starts up, and then immediately shuts down, all with a LOT of white and dark smoke - as if the combustion is incomplete (what is that effect, btw?). I don't want that effect, so I need to trap the engine autostart sequence and block it while the fuel level is low.What's the best way of trapping an event and BLOCKING it from reaching FS until the certain condition is met? The event I want to trap is KEY_ENGINE_AUTO_START. Also - what's the syntax/method for setting up and calling a gauge initialization routine?

Hi Doug - no, this is still FS9, but eventually I'll port it to FSX. I noticed that they are stored as integers in percentage numbers... is that what you were refering to?Also, wouldn't this behaviour exhibit in the default aircraft if the case was as you explained it? I thought my changes to CFG did something that resulted in this problem.

Note to self: :)After a good night's sleep and a hearty bowl of corn flakes, I realized that I could call KEY_ENGINE_AUTO_SHUTDOWN event just before the fuel is completely exhausted (say, 1% remaining) and force the engine shutdown until the fuel quantity gets above 1%... I'll give that a try and see if any other "gotchas" crop up...

I've come across an odd problem, and I'm unable to get past it. I used a default Cessna flight model and heavily modified the CFG file to use it as a land vehicle. I've worked out almost all the kinks and bugs, except one:When I run out of fuel, the engine shuts down. If I re-start the engine on empty tanks (without refueling), the vehicle takes off like a bat out of ####, does a wheelie on its rear axle and literally takes off - at which point, the system freezes. Not just a "The FS has stopped responding" message, but a nasty, all-out lockup, requiring a power down of the computer. Now, I know I've heavily modified and hacked the CFG (and AIR) file, so things are probably out of whack, but does anyone know what's going on in this case, and how to remedy that behavior? Any help would be much appreciated!Misho

No problem, Rob - the gauge is indeed C (.gau) type, and I got it going now... all it needed was a "bogus" graphic element (as in, tiny transparent background without mouse interaction) for it to be "visible" to FS.

Thanks Bill! That worked nicely! Looks like there has to be at least one grapgic element for the gauge to be valid...

Ok, so I thought I set this up properly:I created a "Control" gauge using the following declaration:GAUGE_HEADER_FS700(GAUGE_W, control_gauge_name, 0, 0, ControlCallBack, 0, 0, 0);ControlCallBack is a callback function where all the processing is done. The global variables are declared as externs in all the gauges. The whole set up compiles nicely, no warnings or errors. I declared it in the Panel.cfg, but when I start FS, I get a crash screen right at the startup splash screen. When remove the "Control" gauge references from panel.cfg, FS starts up normally (but the custom processing is missing, of course)What am I doing wrong?

Thanks Rob, yes this is FS9 C (.gau) gauge. I was thinking of the same thing - to group the processing into a common, non-display gauge.

thanks Bill! That's what I was thinking needs to be done. I'm just concerned with the same code executing twice, or unnecessarily. I might look into grouping the processing functionality into a "common", non-display gauge and call it from both 2D and 3D panels.

I have a few custom (as in, non FS-native) parameters that are processed in 2D gauge cockpit. They are also referenced (but not initialized or processed) from the 3D gauge versions intended for VC. If I start the sim in the VC and don't activate 2D panels, the parameters are inactive, and stay dormant until the 2D panel is accessed. How can I kick-start them by default? One way I was thinking is the "dummy" VC panel that references the 2D gauges but doesn't draw them. Is there a better, more elegant way?Thanks!

Hi Dai!Thanks for the info - I'll keep that in mind! Last night I implemented latest suggestions from Bill and Ed and now my gauge is finally working as advertised! I noticed a few forehead slappers I did ( I was calling hiding/showing in every cycle) but now that's been adressed and the gauge is behaving as it should! Thanks everyone!

hmmm okay - as I mentioned before, this is a FS2004 gauge, so I might not be able to use these extensions...I'll test out the OFF_SCREEN macro to see if that takes care of it...

Thanks, Bill and Ed! Bill, the code you pasted above makes sense except for the SHOW_LISTELEMENT macro - I get an undefined on it...must be something extra defined in the "new" gauges.h file. I am working with a stock FS2004 setup. Nevertheless, I have figured it out, with one wrinkle outstanding. I have set up my gauge with a MAKE_STATIC background (with transparent bitmap) and a MAKE_ICON member for gauge panel, working as a 2-position switch. On top of that, I have a MAKE_SLIDER element that is moving along the scale drawn in the MAKE_ICON bitmap. Then, I defined a gauge callback (thanks Ed!) that looks like this:static void FSAPI callBack(PGAUGEHDR pgauge, int service_id, UINT32 extra_data){ if(bShow) { SHOW_IMAGE_TREE(pgauge->elements_list[0]); } else { HIDE_IMAGE_TREE(pgauge->elements_list[0]); }}This basically does exactly what I wanted it to (without the need of element callbacks), except for one nagging thing: The MAKE_SLIDER bitmap, when it is hidden, is replaced by a "ghost" artifact bitmap, in the same position and size as the slider, but it looks as if it is carved out of its background, MAKE_ICON bitmap. Is there something I'm missing? Why is this little piece left behind? Is there something I need to call, akin to "Invalidate region"? I tried a few different ways of doing the same thing, including individual calls to SHOW_IMAGE on all 3 elements, and breaking down to callbacks in the MAKE_SLIDER and MAKE_ICON elements, all with the same artifact left behind...Thanks in advance,

Yup, I know it is the example of the "lookup_var" usage, but it still shows what appears to be showing and hiding of the slider and its background. "lookup_var" is only used to determine the visibility state. Is this then an arbitrary piece of code that would actually never work in a real app, and author just wrote this to illustrate the point?So then, how can I hide a static element? Statics don't allow for callback routines, so how are they referenced in SHOW_IMAGE() macro? Can you give me a short code snippet using the code from my original post? Also, what is the "gauge's main callback routine"? From what I've seen so far, each gauge element has its own callback routine (except STATIC) - there are no "main" callbacks for the whole gauge.Alternatively, Bill suggested that gauge backgrounds can be declared as MAKE_ICON (which allows callback function), rather than MAKE_STATIC, and thus allowing for the access to pelement through the callback. I'll give that a try tonight...Thanks,