Pete Dowson

Have you talked to the Project Magenta autohr, Enrico Schiratti about this? As I suggested, I think you may find a lot of thought and work has already gone into looking at interfacing PM to other sims. Enrico publishes the complete FSUIPC offset list for Project Magenta on his website. That's a procedural interface. There are really no direct procedural interfaces here. Please look at the FSUIPC SDK. It is all data based. Regards, Pete

I don't know. Sorry. I would have tried exactly the way you have. Did you put the alternative CFG file in the same place as the normal FS9.CFG file? If not then do that. Otherwise, I wonder if they haven't changed that bit of code and it still looks in the main FS folder for the CFG: named file? Or maybe a pathname in that parameter would help? I can really do no more than you, and that is to experiment with the assorted possibilities. Please let us know what you find! Regards, Pete

Scenery file? What scenery file? Sorry, can you clarify your question some what. i don't understand. Pete

That will make FS start up in Windowed mode instead of full screen mode. The most noticeable difference between a maximised window and "full screen" is that you don't get a Title Bar in the latter mode. You switch between the two modes by ALT + ENTER. Evidently MS thought you had some sort of video driver problem, or possibly that the video section in the CFG file was corrupted. Yes, please. They seem unique at present. Very odd. Good luck! Pete

Sorry, then I have less idea about what to say. If your previous versions were WideFS 6.02 and FSUIPC 3.07 then, as there've been no Network changes between those, it would point to a hardware problem. When did you last actually INSTALL WideFS and FSUIPC, before this "upgrade"? I need some idea of what you used when you managed to make it work. Quite honestly, with your mix of PCs and operating systems I am surprised you ever got IPX/SPX to work! It is likely that is the reason -- 50 fps is too much for your 500 MHz PC -- WideServer is trying to send too much data and it is blocking. The GC will stop, NOT delay, and it will reconnect. If there is a 30 second delay you must have some big buffers somewhere. From your log it looks like it will stop, and start, then stop, and so on. Where's the Client INI file? I think all that is happening is that at frame rates like 50 there is either not enough power on your PC to push all that data out to 6 clients 50 times per second (that's 300 blocks per second), or maybe there is not enough capacity on the Network. Unlike old versions of WideFS, which simply maintained a steady, but slow, pace, this new one is designed to maintain the same frame rates on your clients as on your main FS PC. By synchronizing instrument updates with the FS frames the best smoothness is possible. With FS2002 and FS2004 there's a "frame rate limiter" in the Options, and for WideFS users that is set to, say, 20 or 30 or similar, whatever is okay both on that PC and all the clients. I think you should be using TCP/IP in any case, as on a mixed operating system setup like yours I didn't even think IPX/SPX was viable. I could never get it to work properly here. TCP/IP is easier -- a bit slower, but the last thing you seem to need is speed! -- and smoother. If you have a 10mbps network, change to 100mbps. If you are using a Hub try a Switch. But mainly you probably need to slow WideFS down. Without a frame limiter in FS2000 it isn't so easy. Experiment with WideServer's "AutoUpdateTime" parameter -- the default of 13 milliseconds is too small for you (up to 80 fps). Try 100 first (that may make things jerky in the clients as it allows only 10 fps), then reduce it, in 10's say, till you get those problems again, then put it up again. You should be able to find a value which works -- probably around 40 or 50. Please check the WideFS documentation on this parameter. You may want to reduce the maximum block size too, but don't do both at the same time! There's a facility in WideClient to show the client frame rate in the title bar. If you enable that (temporarily) then you should see, with your current set up, WideFS trying to match FS's frame rate. I don't know what Client PCs you have, but maybe the frame rate is too high for them as well as the Network? WideFS also logs the frame rates at the end of the Logs, when you close down. Regards, Pete

There's really no way it can run 20-30 seconds behind FShow can the data take so long to go through the wires? Where is it being stored? That makes no sense. The log shows many errors, really horrible. You are trying to use IPX/SPX on a mixture of Win98SE, WinXP and Win2000 PCs. I don't know anyone who has been successful with that. As I say in the WideFS documentation, if you want to stick to IPX/SPX then it is best to make it Win98SE all round. Otherwise, I think it would really be better to remove all protocols from your whole Network except TCP/IP and use only that. Also, what sort of Network is it? 10 or 100 mbps? Do you use a switch or hub? If it is a slow 10mbps then it is likely that all the recent versions of WideFS are too fast for it. They try to equal the FS frame rate. Regards, Pete

Not really heard of such problems in FS2002 (plenty of "interesting" complications like that in FS2004), but you do need to make sure that local weather settings are clear first. How are you "injecting" these clouds? Do you clear all weather first? I think that is important. The only times we ever got discrepancies in FS2002 was when starting with localised weather already. Regards, Pete

Not just the server log, but also the WideClient logs! AND which versions you were using "before", please. BTW did I misunderstand your last message? It occurred to me that, rather than saying that your GC was running 20-30 seconds behind FS, you might simply have meant that it STOPPED responding for 20-30 seconds, then continued but then back in time? I really would be amazed and baffled if it was constantly running 20-30 seconds late, as where could all the data be stored? Well, if it looks like it might be large it would be best to ZIP it and attach it. Incidentally, I no longer had FS2000 installed, but as I had plenty of room on my hard disk I just installed FS2000 Pro on the same PC as my FS2002 and FS2004 (a P4 3.2GHz). I copied over all my added FS modules, including FSUIPC 3.08, WideServer 6.10 and PFC 1.62, and all their INI files and so on. Flying around Meigs with everything on full and at 1920 x 480 x 32 resolution, I get 66 fps everywhere! Moreover, WideClients on three other PCs are getting the same frame rates and the PM GC is as smooth as silk! I tried putting on loads of clouds, and reducing the visibilty severely, and this had no adverse effect whatsoever. So it is looking like a network configuration problem you have. As well as the logs you'd better show me the Server and Client INI files too, please, and tell me what hardware you are using -- processor speed, mainly. Thanks, Pete

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