Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Well, neither SimConnect nor FSUIPC makes any distinction between ground and airborne traffic --it is only a flag saying "on ground" or not. Oh, and of course the range at which FSUIPC adds ground traffic into the list is 3 nm, whereas the range for airborne is 40 nm default, or unlimited if you set it that way. The flight number is not relevant before the clearance. Okay, so it is only TrafficLook not getting the data? Yes please. Oh, maybe for the FSUIPC4.LOG could you enable IPC read logging again, just so we can be sure the ground tables are still all zero? Don't leave it on after this though. It makes the logs far too big and hard to read. Apart from that I need to think what extra logging I need now. Nothing is making any sense. As I say, there's really no difference at all between ground and airborne except for a flag, unless all your ground traffic was more than 3nm away. I have tried it on a P4 3.2GHz with 1.5Gb, a Core 2 Duo 2GHz with 2Gb, and an Extreme Core 2 6800 with 2Gb (my fastest), and none of them exhibit ANY of the symptoms your does. Equally, none of them manage to get to loading any AI traffic for at least the first 120 seconds -- well over 80% of the progress bar. (Did you observe this at all in yours?) Maybe it's related to some setting in your CFG file. Could you Zip me your FSX.CFG file so I could try it please? I'll think about what additional information I need to find out what it happening to the ground traffic. Looks like another day ... Regards Pete
  2. Okay. I've analysed the logs in detail, and I can only conclude that the problems are down to the change to multi-threading in FSX + SP1. I cannot reproduce anything like the problems you see, but I can theorise how they may occur assuming several things are going on in parallel in FSX. There are two things I could do, and I've decided to do both of them. 1. Make FSUIPC4 "start immediately" if it detects SP1 or later. This will put it in a better position to catch things hapening in parallel with the main thread sequencing. 2. Utilise a separate SimConnect facility for requesting a list of all traffic at a given moment in time. I hadn't used this before because it wasn't needed - FSUIPC had always requested notifications of AI additions before they started. Just to be on the safe side, I have made it ask for the list repeatedly, every 5 seconds, until it receives the first notification of an additional aircraft. This will prevent it missing any at all, I hope. Before I make any general release of a version containing these changes, could you please download 4.112 from this link: http://fsuipc.simflight.com/beta/FSUIPC4112.zip This is just the DLL -- copy it into the FSX Modules folder. Try it and let me know, please. BTW, I should have mentioned this earlier really. Instead of enabling all that IPC read/write logging, for AI data you can get good logging by adding these lines to the [General] section of FSUIPC4.INI: Debug=Please LogExtras=512 Actually, with "Debug=Please" there you can enter the LogExtras number in the Logging options. There are a number of different debug logs which I control that way, but they change from version to version and I prefer to have them used on a need and request basis. Regards Pete
  3. Okay. So the problem is actually FSX SP1 rather than anything different in FSUIPC. The phrase "after the sim is running." seems to imply that somehow you are getting AI aircraft populating BEFORE SimConnect has loaded FSUIPC and told it the the Sim is running. The method FSUIPC has of getting data on AI aircraft is by telling SimConnect to notify it of every "Add Aircraft" and every "Remove Aircraft" event. Obviously any of those occurring before it is even running won't be seen. That's actually completely different to what I see here, where FSUIPC is most certainly ready and receiving data from SimConnect when the first loading progress bar is between 10 and 25%, certainly well before it reaches the "loading AI traffic" stage which is generally at 60-80% minimum. I am puzzled as to why your system is behaving so differently to mine -- I've tested this on three different systems, very different speeds, XP and Vista, and with different amounts of add-ons installed from none to a lot. And it seems pretty invariant. I'll take a look. I think only the early parts will be relevant to this, though your other, separate, problem of missing flight numbers is odd too. [LATER} After a first brief look at the SimConnect log, and comparing it with a typical one of mine, the difference i see is amazing. I get no notifications of any objects being added at all, but after 63 seconds of SimConnect starting there's a whole load of these: < 63.60396 [63] ObjectAddRemove: EventID=10 Type=2 ObjectID=2936 which are Object Removed notifications! The sequence FSUIPC is using should be foolproof. Here is the start. within 6 seconds of SimConnect starting up FSUIPC is asks to be notified when the Sim is ready ("SimStart"): > 6.81561 [63, 2]SubscribeToSystemEvent:EventID=2, SystemEventName="SimStart" and this actually occurs 34 seconds later: < 40.39737 [63] Event: 2 upon which FSUIPC asks for notifications of Object Add/Remove: > 40.50822 [63, 13]SubscribeToSystemEvent:EventID=9, SystemEventName="ObjectAdded" > 40.50832 [63, 14]SubscribeToSystemEvent:EventID=10, SystemEventName="ObjectRemoved" but it never then gets the ObjectAdded event for all those which get removed 23 seconds later! All this is happening in the first 60 seconds of FSX being started. Even on my fastest system it takes over 100 seconds before it gets its first notifications of objects being added, yet it seems on your system they must have all been added in the first 40 seconds, before Simconnect has even said it is ready! What sort of system are you using there? Maybe this is all to do with speed and multiple cores. Is it a Quad core or something? Maybe the SimConnect thread is running is one core whilst all these other things are racing ahead in another? If this is indeed where the problem lies, there's one more thing you can try before I work out a general solution. Try setting StartImmediately=Yes in the [General] section of the FSUIPC4.INI file. If it isn't there to change, just add it. Here's how it is described in the Advanced User's Guide: StartImmediately is not expected ever to be useful, but adding it and setting it to ‘Yes’ makes FSUIPC4 initialise the data interface with SimConnect immediately it is started, rather than wait for SimConnect to indicate “SimStart”. This is the way it operated throughout the Beta phases of FSX and in the first few public releases of FSUIPC4, but it was changed in order to avoid the SimConnect problems which seem to occur when more than one Client initialises at the same time, prior to FSX’s “start”. Please let me know. If that helps or works, I may change FSUIPC4 so that it assumes that setting -- for FSX+SP1 only (because the problem it fixed certainly still exists without SP1). Regards Pete
  4. Please check the announcements and stickies at the top of this Forum. You will find one dealing with what to do if you lose your keys. Pete
  5. Updated from what version to what version? You don't have to pay for updates from any Version 4 to another Version 4. Can you describe more carefully what you mean, please? When you say you are "unable" to enter the key, can you tell me what you mean, please. Is something preventing the entry, or what? Perhaps you should send me your registration details privately, to petedowson@btconnect.com, so I can check them. Regards Pete
  6. There are reports of it being done with a 396. Is the 496 are newer model in the same line? If so it should be fine. See for example http://forums.simflight.com/viewtopic.php?t=42486 . USB is just another type of serial port. When connected, does the unit show as another COM port in the Windows Device Manager (Control Panel-System-Device Manager)? If so then it is using USB only in COM port emulation mode -- which seems likely if you can also get a serial cable for the same device. Otherwise, it may be connectable using the more complex USB port name as mentioned in the documentation, though I've no experience of any of that. If you have some sort of active sync program installed for map /route and other type info updates, you may have to kill that as it could be running in the background waiting to grab the device as soon as it is connected and switched on. Regards Pete
  7. I have xclass installed as well, in any case. Thanks. This confirms what you say, but doesn't show why. What I really need to know is whether it is okay with 4.10 (attached in this thread earlier). Because if it is, then it must be purely down to the fact that FSUIPC 4.11 is now waiting for SimConnect to supply the "IS USER SIM" flag, and it isn't arriving very promptly. If it is okay with 4.10 then could you go back to 4.11, enable SimConnect logging (as described in the FSX Help announcement above), and re-test. Keep it short, but long enough to prove the problem. then Zip up the SimConnect log for me. I'll need that to discuss this meaningfully with Microsoft, because it would mean there's a SimConnect bug which will need fixing. Then I shall have to try to find a work-around. The fact that there are occasional enroute airliner flights without flight numbers indicates SimConnect is also being a bit cavalier about some of the less essential data FSUIPC asks for. Did that never occur before 4.11? Regards Pete
  8. Possibly, though more information is the prime requisite, and other tests as stated. If you want to send a ZIP (and it must be Zipped), please send to petedowson@btconnect.com. Regards Pete
  9. Sounds like a connection difficulty, not a TCAS tables problem. You need to start TrafficLook AFTER FS is running. Which version of FS? Which version of FSUIPC? What other programs are running? There's no difference to FSUIPC whether traffic are on the ground or in the air -- the only difference in treatment is the range at which they are included. Flight numbers are not assigned until the aircraft are under ATC control and actually commencing a route. You don't get flight numbers for aircraft injected by programs like VoxATC or multiplayer-type applications. Flight numbers are also discarded for aircraft not reported as in a state known to be ATC-related, so the state is important too. e.g. "Init" or blank would not warrant a flight number, whereas Taxi and Enroute would. As you say later, there are no attachments. Anyway, the log file will show nothing about AI traffic unless extra logging is enabled. Otherwise the file would become huge pretty quickly. The first thing I'd need to know are all the details, like versions of everything, what else is running, and what you've changed recently. Apart from what i mentioned earlier regarding 4.11 and FSX+SP1 there's been no difference in anything regarding AI traffic in FSUIPC for about four years. So I obviously need to know what's changed just recently. If you do mean FSX+SP1 and FSUIPC 4.11 then I need to know whether it was okay with 4.10, and I need a lot more information about what else is running and what you are doing. I've tested it all thoroughly on two different systems and cannot get anything at all to go wrong. In case of FSUIPC4, please look in the FSUIPC4.LOG and see if there are any errors reported. If the SimConnect connection is playing up, that would more likely explain things. Regards Pete
  10. Yes, but I don't know why you are reading any "" in any case. Regards Pete
  11. Ray Proudfoot (visiting me today) and I have just flown three flights with RCV4.3, with ASX running (both on a separate PC to FSX), and FSUIPC 4.11, and the ground traffic detection and RCV4.3 interaction worked fine in all three flights. TrafficLook confirmed this. So, sorry, I am puzzled as to how they can be missing on your system. We'll need some process of elimination to see if there's a specific cause. Once I know more I can maybe suggest some logging options which would tell us more. Regards Pete
  12. Okay. The "" marks around the strings in this log are added by the logging. they are not actually part of the string data returned by FSUIPC. they are there in the log so you can see any leading or trailing spaces. Okay. But it might be a good idea for your code to test for and strip off quotes at either end in any case. I doubt that they'd occur in real titles. Regards Pete
  13. I cannot reproduce any problem with FSUIPC 4.11 and TrafficLook showing Ground Traffic. Have you checked with just FSX, freshly loaded, and TrafficLook? If you are getting a situation with TrafficLook not showing ground traffic even when you can see it (the range is much shorter than for airborne traffic), then I need a lot more information in order to track it down. Like if it occurs always or only when some other add-on is running, or only after a flight reload, or use of multiplayer? If I can't set up a situation in which it occurs I will have to work out what extra logging I can get to show the problem from the inside. Regards Pete
  14. Yes, that is perfectly correct. The wind hits the tailplane causing the nose to try to face into the wind. The same happens in a sailboat -- left to itself a boat with a taut enough sail will turn into wind and the sail will flap as you lose way. It isn't an "issue", it is basic physics. When you are actually flying it is completely different. The whole aircraft it moving IN the airstream, not pivoting on anything. As far as flight is concerned only the relative wind matters, and that comes from your airspeed. You are then using the rudder (and aileron) to correct your ground track (course). If you don't understand this please try to read a book on basic flight. I'm sure it will all become clear. I am not a good tutor. ;-) Regards Pete
  15. FS has never supported any "switch" function for reversers. The nearest you can get is Throttle Decr (the control normally assigned to the F2 key). Try that, with repeat whilst pressed enabled. Sorry, what do you mean "I have but", where "have" you got this and why isn't it doing what your programme expects? There are two controls I see -- INCREASE DECISION HEIGHT and DECREASE DECISION HEIGHT. Don't you think one of those might be relevant? Regards Pete Cheers Craig
  16. I'll check here. Is this only with FSUIPC 4.11? I had to make a change for FSX+SP1 because SimConnect was returning different User Aircraft IDs and SP1 was installed, and often FSUIPC would lose all contact with User Data. In FSUIPC 4.10 the change unfortunately made the User Aircraft also go into the TCAS tables, which caused continuous collision warnings in properly equipped airliners! I fixed the latter in FSUIPC 4.11, eliminating the user aircraft from the TCAS tables by reading a SimConnect variable called IS USER SIM, or some such -- but this means I have to wait for that to be returned. Maybe SimConnect isn't returning this for ground aircraft? I'll do some tests here later today. Last time I did check with TrafficLook I am sure I saw ground traffic, but I'll re-check. Meanwhile, in case you no longer have it, I attach FSUIPC4.10 -- can you try it with that and let me know? Just put the DLL into the FSX Modules folder (save your 4.11 first). If the difference is between 4.10 and 4.11 I will have to review what SimConnect is doing and think again. BTW TrafficLook is simple a demo/test for FSUIPC's TCAS tables and is just as valid for FSX as FS2004. It, along with other FSX goodies, is supplied separately now, in the FSX Downloads above. Regards Pete FSUIPC410.zip
  17. Correct. Looks like a misprint I made (back in January!!). It's of size 256. Well, it isn't a difference in FSUIPC. I don't add anything or take anything away. Which Flight simulator is this? FS2004 or FSX? If FSX, as sounds likely, it'll be a difference in how SimConnect supplies it. I can check. If it is supplying them with such variations I may need to scan for and remove " characters so that comparisons and aircraft-specific checks will work consistently. Sorry, same result for same aircraft, or does the result follow the title? Maybe it's your code? Or whatever FSUIPC interface wrapper it is you are using for your language (is that VB?). I can try it here, but first I'd like to know which version of Flight Sim you are referring to. Just in case it is your code, could you Monitor 3D00 please, change various aircraft, and show me the resulting Log. To do this go to FSUIPC's Logging options, right-hand side, set offset 3D00, type ASCIIZ, and select "normal Log". Please always consider using Logging for debugging purposes. You can actually log exactly what your program is reading or writing (IPC read and write logging) as well. That is what it is for. Also, you can check directly what 3D00 is containing by using FSInterrogate, as supplied for such purposes in the SDK. Regards Pete
  18. You can send the control to FS by program, if it is a program you are talking about. Why would you want them to assign a key to do a job you can do directly? They would need to expect there to be a "loading" progress bar on screen when you execute the control, however. It should be fairly short-lived, though, for most aircraft. Regards Pete
  19. I've tested saving and viewing Flights in the Flight selection menu now on three different systems, including one Vista system in full screen mode, and two XP systems, one with an ATI card and another with an nVidia, both Windowed and full screen modes, and all of the flight snapshots are perfect. Sorry. It sounds as if there's some sort of problem with the video drivers on your setup, just possibly exacerbated by timing differences which may occur when FSUIPC is running. I suspect you'd get the same with any other busy SimConnect client. Regards Pete
  20. Oh, yes. Okay. Anyway, the problem is fixed in 4.11. Thanks for reporting it in time! ;-) Pete
  21. Odd, then, that others have succeeded. Maybe TeamSpeak has been changed since it used to work? See for instance http://forums.simflight.com/viewtopic.php?t=42038 . There is actually a section in the WideFS Technical documentation entitled PTT (push to talk) for Roger Wilco, AVC and TeamSpeak and TeamSpeak gets its own little section within that, telling you the exact details you need to know. Regards Pete
  22. FSUIPC3 keys won't work with FSUIPC4. They are different products with different keys. Please check the User Guide for purchase details. Regards Pete
  23. And you've not reported this for the nine months since FSX was released? Or have you collected all versions and only tried them recently? No. You are the very first in all this time. Shame it wasn't reported in time for an SP1 fix. I can see if it happens here of course, and if it does report it to Microsoft -- because if it does happen generally it will be some sort of SimConnect problem which they can possibly supply a workaround. FSUIPC4 is not like previous versions, it is 99.9% SimConnect interfaced. The minor exceptions (getting the list of controls from CONTROLS.DLL) tend to be very minor and static (i.e. happen once, or not at all until used). I've got to go out now, but I'll try it later. Regards Pete
  24. Okay, never mind about the INI file -- I've reproduced the case where it is logging the Aileron changes notified from SimConnect. I'll fix it in ther next increment (4.105, or maybe 4.11), within the next few days. Thanks for letting me know. Regards Pete
  25. Let me see the INI file -- looks like a Monitor entry is there, or possibly a LogExtras. There's no such thing as "disabling logging". FSUIPC always creates a log. It will log certain things always. However, certainly these: should only appear if there's a LogsimC or Monitor entry for 0BB6, or a specific LogExtras value set, introduced (temporarily, for 4.104 only, to debug one user's specific problem which turned out not to be a problem anyway). I need to see the INI. Regards Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.