Pete Dowson

Thanks. As well as AI traffic logging you have Event logging enbled. Please turn it off for now, if we loook at any more logs. It produces all these sorts of lines in the Log: Well, it is a shame we don't have the TrafficLook display available to compare the Logged aircraft with those being shown. I'm sure you could do this yourself quite easily. With that logging option I gave you there are entries like all these: The ones I've emboldened were in flight (though the last two seem to be falling more than flying! ;-) ), so should have been shown by TrafficLook .... but I am a bit concerned now why the State is being logged as "unknown" when it is == 1. I think that should be "sleeping". I'll check -- it may be related to whether the aircraft is shown (sleeping aircraft can't be airborne). The first airborne one is actually state 12, logged as "init" too. All those "On Ground" above has state "Init" (== 0), so this tends to emphasise my previous point. I will certainly have a look at this -- later today. Unfortunately, as you will see from the above data, whilst VoxATC is always supplying the tail number, it is NEVER supplying a Flight Number (hence the Flight="" parts of those log entries). If FSX is not supplied with this then obviously FSUIPC4 cannot see it. You'll need to talk to VoxATC about this. By all means refer them to this thread and show them the logs. Meanwhile I will double-check my code for the State anomalies shown above. Regards, Pete

To register FSUIPC4, yes. Isn't that what the documentation says? Didn't I say that in this thread? Sorry if I wasn't clear. Vista seems to have several different levels of "Administrator". Just because you are an Administrator doesn't mean you are an Administrator in all the Administrator senses. Daft, isn't it? Regards Pete

That sounds pretty good, and easily adequate for FSX provided you adjust the sliders to suit. I am developing and test on a older Pentium 3.2Gb with only 1Gb RAM, but I also have FSX installed on a n Intel 2.0Gb Core2 Notebook, an AMD FX-60, an AMD FX-53 and an Intel X6800 (my main flying one). This with a variety of video cards ranging from nVidia 7950 at the top end down to the 6800 (I think that's my oldest, no sure offhand). Hmm. Something wrong there. I get 25 fps on my Notebook at country airfields with plenty of rolling hills and even autogen set for lots of trees. quote]But when you get to any airport with buildings, vehicles, etc. it shall be reduced to the range of 2-3FPS and below! There's definitely something wrong then. I have heard of a few others with such problems, but I really don't know what causes them. Certainly, out-of-the-box, with no addons and no special tweaking, FSX should be flyable. It tries to assess the PC it is installed on and sets the assorted sliders and so forth accordingly. I don't think it always does a good job -- that, I understand, is being addressed in the soon-to-be-released update (SP1). The main effects which seem to me to be really costly in terms of performance are (in order) Autogen, AI, Shadows, and Bloom. Start with all of those off competely, then adjust the other sliders to get best performance for reasonably looks. Then re-introduce the autogen and AI a little at a time. See what settings you can get and remain with frame rates in double figures. The SP1 update is getting so near now that it might just be better to wait for that before doing too much experimentation, as it is bound to change some of thoese things, hopefully all for the better. Really? I've never really used VC, prefering the 2D panels in any case on those PCs on which I don't use Project Magenta. Your nVidia card should be able to support two displays. Select the 2D panel, undock it and drag it over to the smaller display. Makes no difference unless you are running other processes at the time time on the FSX PC which you can move across to the other PC. Then it may improve things (especially on single processor systems, less so on Core 2). But if your frame rates are truly as you say, and you have the various settings turned down (certainly the critical ones like autogen and AI), then I think there must be something else that isn't right on your machine. Maybe some conflicts with installed programs or background processes, or the video driver not providing enough acceleration. Regards Pete

Thanks for confirming. But did you allow FSX to install itself in the default folder, in "Program Files"? I think there are dfferences when you seelct somewhere less protected for installation. I'm wondering why some folks have more difficulty that others. Regards Pete

Well, something is sending FS additional signals for the same axes. Please enable Axis logging in FSUIPC's Logging page and reproduce the problem. Zip up and send both the Log file and your FSUIPC INI file. petedowson@btconnect.com. Regards Pete

Sounds exactly like you haven't really disabled them in FS, or you have other controls assigned in FS for the same axes. Try disabling the joystick instead of de-assigning them individually, just to prove this. There's an FS menu item for this. Why are you assigning them in FSUIPC in any case? You can calibrate FS assignments in FSUIPC. The idea of axis assignments in FSUIPC is for more flexibility and switching axes according to aircraft model, but if you don't need to do this there's little point. Regards Pete

From a message posted privately: Maybe some of this is only with 64-bit? Because I've tried both Vista Home Premium 32bit and Vista Ultimate 32bit and the only problem at all is that to register you have to right-click on the FSX incon and select "Run as Administrator!. There was a problem with earlier versions of FSUIPC4 because it wanted to write the FSUIPC4.KEY file to the FSX folder, and if you allow FSX to select the default install path it goes into "Program Files", where no one is allowed to write with default permissions! (Duh!). The current version of FSUIPC4 (4.09) writes to the Documents\Flight Simulator X Files folder instead (though there is a little bug where it names them without the '4', fixed in the next version with automatic correction to existing names). Regards Pete

Sorry, you've lost me. Are you saying it is now okay? What did you do? Are you talking about the SimConnect side-by-side folder with the long weird name? As far as I knew you have to delete the whole folder to get FSX to repair the SimConnect installation. I've no idea why. I don't really understand that aspect of Windows -- Side-by-side DLLs (where you can have multiple versions and Windows matches them up). Regards Pete

But my point is that if you let it run longer there might be more information in the log. Assuming that it really doesn't get any further, we'll need a Simconnect log to see what is going on. Please see the FSX Help announcement to see how to do that. The file could get pretty big, so it would need Zipping. You can send it to me at petedowson@btconnect.com. Regards Pete

The fact that FSUIPC is being loaded and that the Open succeeded is good, but 38 seconds is surely not enough time for it to have loaded into normal flight mode? It takes a lot longer than that here! Assuming that it really doesn't get any further, we'll need a Simconnect log to see what is going on. Please see the FSX Help announcement to see how to do that. The file could get pretty big, so it would need Zipping. You can send it to me at petedowson@btconnect.com. Regards Pete

TrackIR doesn't need FSUIPC, but it certainly needs SimConnect working correctly. Well, the first, as I mentioned, is to check whether FSUIPC is being loaded or not. Did you see if there was a log? If not then SimConnect is not installed correctly and nothing is being loaded. If there is, what does it say? As I said in my first reply. Sorry, but there's nothing else I know. Obviously if nothing using SimConnect is working, then nothing using SimConnect works, including FSUIPC. I cannot fix FSX problems, only FSUIPC ones. But let's try to get more informationfirst the FSUIPC log, then, maybe, a SimConnect log -- to see why it may think there's a problem. Regards Pete

I often run FSX with no Internet connection. It doesn't need one -- and it doesn't need continual activation. Surely you had activated it before now? Folks without internet connections can and do use FSX, and activate it by 'phone just as with Windows and other Microsoft products. Unless you have Beta or Demo versions of FSX it cannot be to do with versions of FSUIPC, and certainly never anything to do with registration. There are only two things which can stop the Add-Ons menu appearing: either SimConnect isn't actually loading FSUIPC (or any other add-ons for that matter), or it is loading them but then they are being blocked from talking to it. These two causes can be distinguished quite easily. If FSUIPC is being loaded it WILL always produce a Log file, no matter how short. So you only need check the date/time on the Log file. The log is either in the FSX Modules folder or, for Vista, it may be in the Documents\Flight simulator X Files folder. Naturally if it isn't being loaded it cannot run therefor no log file is produced. I'm afraid I don't know anything at all about the MP side of things, but I'm pretty sure you don't need an Internet connection, as you can use multiple PCs in a local Network for MP in shared cockpit mode. What does "FSX registers FSUIPC at startup" mean? And how is there any mentyion of FSUIPC in the cfg file? Do you mean where it asks whether to run FSUIPC or not? Best read the "Important FSUIPC4 Installation Notes" Announcement above so you understand this part. If it looks like it is being loaded, then look in the Log. If it cannot Open SimConnect then it is certainly being blocked by firewall or other security software activity, despite you saying you've switched this off. With some programs it's more a matter of uninstalling them completely in any case. I use both Microsoft Windows XP firewall and Norton's firewalls without any problem though. Maybe you should instead find a way of fixing the original MP problem. It sounds more tractable. Try asking about all this on the FS2004 Forum, but it may be a case for MS tech support as you seem to have some weird stuff going on from the off. Regards Pete

Just re-register, following the instructions in the user documentation. You will have to run FSX with the "Run as Administrator" option, as Vista won't let programs update the registry otherwise, even if you ARE the administrator. The documentation does tell you this. Regards Pete

No. But I didn't think TCAS displays showed such information in any case, I though they just showed blobs with some numerical info. Or are you using a different sort of display, not TCAS? Please use TrafficLook and let me know what that shows. I suspect that I may suppress the flight number for 'sleeping' aircraft because otherwise all the AI show up as flight 1142 (or whatever the default is) until assigned to a flight (i.e. file their plan). I may be able to change that but I would need to know how to distinguish between real AI and stuff injected by programs like VoxATC. [LATER] I checked my code. I only ignore the flight numbers for "sleeping" aircraft. The action I took to show VoxATC and MP injected aircraft was based on seeing them as "initialising" -- if they are above ground I change that to "enroute". So, EITHER the aircraft from VoxATC are coming across as "sleeping", OR they don't have flight numbers supplied in the AI data to FSX. In the former case I can fix it, in the latter case I can't -- that would have to be fixed in VoxATC. The TrafficLook display should show if it is the "sleeping" problem, but you could supply even more information by adding these lines to the FSUIPC4.INI file [General] section before running FSX: Debug=Please LogExtras=512 After observing the problem (and checking with TrafficLook for me), close FS, ZIP up the FSUIPC4.LOG file and send it to me at petedowson@btconnect.com. Regards Pete Regards Pete

It isn't so much "is it implemented in FSUIPC?", but "is it implemented in FS?". Can you tell me what the "VAC instrument" is? It is probably masquerading under a fuller name? For instance, "VAC" could stand for "Volts AC", or "Vacuum". If it is "vacuum" then you probably mean "gyro suction", which may be measured in inches of mercury -- but there's ever only one of those, not one per engine -- it is used to drive the gyro instruments (AI, Compass). Or maybe you might even mean Manifold Pressure, though I've never heard that called VAC. You tell me what you are looking for, or search the documentation using the appropriate words. Okay? Regards Pete

Okay. 3.743 is available above now. But, after verifying that it does indeed fix your problem, I would still advise rationalising some of the settings. In fact, as far as I can see, you can use half the number of virtual buttons you are using now. In other words, instead of: use this: 11=W0366=0 P0,1,Cx05003340,x7F 12=D31E4<700000 R64,0,Cx74003478,xFFFFFE3E 13=D31E4<695000 R64,0,Cx09003340,x01 14=D31E4<500000 R64,1,C65615,0 15=D31E4<425000 R64,1,Cx09003340,x02 16=D31E4<420000 R64,2,C65706,5000 17=D31E4<415000 R64,2,Cx09003340,x04 18=D31E4<410000 R64,3,Cx74003478,x000001C2 19=D31E4<405000 R64,3,Cx09003340,x08 20=D31E4<360000 R64,4,Cx74003478,x0000028A 21=D31E4<350000 R64,4,Cx09003340,x10 22=D31E4<341000 R64,5,Cx74003478,x000002EE 23=D31E4<330000 R64,5,Cx09003341,x20 24=D31E4<310000 R64,6,Cx74003478,x000000AA 25=W0366=1 R64,6,Cx09003341,x40 26=W0366=1 R64,13,C65706,6000 27=P0,0,Cx09003340,x7F Note I inserted 25 because I see you don't switch button 12 (my 6) off until you press your own 0,0. Is that right? Is there any reason why you shouldn't switch it off when 0366 gets set? Don't forget FSUIPC will keep applying the effect for another 12 or 14 seconds in any case. Incidentally, the 3478 facilities are not available in FSXyet. I am hopeful of more FSX facilities in the future. Regards Pete

Another thought. In these lines: you are causing FSUIPC to repeatedly clear alternate bits forever, even though they are cleared. Not only that, but because the trigger is itself a virtual button, the scan rate is probably very high -- I'm not sure what, I'd have to check. This may be causing a problem, I don't know yet, I'd have to check. But even if this was not the problem, it is still very inefficient. I don't understand why you are never turning off buttons 1, 3, 5, 7, 9, 11 -- or at least not till you've completely finished. Surely you can turn each off when it is turning off the associated action button, as it is not needed again? i.e. 13=D31E4<695000 R64,1,Cx09003340,x03 15=D31E4<425000 R64,3,Cx09003340,x0c 17=D31E4<415000 R64,5,Cx09003340,x30 19=D31E4<405000 R64,7,Cx09003340,xc0 21=D31E4<350000 R64,9,Cx09003341,x03 23=D31E4<330000 R64,11,Cx09003341,x0c This will get each of those lines only operating once, which is much tidier and probably safer. Even if this fixes it I'd still like to get to the bottom of the CTD. [LATER] Yes! That was it! I managed to reproduce it using your never-ending virtual button clearances. The poblem was recursion -- the execution of the control to change a virtual button setting causes the check for virtual buttons -- yours are set to repeat, so they do and the control is re-executed, again, and so on, forever, in a tight loop. Eventually (pretty quickly actually) the stack overflows and, bang, FS CTDs! I can and will fix it, it is easy to do, but your coding is still very inefficient nonetheless. The suggestion I make above works now, with the current versions of FSUIPC, so please just make those changes and you'll be fine. I'll fix the recursion in any case in 3.743. It probably also affects the FSX version, but I'll do that in 4.10 when the FSX update is isued by Microsoft. Thanks for pinpointing this for me! Please look out for 3.743 in the Other Downloads announcement, and use that when you can -- I'd like to make sure I've not messed anything else up by fixing this. ;-) Regards Pete

Well, please be a little more patient. We'll get to the bottom of it. It is now sounding like an FSUIPC, not an FS problem, so I seriously do need to fix it myself. First, please make sure you are using the very latest FSUIPC so I know we're doing the same thing. The latest is 3.742, available from the Other Downloads above. Then add these lines to the [General] section of the stripped down Buttons section copy of the INI: Debug=Please LogExtras=2 LogButtonsKeys=Yes Run FS, and operate whatever buttons you need to to make the crash. Please write down the sequence of button presses you need to do so I can repeat it here. The problem with a CTD of course is that the Log file may not be complete -- the last buffer won't get flushed. But it'll be a start. The step after that would involve running a separate program (Debugview) to capture the logging as it occurs in real time, thus not losing any of the data. ZIP up the Log, whatever you get, and send it to petedowson@btconnect.com. And please do not expect miracles. I fix things as fast as I can you know. Regards Pete

Yes, your key is for version 4.xx. In fact you are really expected to keep up to date because I can only support the latest version. When you installed 4.09 your existing key (which is retained in the KEY file) should still have been recognised. It will either be in the FSX Modules folder, or in the Documents\Flight Simulator X Files folder (the latter for Vista only). Due to an error, the file in the latter folder may be named FSUIPC.KEY, whilst it should be FSUIPC4.KEY. This will be automatically fixed in Version 4.10, which I will release as soon as the FSX update is available (the current FSUIPC4 will not work correctly with the update). It sounds like you deleted the KEY file. You never need to delete any FSUIPC files when installing an update. Well, it is always necessary on Vista to "Run as administator", as in fact now explained in the documentation -- please see the Installation sections. Unfortunately, being an Administrator still doesn't give you enough privileges. You have to "run as administrator" as well. Regards Pete

No idea at all, sorry. It could be an error in either the Aircraft.CFG file, for specifying strobes, or in the modelling of the aircraft for not having them animated. Or, alternatively, if they are not specified in the CFG file and not incorporated in the model, then there's a bug somewhere in FSX's innards or in SimConnect for reporting this incorrectly. Please send an appropriate report to tell_fs@microsoft.com. Regards Pete

OkayI cannot make FS crash by setting any sort of values in 3478, and continuing to set them, even with my aircraft parked on the ground. I really don't see anything else in your button programming which could crash FS -- the rest is all simply concerned with basic FS controls and virtual button manipulations. Something is evidently wrong somewhere, but I don't really know how to find out what, as you say it crashes to desktop with no error message. Maybe I need the whole of your otherwise working solution to try here. You'll need to supply the Buttons section and tell me exactly what is supposed to do what and which aircraft, etc. I can do the whole thing in debug mode and trap the error as soon as it happens, wherever it happens. Pete

Yes, but isn't this the pilot's job? If you are on autopilot shouldn't the A/P cope? Ah .... there's something seriously wrong then. You shouldn't be able to make FS crash. It understands decimal -- it will output in hex for those controls if you are using the Buttons dialogue in FSUIPC options, and generally for bit masks hex is more obvious. Sorry, let me get this clear. Are you saying that applying a Y component ambient wind change whilst the aircraft is on the ground causes an FS hang? All the time? This should not be soI'd need to reproduce this. This line, line 12, doesn't touch the wind of course. Incidentally, you seem to be switching on 14 buttons in Joystick 65, not 64, yet all your tests in later lines are on 64 (in 3340). You realise you aren't setting joystick 64 buttons now? Is it the action of setting a negative value to 3478 which crashes FS? Or is this the line which crashes FS? Or thisor one of the others changing the Y ambient wind? A process of elimination -- comment out each of the Y-affecting lines in turn -- might help. Won't this final Y-effect continue forever (well, for my 14 second or whatever timeout) after touchdown. You said doing this on the ground crashes FS, so isn't this the possible problem in the sequence? I'd like to know why FS crashes when changing ambient winds on the ground. It cannot do with the X and Z cojmponents as I use those to deal with Taxi wind facilities. This is the part needing investigating. No, I don't know anyway to get that information. Best to read the RA before takeoff! ;-) Regards Pete

I don't really understand you here. Can you explain please. What is "automatic trim" and how are you hoping to work it? So you really mean the sim (i.e. FS itself) crashes, or just the aircraft? There's quite a difference! The byte at 3340 is just the first of 36 offering 288 "virtual buttons". To set a button 'on' or 'pressed' you'd use Offset Byte Setbits, with a parameter with only the approrpiate bit set (1, 2, 4, 8, 16, 32, 64, or 128 in 3340 for buttons 0-7). To set a button "off" or "released" you'd similarly use Offset Byte Clrbits, with a parameter with only the approrpiate bit set (1, 2, 4, 8, 16, 32, 64, or 128 in 3340 for buttons 0-7). Or of course x01, x02, x04, x08, x10, x20, x40, x80 if you use hex. If it "makes no difference" to what you are doing whether the buttons are pressed or released, then there's really no point in using them, is there? ;-) They are actually buttons 0-7 and 0-5 respectively (you have 6 bits in the second line's parameter), and you are using Offset Dword Setbits, not Byte, though if you don't care about the other 50 buttons being changed too then I suppose it doesn't matter. Why are you setting all 14 buttons "pressed" or "on" when you press Joystick 0 button 1 and the aircraft is airborne? If you only need 14 buttons, I'm not sure why you don't just use buttons 0-13 on the first joystick number, with Offset Word ClrBits/Setbits. First, just a little suggestion: it would be easier to see what was going on here if you used the radio altitude in metres at W31E6 instead of *65536 in D31E4. All multiplying by 65536 does is shift the integer part up 16 bits (65536 being 2 to the power of 16), so it resides in the 2nd 16-bit word (31E6). The 16 bits in 31E4 are the fractions of a metre (eg 32768 there would be 0.5 metres, being 32768/65536). Second, it looks most intreresting and I expect I could spend a few pleasant hours working out exactly what you are doing (or trying to do), but I really have too much else on at present. Do you think you could present the same code, with line-by-line comments on what you think is accomplished by it? This would make it a doddle to check for you. I've not seen anything quite so, er, complex on this Forum, and I am lost too but mainly because I really don't know what you are trying to achieve nor how. If you'd like to annotate it, as I said, I will take a further look. Okay? Regards Pete

You won't find any reverser in any list of FS controls, because it isn't FS which supports a separate reverser but FSUIPC. Please see the section Assignment of additional controls (Reverser, Aileron and Rudder Trims, and Cowl Flaps) in the FSUIPC4 Advanced Users Guide for details. You need to de-assign the axis altogether in FS assignments and instead Assign it in FSUIPC's Axis Assignments. Select the Send direct to FSUIPC Calibration option checkbox in the Axis Assignments, then choose the Reverser from the drop down controls listed. You then need to go to FSUIPC's axis calibrations, find the reverser and calibrate it. Regards Pete

Right. The current version is 3.74. I don't support old versions. There's no way you lose your key unless you delete the key file, and then you'd need to find the backup you made (of course). As the installation instructions say, installing FSUIPC is only a matter of copying the DLL into the Modules folder. As for problems, since each update for FSUIPC is intended to add new facilities and FIX problems, why should it introduce any? In the unlikely event that it changes something you are using, just let me know and I'll fix it. Pete