Roman G

Check your sound settings. Try to disable hardware acceleration for audio.

The difference between MS Flight Simulator and LOMAC is that MS FS has SDK (software development kit) and LOMAC has not. The SDK allow third party developers to provide FS add-ons - while LOMAC modding is much more limited. So for FS there is a lot of developers outside of Microsoft - while with LOMAC we are limited to ED's resources. There were a couple of threads suggesting that LOMAC should provide SDK but as far I remember the official word about that possibility (I guess it was Stormin - not sure whether he was still in ED that time) was that ED is unlikely to release one because of fears of competition "reusing" their code . I read those threads and it seems to me that there was big confusion between open-source code and SDK. Most people thought that it was one and the same. IT IS NOT. Releasing SDK does not mean you you have to disclose your source code. Perhaps a biggest example of this is MS Windows Win32 SDK - which is SDK for Windows operating system. Microsoft realeased this SDK a long time ago and in that time it was (and still it is) one of the best documented SDK compared to competition. Lot of developers started to make applications for Windows because it was easy to do - and guess what - everybody who is using those applications must buy MS Windows - that's why MS makes tons of money. They did the same thing for Flight Simulator - they made it like operating system (well in less scale) for flight simulators. I think ED not releasing SDK and not wanting it - is bad business strategy. They could make money on each third party add-on - because users for these addons would have to buy original LOMAC ("OS") in order to run them. LOMAC terrain engine is wastly superior to nearest competition - this make for a LOT of eye-candy, and their aircraft models are at least the same quality or better than competition. If they provided SDK then a lot of people would be interested. An example of sucessfull SDK for games might be Operation Flashpoint. Even if it is about five years old game people are still releasing addons for it DAILY (!) - take a look at http://ofp.gamezone.cz.

The only problem I have with that is that if you hit flap-down key twice by accident at high speed then your flaps will break out of your wing (it happened to me already in SU-25T - not sure whether ED modelled this for other planes). If it is not this easy to put your flaps into landing position in real life then I would restrict the flaps-down key for "combat flaps" position only - you shouldn't be able to use flaps-down key to put flaps into landing position - I would recommend other key for that.

As far I remember LOMAC ignores the flaps command when flaps are currently moving. So perhaps when your slider is in lower (landing) position - you try to go to upper (flaps-up) position - but as your slider goes through middle position you will start move flaps to combat position - and your "up" command will be ignored because the flaps are already moving into combat position in time when the "flaps-up" command is issued. Could be wrong however ...

Yes, my bad, you are right - two keys are currently enough to fully control flaps in LOMAC. On second thought - it probably wouldn't be good idea to use the same button for puting flaps to combat position and putting them into landing position. I once fully retracted flaps on SU25T during high speed in hope to quickly slow down - and one flap piece just broke out (good modelling job ED !) - it was then quite challenging to fly the plane with half side of the flaps on one wing missing. So if the same key was used to control both flaps position then this could happen acidentally quite often. The way I would like to control flaps is: o one button (F) - to move flaps from "up" do "combat". If flaps were already in combat position then this key wouldn't do anything o second button (CTRL-F) - to move flaps from "landing" to "combat" or from "combat" to "up". If flaps were already in "up" position then this key wouldn't do anything. o third button (SHIFT-F) - to move flaps into "landing position" from any previous position. If flaps were already in "landing" position then this key wouldn't do anything. This way you can control flaps without remembering/looking where your flaps currently are.

To go flaps from up position -> to combat -> to landing and reverse you have to actually do F -> Shift-F -> Ctrl-F (or F) -> Ctrl-F (or F). At least for Su-25T, I just tried it. Pretty confusing. Even you got it wrong. I agree with 169th_Cobra's suggestion. That way you need only two keys to fully control flaps - and there is not much mistakes you can do there. Currently you need three keys to fully control flaps - and if you are using F key you better take look at where your flaps currently are because otherwise they might go opposite direction than you want them to go.

That depends on what is actually "eating" CPU time in LOMAC. If let's say 5% of code (for example collision detection plus visibility detection - like whether object A (radar) can see object B (plane) ) eats 80% of CPU than it might not be that hard to change that 5% of code to run in multiple threads and you will get about 65% performance boost. If LOMAC modules consume CPU more or less evenly - then supporting multicore/CPU could be really a major task.

So the laser beam moves that it illuminates cone or pyramide-shaped volume in space instead of illuminating just a point in space ? That plus what you said actually would be explaining how it might work (even if for a rotating Vikhr missile it might be hard to tell whether it is left or right from the beam (unless it has inertial sensor inside, I don't know) - it might use different algorithm which might tell it whether it moves away or into the beam). Thanks !

Glacier, I am not sure how long you are planning to keep the box you are going to buy. If it is let's say two years and ED will in six months release patch which will enable full multiple cores utilisation - which will almost double performance on multicore/dual processor rig when running LOMAC - how will you mentally cope with your then-six-months old CPU decision ? ;) Don't forget another scenario, you buy multicore box now and after two/three years LOMAC still does not support multicore/CPU boxes ? Hopefully some other games MIGHT support it (again not certainity that they will) ... I think at this point - without any word from ED about their plans to support multicode/CPU boxes - your decision is just a bet :).

Excuse my earlier ignorance about laser beam-riding. I checked the manual and also did some research on internet and there is actually such a thing as laser-beam-riding. The missile sensor(s) is not in the missile head but on or near to missile tail fins. Sources are sying that this system is much more resistant to counter-measures than laser illumination. Still I don't know how this works from physics point of view. Does the missile actually see the beam (because I don't think any missile would be able to ride exactly-on-the beam - especially Vikhr with it's spiral flightpath) or the beam is diffused with greatest intensity in it's center so the missile detects intensity difference and tries to keep itself near the center of the beam ?

I strongly agree. I remember how confusing it was when I was trying to buy FC. In that time the lockon.ru web site was saying on couple of places that payment method is PayPal. When tried to pay for FC it even redirected me to PayPal. But from reading forum I knew that PayPal option was no longer accepted by ED for at least a week. But even on the forum a couple of stickies were giving instructions about how to use PayPal, and ANOTHER couple of stickies were saying that PayPal will be not accepted by ED for "future" FC purchases. VERY CONFUSING ... Was not sure whether by "future" they meant "from now on ...", from "some (unknown) date in future", or "sometime in future" ... ED definitely needs to improve it's bussines communication with user's base (A LOT).

I am not an expert but I don't think the skhval missile is actually "riding the beam". I don't see how it would physically be able to do it. I think it just navigates itself on the point illuminated by the laser ...

No, I don't know about any problem with Vec Expansion. I was just thinking since head Z-movement with Vector Expansion is used for cockipt zoom in FC than it might mess somehow with your other zoom settings ...

Force_Feedback, are you using TrackIR with Vector Expansion by any chance ?

Han, Thanks for checking. Here is my latest story: 1) I got mouse bindings working a few minutes ago. 2) I don't know what I did to make it working. In case you are interested in further details - here they are: Attached is snapshot of my current mouse bindings. To me it looks exactly the same as I had it when my mouse was not responging to pitch / roll settings. FYI, I was installing (a few days ago) FC on clean XP system where LOMAC was not installed before - but the hard disk was used for LOMAC in past. I have dual boot system (Windows 2000 and Windows XP) and I was previously playing LOMAC on Windows 2000 using the same hard disk. I uninstalled LOMAC from Windows 2000 before installing it on XP. I am using DirectX 9.0c. After I read your post I experimented a little more with my settings. I tried to turn off "Enable Responses" check button for all mouse axis. I ran the game and mouse was now responding to pitch and roll!!! Then I went back and enabled "Enable Responses" again, ran game and my mouse was NOT working for pitch and roll again. I tried several times to turn "Enable Responses" on and off, when responses were OFF the mouse bindings WERE working, when it was ON then mouse binding WERE NOT working (except for Axis2 - zoom settings). The "Enable Responses" OFF option was not quite acceptable for me because then the mouse sensitivity curve was not active and I had to move mouse all around the whole table to control flight stick. I didn't remember whether "Enable Responses" option was available in 1.02. So I went ahead and uninstalled LOMAC completely and manually deleted all files left there. Then I installed LOMAC 1.0 and binded mouse axes to pitch and roll. I tested it and it was working. The "Enable Responses" checkbox button was there, I tried to turn it on and off and the mouse binding were still working doesn't matter what "Enable Responses" option I choose. Then I installed FC, went to options - binded mouse to pitch and roll again (the FC did not picked up the LOMAC 1.0 settings), tried it and NOW IT WAS WORKING with both "Enable Responses" on and off!!! I really don't remember what I did differently with this LOMAC install since I did the same thing a few days ago (installed FC (mouse bindings were not working), then uninstalled, installed LOMAC 1.0, binded mouse to pitch roll axes (mouse settings were working with LO 1.0), installed FC, binded mouse once again - mouse not working with LO 1.1). Only difference I am aware of is that previously I had no TrackIR installed before installing LOMAC & FC, today I had TrackIR drivers installed when reinstalling LOMAC. Shouldn't matter - but who knows ... Other thing is that I am usually not running as administrator when using my box. Previously I installed FC as administrator but was changing my mouse settings under different (non-administrator) account (there were actually a couple of issues I had to solve when trying to run LOMAC as non-admin - maybe some day I will post those). Today I was installing and changing mouse bindings as administrator only ... Hope this helps ... Thanks again for veryfying my problem ... Roman

I bought FC just two days ago. I was able to use mouse for pitch & roll control in 1.02, but I am not able to use it with FC 1.1. I also tried to enable CockpitMouse in the lua file, it didn't help. Is there any solution available for this apart from buying joystick ? Thanks, Roman

Excelent. Thanks !

MBot your IP address will sure get onto Homeland Security radar soon. Be prepared for extra treatment on the airport when you are going to board your plane ;) ...

800 x 600 resolution. 200 : 1 contrast ratio. Are you OK with that ?

No, you actually don't have to. You can generate the data using noise functions (such as Perlin noise) and unless you live in the area you won't be able to tell whether you see real terrain data or not. This is what (IMHO rather unsuccesfull and very buggy) SOLDNER game is doing. They are using real data for area about 2000 x 3000 kilometers area in about 1 x 1 km resolution. To get more detail they generate the "in bettween" data by noise functions - and the result is IMHO very good. LOCKON also use noise functions (as far I remember for terrain textures, clouds and perhaps smoke). If you saw any CGI holywood movie, they all use parametrized noise to generate data. Otherwise it would take about forever to manually create all the data seen in movies like Finding Nemo. The "inventor" of noise function usage - Perlin - actually got Oscar for this his contribution to Holywood special effects. Those interested in more info can take a look here: http://mrl.nyu.edu/~perlin/ http://freespace.virgin.net/hugo.elias/models/m_perlin.htm DayGlow, you are right, the procedural textures (most of them use noise functions), can reduce texture size more than thousandfold. The problem is that - as far I remember correctly NVIDIA GPU programming articles from less than year ago - they are still very slow for using in real-time. They way how they are mostly used today for real-time apps is that the procedural textures are pre-calculated usually when the application loads - instead of loading texture from JPEG file the texture is "calculated". The problem with this way is that you lose the memory size advantage - once the texture is "calculated" it occupies the same size in memory as if it was loaded from a JPEG file. I don't remember direct hardware support for noise functions advertised in Cell (if It was there I am sure they would tell about it), so I presume - while the Cell might be faster in calculating procedural textures in real time - it is probably still slow. The other things you talked about - the normal maps, light maps and so on - they are in fact additional textures - while they improve model look and require fewer polygons/triangles for rendering - they are still just additional textures (of different kind) - you need "original" texture PLUS normal map/light map/specular map & reflection/environment map to render your model. But yes - with normal map your model might require far less triangles. This is what FarCry & Doom are using ... One more link: info about PS3 on Wiki: http://en.wikipedia.org/wiki/PlayStation_3

The only sure-realtime part of presentation I saw was the Unreal Engine demo presented by Epic & NVIDIA CEO, and series of demos started with the Lot-of-Ducks demo. All those demos theoretically could be running on today top PC. I have no doubt that the part with "upcoming game demos" (such as Killzone) was prerecorded and played simply as a movie during presentation. If you just look at choice of camera angles on these demos - no way that somebody was driving those virtual cameras and making scene cuts in real-time during presentation, so yes - the presentation could be running from PCs as a movie. The question is whether prerecorded scenes were captured from real-time gameplay, or they were non-realtime-rendered. Even if I have no doubt that CELL & RSX are significantly outperforming current PCs and that comparable horsepower probably won't be available for "under $1500 PCs" for about next year or two - I still have doubt that PS3 will be able to give realtime graphics equivalent to what was presented on those game demos. Even two TFLOPS might not be enough to do that. Plus 512 MB of total CPU & GPU memory seems too tight to fit amount of polygons & textures used in those scenes. I watched a interview with Sony representative (the same guy who presented Lot-of-ducks demo) presented by G4 channel - they directly asked him whether the graphics of KillZone demo was real-time. The guy answered as typical politician, saying a lot of other stuff, saying that to produce that demo they used real KillZone game engine and so on so on, but I don't remember or catched him saying - yes - when you will play that game on PS3 you will have the same graphics. Saying that the real game engine was used to produce that demo is not quite enough. Even in LOMAC you might record track with low graphics setting and then non-realtime render the movie of it using much higher graphics settings. Ruggbutt, how your brother know what was inside of those "PCs or Macs" he saw ? How he knows that inside that PC box was not Cell & RSX? That might not be that unusual because I can imagine when they do prototypes & testing - they probably won't put the hardware inside the PS3 box - they might not even know how PS3 box would look like in time when they were preparing for E3. But I will also take wait & see attitude, as I said even two TFLOPS might not be enough to run realtime graphics of those demos and I am even more doubtful about the 512 MB used for that. But for me the new PS3 and Xbox 360 hardware are major step forward - if nothing else they will help develop multithreaded programming techniques for games (since both new consoles are multi CPU/cores) - and this will be useful also for upcoming multicore/multiCPU PCs.

Yes, both consoles hardware-specs are very good news. I never thought I will want console - but the specs are excelent ... so I don't know ... The only consoles spec not better than current PCs is the memory size (512MB for sum of system memory & GPU memory). Let's see how soon the games FULLY utilizing the console hardwares will arrive. I think it will take at least a year ...

Some time ago I asked on Lomac Forum multi-processor box owners whether they see any FPS improvement in Lomac compared to single-proc boxes with the-same CPU frequency. Their response was that the FPS was about the same. I think this proves that Lock-on is single-threaded. Maybe some minor things are running in separate threads but the main functionality in Lomac appears to be single-threaded. As 99% of gaming computers are single-CPU boxes - there was no much incentive for programmers to write multithreaded code. What is singnificant in recent dual core shift is that in about two years perhaps 25% of computers will have dual-core CPUs. The games which will be able to fully use both cores will be able to outflank competition. This alone should be enough reason for developers to start developing multi-threaded games. I think it might be quite easy to split a lot of functionality into multiple threads in Lomac. From top-of my head I can think of these: each aircraft is pretty independent on each other so the advanced-flight-dynamics simulation should be able to run in separate thread for each aircraft (or simulation for half planes run in first thread and simulation for second half of planes in the second thread). All this without any need for synchronization, except perhaps for passing the resulting aircraft position and orientation to the rendering thread (this should be just a couple of hundred bytes per second data transfer). Other fairly independend parallelizm I can see is bullets simulation. Again they are independent on each other (I think we can ignore cases when one bullet hits another) so their balistics and collision detection calculations with ground/objects should be easily splittable into multiple threads.

I think (I might be wrong) the ruling is also about that you should be able to make backup copy of your CD, which in the case of SF-protected CD you are not able to. I don't think the ruling will stand - as it have wide consequences for a big market (France - perhaps EU?) with huge opposition/money from the movie industry against it. OT: Personally - for software I like more the the per-computer activation approach that having to run things from CDs which I cannot backup. With that many activations as ED currently offers - I think you will be able to run FC longer than lifetime of actively-used single CD. With copy-protected CDs and requirement that you have to have that CD in the drive while playing game - I don't like that I have to change CD everytime I start different game/software. Plus, my CD drive can be VERY noisy ...

I think the info in the first post might be useful. However (if I understand the company's offering correctly) it helps to solve just small part of the online-shop problem - that is that buyers will not get "Unknown Certificate Authority" warning from a Web Browser during payment transaction. Which is not a big issue for somebody who knows what that warning is about - but can scare off many others. (There was actually post on this forum about test SSL certificate ED was (and still is) running on their site - most of people actually don't understand the certificate warning). I haven't read more info from that site though for information whether that company also provides credit card payment services in Russia too - anybody read it through ? Dmut, whether putting up custom online shop is big task or not - it all depends. If everything works well (such as - your other suppliers such as StarForce and payment processing company has well built and reliable interfaces) then a couple of experienced people could do it within about two months, maybe less. If there are problems - such as after you deploy your site you discover that your supplier's software deesn't work as promised - then it can take many times that time. It can be also done gradually - you start soon with something which is not completely perfect but working - and then you improve it over time ... I work as programmer on online trading services for major brokerage company in US for about seven years - in case you are wondering how did I get my estimates ...