Jump to content


  • Content Count

  • Joined

  • Last visited

About FactionOne

  • Rank
    Flight Student - Groundwork

Recent Profile Visitors

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

  1. Thanks for your help; I'll hold my horses until you've been able to clarify the other point. Cheers, Rob. PS> You're more than busy enough to have [understandbly] forgotten, but I was in touch with you some time ago about an idea I'd had, and then vanished quite abruptly - I think we'd got wires-crossed at some point, but things here went crazy before I got a chance to clarify - anyway, my apologies [for the record, the idea wasn't abandoned, just parked - hopefully to be revisited now that x64 has become established]. Thanks again.
  2. I just discovered the bundle can be [pre-]ordered (I guess so bundle owners get to use the A318/319 between now and the new A320/321 roll-out?). I notice upgrade validation is done by serial, my question is two part: i) If I bought a 'bundle' from a third party reseller, can I buy the new version 'upgrade' direct from the AS shop using the serial(s) for the previous version delivered by the third party shop? ii) My full family (A318-21) bundle was supplied with two serials (one for A318/319, one for A320/321) for separate setups. I suspect this means I got bundle pricing, rather than the bundle bundle; and that to upgrade, I need to buy the A318/319 and A320/A321 upgrades separately, supplying the serial for each? Thanks, Rob.
  3. Not sure if this has been suggested before or not, but if we get a fuel/load planner with the A330 (and using the A318-21's as a reference): Is there any chance we could have ICAO entry for alternate (rather than specifying a distance), and an ability to save & recall loads? Another cute thing, but requiring a bit more code, would be modular checklist(s)... A list of 'possible checklist items' on the left, 'selected checklist items' on the right, whereby a pilot can move an item from possible to seleted, and perhaps once it's in the 'active' list, present a drop-down/radio-button/whatever to allow response selection: "checked, set, set on, set off, value x" (I realise that the value x one would be the most code-heavy to implement, but perhaps not enormous if it's handled logically - one wouldn't want to make a checklist item for pitch trim dependant upon setting flight deck air-con to 21 degrees, for example - I guess all [most of] the hooks are there for existing 'static' lists, anyway). I dunno; just an idea that popped into my head that I thought might be useful too - I guess if it were push-direction aware, it could be handy for the single-engine taxi folks; but that notwithstanding, it could be useful (moving xpnder stdby to parking checklist for example; setting electric hydraulic pump on/off at 'company' specified stages, etc.). Again, this is somewhat off the top of my head stuff, but it seemed like a potentially useful idea, and probably in keeping with the Aerosoft 'immersion' ethos? I'll go back to my terminal and be quiet(!)... Regards, Rob. EDIT: Speaking of push-direction... I imagine I'm one of not very many who don't use GSX, but if the A330 is to get the MCDU pushback gadget, I'd be grateful if its distance controls could be looked at - the A318-21 push seems heavily affected by the aircraft type (a 9 metre push is OK in a little bus, but in a '321, 9 metres/90 degress gets you half way down the STAR with the tug attached! - I find myself using 9m/45deg in basically all cases to avoid going [unexpectedly] too far)
  4. @Griffin78 St. Elmo's fire is basically harmless; it's air molecules in plasma state due to ionisation. It's most frequently seen where there is lots of static electricity (around thunderstorms), but in the case of BAW9, the ionisation was seen because of static electricity generated by the friction of ash particles in the airflow around the fuselage. The St. Elmo's fire categorically DID NOT cause the engine failures. The engines failed because ash choked the intakes. The ash caused the St. Elmo's fire, and it separately but coincidentally caused the engine trouble. Regards, Rob.
  5. 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.
  6. Thanks, Mathijs (I hoped it would help, but worried my analogy might not; your [authoritative] reassurance comes as some relief!) Rob.
  7. 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
  8. 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.
  9. Hi Shaun, From memory, the file I downloaded/installed was: AO_LTU_A320_310.zip ...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.
  10. 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...