Pete Dowson

I added such an option in any case, because it was easy to do and may possibly come in useful. Download and install FSUIPC4839a.zip. In the [General] section of FSUIPC4 you would need to have InitDelay=30 InitDelayDevicesToo=Yes or whatever delay might work. The device initialisation is delayed to the same point as the Simconnect initialisation. I don't really hold out a lot of hope. Checking other things such as your memory sticks, as suggested by alaxus, is probably still your better hope. Regards Pete

No, it is only doing that because the previous "trust" acknowledgement didn't get recorded in the FSX.CFG file -- FSX only saves an updated CFG file when it terminates normally. All your results certainly show some bad interaction between the headset and FSX, with FSUIPC's presence only assisting by altering the timing of events. With that dummy entry in the [sounds] section of the INI, FSUIPC is no longer scanning Direct Sound devices, so it isn't this. The fact that your CTDs are (presumably) all in DINPUT.DLL does mean there's some conflict between device drivers at quite a low level. Maybe there's an IRQ (interrupt) assignment conflict beng made by the BIOS. In the old days, of simpler Windows systems, one could adjust these quite easily, but i think it is all automatic now and I wouldn't advise messing. The only other thing I can think of doing for you is to move the initialisation of DirectInput devices to a later time during the startup of FSUIPC, to see if avoiding talking to direct Input at perhaps the same time as FSX is doing so manages to avoid the clash which is taking place. If it isn't this action, however, it will be a waste of both your time and mine, so please do this next test first: Remove the FSUIPC4.KEY file from the Modules folder -- or simply rename it. This will make your FSUIPC4 installation appear unregistered. As a consequence it will have nothing to do with any Direct Input device. If that succeeds then I'll try to find a way to add an option to delay Direct Input device activation. Regards Pete

No. It can't "fix" any at all, really, not in the sense that it makes the FS code do what it should be doing. The current FSUIPC4 version patches G3D.DLL to work around a problem which causes a very specific, but apparently quite common, FSX and P3D crash. The code it patches happens to be convenient enough to patch as it is merely a routine which does some tests and returns either TRUE or FALSE. The patch merely checks that the address it is using is valid (which in the case of a crash it is not), and if not it forces the FALSE exit and avoids the access protection crash (error code C0000005).. Luckily this action seems to have no adverse consequences. I did look at another place in G3D.DLL which was indicated in some crashes, but in that case it wasn't possible to take a work-around course of action. Mostly other crashes I've seen don't have much in common in any case. Regards Pete

Yes, that's true. FSUIPC isn't aware of the phase of flight and doesn't make changes "on the fly" -- only the rudder vs steering tiller adjustments below a transition speed on the ground, if you have both assigned (which you don't). Pete

Thanks for this. Ingenious. The things folks can do with Lua never cease to amaze me. BTW the link on your page for SayStatic sems to be broken. I found it at http://code.google.com/p/raptor-chess-interface/downloads/detail?name=SayStatic.exe&can=2&q= Regards Pete

It certainly sounds like something else was sending rudder values -- either axis rudder set or rudder set controls. I just checked. Even in 2direct to calibration" mode the calibration tabs would pick up any controls for their axis. Those would mix and cnflict with those arriving fromthe direct axis assignmet. The log would show what controls they were, but unfortunately can't show where they originate from. The inputs must have been fast and furious to prevent the rescan or clear working. This is why there's an "ignore axis" button, so that other axes can be handled even with a rogue one monopolising everything. So you did mean the max value? Wow! As I say, the only code which changes that is one needing user action -- either reload all settings, in which case it is reset from the INI file, or pressing the SET button above which copies in the current axis value providing it is not lower than any of the values to the left. For that field to be changing on its own something external to FSUIPC must be really doing something weird! Okay. There's really nothing wrong at all that I can see in the INI. Regards Pete

I am pleased you are able to make such good use of FSUIPC. You seem to be well in advance of anything i know! ;-) Regards Pete

Please update to a supported version. The current full release is 4.827, and we are up to 4.839 with interim updates. I know the Schiratti "dowson" page probably labels it older, bt it links to the 4.827 installer just the same, or else just go to the Download Links subforum here, where latest versions are always available. Which numbers on the calibration page are you talking about "IN" or "OUT"? If IN they will be identical to the axis tab readouts UNLESS one of these things is true: 1. There are multiple assignments to the item being calibrated - i.e. rudder in this case, 2. The Axes assignments themselfs have multiplers or other scaling actions defined in the INI file 3. The rudder is not assigned "direct to calibration" and something else is intercepting the FS rudder controls before FSUIPC sees them. The rescan will simply pick up whatever axis is changing, which may or may not be the same one. Without knowing more I couldn't answer the "clear" question. If the axis was jittering al the time you might never get in. The "Max" field? That's set from the parameters in the INI file, once when you enter the tab (or again if you click "reload"), and then only changed if you press the "Set" button just above. There's absolutely no code to change it on its own, it has to be by user action. It sounds like something is actually infiltrating the Windows dialogue in order to do such a thing. It can be done by hooking and subclassing standard controls, but it seems to be a weird thing for somenoe to do -- unless it's virus code. Maybe you don't mean the "Max" field? No. It sounds very puzzling. I would need a lot more information anyway -- like how things are assigned, what the calibrations look like 9eg your INI file would help). Also you could find out if it's down to spurious Windows controls flying about by using FSUIPC's logging -- axis logging in this case, though maybe the normal events too, because they can affect axes. But please update FSUIPC4 first. Regards Pete

Weird, then, because FSUIPC has nothing to do with sound devices, unless you are using a Lua plug-in which uses the sound library. However, it does build a list of sound devices in order to provide the sound configuration list in the INI file. For example here is mine: [sounds] Device1=Primary Sound Driver Device2=Speakers (Sound Blaster X-Fi Xtreme Audio) Device3=Speakers (10- USB audio CODEC) Device4=Realtek Digital Output(Optical) (Realtek High Definition Audio) Device5=Digital Audio (S/PDIF) (Sound Blaster X-Fi Xtreme Audio) Device6=Realtek Digital Output (Realtek High Definition Audio) Path=E:\FSX\Sound\ In order to make this list, FSUIPC enumerates DirectSound devices. Maybe something in this loop is a problem . But if there's a list already in the INI, FSUIPC does nothing. In fact it only takes one entry in the list to stop it ennumerating them on the next load (you'd need to delete the section to force it to re-scan). Try this, to get more information: add these lines to the [General] section of the INI file: Debug=Please LogExtras=x20 Let me see the resulting log file please. If there is no list of devices in the [sounds] section, or no [sounds] section, try just adding a dummy, like: [sounds] Device1=Primary Sound Driver to stop it scanning. If none of this bears fruit I'm afraid it's just down to some timing interaction in your drivers, when FS is opening the sound device, which is exacerbated by the differences having FSUIPC installed makes. The only thing I can think of then is to uninstall ad reinstall sound drivers, or those specific to the headset (if any). Regards Pete

It abbreviates to the size of the offset, which is 14 characters plus zero terminator. If only tail numbers are selected you will only get an abbreviation if the tail number is longer than 14 characters, which seems incredibly unlikely. And then it is the last 14 characters in any case. I don't know where you are getting "3" from. Perhaps you need to clarify what it is you mean. You should also please state the version of FS (FS98, 2000, 2002, 2004, FSX, ESP, P3D?) and the version number of FSUIPC. Regards Pete

Can you please tell me what Simulator you are referring to, and which document? In the FSX offsets list in the SDK it states that 3BDD controls the electrical failure. In fact it is assigned to the Simconnect variable called "PARTIAL PANEL ELECTRICAL". Offset 3BDB is "PARTIAL PANEL AVIONICS" In FS9 and before, yes, 3BDD is listed as "? (unknown)", so i assume you are using FS9 or before? If so, thanks for the info, I will update the older list when you confirm. Regards Pete

Okay, good. Making release in Download Links now. Best Regards Pete

Hmm. I'll try to do a test here to see what is going on, but I only have default aircraft -- not sure which has a value I can toggle, but there should be one. [LATER] Yes, default 738, MFD Centred and scale display. I've repro'd the problem so it'l be fixed today. Just looking at the code I couldn't see how it could happen, but further experiments showed that if a non-zero parameter is provided, then the toggle works. ANY non-zero. It was yet another stupid typo: an "=" instead of an "==", which changed the Toggle into a Set if the parameter was omitted or 0. Duh! That's two stupid typos in one line of code! I'm getting senile I'm afraid. Fixed in 4839test3, same ID different date again. I think this is it now. I'll probably release it and the FSUIPC3 version tonight or tomorrow morning. FSUIPC4839 test3.zip Thanks, Pete

Yes, something like that. It's evidently a complex area. Okay, good. It's nice to at least have a useful resolution f not a complete answer.. Regards Pete

Sorry I don't know what dependencies add-ons have. Most of FSUIPC's development has been in the area of user facilities. Maybe you aren't interested as a user of FSUIPC, but if you stay with such an old version I can't help you with anything. You'd need to update to a supported version first. Pete

If you have not yet installed it, do so. The installation guide tells you that the documentation is in the FSUIPC Documents folder, inside your FSX Modules folder. There you will find the User Guide. The second chapter, as shown in the Contents list, is "Paying for FSUIPC4 Registration". That will tell you all you need to know about this. Or just go to SimMarket and pay on the FSUIPC4 product page. Regards Pete

Good, well done. It forces focus back to FS in case it was elsewhere, that's all. Keystrokes go to the program with current keyboard focus. Regards Pete

Sounds like your throttle axis is misbehaving. I've never known filtering to fix anything except some jitter on systems with poor power supplies. In fact it was added to help out a chap with computers in some out of the way place in south east Asia. In your case, better than using the filter would be to calibrate a slightly wider idle zone, so that the thrttle stays properly in the idle position. Regards Pete

I already told you! Because it will make anything programmed to use the correct documented value go wrong! In other words it reintroduces an old bug in FSUIPC which was fixed! If it doesn't affect you, why are you so worried? I don't like bugs. I always fix them, but unfortunatley some add-on makers, such as presumably the ones making the two aircraft you mention, do not! I know at least one which does -- the VRS Superbug had the same error and was fixed. I think it actually now works either way. Maybe there updates which fix the bug in the add-on aircraft you are using. I don't know. Pete

On this other matter: Could you please find the FSUIPC4 install log file (it'll be in the Prepar3D modules folder). I'd like to check what happened. The only way it would be asking for FSX.EXE was if you still have registry enties saying FSX is installed, but the folders containing FSX have been moved or deleted. Might you have had FSX installed once and uninstalled it, or, worse, simply deleted it? Either way, I think you certainly have FSX bits left in your registry which should be removed. With the log I can probably help with this. Regards Pete

Further to my last message, I'm also wondering if it might be related to the actual Profile settings themselves. Maybe the axis assignments aren't occurring for the other aircraft, and one or other of those axes is hanging in the joystick driver or similar? For purposes of elimination, please see if you can try two things (obviously save your INI first): 1. Create a plain [axes] section with the same contents as your current A320 axes section, so it applies to all aircraft. See if this has any bad affects on other aircraft loadings, and 2. Remove parts of the content of the A320 axes section at a time to see if one or more entries in it are causing the problem. I'll try similar things here, but I can only use default aircraft. Regards Pete

I don't quite understand. You say FS hangs on the aircraft choice, yet FSUIPC seems to be running okay still and, as seen above, terminates normally. What is displayed when it "hangs" and how are you terminating it? If FSUIPC were doing the hanging it would not be able to log the closing of FS. Very puzzling. I'm wondering if it's some graphics or other problem, not really directly related, but affected by the difference in timing. Could you try a test with a Profile-specific default aircraft please? I'll need to be able to try similar things here, and I cannot do so with add-ons I don't have. Please also show me the [JoyNames] and Calibration sections from the INI. Regards Pete

This is a little bug which was discovered, reported and fixed a few weeks ago. Please go to the Download Links subforum and download the latest version of FSUIPC3 or FSUIPC4, whichever it is you are using. (It is always best to do this before asking about a problem, just in case. There is a lst of changes included with each update). Of course! You can read any FSUIPC offset in Lua. You can set an event for a change in the aircraft name offset, and so receive the name in a string automatically in the function it calls, or an event.sim for "AIRCRAFTCHANGE" and read the aircraft name string in the function. All FSUIPC offsets are listed in the offset lists in the FSUIPC SDK. Just search on "name" or "aircraft". I don't remember all the offsets myself and would need to do this in any case, but I think it's a string at offset 0x3D00. Regards Pete

Fixed. Sorry to have wasted your time -- a silly typo, as usual. That's the trouble with thinking up "easy fixes", they are so easy that it makes one careless. Complex changes take a lot more care and are less prone to stupid mistakes. Please check this one: FSUIPC4839 test2.zip Only the date has changed on the ID. I didn't yet want to move on to 4.84. Regards Pete

Ugh! Doesn't this destroy any sense of realism? >> I am wondering if there is any way to automate this task via an FSUIPC control, which could be activated on the Clients from the Server via transmission of a key command (using the program Input Director). Or at least a way of opening the FSX Options/Settings/Load menu on each of the Client computers via an FSUIPC control. << I don't know of any way of loading that stuff except via the Menus. You can manipulate menus using Lua plug-ins, and you can trigger a Lua plug-in to do things by any number of ways. See the Lua plug-ins examples provided (in your FSUIPC documents folder) -- the Fuel737 and Payload737 examples manipulate the fuel and payload menu dialogues respectively, so should be a good start. The main problem, if you want it to happen automatically on 5 separate FS PCs all together is how each determines now is the time to do a change to xxx. Obviously the FSUIPC's in each are not linked at all. Can WidevieW signal anything? Othwerwise I can only think that you trigger on something happening in the aircraft or the scenery -- Latitude/longitude? Or do you have any buttons connewcted to al 5 which can be used? Regards Pete