topdog

Only time I could think you might want to use a "gaming mouse" would be if you didn't have a separate throttle unit (so instead of a HOTAS you could have a.... HOMAS? instead, hehe). In that situation I could see it bringing some relief, otherwise (and I have a moderate gaming mouse in a razer copperhead) I'd feel there's not really a purpose for it. I still only really wind up using basic mouse features in the end and leaving the bells and whistles alone.

You need the 'macro' option (which can be by itself, or you can tick the box for Advanced Command rows to act in macro mode) to have a button that once clicked, carries out all actions assigned even if released before the actions have completed. That's how Saitek differentiate what a macro is. Not too many use cases for us simmers to need an interruptible sequence; unless you wanted to be lazy and have a full startup sequence bound to one button press but with the option to stop the sequence if something bad/wrong/unexpected happens and you want to abort it and continue to fix things from there manually. Otherwise as a macro, it'd continue to drone on through the mess unaware of the issues. By the way; not sure what you mean about not loading profiles at system startup, unless you mean it's a choice that people make or before a user has logged into their Windows account? The top profile that's active with the 'flag' by it is always enabled for me as soon as I login though, it requires no action on my part to make it so:

nvlsp is a network driver (of all things), and must be part of nvidia's awful (it really was) 'game prioritised network' QoS driver in their forceware drivers. These would cause me to have many hard and random lockups when playing games - even non-network / single-player only ones - that I thought I had an acute overheating or faulty RAM problem for a while initially. Getting rid of that was the best thing I did on this system build.

crossfeed has worked for me before (limping home on bingo, one tank always goes before the other, but I managed to keep both engines until the final flop on deck - pity the FARP only had a rearm truck and not a fuel one though... even bigger pity I couldn't tell that until I had landed without any fuel...) Maybe you sustained some other dmg that hindered it, hydraulics perhaps?

I presume a darker trim in the cockpit is better for NVG, less glare from low level lighting (or external light streaking in from outside at various angles). May be one reason for changing it but just guessing. The ipod is already in... dump a powerful radio transmitter on top of mount elbrus or whichever one it is and tune in ;)

The patch to enable that in blackshark hasn't been released yet, it's in testing, due soon.

There wasn't anything being reported in the procmon logs relating to path/file issues. It got as far as reading the AboutGeneral.txt file from the Blackshark\data\text directory, the next file it wanted to read in the main app thread was AboutCredits.txt, but it didn't even attempt to open this file/location before it bombed (so whether the file exists or not is actually moot, the crash happened before). Around the same time although this could be coincidental, it was about to play the beginning chunks of the Sounds\EditorMusic\Babylon.ogg file, but never got to read more than 128k into the file before the app crashed - unknown from the procmon log if it was the sound itself contributing to the crash, or the game simply didn't last long enough to need to stream in any more than this because it crashed so fast. Either way, the file was there, and buffer reads were successful from it, no premature end of file or the like. Everything else in the file was pretty clean, and could (relatively speaking) be mapped across to my own procmon log even though there are some differences in hardware and codecs/libraries, nothing that stood out as being undoubtedly wrong. So unless the testers/moderators here have access to an internal list of error codes that the games are mapping to (unlikely for an app to remap core codes), then I think it more likely this is a genuine C0000090 error instead which is a floating point exception (like trying to do things like divide a number by NaN (the special indicator in FP math for 'not a number') or some other incompatible conversion/calculation). (EtherealN - may I ask what made you think this was search/path related, just to be sure?) ERROR_CODE: (NTSTATUS) 0xc0000090 - {EXCEPTION} Floating-point invalid operation. Non-games can hit this error too, like SQL Server: http://support.microsoft.com/kb/318053 Here it blew up in a 'float to long' conversion function (aka ftol()), which could certainly happen if you tried to convert a 'NaN' to a long integer value. This isn't always called explicitly, the compiler can sneak them in whenever a typecast is done to a long/int from a (potentially) floating point value. And other games/apps have had this exception too, but normally the cause has not been clear, however the general consensus is that this is an error code thrown back by the FPU because it couldn't comply with what it was asked to do. Unfortunately little in the way of clues beyond this; typically these problems would be reviewed by the developers themselves using crashdump / minidump analysis and the source code they're in possession of. Else I would have to hope that the BS/FC2 compatibility patch contains an updated launcher for BS that uses the codeline from FC2. ... Only closing comments I have, are that functions like ftol() reside in the msvcr71.dll within the bin\stable directory, and at the point of the crash, this was the first library queried by the appcrash dialog that pops up. In case you're experiencing a form of "dll hell", there are two solutions you may try: 1. Putting a new (empty) file named launcher.exe.local in your bin\stable directory or 2. Rename the msvc*.dll files in the bin\stable directory The first option tries to advise the game to use only local DLLs if it finds multiple, the latter is forcing it to try and look elsewhere for them (in case there are conflicts with the Windows SDK / DDK stuff that your machine seems it may contain, even if these are just leftovers from some wonky driver development and installation). Both options are easily reversible (delete the .local file, rename the .dlls to their original names). This isn't entirely clutching at straws, just an outside chance at trying to resolve any incompatibilities you may have with these files since there are many versions of each and "dll hell" is a long term compatibility problem.

I'll aim to check your procman log tomorrow; seems it required a 64-bit OS to read the file generated by the same, and I just don't have one near me today, sorry.

In case Panzertard's review of your SET / path results comes up blank, please could you try the following: 1. Download and run Procmon ( http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx ) 2. Once it's launched press Ctrl+L (or go to menu Filter > Filter ...) and select the following: Process Name is launcher.exe include 3. Click Add (important else it doesn't get used) and then OK. 4. The main window for procman should now be blank, this is OK. 5. Run the single-player Blackshark from its normal icon, wait for it to crash. There should be a lot more output in the procman window now all related to launcher.exe (probably thousands of lines, hundreds at least, depending on how far it gets before crashing of course) 6. In Procman do File > Save and pick these options: Events to save: Events displayed using current filter Format: Native Process Monitor Format (PML) 7. Zip up this .pml file you created and upload it here. This should help to identify all of the different file and registry accesses that the launcher.exe is trying to do, and at least be comparable against the same output on my machine (or your wife's) so that you can see where it stumbles to see the difference and what it's trying to do next.

You need to make sure all the file editing you do is with a program that is also run 'as administrator' then, otherwise data virtualization is a technique that when you try to read or write a file from a protected location (such as Program Files) it sneakily does it somewhere else (your own virtualstore, a special per-user directory). But then you run the game 'as administrator' and it reads/writes from the original and true location on the disk instead so ignores your editing attempts. Note this does only apply to protected locations like your OS's designated Program Files folder. The thing to remember is that being the administrator only grants you one additional thing - the ability to override stuff that normal users aren't allowed to override - and it's not an automatic or permanent 'full rights' mode (like previous versions of Windows typically gave you). In most cases the 'full rights' overrides are only temporary, such as for the duration of that app's run time, and then gone again, as a form of 'you can do this, but are you sure you really want to do this' protection from both yourself as well as from malware. Anyway, just to be sure, right-click your desired editor's icon and Run as Administrator, then open the file you were making changes to, and see if they are still changed like you expected. If they're not, data virtualization had been kicking in, if they are, Slayer's suggestion about the 'use these options for all missions' may well be the cause.

I've re-read this thread from page 1, and just so we don't lose focus of where the actual problem is occurring, you're still getting the c0000090 code in the app crash output, is that correct? And this is happening more or less within the first few seconds of launching the single player icon (so the loading screen is the first and only screen you see before it crashes, you never see the main menu)?

lua's involved with any activities in the code to which it is linked, whether that's graphics or input or output. All of the UI's setup in terms of where buttons are, what the text of those buttons are, what they're connected to (their behaviours) for the GUI are all defined in lua script, and has calls from the script direct through to graphics drawing APIs, so it's quite tightly integrated. This is true for both the game and for the UI, except of course being the difference that the luagui library for the menus/forms interfaces to OpenGL whereas the lua responsible for directing the drawing of the various panels and instrument structures in game is directx. I have to say that whilst I need to be doing things I shouldn't be doing to make luagui crash on my system, there are some things that just aren't quite right about it too (such as severely degraded performance without justification). I've just not seen it as severe as Andi is getting it here.

That output I gave as last example, is just estimated fuel of the current (active) route that is plotted into the Abris' as waypoints, so it doesn't reveal anything you can't see anyway, and it's still local instrumentation so not like a 'super radar' or anything. I just use that as an example of a function you call that instead of just bringing back a simple value, can give you a whole structure of information. Some functions are like this, whilst some just give you the single values. I was just happy it worked :D Some of these do not work unless your camera is inside the cockpit still, because (I presume) their devices do not have the update_arguments() function available. If you try to call the functions at this time, your error log will quickly fill up with lots of 'cannot access nil value "blah"'. I don't know yet how in LUA I can tell whether the camera is inside the cockpit or outside, except to try calling one of these functions that don't work outside. I would like to find a better way for that.

You're correct I believe.

I also had this by the way as part of the same test code I was using. It's referring a modified version of the Serialization.lua script that just wrote its recursive output to a string instead of to the io library (since I'm too novice to know how to redirect the io to a string buffer in LUA), so that I could then call many of the functions dynamically and get some interesting output back again:- ... local d = GetDevice(devID); local result = d[funcname](d); if type(result) == "table" then socket.try(c:send(serializestr(funcname, result).."\n")) else socket.try(c:send(result.."\n")); end ... DevID is number of the device, and funcname is a string for the function I want to call. Results of me calling get_active_route on Abris for Instant Action yielded this lovely response :D

You can parse out (all?) the available functions for most devices by doing this, so you can see if one of a given name exists before you try to call it: ... local d = GetDevice(devID); local funcscan = getmetatable(d).__index; for k,v in pairs(funcscan) do socket.try(c:send(k.."="..type(v).."\n")); end ... (Here I was sending the results back to a program of all the available function names, before deciding whether to call any of them). Here for example is the response from the Abris (device 9): 1(get_active_route=function) 1(get_current_route_segment_info=function) 1(get_mode=function) 1(print_to_console=function) 1(get_edited_route=function) 1(performClickableAction=function) 1(get_sns_mode=function) 1(get_current_route=function) 1(replace_last_console_line=function) 1(SetCommand=function) Note the format used by the program receiving the output is as follows, but LUA is only actually sending the data that is between the brackets: socketnum(keyname=datatypevalue) Here is mainpanel (device 0): 1(get_argument_value=function) 1(performClickableAction=function) 1(update_arguments=function) 1(set_argument_value=function) 1(SetCommand=function) So you can 'safely' check for the presence of this before calling it, and by interrogating LUA state live (which is good because what you're looking up are bindings to C/C++ functions in LUA custom structs, which aren't exposed well otherwise in any LUA source or table navigation - as far as I could tell anyway). This 'metatable' that's being queried is a kind of lookup populated by ED, and may not list internal or blocked functions at their choosing, so that's why I question whether it will actually list all functions or not.. in reality, it lists those which we may be allowed to make use of. I did do this in a loop one time, scanning devices 0 through 255. Note that the device ID appears to be an unsigned byte, so if you try to get device 256 it wraps around to 0 and you get mainpanel again as the response. So it can be quite quick to zip through all the available devices today in a loop up to this value and find out which ones have active functions that can be called, and whether they include a specific one you're interested in.

If you're editing/viewing the file as your regular Windows logon user, but running the game as Administrator, that can cause you a problem. The same is true in reverse. So whenever editing those files, do it at the same privilege level that you run the game at. This is if your Program Files is _the_ Program Files that Windows loves to protect, if it's just a folder with the same name you created on another drive, then as you say, you wouldn't have to deal with any of Windows' oddness in that situation. Personally I install the whole shebang (modman, LO:FC, blackshark, etc.) under _the_ Program Files without any issues at all, but if you're not too familiar with when exactly app registry and data virtualization takes place and on what files, it could be a pain.

We're probably just victims of the nuances of floating point math in (x86 architecture) computers causing some crazy rounding at times, it isn't entirely accurate so there are some apparent approximations occurring due to precision loss at varying degrees. Unless this is an accurate model of some craziness from the PVI-800 itself :D

True for the most part, though one manouver performed in those videos which makes it seem like it's the rudder action involved is this one. When doing the 'hammerhead' type kick-turns (going vertical to a near-stall, then punting the nose around to point to the ground so you drop into a natural dive) you effectively change the blade pitch from an aggressive deceleration in one direction, to an aggressive acceleration in the opposite direction. It's still rotor pitch that instigates the action and sets the move up, but the turning only begins and seems to take place when using the rudder, so it's deceptive.

You can put the Desired Heading/Desired Track** to its middle position (it's a 3 way) so that instead of being tugged towards a waypoint, it'll instead try and stabilise around the point you let go of the trim (all with the Heading Hold AP enabled of course). It shouldn't make your flying any LESS stable. ** This is the switch furthest right on the AP switches panel, directly below the FD button.

There are some values we found the PVI-800 would oddly reject; for example doing an Instant Action and trying to re-key in the coordinates for WPT1 would result it in not accepting the last digit either and would appear to round it down. Check out this thread too:- http://forums.eagle.ru/showthread.php?t=47579&page=4

I'm not too familiar with ATI drivers (having had some bad experiences in the past, I've kept my distance even though more recent hardware may be completely different). So as I was suggesting to a friend in a gaming group that his own problems might be solved by using a different version of the ATI drivers, another friend in the group (who is quite knowledgeable on business PC hardware) had this to say. I thought it might be worth sharing for your situation of ATI + Laptop too: Isn't something I can comment on having tried myself of course, but I know the level of skill/experience of the person making this advice so I would definitely consider it.

Hmm, might just get that if only so I can run a server on a separate box. Thanks.

That's cool, I'm going to have go out and find that boat now, well done :) My landings are a bit haphazard so it could be just the practice and confines that I need to break my bad habits :D

So long as you trim to stop the craft from wanting to bolt backwards to your last hover point after moving, I don't bother to switch off back to nav view, you should be able to get used to it after a few tries. It all works just as before, you just don't have it displayed on the hud. You probably already have collective and trim on your flightstick/hotas, but the other item that helps me when using hover-hold (along with it's alt-hold AP channel) is to put the Collective Brake on a hotas button, if you don't have it already. So it's like I go from my original hover-hold position, find I'm not quite in range for some of the back targets, and then:- - move the craft 1-2km forward to where I want it to go, watching collective to maintain approx. the same altitude - once at new location, before letting go, stabilise my position quickly and then trim - check collective and ascent/descent rate to get myself still - now hit the collective brake to tell the auto-hover that this is now my preferred altitude since it probably shifted a bit Then I'm back to business with targetting and shooting, without having to go into Nav mode or worry too much that my current hover settings are going to drift out too significantly. Works for me anyway, I will sometimes do exactly that if I've actually gone in too close and just need to back out to stand-off range, but am otherwise happy with my current parameters and setup.