Aerosoft official retail partner for Microsoft Flight Simulator !! 
Click here for more information

Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

20 Excellent

About FactionOne

  • Rank
    Flight Student - Groundwork

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The 'belt & braces' method (as opposed to picking through specific folders) for all this is... Browse to \<P3D Root\ORBX\ Search EGCC from there (so it searches ALL ORBX folders below its root), RENAME anything (everything) in the results to <filename>.<originalextension>.OFF (for the record, I actually just replace the last letter of the original extension with an underscore - it helps me track what I've disabled and what other things have (given that the .off suffix is used by other tools/installers)) ( @tomkellock92 : you clearly know your stuff, but I'm not sure deleting things is good advice; if OP wants to reinstate his previous scenery set-up, he's stuck - renaming or moving is the 'safe' way) If after disabling EVERYTHING in ALL the ORBX subfolders with EGCC in their name, you still have a problem, it's 99.9(r)% likely caused by something else. Best regards, Rob.
  2. Thanks, Mathijs (I hoped it would help, but worried my analogy might not; your [authoritative] reassurance comes as some relief!) Rob.
  3. Virtual Address Space (VAS) is simply a mechanism by which a 64bit-native environment can host 32bit processes. It's all about memory byte addresses. In a 32bit environment, memory addresses are 4 octets long. In a 64bit environment, memory addresses are 8 octets long. Imagine we're building a [crazy] new telephone system. Everybody we connect to our system of course needs a unique number, so that the right person can reach the right person. We also need to set a format (limit) to the numbers, so telephone numbers are uniform in length and therefore recognisably phone numbers. Let's say we only ever expect to connect a few thousand people to our telephone service, so we decide a 32bit range of numbers is more than enough. That means our available phone numbers are 0000000001 to 4294967296. Now, there's a population explosion, and suddenly we need lots more telephone numbers; so we decide to move to a 64bit range. Now our numbers are 00000000000000000001 to 18446744073709551616, but immediately there's a problem. Our first customers (the 32bit ones) all expect to use the shorter number format, so if we wanted them to continue to operate in our new 64bit system, we'd have to block-out the first 4,294,967,296 numbers for those customers, and somehow zero-pad them at the exchange when they're called. In computing terms, this would mean that for 32bit programs to run in 64bit address space, the first 4,294,967,296 byte adresses (4GB) would have to be reserved for 32bit programs. This would work, but it's far from ideal, because it means that the first 4GB of memory in a 64bit computer isn't available to 64bit programs - let's say the computer has 16GB memory, 32bit programs would be able to use up to 4GB as they always have (because they use the shorter telephone numbers which our telephone exchange zero-pads), but 64bit programs would only be able to use 12GB, because the first 4GB worth of addresses are blocked-out run [zero-padded] 32bit programs. Ideally, we'd have all 16GB of memory available to 64bit programs, and just give 32bit programs the memory they need if we ever use them. Of course the problem here is that if you're using the first 8GB of memory in Photoshop 64bit, you can't start a 32bit program, because all the [zero-padded] addresses it understands (and more) have been taken up by Photoshop. Enter Virtual Address Space... In effect, a system for virtual addressing works as a container and a translator. To run our 32bit program when we already have Photoshop chewing 8GB, we 'fence-off' some memory (up to 4GB - because that's all it could ever understand) for the 32bit program, inside the fence (container, Virtual Address Space) we effectively give each of our 64bit addressed memory bytes another (fake/virtual) 32bit long address, so the 32bit program can read from and write to physical memory after the first 4,294,967,296 bytes without ever needing to know about it. Regards, Rob. PS> Memory in excess of 4GB for a FSX/P3D system is preferable because with more, the simulator can be given a full 4 gigabytes of virtual addresses, and there still be physical memory available to other processes. PPS> Mathijs' assertion that MHz is most important for RAM is fair, but not strictly accurate. DDR4 architecture does have throughput advantages (despite its often higher latencies), such that DDR4 clocked at the same speed as DDR3 should in theory be faster; however DDR4 is generally clocked at far higher speeds (DDR3 tops out at 1800(ish) [stock] MHz, DDR4 3200MHz+), which as Mathijs says, will yield massively higher throughput; and is the architecture of the memory controllers in the quickest CPUs - and as nealmac suggests above, FS chews CPU. The other advantage(?) is the availability 16GB modules - in case you like to leave huge Photoshop projects open while you fly FS! NB: Memory throughput is only really good for FPS, though - memory being read/written faster means the sim can render frames quicker, so you get more per second. Memory throughput doesn't really help with OOM however; you can fly 200fps toward a huge airport covered in AI all with 4096px textures, but as soon as the system tries to load more than 4GB worth of stuff into the memory, it'll run 200fps into the same OOM
  4. Just a quick update on this one; I got pretty much all my issues resolved / questions answered this evening - it's a bit late as I write this, so I'll post more details soon... Shaun - if you would be so good as to drop me an email (address in my profile, I guess mods can view?) so I have a return-address, I'll send a package of the details over in case my questions pop-up again... Regards, Rob.
  5. Hi Shaun, From memory, the file I downloaded/installed was: ...Also, one other observation... I seem to have a little bug occurring with the lovely soundset too... When in spot-plane, there is a burst of white noise every few seconds from my left speaker. This only occurs when the engines are working at something like Idle - 60%-70% N1. Any ideas on this one too would be gratefully received. ...I'm going to try to do a complete reinstall when I get home tonight which I guess might resolve some of these issues (perhaps it's just a little confused)... Is there anything I should know about making sure I get everything completely removed before reinstalling etc? Also, just a note, even with these little questions, I still enjoyed my A320 flight well enough to go buy the A330 too (I just wish I'd done it all together and got some scenery into the bargain!). Thanks again for your help, and regards, Rob.
  6. Hi guys, Just a quick one for you all... I recently installed the LTU A320/A321 pack and I'm really impressed. There are no claims that the product is a '110% simulation' - just that it's great fun to fly; and it certainly lives up to that. I think the balance between realism and 'click and go' has been reached very well. I'm particularly impressed with the basic but cute FMC, and the FADEC system; the panel in general is pretty cool - I think you can definately tell you're in an Airbus, but without getting horribly lost in checklists. [EDIT: observation about panel background removed - just needed some getting used-to ] All in all, great work, and a big thanks to Aerosoft. I've just set-up to do an EGLL - LEMD flight; and I remembered seeing a screenshot of an Iberia A321 in the product pages, so I thought that would be a fitting choice... It's not shown in the list of FS aircraft? I seem to have a few missing... I'm showing 5 paints in total for the A321; and while I have a good number for the A320; a portion of those are variants of LTU liveries; and I notice I'm missing at least the Monarch, MyTravel and Air France paints. I will do a full list and post if required. I checked the directories in my FS9Aircraft directory; and I can see that the textures are all there; but when I open the aircraft.cfg files they aren't... I'd have a go at fixing this myself, but as I say, I don't want to make anything worse as it seems quite confused already (each aircraft.cfg for the 321 (IAE / CFM) has three fltsim.x sections; so I should be seeing at least six of the full number of paints, but I only see five? Any help with this would be gratefully received! The other question I have... Is it possible to 'raise' the eye-level in the VC at all? I had a quick look around the A320 last night, and I noticed that I seemed quite 'short' in the VC - it was difficult to see much over the panel/glare-shield? Once again, thanks to aerosoft for a well-rounded package; and best regards, Rob.
  • Create New...