Pete Dowson

The current version of FSUIPC is 3.08, and WideFS is 6.10. There is only one correct version at any time. Just WideFS. There is no current free way to do it -- the last free copies of WideFS and FSUIPC were 5.50 and 2.975 respectively, but I don't supply them nor support them now. Regards, Pete

Sorry, I don't know Visual Basic enough to advise you accurately on this. The usual problems VB programmers have are (a) wide (16-bit) characters being used instead of the normal standard ASCII as understood by FS, and (b) not passing the pointers to strings, but values instead. It looks like the former may be taken care of by your preparation loop (though I don't really know this, I should add), but I thought the writing of strings from VB was best done by the use of the "FSUIPC_WriteS" variant some kind person added to the VB part of the SDK? Have you tried that? It may be that the declaration of the FSUIPC_Write function is de-referencing your string pointer. Regards, Pete

Are you sure there was no turbulence or variability? Unlike in previous versions of FS these both seem to work very well in FS2004. Certainly I don't think the wind effect is "too strong" -- the reverse, if anything. I've never found it so easy to do cross-wind landings. With a steady wind they are now quite a doddle. Maybe its some improvment in the aircraft modelling that helps. No aircraft, even a super cub, should really get blown about in the air with steady winds, you'll just get blown in the wind direction. I've never seen anything else except in turbulent or viriable conditions, in FS2004 or before. So I feel pretty sure you must have had one or the other effect. Both turbulence and variance values are shown in the WeatherSet2 display by the way, so it is easy enough to check. No, sorry. I can't get at the current weather and make any sensible changes. I spent many many hours looking to see if I could override the winds in order to implement the "Taxi Wind" option, and thought I'd succeeded once, but it was not to be. If anything my fiddling about made things worse. I can of course influence the weather being input by external programs, and I can play around a bit with global FS weather, if you enable the Technical option for me to do so, but, as you'll see from one of my "Important" notes (now also in the FSUIPC documentation), none of the FS weather stays "global" for very long. If you don't like turbulence, there's an FS option to stop its effects -- Options-Settings-Weather. Unfortunately it's an on or off thing. In the FSUIPC guide I do mention pparameters in the FS CFG file which can be adjusted, maybe these will work with FS2004 as well? Regards, Pete

You don't mean trying to use FSUIPC in another simulator, I assume? It is too intimately interwoven with FS, more than 90% of the code in it is completely FS dependent and dedicated. If you mean you want to implement your own FSUIPC-compatible interface, then that makes more sense. Have to spoken to Enrico Schiratti about this? I think you may find some things have already been thought of. No, that is not a good view. You need really to think of the offsets as "Op Codes" (Instructions) and the data being read or written as their parameters. Each Instruction is treated differently, according to what is needed to get the data into or out of FS, or to achieve the correct reaction, whatever that might be. There are no rules here. EAch item has to be dealt with on its own merits. The whole image of it looking like an area of memory with values to be read and written, which magically influence the simulator, is one deliberately maintained to make programming it more or less the same as it was in FS95 and FS98 -- when in fact most of MSFS was actually like that! It isn't now. There are hardly any variables left these days in their old positions, and many aren't even anywhere without calling procedures and performing computations. And almost nothing now works simply by writing some nice number to some nice location. Most all of the actions requested by writing have to invoke some call, some function, or even a sequence of them. Treat the reads and writes as requests, forget the memory image, then see how to meet those requests in your simulator. Regards, Pete

Sounds like the MCP program is hung or going wrong. Why are you blaming your network? Have you checked with Project Magenta support. I'm sure they'd be able to help a lot more than I. They certainly help me a lot! Please leave most things to default, unless you really know they are beneficial. For instance, delete: Timeout=0 in the Clients, and autoupdatetime=13 Restarttime=100 MaximumBlock=5096 in the Server. 641375 Note: Send() request depth is over 100! 649703 send() failed [0 bytes] after 40 retries, request depth is 478 649703 Ready to try connection again 649703 Attempting to connect now 649719 Connection made okay! This isn't terribly good -- you are getting some sort of blockage from the Client to the Server. However, if it doesn't occur too often then it shouldn't be a big problem -- it recovered, so all you should see is a temporary stutter, or a few. In the Server: 764953 Client socket disconnected at Client: removing (skt=2168) 765000 Incoming connection Accepted ok (skt=2160) 765016 Connected to computer "EICAS" (skt=2160) you can clearly see that the reconnection only took a matter of milliseconds. There would be a short period of sluggishness whilst the data is refreshed, but nothing major. If you are getting these blockages often I would say you need to check your network -- try swapping the interface cards, or even cables. I think it was our Mr. Schiratti himself who had such problems and eventually replaced the cables nd all was well. Amazing. But the logs you show don't really explain the problem you describe, only a passing problem. That is something else. The logs might imply one set of stutters, that's all, possibly a lost input but even that should recover.. Regards, Pete

Have you registered FSUIPC? If not then the crash in EpicMapper may be simply because it is not registered and not getting a response it likes from FSUIPC. Another possibility is that it doesn't cater for an extension to the range of FS versions now supported by FSUIPC -- FS2004 is encoded an #7 in the offset for FS versions. FS2002 was #6 in that table. Possibly this #7 is outside of some array bounds and so causing the crash. If EPICmapper works in FS2002 with FSUIPC 3 then this is, in fact, the most likely explanation. If you like, go to FSUIPC's Options, the Logging page. Turn on IPC read and write Logging, then start up your "EpicMapper". When it fails, be sure to close FS down normally, then Zip up and send me the FSUIPC.LOG file to petedowson@btconnect.com. I doubt that I'll be able to fix it (it is not my program of course), but at least I may be able to tell you what is wrong. Regards, Pete

Hi Greg, I emailed a list of additinal questions and ideas to you on Wednesday night. Did you receive this? I also emailed a special version of FSUIPC with several tests for you to try for me, if you would be so kind. These will enable me to at least pinpoint the cause of your stutters, within the weather interface, and possible make improvements or at least provide options for reducing or eliminating them. This was earlier yesterday (Thursday 18th). I was hoping to learn how they went before releasing Version 3.08, just in case there was anything I can do -- so if you can get back to me soon I'd be most grateful. Thanks, Pete

Have you checked with the author? Does he have a support site? Certainly he should be able to diagnose this for you in no time. BTW "msvcrtd.dll" is the Debug version of the MSVC run-time library, not normally installed on user systems. Is this a Beta test version of EpicMapper you are using? Regards, Pete

Yes, it does! What is the exact problem? Is it difficult following the instructions, or are you having difficulties with the program? You must first calibrate your joystick in Windows. Only use FSUIPc for the final trim and to set accurate dead zones. There is no difference in the Joystick facilities in this version -- it has not changed for many months! What do you think is different? I don't undertstand. You need to be more specific, please. I don't think it is good to be so nasty and without justification -- there are no details given of anything wrong. There is a bug in 3.07 (only) in FS2002, and as advised in the IMPORTANT announcement it is better to stay with 3.06 for FS2002 until 3.08 comes out (tomorrow probably). But the operation on FS2004 is okay, and the bug did not affect Joystick calibration, only button and key assignments. If you have a problem, please report the details. I cannot help you if all you do is insult me and my program. :cry: Yes, pleasethank you VERY much! Can you please also ask him to turn his CAPS lock off! :? Regards, Pete

What flight sim yoke is it? FSUIPC will only recognise Joystick Buttons if they are visibile in the Windows joystick interface. As far as calibration is concerned, there should be no problem, as FSUIPC is not reading the joystick, it is only manipulating the FS controls internally. Can you explain what the problem is -- is it just that you do not understand the documents? I hope your friend can translate for you. And can you please turn off the CAPITALS, it makes it much harder to read! Thanks. Regards, Pete

Ah, sorry. But perhaps he might understand Portuguese? I wonder if he means he cannot see how to, or cannot understand my document (which is probable), or if he's saying there's something wrong somewhere? If he is using it on FS2002 then there is a problem in 3.07, it is okay in 3.06 and is fixed in 3.08 which I will release tomorrow or on the weekend. Regards, Pete

Are their any Spanish / English speakers here who can help, please? Eugenio does not understand English and I not spanish. First, perhaps someone could ask him to turn his CAPS lock off, but a translation of his questions would be very useful in any case. Thanks! Pete

If you are using FSUIPC 3 and have not registered it with SimMarket, then you need to register Squawkbox with FSUIPC. The access key is provided in the Freeware Access Key list in this forum (look at the titles near the top). You enter the details (program name and access key) in FSUIPC's registration page -- there's a button, bottom right, in the first page ("About"). Pete

I used to have such a dedicated FS machine, but I've linked up my machines in a Network for years. Unless you are talking about different rooms, Networking has great advantages in just about all respects, and makes stuff like that much easier. even though my current FS PC does have internet (I'm using a router on the Network, so any Network PC has access), I still always download to the main Internet PC (this one) and transfer things for FS across the Network. I do use CD-R for backup, though. You can download any of my FS programs and modules at any time as you wish. The registration is a personal one and recorded on your PC, it does not affect the modules directly. And there's no "if" about it, by the way, the software is updated regularly, and will continue to be so until everything that needs to be done for FS2004 is done. The current version of FSUIPC is 3.07 but I have 3.08 waiting to go iut, just pending resolution of one outstanding problem. Regards, Pete

Values 0, 6, and 12 won't do anything, except maybe add extra logging and possibly slow things down -- performance related stuff mostly. Only the value 16 as I said will bypass any of the weather code. Please don't play with other values, you may get some nasty surprises! :) The routine used to read the weather is done roughly once every 4 frames or so, so I'm not sure how that can create stutters 1-1.5 seconds apart. What's your frame rate? It is a bit odd. I'm suspecting something odd with the WEATHER.DLL interaction, or possibly with the memory management calls in FS. How much memory do you have? Is there plenty free? Only 0 and 16 were relevant in any case. Any other variations were probably random or imaginary, though you were probably enabling excessive logging, which may cause stutters if your disks aren't defragmented or if you've turn file write caching off. All this indicates is that it isn't a good idea to access any weather at all. Though it doesn't seem to matter on most folks' systems it evidently does on others. The routine to read the weather is a direct call into WEATHER.DLL which returns the data in structures which are allocated on the Heap. FSUIPC then copies the stuff out into locations for programs to read, then frees those structures. So there is some memory management involved, but comparing it to the numbers performed by FS all the time it is nothing -- in half an hour FS can clock up several million allocmem and freemem calls. The weather reading is a fraction of that. In your case maybe you never have any programs that need to know the weather, but mostly that isn't the case. Supplying weather data has been a prime function of FSUIPC and FS6IPC before it for years. I could make it switchable, but I would be worried that folks would forget it was switched off and complain that programs like Radar Contact and so on were going wrong. I'll just try, initially, slowing the read rate down somewhat -- say to once every 16 frames instead of 4. On my system that would mean weather data changing about once a second. Oh, that reminds me: what is the frame rate you get with FS2004, please -- during these tests, for example? Do you have the FS frame rate limiter set to below "unlimited", as actually recommended by MS? The general recommendation, for smooth flight, is to gauge what your average frame rate is with it on unlimted, then set the limiter to something below that. the more additions you make, needing processor time, the more it needs restricting. I have mine at 20 fps even though it can attain 30 fps mostly, during flights (10-15 at detailed airports). But this is mainly because I also run WideFS with several clients, and 20fps keeps them smooth too. So: TEST # 3, check frame rates and set the limiter. After that, please write to me at petedowson@btconnect.com and I'll try to set up some experimental changes in FSUIPC for you to try. I can't make such attachments here, and any case I don't want any experiments going to a wider audience, not yet in any case. BTW I have tried, in vain, to find the weather directly to avoid the procedural calls and messy memory management, but even after many many hours of searching and tracing through FS code I've failed miserably. One day I'll have another go. I did ask for help from MS, but they are not really interested these days and simply point to the SDKs, when they come out. There never was an SDK for weather access and control and I don't believe there'll be one now. :cry: Thanks Pete

The name, email and Key must be all absolutely EXACTLY the same as originally notified to you. Best to cut and paste from the original email. Was the version on the old PC 3.00 or 3.01? If so, some key changes were made after that, but this was all within a few days of first release, before, in fact, FS2004 was released. If you still have difficulties, please forward me a copy of your original email, containing your details and key, to petedowson@btconnect.com, and I'll check it. Do not publish any thing here for obvious reasons. Regards, Pete

No it isn't, not at all. WideFS is a method of connecting programs using FSUIPC's interface to FS when they are running on a separate computer which is NOT running FS. You cannot run the WideFS client software on a PC running FS. You are thinking of WidevieW by Luciano Napolitano. Regards, Pete

There's some confusion here. That so-called visibility layer you see if in fact a deliberate cloud graphic drawn at the altitude which is defined in the weather as the top of the visibility layer. It is not actually a visibility thing, but a graphic addition, like any cloud. It was done by MS in response to the many complaints about FS2002 that, as soon as you climb out of the murk, suddenly the ground is sharp and clear below you. I actually like it, but then I tend to fly mostly in or from the UK where it looks quite good, especially with limited visibility in action above the layer too (more below). The only answer is to raise the top of the visibility layer -- it's a parameter you'll see in the Weather dialogues. Unfortunately, FSUIPC can only do this for global weather or weather provided by an external program -- the parameter is bottom left in the FSUIPC visibility page. I cannot get at the localised weather without re-writing it (the weather, that is), in which case I'd be doing the same job as an external weather program. You could try using the visibility limits and graduated visibility facilities in FSUIPC, which do apply to all weather, even localised. If you set the lower altitude of the graduation to 0 it will start at the top of the visibility layer. With a suitable upper limit to should be able to lessen the effects you don't like. Regards, Pete

This is a timing issue to do with panel detection on first loading FS. It doesn't affect the panels if they are loaded later, nor if you switch views. It's just on initial loading of FS. I've fixed it in version 2.123 of Advdisplay, which I will release later, tomorrow (Thurs 18th Sept) at the latest. Thanks, Pete

I've made some small changes to the PFC driver and the problem of overriding the Gear switch with FSUIPC programming seems to be fixed. It'll be version 1.62. I'll release it later, tomorrow at the latest. It's too big to attach here (I've tried!). Thanks, Pete

Yes, I get the same here -- but only with that switch! It is very odd. I am looking at the code now, and wil get back to you. Sorry. Pete

Apart from the special facilities in FSUIPC to read buttons from the PFC driver, the only buttons it can see are those reported through the standard Windows joystick API (joyGetPosEx). this is an older interface than the DirectInput one used by FS itself. It supports 32 buttons on each of up to 16 joysticks. If the GoFlight drivers are only supporting the DirectInput interface then FSUIPC won't see them. Regards, Pete

I've not heard of anything like that before. Can you tell me what version of FSUIPC it is please? And I need to see the FSUIPC.INI and LOG files, both from the Modules folder. Please ZIP them up and send them as attachments to me at petedowson@btconnect.com. Also I need to know what programs and panels you are using with it -- when you registered FSUIPC to allowed all and any programs, gauges, DLLs to use it freely if they wish. It may be something else, not FSUIPC, which is crashing. In fact that is much more likely. Also, try it with FSUIPC's weather options set to "minimum" (there's a button on the first options screen). By default FSUIPC does make the weather a little more complex on FS2002, and this may be placing more of a strain on your graphics card and showing up a fault or problem on that -- maybe temperature, driver, or DX problem. You could also check for that by reducing the hardware acceleration on the card, or try a lower resolution (just as a test of course). You should be aware that FSUIPC has been in use on FS2002 without such problems now for over two years. I don't know where you heard about such problems before, but no one has reported them to me. The difference registration made is that lots of default options got switched on when you did that, making it run as it has been on FS2002 for a long time now. Without registration and no aplication programs it wasn't doing much. Regards, Pete

Not a lot, actually, at least not yet. I don't know anyone with consistent stutters when nothing is using FSUIPC -- yours is the first report of anything like this I've actually received. I run FS9 on three very different PC systems and the only stutters I see are from things like scenery and autogen coming into view (provided I have all the cloud stuff set full). So I need to use you to test things, if that's all right? If you haven't registered FSUIPC then this might not get very far, so say so, and after a couple of easy tests (below), I may have to wait for a volunteer who has a user registered copy. Basically, when nothing is accessing FSUIPC, which is the only test I'm interested in at present, then FSUIPC does nothing except: 1. If you have any weather options set AND you have the Technical option set to influence FS weather, then it will update the weather now and then. So please set all options off. If your FSUIPC is unregistered (what!?) then use the button to set minimum. 2. If does obtain numerous items of information from the main simulation engine, SIM1.DLL, but you cannot stop this. If it looks like an area which could be causing your stutters then I'll devise a way of bypassing this code, to try to narrow it down. 3. It regularly reads the "weather at aircraft" so it can report all the weather details in the appropriate offsets. Unlike in FS2002 and before, this is done by a call into FS's Weather DLL, which isn't as efficient as I'd like. But I've found no other way. 4.It scans the population of AI aircraft regularly, so it can provide TCAS data. And that's about it -- any other functions are completely dependent upon options being set to use things in FSUIPC (I assume you aren't actually using any), or being called or used by other programs, DLLs or gauges. So, for any tests, please don't run any FSUIPC applications, make sure there are no other add-in DLLs in Modules, and only use default aircraft and panels. TEST #1 You can make FSUIPC bypass ALL the weather actions completely (it doesn't go near WEATHER DLL then) by adding the following two lines to the FSUIPC.INI file: Debug=Please LogExtras=16 so first, please try that and see if the same stutters persist. You can actually then turn this on and off with FS running. Go to the FSUIPC Logging page and change the "Debugging Data" field to 0 for normal weather scanning, and back to 16 for no weather stuff at all -- that way you can compare things to your heart's content. TEST #2 Turn the AI aircraft off completely (Air Traffic Density = 0). Do the stutters persist? You can change the amount of time FSUIPC spends on AI aircraft via the parameter "TrafficScanPerFrame" -- set it real low, 1 say for 1% per frame, to see if that has an effect. Okay, let me know please. Also, please can you describe the stutters more precisely, there timing, frequency, persistence? I'm really at a loss to understand what you are seeing. Regards, Pete

That's great news! Well done! I'll certainly have to remember that solution in case it ever comes up again! Thanks for explaining it! Regards, Pete