Jump to content

markdf

Members
  • Content Count

    143
  • Donations

    $0.00 
  • Joined

  • Last visited

Everything posted by markdf

  1. The time to convince them of this would have been while the MD-11 was still on sale, by persuading more people to buy it. Those are the only relevant numbers to them (rightly so) Hard sales figures are reliable and persuasive, a list of people posting in a forum thread are much less so.
  2. Where do you get this impression? You can still purchase licenses for all versions of P3D, including v1 directly from LM - I don't see them removing v3 any time soon
  3. Converting code to compile in a 64bit environment can throw up issues and obstacles I accept, but it also doesn't require the complete re-write from scratch that you seem to think it does - I could see some of the FS2Crew products being more complex to adapt, but given that RAAS reads it's data from a csv file on disk, rather than through direct communication with the simulator to get that information (the heavy lifting of which is already performed by MakeRunways) and then compares that against user location + direction, I'd question the decision to charge full price for it. One of the biggest issues with going to 64 from 32 comes from code that makes assumptions about the size of various data types in memory rather than verifying it at runtime, which really from an application developers perspective, is probably the largest change. Well written code for smaller programs should actually port reasonably easily, which is why we're already seeing such a large number of compatible applications this soon after launch. Language/syntax doesn't change between 32 and 64bit, and code that obeys the industry standards should be valid on either architecture. (Barring quirks in P3D's APIs, because obviously they play a role in this, whilst I'm a developer myself I don't develop for P3D. I do however maintain a codebase across three different CPU architectures, two 32bit based + one 64bit on an ongoing basis) Contrary to popular belief, it *is* possible for 64 and 32 bit processes to communicate, which is why even un-maintained utilities like Radar Contact (which uses the same source data from MakeRunways as RAAS) can still provide working ATC services under P3Dv4. Another fact correction - FSLabs have already announced that they will not be charging for the A320 update, they considered it and decided against it. Aerosoft are charging for the Airbuses, but not because of the change to 64bit, but because the update is also going to represent a significant improvement to the feature set and performance, bringing it up to date with their A330 project's code. (And even with that, they're only charging an upgrade - not a full re-purchase) Regardless, for me this debate is immaterial - as I posted above, the use of PayPal as the sole processor rules me out of being able to use the 5EUR discount voucher for existing owners, and I won't pay more than everyone else elsewhere on principle. I'm not saying it should be free, and I would pay happily, but only the same price as other customers. Edit: In before someone says "Why don't you do it then?" - draft an NDA, make me a defacto temporary (unpaid) employee and I'll happily take a leave from my day job to contribute to the conversion.
  4. PayPal will flat out not process for me, logged in or just with my name, billing address or any of my cards. Had an incident where they somehow insisted my ID wasn't legitimate (which was ridiculous since it was my passport which I travel on frequently?!) and since then I've been outright blocked/blacklisted. I actually emailed you some time ago about this, and was advised by you to purchase from simmarket instead for future purchases (5th of May last year) so unfortunately my post still stands :( Once PayPal decide they don't want you, that's it - there's no appeals process (at least no more than a sham one), nobody you can talk to, they won't tell you a thing about their reasoning or provide evidence to support their decision, and they are VERY good at stopping you using any of their services, so if a website only processes via PayPal, I can no longer buy via that website. It is not a choice, I simply can't use it in any way - and believe me, I've tried.
  5. Since I'm assuming the 5 euro discount only applies when bought direct, and your site only accepts PayPal (who I no longer deal with since an account dispute a couple of years ago) then unfortunately I'm probably out. I was ok with a reasonable upgrade fee, and even the relatively small 5 EUR discount was welcome, but if not using PayPal rules me out of even that, then I'm not prepared to have to rebuy everything at full price for v4 support (When the PMDG 737 package is released this would be the third version of have been purchasing for the same plane!) I'd feel differently if we were getting an overhaul like the NGX reboot, but if it's purely a compatibility update then it's not worth paying a higher price than other users at a third party store. TL;DR - You're welcome to my money, but I won't pay more than other users just because I can't PayPal Mark Fox
  6. Well, it also helps that a lot of the default aircraft use XML based gauges which are architecture neutral so will work either way, since the basic functionality they require is provided by the core sim rather than a standalone DLL specific to the aircraft. Quite sensibly, the default aircraft in FSX are mostly (possibly entirely) built like that, so will therefore work fine.
  7. Had to refund the 767 from them after they stopoed bothering to respond to my support thread about a constant crash to desktop, after asking questions I'd already answered in my initial post they never did anything further. As such it's highly unlikely I'll pick up their 757 either, which is a shame considering how highly regarded the 767 seems to be. Still, I wish them the best of luck with it, and hope it brings joy to the people who do buy it
  8. Well, that still indicates that there must be a third factor at work. If it was purely an FSUIPC5 + 747 issue, then everyone with those two products would be experiencing the same thing Mark Fox
  9. Had FSUIPC5 installed here before installing the 747 - didn't have any issue with activation, gears or displays, so there must be another factor involved Mark Fox
  10. markdf

    DLL

    uiautomationcore hasn't been a needed fix since FSX (pre-Steam) - Dovetail patched it for the Steam edition, and Lockheed Martin also fixed the bug when they released Prepar3d originally. Best case, it'll do nothing. Worst case installing the file will introduce instability for you. Mark Fox
  11. A good amount of UK2000 scenery (other than EGLL v3 which crashes regardless - v1/v2 will work) will work as long as you don't load the UK2000 Common Library.
  12. The new system works for scenery, simobjects (aircraft/etc), and for loading standalone dlls/exes, so there shouldn't be too many add-ons that aren't capable of being installed that way. (Only issue I can foresee is addons that rely on replacing stock files, unless LM add some sort of "override" syntax.) I've been converting as many of my old addons as possible to it, to make future reinstalls easier. Mark Fox
  13. Just tested Plan-G, seems to work fine and will connect to P3Dv4 as long as you use FSUIPC rather than simconnect (which fails) - this bodes rather well for older programs that aren't going to be updated but use FSUIPC. Only seems to scan the traditional scenery.cfg, so any scenery using the new add-ons folder will obviously not be picked up. On the subject of no longer updated software - Radar Contact v4 also appears functional once FSUIPC5 is installed, and an updated version of makerunways lets it pull data from P3Dv4 with the same limitations as Plan-G for now. It currently does not appear in it's own text box, but hijacks the notification area at the top of the screen instead - not perfect, but definitely usable! :) Pete Dowson has stated that a further updated version of makerunways should be released at a future (unannounced) date to work with the new add-on structure. Mark Fox
  14. It is entirely possible that by purely recompiling with the /LARGEADDRESSAWARE flag, that they can grant FSX access to more memory on 64bit OSs, even though the code is still 32bit which would vastly reduce OoM errors. Typically this can grant an increase from the default 2gb to 4gb, and in itself would be a worthwhile change - and if they haven't done so already, I'd be very surprised if it didn't follow as an early update. http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx states: A similar technique has been used (by reverse engineering/3rd party patches) to patch games such as Fallout 3 which also suffer out of memory issues from large collections of add ons, and has worked very effectively there to improve stability with large amounts of add ons loaded.
×
×
  • Create New...