Team_P3DSpacePort

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.