TheGrunt

Nobody knows the answer to that except people in LM. I guess we'll find out quite it quite soon as a company in that level probably releases announcments if something will happen in near or longer term considering the developement and/or support (I believe some of the LM layoffs happen till the end of 2014). In any case, nothing we can do about it.

I also bought yesterday Boston along with the Massachusetts and took short flight around the Boston city centre and I liked it a lot. Is it worth the price? One have to judge it by themselves. I don't regret buying this at least for the discount price. I didn't notice that big increase in the loading times and flight was extremey smooth in P3D. I only have those sceneries + meshes activated which I use in the flight, though.

And as a template (or as is) it is easy to use the settings of about same size default aircraft.

What a relief it was when I got to the end of the thread! PacSim sceneries are awesome (and mostly beautiful areas ignored by other devs) as is the support and it would be a loss for the community them to shut down.

There are no night textures with MSE 2.0, so you are seeing default, UTX or some other night textures. In their store page they are promising night textures as a free upgrade later after the day sets for USA are released.

I may be wrong and I have just forgotten, but is this part part of the contract confirmed somewhere? This contractual restriction seems to pop up in P3D and EULA discussions every now and then to me this seems just another assumption. I don't remember seeing anyone from LM confirming this and thus this may be completely false. I'm not saying there isn't a restriction, because I don't know about it and there definitely may be something which prohibits LM to compete within consumer entertainment market with ESP licensed software, but I wouldn't be surprised at alll if this is purely just a choice from the LM side and MS has nothing to say to it. After all, it is completely natural when you look at where the company's market is and I wouldn't be surprised at all that they aren't pushing it for consumers even without any contractual restrictions. I know bunch of companies who don't sell their products to consumers, only for other businesses or organizations and at most offer some very limited usage for home use at most, so what is the big deal here? Why there needs to be some contractual restriction at all? And why should it matter why it is not aimed at consumer entertainment? My post is by no means directed to the quoted post in the sense, more in general to this subject that pops up every now and then.After allm this is just one example where some people in the sim community make assumptions regarding the contract without any real knowledge what is written in it and then transform those assumptions to another ones to find some imagined reasons behind the decisions of LM, MS or some other company without any actual facts. After that, some of these assumptions just become truths which are poked every now and then and many seem to hold those either as a fact or then understand them how they personally want to see them. In the end, only thing that matters is the agreement with the purchaser and copyright owner, in the case of P3D LM. What is between MS and LM, is completely between those companies. World is full of applications which are or include licensed technology and nobody seems to discuss those anywhere (unless it is perhaps a news relating to some interesting patent infringement battle between corporations etc). Why? Because it shouldn't concern the purchaser in any way. Even the position of these EULAs and enforcement of them in the court of law differs between countries, so making some generalisations and assumptions of the whole is really quite useless. But EULAs alltogether are another story... My point just is that there doesn't need to be anything complicated why LM is not marketing P3D for entertainment. Or there doesn't need to be any other reason behind PMDG's reason other than the protecting their business with their professional customers and thus keeping those segments strictly separated. Companies make decisions which they think are best for them and their business whether it is a deal concerning licensing or aiming for different markets. No more, no less :lol:

No, I meant that if you have a program which is small enough to fit in the processor cache, even the L1 or L2 which are faster, and utilizes prtty much only the processor without much addressing the main mem, you get quite linear benefit from higher clock speed of the certain processor. FSX though, like many games for example, addresses quite a lot memory and renders graphics through GPU, plays sound from sound processor etc. and all those play part in the performance of the software. FSX is not by any means utilizing only the CPU and thus linear rise in performance is quite impossible to achieve just by rising the CPU clock speed.

It responds at maximum to the relation to clock speed. That is exactly the 4.5% or so and in heavy scenery with 4.5GHz 20FPS it can give you that extra 1 FPS with that 200MHz, but most likely not, depending of the other hardware. FSX doesn't run in the CPU cache like PiFast which shows immediately the extra clocks by decreasing the time of calculation in the proportion. FSX, like other games too, uses heavily memory and graphics, which affect the overall performance. Of course, if you have for example over 60 FPS over less crowded area and we still assume FSX gaining FPS linearilly, you gain several FPS more in the upper area. People seem to look at just the clock speed and forget completely the improvement of the IPC with different generations when they are upgrading. But if you put same Sandy/Ivy/Haswell in compariston with the difference of 200MHz without changing the rest of the configuration, you gain at maximum exactly in the relation of the processor speed, not more.

No way 5GHz is by any means easy or trivial to achieve with any of the Intel procs from the last three generations at least with such moderate voltages that system can be be easily used with air cooling, which is still the mainstream way. And even with water it depends on the rock - a lot. In the history I built several high performance custom watercooling kits (all cooled with H2O, proc, GPU and NB when those were still present) for my systems and it was quite many times that you just hit the wall suddenly. No matter how much you pump the current or fiddle with different settings and temps are low, you just can't get past some level. Leakage current, transistors and data circuits which can't keep up with the state shifts or both just bring you to the end even though your temps are fine. Small, microscopic manufacturing differences make one rock go, others not so much. Same applies today, you need a good chip to succeed with high overclocks and best chances to achieve over 5GHz were with early Sandys. You just need to visit some overclocking forums and it is easily noticable, that most overclocks hit the 4.5-4.7GHz with Ivys and Haswells. In fact, 4.7GHz Haswell is considered a very good chip. 5GHz is difficult even with delidded procs. On the otherhand, slightly better IPC of Haswells and Ivy's pretty much even the performance, if you manage to pull over 4.5GHz compared to 5.0GHz Sandy. Still, many stay even below that. Overclocking is in many cases overvalued and I mainly do it because I like it. Normal games are mainly GPU limited and difference may be few FPS at maximum between default and heavily overclocked system, which is completetely insignificant, when you pull easily 60+ FPS with both default and OC chip. Also, while overclocking helps with some proc intesive tasks, like with FSX and the first core it tends to "overutilize", usually going desperately after the last 100-200MHz is also useless. For example, with 4.5GHz and 4.7GHz there is about 4,5% more clockspeed in the chip compared to 4.5GHz. If that would go linearilly to FPS (which unfortunately it most likely doesn't) and you would struggle at some busy airport with 20 FPS, you could get whopping 21 FPS or just under with those extra 200MHz. That's hardly a FPS solver. Like many games, FSX definitely does not gain FPS linearilly (although it gains FPS better in relation to CPU speed than most modern games, thanks to the way it is coded), so you most likely wouldn't notice anything at all: that less than 1FPS disappears in the normal FPS fluctuation.

I'd probably give it 6, but it has all the possibilites to have full marks in the future. I'll keep my eye on it where it goes, although I fly XP pretty seldom nowadays as it is.

I bumped a while ago in the apparent flight model bug with Prepar3D, but same should be repeatable with FSX too, of course. I lost the control of the plane (I'm not 100% sure what it was, perhaps Piglet's freeware A-1J) in stall and got it in a weird, fast and tight spin, but the plane didn't want to drop to the ground when I released my controls. Instead, it spinned wildly in the air rolling practically around the horizontal axis through the center or gravity (or at least it seemed so). There it was in violent spin for a good while just a couple of thousand feet above the ground until I yanked my controls and finally got the plane crashing down. That was definitely one of those ##### moments with these sims and quite a sight outside of the aircraft.

To a certain extent making chips low power also helps to create affordable processors with good performance. When you increase the current in the chip, heat will become a huge problem and with ever smaller die sizes/transistor count it causes problems in the data circuits and transistors unless you have some special cooling solutions. And smaller manufacturing process is in itself a requirement to keep die size low and still retain high clocks. Die size is huge factor in manufacturing costs and keeping it in affordable level while performance, features and instruction sets increase. Smaller manufacturing process also allows the developement and application of new technologies such as quite recent 3D transistors. Actually Intel made a mistake with their NetBurst architecture, where they practically left power consumption and heat out of the primary design. At first, Intel thought that they could during the normal developement eventually rise the speed of the NetBurst all the way to the 10GHz range and the whole consept of high clock speeds was actually essential to make up with the performance loss of the deep pipeline. But in the end they bumped in to a wall at under 3.8GHz and last Prescotts/Cedar Mills were extremely hot without practically any headroom left for higher clocks. Also chip was much more difficult to implement for smaller manufacturing processes, than Intel at first thought. After that they went back and designed Core 2 which was actually based on older P3/Pentium-M architecture. It is true that there is much thought put to low power applications with modern Sandy Bridge, Ivy Bridge and Haswell processors, though they are marketed for dektops and as Xeon line for servers with negligible or larger differences depending on the Xeon model. Still, especially Intel's 6 core high performance desktop processors are wonderful chips and are still powerful compared to many older designs, while there is much more emphasis in the low power features in the micro architecture than before, one example that low power is not conflicting with performance needs. Market requirements for consumers are still quite small with these kind of processors when you look at the volumes today: laptops rule over the desktop market and with smaller ultrabook designs that become more and more popular, heat is a problem and integreated graphic chips and low power technologies also help to keep the system simple to design, smaller and cheaper. Also all technologies developed to minimize power consumption are essential for server market too, which also in many cases has very different requirements for the processors compared to powerful desktop processor, like single thread performance doesn't have to be that high, but you need to process huge amount of threads simultaneously (that is up to dozens of processors in the server) and you need extremely high performance memory and disk operations with the system. Things have changed and will change. In the future many tasks requiring high computational performance may be processed in the cloud making powerful desktop processors more or less useless as a form of PC we know today (mainframes, anyone? ). There are of course many things hindering this, mainly in the network infrastructure: you'd practically need fast low latency fiber Ethernet connections to be able to run realtime cloud based applications. About next generation consoles they are an interesting example of computer platform design, although to me, it seems that larger steps were made with the last generation. There is really nothing special design charasteristics with new systems, perhaps the only one is the GDDR5 main memory of the PS4. Both use low power CPU which do have the capability to handle 8 threads, that is one per core, if I remember correctly. Cell processor used in PS3 for example could also deliver the same amount of threads and it is far more interesting consept than either of the new consoles and offer still really good performance after 8-9 years of the developement for certain applications, but game developement proved to be quite difficult because of the complicated dev platform (I've heard), the ring bus design of the Cell, which requires careful thread timing in the software design and because of the low performance of the PowerPC core of the Cell, which again practically demands effective use of the SPEs and thus multitasking. This makes Cell really a good processor, even today, for many scientific, encryption and multimedia tasks, but for game design where multithreading is often quite difficult or you at least you gain smaller and smaller performance benefits for threading it more and more and still every time complicating the software design unnecessarily. New consoles will bring the consoles to the 2010's when it comes to performance, especially from GPU side, but the performance estimations I've seen suggest that the CPUs itself can deliver the performance of less than one quarter per core of that of i5 3570K (http://www.rockpapershotgun.com/2013/05/27/week-in-tech-hands-on-with-those-new-games-consoles/). That is quite underwhelming and even though your desktop PC can't handle the 8 threads that are possible with new consoles, its raw power makes up most of that easily. Software optimization is of course wholly another thing as is the performance of the less complicated OSs of the consoles compared to complcated all capable, all around computer OSs. Just my 2 cents about hardware at this point...

Cpu frquency is not like the one for radio receiver, so there is no optimum frequency. In the case of CPUs frequency is related to the states of signal lines and driver transistors. For that the bigger the clock rate, the more you get performance from the processor which means again faster running software. There is no simple way to say how to achieve the best overclock. First, it depends on processor and main board. With some MBs, overclocking capabilities are almost zero and some processors are multiplier locked, which means you have just few MHz of bus speed to rise. Then there is cooling which has huge impact in the overclocking capability. Other components may play their part in the show, mainly memory, if system is using dividers, like X58 platform. After setting significant overclock, hours of stress testing is required preferably with different testing programs to make sure it is stable. Hardware and overclocking enthusiast forums are the best place to search OC information regarding specific hardware types.

I was going to suggest this. Good engine modeling and otherwise nice aircraft too.

FSUIPC payware version fixes the FSX battery draining issue nicely. It has so much other tremendous qualities especially for configuring controllers, so I suggest you get it. I can't live without FSXUIPC anymore.

Launch FSX the way you want, from desktop icon what ever. When sim is loaded, press fly now from REXE control panel and weather engine starts.

I haven't coded a single line of C for over fifteen years and it is years since I fiddled with assembly on 808x series processors and my knowledge on programming otherwise is also quite poor (some Java, Ruby etc.). Programming really isn't my line of business (I'm in comms and networks line of work), but still that is something I suspect too: Assembly code in FSX is simply inline assm within C or C++ code, where assembler is used to limit inefficiences or constraints of the compiler. That is the way it is mostly used nowadays, but on the otherhand, LM team member said that it is old code and as such used in a way that is not that usual today. And for that I don't wonder that there may be some diffiulties in conversion to higher level language and/or to 64-bit may be daunting task. And I agree with everything you said. There is usually a reason when asm is used nowadays. Performance yes by doing things in simpler and with more straight approach like I said to get away with compilier limitations. But as you said, assembly is very hardware specific and you easily may run into troubles and do stupid things with it too. Like you said, there is no "right" programming language.

LM team member told about it in their forum or in interview, can't remember which. He didn't say anything about the amount of lines in it but you don't need to have "large portions" of it to run into big work with conversion. About the programming language effectiveness. IMO it is pretty much bullcrap, when some claim that low level languages are somehow noticable faster in essence. True, assembly is practically symbolic machine code and very close to what processor understands, that is zeros and ones. With higher languages it comes to the compiler, but also very much to how you code it. You can make performance lowering mistakes with assembly too, perhaps even more because it is far less intuitive than C/C++/Java for example. Only thing you remove is the possible inefficiences of the compiler. Main point is that there is no practical difference if you know your code and have the skills. Sent from my Lumia 800 using Board Express

This. Of course they would sell it to one who bids enough, unless there are some restrictions from LM/ESP licensing scheme. But they don't have to do it cheaply. At the same time they don't have to do it, because they don't need the peanuts they could pull from it: MS has no reason to sell away its assets. And they are a company so they there is no reason to do some charity for the sake of few sim enthusiasts. World is full of similar kind of software which have no more support or developement, even far more less users than FSX, is older and even the developer has went belly up, but the code is still under copyright and is propretiary code that someone has rights. Source is closed even if the economical benefits for keeping it that way are meaningless. FSX is no exception, it is like 99% of the propretiary legacy software is.

This. It is really hard to believe that there is assembly in FSX that is still a quite recent software. You would think that it is coded fully with C++ and possibly some older stuff with C, but no. There is Assembly in it, which is straight from the computer jurassic period! Assembly is completely fine nowadays for one thing: using it as a one part to teach first year bachelor students how processor or microcontroller works. I don't know what they've used there that is assembler stuff, but it has to be old, at least from deep 90's.

In many cases it is, but not always. In the easiest possible scenario, you pretty much just recompile your software and you are done. But something that has old and low level coding in it and who knows even badly documented, things can get quite tricky.

Very true. Besides, you can't "emulate" 64-bit. Your program either has 64-bit word length or not. If it hasn't and it is 32-bit, you have to rewrite the software core to get it to 64-bit. You can't magically make for example a 32-bit address pointer or integer in the code to change into 64-bits or vice versa. How big conversion task is, depends fully on software architecture. If Laminar Research achieved it with XP, it doesn't mean that it can be achieved easily with FSX, which still has parts of some low level Assembly code from the 90's. LM guys have said that 64-bit conversion is a tough and long job. Is it even practical anymore, who knows.

Ezdok is its own process and runs in its own address space. Accufeel is a dll module that is loaded within FSX address space. Accufeel is so small, that the overall impact to memory is negligible.

Awesome! Great model gets even better with this. I'm going to download this immediately when I get back from work. Big thanks to you and all the contributors! :im Not Worthy: :Party:

I have pretty much same stuff and I've been happy with them. I have actually two quadrants, as yoke was bundled with one. I don't use it though, as it attachs to specific yoke port (not usb) and I always remove yoke when I'm not flying a plane equipped with one. I also recently bought Saitek TPM which is good for many GAs and also features 9 on/off or select switches, which I haven't yet fully set. IMO Saitek stuff isn't perhaps the best available equipment out there, but they offer good value for the money and a good selection of different controllers. TrackIR is also a must and I can't fly any sim without it anymore, they feel just silly. TrackIR helps working with VC hugely and gives beautiful immersion with triple monitors.