anthony31

There is an error in your code. No one knows what the error is but make no mistake there is an error as FSX will always do this when there is an error. It opens the 2D screen, realises there is an error and then shuts it again. If I had a dollar for each time I had seen that popup flash I would be rather well off financially. It is best, when working with these sorts of things, to do things one step at a time. You shouldn't add a whole bunch of gauges all together but instead try just one. Only when you have that one gauge working do your continue adding others. Posting the code here would indeed be a good way to start.

Source file Shapes\???_St._George*.shp Open your SBuilderX313 folder (depends where you installed it to but I think the default is C:program files (x86)/SbuilderX313. Then go to Tools/Shapes What is in there? There should be a number of files starting with PKX and RDX. A screenshot of the directory listing would be helpful. The error message obviously tells us that one of the .shp files is missing which means your scenery is not compiling. The question is where has your .shp file gone and is it just your .shp file missing. Personally, I would have just created one or two hydro polygons around the island by hand rather the making a hole. Ignore any tutorial that tells you to remove cvx files from the main FSX folder. There is absolutely no reason why are properly written scenery would need you to remove any files from FSX.

No. I was right the first time. I didn't write that because that was how I think it works. It's because a few weeks ago I had to go through my XML gauges and fix up the errors found in the new P3D V2.1 error logging. Gauges which ran perfectly fine in FSX and P3D V2.0 but didn't in V2.1. Now, if you have any sort of useful experience in the matter of writing XML gauges for FSX or P3D then maybe your comments will be worth reading.

Because that is how it works in the real world. From my experience the FSX XML parser would read each line of code one by one. If it encountered a syntax error it would still process the line up to the point of the syntax error and then throw away the rest of the line. So, in FSX you can have code like this: (>K:LANDING_LIGHTS_TOGGLE)) and the gauge would still run and work perfectly well. While in P3D the gauge will fail due to the syntax error with the extra closed bracket at the end of the line. Note that in C++ this kind of syntax error would be easily picked up during the compilation process.

There are many definitions of LOD (level of detail). The one in the FSX.cfg affects only the ground textures and has absolutely NO effect on buildings and scenery models. Individual 3D models can be built to contain multiple LOD versions and the developer controls this completely. The LOD version to be drawn is determined by the number of pixels the object will occupy on screen. A single model file can contain multiple LOD models to help improve performance (no point in drawing a complex model when it will only occupy 10 pixels on screen as that is a waste of resources). For example there may a LOD_400 model which is drawn when the model is more than 400 pixels on screen, a LOD_100 model for more than 100 pixels and so on down to maybe a LOD_5 model. The only user control over this is the SmallPartRejectRadius in the FSX.cfg. I believe this defaults to 5. This means that any object with LODs and that is going to occupy less than 5 pixels on screen will not be drawn at all. Note that there are 2 types of model files, for simplicities sake I will refer to them as one's which have LOD's and ones which do not (there are other differences between the model types and there are good reasons why a developer may choose one type over another, depends on the application). The ones that do not are not affected by smallpartrejectradius. Also note that 3D models are generally only drawn when within 15NM of the object. I think it is 15NM, not sure, can't remember the exact number, could be only 12NM. Either way, if the object is further than that distance it will not be drawn at all.

Aircraft.cfg file has the solution. You must edit each aircraft.cfg individually. Look for the [Views] section [Views] eyepoint = 0.00, 0.00, 3.1 zoom = 0.45 Just change the zoom value to whatever you like. You can also change the eyepoint position here if you like. The numbers are longitudinal, lateral and vertical in feet.

In the P3D.cfg file [Main] ContentErrorLogging=0 Does that turn it off? I know that before the latest patch developers had to turn on Error Logging by adding ContentErrorLogging=1 manually. Maybe that is the new default position for all users?

Transparency is not so much a problem I think as it is a simple check against the z buffer. Specular and environment maps can be more of a hit. I find that when modelling an aircraft changing the textures from plain diffuse to include the bump, spec and env mapped can easily knock off 10% of the framerates. But that is for a whole aircraft with a lot of textures. Make sure your environment map is mipmapped as this will make a big difference and use the smallest possible amount of texture on your glass that you can get away with (less pixels to calculate means better framerates). I use a 512 pixel environment map for my aircraft (so much smaller than the 1024 ones and not much loss of detail) but for scenery you may like to try 256 or even 128 pixels. Depends on how much detail you really need. My personal pet hate is developers who use GMAX, decide they don't want any specular on something so they just set the specular colour to 0,0,0. Ugggh. You still have specular calculations going on even if you can't see them. If you don't want specular select "No Base Material Specular = True". If in doubt you can always do a framerate test, make one model with all your fancy texturing and another with minimal textures. Make sure they have the same guid and switch them in and out of your model library and see what the actual framerate difference is.

vaporware? I'd call it fraudware? or scamware. Looks like the site is down again as this is what it shows just now (I have removed the hyperlinks in the text): This web site has just been created from Websitepanel and it is still under construction. The web site is hosted by iranserver

Hmmm Virgin Australia's major shareholders are Air New Zealand, Etihad and Singapore Airlines all of which have considerable government ownership I believe. And here we have Richard Branson saying the Australian government shouldn't get involved in guaranteeing QANTAS loands. Sounds a bit like "do as I say and not as I do".

Agree with you bill. I'm using 2.1 to check for eroors and it is great for that. Its already spotted some errors which I never noticed with Fsx.

Hi ya It looks like I will have to go through all my old aircraft (inluding the Tiger Moth) and make updates for V2.1 (god knows when I will be able to get that done though). Honestly though, I think LM could loosen up the XML parser a wee bit to prevent these problems. It seems to me that with the FSX XML parser if it read a line and found a syntax error it would just discard the rest of the line from the point of the syntax error and then continue onto the next line. It seems that with the V2.1 XML parser if it finds a syntax error it throws the baby out with the bath water so to speak. A small change in the P3D code would save hundreds of developers having to issue updates. Of greatest concern though is the memory leak problem this causes in XML code in the model files. A syntax error in XML code shouldn't bring the whole P3D program down. It's cool though that P3D have the error logging system which allows developers to find these problems and sort them out before releasing any new products.

Hi Bill It does seem LM tightened up the xml parsing code but it also seems like this is now causing a memory leaking problem. It may not be the only memry leak cause as there may be others but it was causing problems with my model. I suspect there is some sort of infinite loop being created where memory is being continually allocated and pretty soon one runs out of memory. In my case it was about 40MB every 2 or 3 seconds. That is certainly something that LM need to look at as P3D needs to be able to handle syntax errors in XML without it causing a memory leak. I didn't test whether it was just xml gauges or the xml code in the model file that was causing the leak. I tried testing without any gauges and still had the problem so the xml code in the model is definitely one cause of the leak. XML gauges may be another cause but that would require verification. I know that after cleaning up my gauges and model file to get rid of any errors that my memory leak has been fixed (although I have a completely clean V2.1 install with no addons beyond my own aircraft).

Hello all I downloaded the 2.1 patch yesterday and today I loaded an aircraft I was working on into 2.1 and pretty quickly got the OOM error. The problem I have found is that V2.1 is not parsing XML code as well as it could (or did with V2.0). If I use a comment in a gauge like this then it causes the gauge to fail: // Double slash comment In addition, the modeldef.xml (the file that contains the animation definitions and is used when the model is compiled) should not have // comments either. I've just stripped these out of my modeldef, recompiled the model and no longer have a memory leak problem. Note: that only developers use modeldef.xml. It is not a file used by the end users system. Seems at this early stage that either all developers have to check their models to make sure they are not using // comments or LM fix up P3D parsing XML code. P3D has an error logging system which can be activated by entering the following into your P3D.cfg under [Main] [Main] ContentErrorLogging=1 This will generate an error log in your Documents/Prepar3d v2 Files folder

What does mapcacher generate? If you are making photreal ground textures you need to have source imagery in either bmp, tiff , geotiff or tga format. Personally I just open Google Earth, turn off any terrain elevation (so it is flat as possible), set a marker so I can return to the same height at a later date if necessary and then screenshot, paste into paint program, move GE view and repeat until I have covered the whole area. Then in the paint program I arrange all the screenshots to make a nice big bmp which can be used to make the photoreal. I suggest reading the FSX SDK documentation under the Terrain and Scenery subject, have a look at the part about Resample. You can also try looking for some tutorials in the AVSIM library. There are a few about making photoreal for FSX which would be a good place to start looking. There is also this tutorial about PR scenery which you may like to read. http://aussiex.org/forum/index.php?/topic/74-ozx-guides-10-making-scenery-for-country-airstrips/

Yeah sure there is. It's called the Ruler in Google Earth. Just zoom into your airport in Google Earth, select the ruler, make sure it is in the right system (ie feet or metres) and measure all your buildings. For pinpoint accuracy, if the building is brick or block work you can count the number of bricks and then multiply be a standard brick width. Same for any building with corrugated cladding, again there are standard measurements for these and you can work out the width very accurately. Once you have the measurements you can then rather accurately determine the height by comparing the ration of the side length to the height in any photos you have of the building. It also helps to know that door heights are again a standard 2.1m so you can work out building height if there is a door in the side of it becaues that is a fixed number.

1) Is this possible? Of course it is. 2) How do I decide the scale of how big they should be? You make them how big they are in real life. If the building is 10m wide by 20m long then that is how big you make it in the modelling program. 3) When I am done with creating them in FSX, do I just use the FSX SDK Annotator and put my custom created buildings in as the autogen, or is there some other process that I have to follow? You don't create them in FSX. You create them in Max. First off though you must install the FSX plugins for Max found in the FSX SDK under Environment Kit/Modelling Kit. You then export them as a MDL file from Max. Then you get the Library Creator program from fsdeveloper which will compile all your models into a model library .bgl. Then you put the model library .bgl and textures into a new scenery folder which you add to the FSX scenery library. Then you get Instant Scenery program (payware but it is the best tool for the job). Then you start FSX, run Instant Scenery and start placing your models.

As I mentioned earlier the forms are provided by 123contact and that I had reported to them genuine simulations scam. This was the message I recd in reply from 123contact: "Hello, Thank you for reporting this situation. Unfortunately, we can't do anything regarding the website, but we can ask for further details and investigate the way our forms are being used. If you would like, we can keep you updated on this matter." As you can see 123contact are not responsible for the website but were being used to handle the forms. Obviously they do not like their service being used by scammers too.

While you may not be able to get this site taken down you can report them to 123contactform which is the company that they use to handle the contact. You can report abuse at this address (which is what I just did): http://www.123contactform.com/contactus.html

Start DXtory and select the Movie tab Under Video Coded there is the Codec selector. You can select another Codec rather than the default Dxtory Video Codec, with some of these you can control the quality and data rate. You can also click on the set of pliers icon to the right of the Codec. In the case of the Dxtory Video Codec you can select 4 different levels (even medium quality is quite good but still produces quite large video sizes).

I wonder if anyone has noticed this anomaly with P3D and aircraft shadows cast onto terrain? With FSX the aircraft ground shadows are a fake kind of shadow which gets placed over the terrain as a fixed polygon rather than a true rendered shadow. This shadow was generated from the exterior model however which allowed developers to delete all those parts and polygons not visible in the virtual cockpit which would save quite a few fps. In fact, you can easily cut the total number of polygons in half for the VC by removing those parts not visible from the cockpit (eg, landing gear, bottom of wings and fuselage, engine etc) . With P3D and the new shadow system this throws up a bit of an anomaly. The aircraft ground shadows are now rendered based on the interior model if you are in the VC view, if you are in an exterior view then the exterior model is used to render the shadows. Because aircraft shadows in the VC view are rendered using the interior model this can produce a few holes in some aircraft shadows. For example, the IRIS T-6 Texan has a few holes in the VC model which now become noticeable in the ground shadow. Now, usually when you see the aircraft ground shadow it is really small as you are in the air so you may not notice the holes but if you know what to look for you can see these holes. When PMDG port their 737 over P3D they are going to need to include the full exterior model as the current VC model of the 737 includes just the cockpit and wings.

A google search for Windows 8.1 3D display mode shows a number of references. One solution proferred by these references is this: "I had this too. Easy. Go to your desktop, right click, nvidia control panel. On the left there should be something that says stereoscopic 3D. Click it and uncheck the "Enable stereoscopic 3D". " This is assuming that problem as described is indeed caused by 3D display mode. P.S. Never a good idea to post your email like that as bots trawl the internet looking for email addresses so they can send you spam.

Do some research first. You may like to read this post about this alleged A380: http://forum.avsim.net/topic/433209-the-genuine-simulation-a380-scam-is-taking-a-step-further-dont-fall-for-it/

Maybe someone who knows a bit of C programming would be nice enough to write you a program to do it. It would involve opening the output files and then loop through them looking for each lat and lon text pair and then write them into the new xml file.

Sadly the poor guy is the one that ends up looking bad and not Megascenery. If he had taken a few minutes to actually watch some of the videos he commented on or even took a look at the screenshots on the Megascenery website he would have realised that there was no autogen. Because he didn't do his research he would rather blame Megascenery and try to hurt them rather than admit he didn't do enough research. Hate to think how he will react when he finds out there are no seasons with PR too. Although, it looks like his comments have now been removed from the couple of youtube videos I checked. Maybe someone reported him for spamming?