Exe add-ons could be a source of concern; for example .exe’s running with FSX can load up simconnect and register for a large set of data and events. So again I always recommend that the exe.xml allow only what is needed for the flight.

 

Unfortunately many don’t realise this, and after installing two hundred and forty three add-ons, it’s possible that the exe.xml and the dll.xml need an edit. :}}

I do have the PMDG_NGX_ED.ttf font, but it's located in E:\Microsoft Flight Simulator X\Fonts not in C:\Windows\Fonts\Fonts ... I believe what is happening here is that a path is not being specified for the Font hence will default to OS path for fonts.  This is not a big deal, but typically an installer should registry a Font with the OS to avoid this problem ... fonts can be registered using gdi32.dll - AddFontResourceW - this would avoid the 

 

Ok thanks - I'll enter this one into our system for the NGX SP2 update.

 

 

Ok thanks - I'll enter this one into our system for the NGX SP2 update.

 

Make it a priority 999999 issue ... I'm sure you ladies/gents have more important things going on.

 

 

 

Although in my defence I did say "over” ambitious

 

Haha, true Steve ... but there again, one might also consider just trying to code a "World" flight simulator for a Personal Computer is "over ambitious" ... fortunately for all of us common sense didn't prevail

Yes, perhaps in the sense you put it, I’ve been known to be a bit over ambitious myself. If I had any sense I’d be a lawyer.  :}}

Back in the day of BGLC scenery MS sdk was very clear about assigning the proper lat/long extent in the bgl header for performance.  But in the transition to FS9/FSX that emphasis I think went away.   As far as "reading scenery areas", from what I've seen most file access is to bgl model libraries.  Since libraries have world-wide scope, that is probably required.   One solution would be to "geolock" models which then I don't think get read except when needed, but I don't think most developers do that.  You could in principle use a model extraction program to pull the models out of a library and then redo the scenery object placements to include the models thereby locking them, but that's a lot of work and I don't know the real payoff.  Or the alternative is do something like FSDT does and not use bgl scenery instead inject it from misc simobjects but then you need an injector like couatl/bglmanx (and people also complain about pop-up scenery).

 

scott s.

.

Hey guys,

 

I any add anything to this topic, but I've been following it since it started and its simply fascinating. Keep it going.

 

Best wishes,

Jess B

The issue with fonts in FSX, is that FSX is looking in an "incorrectly referenced font location"

 

c:\windows\fonts\fonts

 

and then in the FSX font directory.

 

when it should ideally be looking in the FSX font directory FIRST, and then in the correct

 

c:\windows\fonts

 

Whatever order it looks,  it should not be looking in

 

C:\windows\fonts   +  \fonts        !!

 

It would seem that ACES never looked at FSX in Process Explorer  -- or maybe they did, and closed it quickly & moved on !!

 

 

However, putting it into perspective,  there are so many other file searches going on,  that a few non-productive searches  in c:\windows\fonts\fonts,    hardly makes any significant difference to FSX's performance.

 

It's a question of choosing one's battles   

 

Once you start looking "below the hood", with tools like "Process Explorer", you are really opening Pandora's Box,  and are in for quite a few unexpected  surprises.

Make it a priority 999999 issue ... I'm sure you ladies/gents have more important things going on.

 

 

 

 

Haha, true Steve ... but there again, one might also consider just trying to code a "World" flight simulator for a Personal Computer is "over ambitious" ... fortunately for all of us common sense didn't prevail

 

Rob, I found something interesting. I ran this process manager and see the same path not found error for C:\windows\fonts\fonts folder, not just for the PMDG font but others. But the operation wasn't an open or read, it was a Create File operation. Looking at your example it's different, are you accessing a network drive? It still looks like a create operation though. I'm not sure why FSX seems to want to create a file there?,

Rob, I found something interesting. I ran this process manager and see the same path not found error for C:\windows\fonts\fonts folder, not just for the PMDG font but others. But the operation wasn't an open or read, it was a Create File operation. Looking at your example it's different, are you accessing a network drive? It still looks like a create operation though. I'm not sure why FSX seems to want to create a file there?,

 

Look more carefully - It is only opening the file in read-only mode.

 

Process Mange can also list the file attributes, including Creation Time.

Maybe that is what you are seeing.

 

FSX better NOT be writing to any Font directory !!!  (unless its an addon installer)

( and I really don't think it is)

 

You can easily confirm this by looking at the properties of the fonts in Windows Explorer, and seeing that their modification date, or creation date is NOT being updated. (only last accessed)  

-- assuming you have not turned off this property updating, in order to speed up your computer .

But the operation wasn't an open or read, it was a Create File operation. Looking at your example it's different, are you accessing a network drive? It still looks like a create operation though. I'm not sure why FSX seems to want to create a file there?,

 

The "CreateFile" API function is the main one for all file openings, also for device streams, the lot. It doesn't only mean "create" a file, more "create a file object linking me to ...".

 

Pete

As far as "reading scenery areas", from what I've seen most file access is to bgl model libraries. Since libraries have world-wide scope, that is probably required.

 

Interesting Scott, prompted me into some more digging ...

 

Found this thread: http://www.fsdeveloper.com/forum/archive/index.php?t-9127.html

 

Seems like a strange way to process scenery/objects ... but the BGL headers for disabled scenery areas are definitely NOT being read.

 

Rob

Hey Rob,

How about starting with a fresh copy of FSX and no addons installed, do the tests, and then test again to include the effect of third party .dll's? And .exe's?

Steve

How about starting with a fresh copy of FSX and no addons installed, do the tests, and then test again to include the effect of third party .dll's?

 

Already done that Steve.  My basic process before installing any Add-Ons is to make copies of FSX.CFG, DLL.XML, EXE.XML, Scenery.cfg (and a few other files) ... I think I have over 300+ copies of these files starting from day one on install (fresh install of FSX).  I use UltraCompare (compare tool, works on binary files or any file for that matter) to see difference whenever I add scenery, airports, AC, etc. ... I always like to know what changes.

 

But of course, with:

 

70,000+ BGLs

504,511 AGNs

23,513 DDS files

 

(and growing with each scenery/airport purchase)

 

It's no wonder I/O and bus saturation happens with FSX (and then toss in everything else FSX needs to do ...) -- it really is in need of a better process of file management/indexing.

 

Does anyone know what happens to FSX if any of the BGLs, AGNs, or DDSs files are malformed?  My assumption is that if any one (or more) of my 600,000+ files is malformed it will just get rejected by FSX ... is that a valid assumption?

 

Rob.

Hey Rob,

 

Of course, with FSX It's not enough to simply work from a default install, though you no doubt know all that. Good job. :}

 

Steve

 

 

with FSX It's not enough to simply work from a default install

 

Absolutely agree, have a few key entries in there and try suggestions as I come across them and either toss or keep if they are any benefit without bad side effects.