Pete Dowson

I was puzzled this morning when I couldn't rerad some of the threads, including ones where new messages were awaiting my attention. Apparently there was a problem on SimFlight, as explained in this message from http://www.simflight.com: So, if anyone has a query outstanding, please post as a new thread. Thanks, Pete

There is really nothing in FSUIPC or WideFS that knows or cares what the visibility may be when dealing with data being sent. It sounds very strange indeed. Normally, with limited visibility, FS2000 (especially) runs much faster, so you'd expect better performance, not worse. I really cannot imagine how the GC can be 20-30 seconds behind! Where is all the data for 20-30 seconds worth of flight being stored whilst waiting for the GC to read it? Do you have some sort of switch or hub with a lot of memory doing this? It is hard to imagine, isn't it? You don't say what versions of FSUIPC and WideFS you were using before you upgraded to the latest, but if you were using a very old version of WideFS (before 5.00) then you probably need to delete most of the parameters in trhe WideFS INI files -- there were lots of tweaks using before version 5. You should find Version 6 works best with default parameters in any case. Otherwise, you need to look at the WideFS logs and see what is going on. As I say, I cannot imagine where the data is waiting, it seems absolutely incredible. 20-30 seconds worth of data is a *lot*! Pete

It most certainly is true! You are not reading it correctly. That problem was only with the drop-down lists of controls in the settings dialogue. It was nothing to do with the operation of any of the facilities. The problem was that FSUIPC was getting the wrong address for the list of controls in CONTROLS.DLL, with FS2002 and before only, so that when PFC tried to show the list in its own dialogue it crashed FS. There was never any problem with actual operation, only making or changing button assignments! You don't say what versions of PFC.DLL you are using with each. Do you change back to an old version of PFC.DLL when you do that too? Maybe you forgot, when returning to FSUIPC 3.xx to also re-install PFC version 1.62, the current and only supported version? You cannot use an older (FSUIPC 2.xx) compatible version of PFC.DLL with FSUIPC 3.xx, nor vice versa. Please keep your modules up to date if you want them to work, and me to support them. Please always check the "List of supported versions" on the Support Forum. Thanks. Pete

This is because, as mentioned in the new edition of the Access Registration guide in the new SDK, Visual Basic sign extends your &H8001 and actually sends FFFF8001, not 00008001. Many of those bits are used as flags for special facilities in WideFS, so FSUIPC derives the address 000F8001 from it, which is wrong. I am not a Visual Basic programmer, and it never ceases to surprise me how so many obscure oddities like this lie in wait to trap relatively new programmers who's first choice is often this (to me) awful language, but I have been reliably informed that using &H8001& instead (note the post-pended &) stops the sign extension. An alternative is to use decimal instead, i.e 32769. Pete

I don't think you want to sent such corrections at such close intervals as to run afoul of the acceleration problem. Surely just once or twice per second would certainly be frequent enough? And if you use the AP_PANEL_HEADING_SET control I don't think it gets involved in anycase -- it's only the event triggers that do it, not the value setters (I think, I wouldn't swear to it!) Not sure. Some value in milliseconds, maybe 50-200? Probably relates to typical keyboard repeat rates. Regards, Pete

The => isn't a valid operator, you need >= there. The only other difficulty would be the small window of opportunity to see such a precise value, though as you say increasing the polling should help. If you want the WAV to sound when passing 1.00 in eiither direction you could use two entries with greater reliability and no change in polling: 2=MACH>=1.00,1 3=MACH<=1.00,1 This works because the trigger is the CHANGE in the condition being FALSE to the condition being TRUE, not the actual static value of the condition. However, I would advise some hysteresis be allowed -- i.e. a gap in the change. Otherwise if you maintain "around 1.00" it could be going off all the time as there are minute changes in speed. I would think something like: 2=MACH>0.98,1 3=MACH<1.02,1 Experiment till it works okay. You can refer direct to values in FSUIPC's range of offsets too, which gives you more to choose from, but you'll need the FSUIPC SDK for a list of those. BTW, you say you are using the latest version of Esound, but it would be better to quote the Version number, as most folks' view of "latest version" is the last one they saw or downloaded. There was a bug in versions before 2.56 which would have the effect of not checking named token variables which any recent version of FSUIPC. The current version of Esound is 2.57. (And the current version of FSUIPC is 3.08). Regards, Pete

Can you look at the FSUIPC.LOG file pleaseis it full of repeated reports of a program/gauge trying to access FSUIPC? It maybe that the Dash-8 is checking FSUIPC for access permission at regular intervals. Each time it does this, FSUIPC has to try to identify the program and this will take time -- especially if it is using external application access methods. If the DASH 8 is doing it very frequently it will certainly make a big impact. I'm not sure why cancelling a Register attempt would stop this, so that is interesting, but if there are any log entries please let me see a sample (I don't need the whole log), and I'll try to work out what is happening. Maybe I can fix it in the next version then. Regards, Pete

Sorry, no. I've no idea I'm afraid. I don't this can really be related to anything in FSUIPC and certainly not PFC. The weather things sounds like you have a corrupted install of FS -- I would suggest a re-install to try to fix that. There's nothing much happens in FS when you make that change, it simple enables some other buttons on the same dialogue. My software isn't even running when you are in FS dialogues. The sound related problem may be something to do with sound or video drivers, or that dreaded DX9 again. What was this "magic setting" you changed from '3' to '0' by the way? I'm intrigued! Regards, Pete

[quote name="Jamie Fox Could this be done by writing to (0xC800' date=' 2) and (0xC80C, 2) (in a single _Process()) rather than filling the bits inbetween on the struct?[/quote] Yes, but the other way around -- FSUIPC will need the dynamics value as soon as it seens the command. Same consideration applies to all these things in FSUIPC. Use the the one Process call, so it all gets written at once, but make the activating wrte the last, as that's when it happens. Correct. There are no facilities in FS2004 at all for me to set or change just one aspect of the weather. It all gets written together. If you only want to change one thing you'd need to read everything first copy use the same data, with your changes, when writing. Exactly. Good. Pete

Just send the needed bytes -- the uCommand filed of 2 bytes for CLEAR and ACTIVATE, but enough to include the uDynamics filed for DYNAMICS. Sorry if that is confusing -- the question hadn't arisen before publication! Ah! You win the prize! :lol: I'll change it now I know. Declare your structure and zero it initially (if your compiler doesn't guarantee zero initialisation). Fields which are part of structures won't be "ignored" if they are zero -- zero is taken to mean zero. A zero fraction is .0. Regards, Pete

No, it was a mistake. I hadn't realised that I'd put the original in, earlier. Sorry. I've deleted the older one here. Hopefully folks will see the new one first in any case because of its bigger title, and it is also the one referenced in the "read me". Regards, Pete

Hey, that's a useful tip! I never knew that! Thanks. I'm sending a copy of your message to Enrico -- perhaps it would be a good idea for him to say this on the his "Dowson" page. Regards, Pete

No, as I say in the text, I defaulted the value of InitDelay to 0, instead of 3000 as in previous versions. If the parameter is omitted, which it is usually, then the default value is used. If the value of InitDelay is the default value then it isn't needed in FSUIPC.INI and is removed. You will only see it, and it is only needed, if you want it to be something other than the default. BTW I here reproduce the text from another user (Jonathan Clay) who did some research on Microsoft's database about black screen problems. You might be surprised at how universal they are with DX9. This is from another thread but it is getting lost deep in this Forum, so it will be useful to reprise it: Regards, Pete

Sorry, pretty much none of my programs will run on something as old as Windows 95 now. they depend too much on facilities and fixes added in later versions of Windows. In this case it is probably the lack of Winsock2 which is he problem. You could try keeping your older WideClients on those systems and seeing if the work with the new WideServer, but I don't think it will be very good. Time to update your operating systems, I think. If you don't want to get right up to date with Windows XP I would recommend Windows 98 Second Edition -- do not try Windows Me whatever you do! Regards, Pete

I don't have a site, the Schiratti site is Enrico Schiratti's, not mine. I always recommend his site as it is the most complete and he is almost always first, but I actually distribute all my stuff to around 50 site owners and developers. Most ignore most of it, and some others merely use links to Enrico's page in any case. In the past the usual reason for the problem you've been getting is the caching not on your system, but on your ISP. Apparently many ISP's cache files locally and supply from there. When the filename doesn't change they don't seem to spot that the cache needs replenishing. Their software should be checking the date/time stamps on files too. I don't know of any solution except (a) complaining to your ISP about their bad software, or (b) continue retrying till it gets sorted, or maybe © trying another ISP. Regards, Pete

Yes, as I said many times, the bug is not in FSUIPC, but either in FS or, more likely, looking at all the other games and programs which suffer in the same way, DX9. I hope Microsoft will be able to fix it. All I found was, on my system and on many others, changing the timing of FSUIPC (and also AdvDisplay and PFC.DLL) helped. There's also ViMaCore2004.DLL which did it on my system (I don't know about others), and there may be others. Alternative video drivers also help, sometimes, with some systems. But I think all these little things do is subtly alter the timing here and there. it is almost certainly some clash between some call and an interrupt, or similar. But, sorry, until Microsoft deal with this (I suspect it will have to be by a DX revision) there is no single answer. All I tried to do was help a bit -- sorry it didn't work for you, but I'm glad you found a work-around that you can use. Regards, Pete

Ah, that is very good to hear. Thanks for letting me knoe! Not sure what you mean, but if it is that the visibility is never very good, it may be that the default maximum METAR visibility "10SM" is being set even when it is better than this. To fix this, just go to the Visibility page in the FSUIPC Options and check the "Random extend METAR maxima" option, near top right. Regards, Pete

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