Pete Dowson

Replying to message sent privately: Thanks for letting us know. I've not heard of NOD32, but it sounds like it is one of those whose hooks disagreee with the way SimConnect works. There seem to be some programs which cause these problems and others which don't. AVG and Norton seem okay for example (I use Norton). Maybe some of these problems will be fixed in the forthcoming SP1 update for FSX. I don't know, but let's hope so. Otherwise I think Microsoft may need to publish a list of incompatible security programs. Regards Pete

Yes, but all versions of FS have been made for hardware not actually available at the time of its release. With FS9 you couldn't put all sliders to full on the hardware available in July 2004 -- only in the last year or so has that been reasonably possible with all the advanced add-ons too. And it was the same for FS2002 and FS2000 etc, going all the way back. FSX is designed to be usable now with compromises, and to the full later -- it has at least a three year life to endure. It is not like many 'games' which you play for a month then discard for the next. All the traffic features -- Airline, GA, airport traffic, boats and ferries are the "AI" traffic. There are sliders for them on the traffic tab in the settings. Regards Pete

Do you mean 3.70, or a later version? The current version is 3.74. Please confirm you are using 3.74. If not, please update first and re-check, then let me know. Thanks, Pete

Yes, that is because of the conversion of "unknown" state aircraft to 2enroute" when they are above ground. This is worrying. It may simply be that this flight number is the default once inside that particular aircraft's CFG file. could you check that for me please? The two entries were: They are obviously distinct aircraft with distinct positions and tail numbers. It looks like VoxATC is not injecting the Flight numbers (or possibly it cannot in the interface it is using -- I don't know, but Tegwyn will). If SimConnect is merely supplying whatever flight number happens to be placed in the AIRCRAFT.CFG file then I will have to change my code to clear it again -- best to have nothing than have wrong information. So, let me know please. Apart from undoing that change there doesn't look like I can do anything else. At least not without input from Tegwyn. Regards Pete

Okay. I've been through my code and explained a few things to myself. Here are the 'anomalies' and their explanation: 203734 AIRCRAFT: Ref=682 [x02AA],OnGnd=0,Tail="N6167P",Airline="LUFTHANSA",Flight="",Type="BOEING" 203734 Lat=37.5348,Lon=-122.1105,Alt=2923,Gnd=13, GS=0,AS=208,VS=0,Pch=0.0,Bnk=0.0,COM1=2485 203734 State="init" [12], Runway="", From="", To="", Flags=03FF The "State" string is what I receive from SimConnect. In order to deduce a numerical state value to equate with previous versions of FS, I look that up and convert it to a number based on a list of known state strings. In this case, the original state told to me was zero, ("Init"), but as the aircraft is above ground I convert that to 12 ("enroute"). Note that is has no flight number, nevertheless. Strangely, of all those shown as airborne in your log, that was the only one in "init" state: 204766 AIRCRAFT: Ref=685 [x02AD],OnGnd=0,Tail="N3177U",Airline="AMERICAN",Flight="",Type="BOEING" 204766 Lat=37.3938,Lon=-122.1349,Alt=3007,Gnd=208, GS=208,AS=208,VS=-861,Pch=0.2,Bnk=-0.3,COM1=2485 204766 State="" [1], Runway="", From="", To="", Flags=03FF This one, and all the rest, were actually set with an unknown state value, and SimConnect sent me the string "". By default FSUIPC4 converts unknown states to 1 ("sleeping"), not to 0 ("init"). As a result, even though it is airborne, its state is never converted to "enroute", so TrafficLook never displayed it. Possibly, though maybe unlikely, these state flights might also have actually had Flight numbers. As already mentioned, FSUIPC clears Flight numbers for aircraft in "sleeping" state because otherwise, for true AI, they all get the same default flight number (the one in the Aircraft.CFG file). SoI have changed FSUIPC4 so that it converts airborne aircraft of either state 0 or 1 to state 12 (enroute). This should at least bring more airborne aircraft to TrafficLook, and may, if we are lucky, get the flight numbers. If you still get no flight numbers, it definitely needs VoxATC attention. Please try the attached interim test version 4.099c and let me know. I'd like to see another Log as before, please. Regards Pete FSUIPC4099c.zip

I don't know what FSCommander's message "Unable to connect to Flightsimulator Msg #2" means -- you'll need to go to FSCommander support for help on that. But I would like to see both FSUIPC and WideServer logs please. Make sure they are complete -- close FSX down completely before getting the log files. If they are short enough show them here, else ZIP them to petedowson@btconnect.com. Regards Pete

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