Asterix28573

Ok, I'll reach home aprox. at 16:30, I'll send you then the profile. I'd need your email address, though, so if you could send it to me through PM... :) Cheers, Asterix

Hi, I'd send you mine, but it's not for HazardScript but for Biped (another Dhauzimmer's driver profile editor). If you are interested just let me know and I'll send your ASAP (ASAP means in aprox. 8h from now as I'm currently at work ;)) Best regards, Asterix

Hi, Maybe it's some sort of incompatibility with StarForce drivers. You should check Starforce site for help on this. Sometimes it's just a matter of reinstalling the burner software, IIRC. Regards, Asterix

OK, your GPU is somewhat hot. This could be very well the cause, but I don't know. If you say that it has always run at that temperature, well... I still think it's a bit too hot. Anyway, you can be sure that a game in XP CAN'T restart your system. At maximum it can crash and XP will show you the usual message about "this application has caused an error etc etc...", but it can't alone make your system reboot. This only can be caused by, as posted before, as hardware issue or a faulty driver. It's for this I said you to disable the automatic system restart on crashes. This way ff it's a driver you'll get a BSOD with a message telling you what driver has caused the error along with a some cryptic message indicating the reason (something like "Invalid IRP call stack" or whatever...). But if your system simply reboots inmediately without any BSOD then it's for sure a hardware-related issue. If it only appears with 1.1 is maybe because this pushes limits a little bit harder that 1.02 ;). Regards, Asterix

Hi, Automatic restarts are mainly due to any hardware malfunction (including CPU overheating sometimes), or to a faulty driver. In the first case you should try to fix whatever hardware issues you might have with your machine. Most probable candidates are memory and VGA card. Try i.e. to extract one by one your memory modules (alternatively) to see if without anyone of them your machine runs fine. For faulty drivers, you should first be sure that you have "Automatic Restart" option turned off. I can't remember right now how to deactivate it, but it's somewhere in Control Panel. With it turned off you should receive a BSOD (Blue screen) telling you what driver has caused the error. This should help fixing it. Regards, Asterix

I don't know.

Hi, Radar emissios obviously can't be stopped at 15 km ;). They are electromagnetic signals that extends indefinitely until they vanish by losing power with distance. The only way to "limit" them would be to emit such a low power signal that would vanish at aprox. that distance, but I really doubt it's that way. It's the radar logic of the emitting aircraft who discriminates and ignores any return from beyond that limit distance. So yes, a real RWR should detect those emissions, although I really don't know what happens in LOMAC. If GGTharos says it doesn't, then as he says it's wrong how the game simulates it. Regards, Asterix

Hi, As said a zillion times before, this has happened some times, to some users, and when using some configurations of DVD burners / sofware burners / Windows and so on. Statistically there's more problems with graphic cards than with StarForce. And, to my knowledge, most of the times this problems can be solved by a full reinstall of these software in an appropiate order (Windows driver stack is somewhat "delicate" sometimes ;)...). By the way: I have a DVD burner that still burns at the usual speed, using the very same program I used before (Nero or Sony DVD Arquitect), and my "virtual" drives (at least Nero ImageDrive) are still working too. And all this without taking any specific care when installing FC ¿can you imagine? Best regards, Asterix

If you exclude "drivers" from "software" category, then yes, you are right ;). @T-Bone: if the problems have appeared after installing a new version of Cat drivers, then try to reinstall old ones. If the problem disappears, then don't reinstall new's. Sometimes lastest drivers are not the ideal ones for "old" cards, because they are intended for the lastest products. At least, this is how it works in nVidia world, although with ATI it could be different, though. Cheers, Asterix

Hi, Sorry for my ignorance, but... ¿What does "vortex effects" mean exactly? Regards, Asterix

Hi, Sorry but there is something that I can't understand in your post: if the problem causing the hog is that his CPU is not powerful enough ¿why should he turn sound hardware acceleration to minimum? This would allow more workload to the CPU. Best regards, Asterix

Hi, I know there won't be a DC inside the game at short - medium term, and probably neither at long term. Developers seem focused exclusively in the simulation part of the game, adding new flyables, optimizing graphics, etc... They can't - or don't want to - develop a full DC engine because this will take up too much resources on dev's hours and money, and probably the result will not be worth the effort. What I was proposing was simply a sort of 3rd way between the duality of "DC Yes - DC No" paradigm. DC Yes, but external. I don't think it's something so strange, it's just a step forward the current missions editor, but in runtime. However, I can't understand that modding planes is out of the agenda for now, as this would require a lot more of interaction between the game and the modder, so the later could add specific code to deal with specific radar modes, weapons, etc... As Pappavis pointed, it's impossible to know how difficult would this be without knowing how's the code organized internally. Best regards, Asterix

Exactly :D. Regards, Asterix

Hi, Thanks a lot. This is all I wanna know when I started the thread :D. Cheers, Asterix

Hi, Just to clarify: what I was suggesting is precisely a way to avoid putting LOTS of units inside the game, so converting LockON in a sort of 'bubble' in which units (friendly / enemy / ...) are DYNAMICALLY entered / retired as long as the player moves arounds the theater and, most important, in real time as the player flyes. This is process could be done if LOMAC provided some sort of mechanism to do it, like a hook DLL, an OLE interface, whatever. This interface should provide the "client" program (the campaign generator) a constant flow of information about what's happening inside the game, and according to the events this client software will feed / remove new data inside the simulation world. This indeed could offload the LockOn simulation, as "action" occurring out of the player scope could be removed from it and managed by the "client" AI, which could simulate the results à la Falcon (statistical computing based on player's rating, i.e.). This is exactly what the Falcon "player bubble" does. However, instead of reimplementing such a complex mechanism ¿why don't convert the whole LOMAC game in THE bubble? I think it would be fairly easier (note that I say EASIER, not EASY) than reimplementing Falcon engine again (after all, Falcon engine is just what I say packed inside one executable file). This "client" could be a completely automatic campaign generator, or else another one that allows for some kind of external user interaction during playing, thus allowing for something similar to the "Force on Force" concept implemented in F4-AF (it was included in initial Falcon versions, but it was too buggy to work, IIRC). This can open a whole new world for online gaming, with both a Red and a Blue human "generals" adding / removing flights (both human and AI) from the whole game in real time according to what happens in theater). As I said in my previous post, there's a number of 3rd party Campaign Generators out there that could benefit a lot from such an interface, for the reasons yet posted, and this could open LOMAC to a new whole modding world, while the developers keep focused in "simulation" part of the game. Just an idea. Maybe you can think I'm a dreamer (John Lennon said... ;)), but I'm a profesional C++ developer with a lot of experience, and I know that such a system would not be THAT hard to implement ;). Just my 0.02€ Asterix

Hi, Water is the texture assigned to the "base" surface, and it's only really rendered when there's nothing above it (i.e. the terrain surface). The card Z-buffer management takes care of not rendering those parts that are obscured by any other object (in this case, the terrain mesh). What happens sometimes is that the terrain mesh and the objects above it, aircraft polygons and textures, etc... loading process take some more time than expected due to system "congestion", and this causes the water to be visible just because, when render occurs, the terrain mesh above it has not been yet loaded. This is normal, and as soon as the terrain info is loaded the water stops rendering, just because it's not yet visible. Well, I hope you get the idea... Believe, this is a very common technique in 3D graphics, and I can assure you that it works fine :D. As stated 1 zillion times, it's more efficient to let the GPU do this "clipping" that do it "manually" by software. The GPU has specific circuits optimized for such a job ;). This is something similar to be wondering if the light of your refrigerator effectively turns off when you close the door... Cheers, asterix

Hey, something has read my idea :D! Cheers, Asterix

I though the 'C' technique didn't work any more with FC. I seem to remember that one of the things stated in the readme file for 1.1 was that the use of cannon for IFF had been disabled because it was considered indeed a bug. I'm currently at work so I can't test if it really still works. ¿Could anybody confirm if this is the case and if so which are the RWR reactions? Cheers, Asterix

Yep, but I was asking specifically for HMS mode, which takes profit of extended gimbals of the R-73 seeker. ¿What happens if the target is outside both's gimbals (radar / EOS)? ¿How I command IFF in this case? I assume that I must point the nose to it so the radar covers it, isn't it? Regards, Asterix

Yep, I supposed so. No prob for me, if this is the IFF game implementation then let's deal with it. So (going back to the original question): I assume that in HMS I must point my radar to the target and activate it shortly so I can get an IFF response from him. If I don't get the 'F' in the HUD then it's a hostile, isn't it? And I suppose also that if the target is outside my radar gimbals then I won't get any IFF information (which dangerously equals to 'hostile'...), isnt' it? I'd just want to clarify this to avoid more mistakes... :) Best regards, Asterix

Hi, From some time ago I've been thinking in "3rd" way that maybe would interest ED about the DC subject. ¿What if they implemented some kind of mechanism that allowed "external" control of LockOn? What I mean is: expanding the current LUA interface or even create a new one (through a DLL interface plugin, i.e.) that allowed a 3rd party executable to monitorize all the events ocurring inside LOMAC's 3D world, and according to how they're developing then, in RUNTIME, add / remove the proper elements inside it (i.e. launching a CAP flight when you are detected by an EWR station, i.e.). At the very same time, this external engine could throw off of the LOMAC 3D world those objects / planes / whatever out of the scope of the player, thus creating an effect similar to the famous Falcon 'bubble', where all the "war" out of that player bubble is only statistically simulated according to player's rating ("2D-war" in Falcon terms). I think this could be a good approach for the following reasons, i.e.: creating a Dynamic Campaign engine from scratch is a VERY hard task. Look at F4 campaign engine: after near 10 years there's still a lot of bugs in it. For instance the "bubble" mechanism wouldn't be necessary, as the game itself would be the bubble, and all the 2D calculations would be run in background by the Campaign Generator software. there's a number of 3rd-party "Campaign Generator" projects in development out there (I think SwingKid had one, IIRC...). AFAIK currently they only can generate missions according to the debriefing of the previous one, but not interact with them in runtime (which is the cool part of Falcon DC). Maybe if such a mechanism was designed they could, thus creating a new interesting "market" for add-ons. Just my 0.02@ idea ;). Best regards, Asterix

Ok, but then ¿what will happen if I'm using HMS and the target is outside radar gimbals (this is the good part of HMS, after all...)? Will IFF work as usual or will have to point my nose to the target to get a proper IFF response? There's a thing I don't understand about how IFF seems to work in Lockon: AFAIF IFF is implemented IRL using some kind of encoded radio signal (but NOT radar) sent to the remote plane. This signal contains the interrogated plane's position/speed/whatever, and when that A/C receives the IFF signal it checks that data against himself, and if they match then he answers with a "Hey, this is me and I'm your friend!" answer. ¿Why is then radar necessary in LockOn for a proper IFF interrogation? In theory it should be needed, as fighter planes have dedicated antennas for it so it could be used also in EOS mode or even HMS (although positional info of the targeted plane from the lastest is probably less precise). ¿Is LockOn IFF implementation plain wrong or I'm just missing something about the whole system...? Just being curious... Asterix

Ok, thank you. I assume that this will trigger some kind or warning in his RWR, won't it? Cheers, Asterix

Hi, Just wondering how do you perform IFF check when using HMS mode in Russian planes. I mean, if you just discover a plane "around" you unexpectedly ¿how do you check if it's a hostile trying to sneak up on you or just an inoffensive friendly following his route? I ask because yesterday night I shot down a pair of friendlies in that situation and I'll be glad NOT to repeat it :redface: ... Best regards, Asterix

Hi, Maybe this is also useful to you: http://forum.lockon.ru/showthread.php?t=8539&highlight=key+card It's a useful sheet to have printed at hand's reach while playing, even more than the official key list from Docs folder. Cheers, Asterix