Pete Dowson

URGENT Okay, I've found my PSS Dash 8 (I had it in my archives), and I've installed it inot FS2002. I've not flown it before, and being very used to glass cockpits Boeing style these days, I must admit to having got very confused trying to get the autopilot set up. I note that it does its own thing to some extent, not using the FS one. Fair enough. Now you said this: I've got the Dash 8 cruising now in heading select mode. It acquired the heading I set smoothly and is holding it well. This is with FSUIPC 3.08 (well 3.08 and a bit, actually -- it's the 3.09 I would have been releasing tomorrow and still might if we can resolve this quickly). Now, how do I make it exhibit this alternate banking please? Is there something else I need to set? I really do need to reproduce it to find it, as at present I've no idea whatsoever what could do this, especially with an aircraft which has its own autopilot, which FSUIPC can't even participate in. Perhaps you can get the Dash 8 into such a state on your PC, please, then save a Flight, ZIP it up (with your FSUIPC and PFC.INI files please), and send it to me at petedowson@btconnect.com. I'd be very grateful. This needs resolving, and at present, even with the PSS aircraft here on my PC, I am completely at a loss. Thanks, Pete

No conversion is necessary. The values are 32-bit floating point values, which are supported as standard on all Intel type PCs. They already are latitude, longitude (both in degrees) and altitude (in metres), as described. You should read them into variables declared as float (for C/C++) or whatever the equivalent is in the language you are using. If it is not C/C++ please look up in your programming book to find out about floating point numbers and how to declare them and use them. Regards, Pete

First, if you are still getting that terrible slow down, even with the registered copy of FSUIPC, then my fix for this in 3.09, which I was planning to release tomorrow, won't work. So I need an FSUIPC.LOG of when this is occurring, including the part, some time into it please, where pressing "register" and cancelling out appears to fix it. If you could enable IPC read and write logging first it may also help. I also need to know which actual "Register" button you press. Second, I will need to be able to reproduce that odd Dash 8 a/p behaviour to see what is going on. I don't think a log will help there, but I could do with seeing both your FSUIPC.INI and your PFC.INI files please. You can ZIP and post everything to petedowson@btconnect.com. Thanks. Why do they tell you and not me? :? Regards, Pete

The NWI, like the AWI and the old FS98 weather interfaces are all covered in the FSUIPC SDK. So, it looks like a graphics thing then. Well done, and thanks for posting the solution. Regards, Pete

How can you disagree with a statement that says that a registered 3.xx SHOULD work as 2.9xx did in FS2002? That was/is my aim, it is up to me to say whether it SHOULD work or not, isn't it? How can you disagree with that? :cry: This has been reported already, and is fixed in FSUIPC 3.09 (released tomorrow), but it should only apply to an UNREGISTERED copy of FSUIPC. The problem is entirely due to the continuous retry attempts being made by part of the PSS panel to obtain data which it cannot from an unregistered copy. If you still get such a problem with a registered copy, please send me the FSUIPC Log file. Yes, and I wrote back, the same day or the next, that I had found the reason and am fixing it in the next release, which is imminent. Okay. this is a problem that most certainly has not been reported before. And it needs to be looked at and fixed, for sure. If you don't report it and simply backtrack to a year old version of FSUIPC instead, then how on Earth can it ever be fixed? If everyone did that I might as well close up shop and stop right now! This is why I asked you for details! Version 3.xx should NOT make such a difference. In fact it should not be getting anywhere near any autopilot by itself. But you said you had to use 2.95, which is much older, from last year in fact?! I'm getting confused now. :? Oh, dear. When you changed to version 3.xx of FSUIPC, did you also change to the latest version of PFC.DLL? If not, that is almost certainly the reason. I updated all my modules together in that period, and they are very interdependent! If you are going to swap back and forth please remember to do so with PFC and FSUIPC drivers together. Let me know please. I really do need reports and details of problems if there are problems. Merely saying "this only works with 2.9 blah blah" and not allowing things to be checked out and fixed is really very upsetting for me. :cry: Pete

[quote name="DavidSolinger I have been able to read from 0BB2 and also to write to certain other variables' date=' but a write to 0BB2 does not seem to affect something. [/quote] It and the other control surfaces are certainly working okay for writes. Possibly you had the FS autopilot engaged, or did not diconnect the joystick input as mentioned, so it was overridden? In FS2000 and before these locations actually affected FS directly. Since FS2002 it is FSUIPC which sees the writes and converts them to control inputs using standard FS controls. Regards, Pete

FSInterrogate isn't the best reference. The fsi needs a bit of an overhaul. I maintain the Programmer's Guide tables with all the information I have, but the FSI is too much work :( . The document itself should be your first reference. But I don't know of any distance travelled value. Maybe the new GPS provides such information? It would have to be a GPS function if anything -- there are no traditional instruments which could measure that as far as I know. Regards, Pete

With a registered version 3 .xx there should be no difference whatsoever between it and 2.95 (which is from last year!) as far as FS2002 and your aircraft are concerned! Going back to an older version (expecially 6 or 7 versions before 3.00!) helps no one. Can you please identify exactly what the problem is so it can be investigated? Who tells you to use version 2.95 and why? Regards, Pete

Oh, that's a shame. I've no idea what the problem is in that case. How strange. Hmm. I'll get to it in a few days. Regards, Pete

Ahin that case it will be the weather I should think. Are you sure its the "scenery" reloading? Does the message box come up with a progress bar, or are you just seeing a hesitation and clouds redrawing? Does it happen in clear weather? If it is the clouds, try setting the cloud sliders (Options-Settings-Display-Weather) full right, especially the 3D one which should be at 100% If the SIMWX is resetting the weather every 30-60 seconds then it might need revising to use more subtle ways of injecting the weather. The engine in FS2004 is very different from previous releases. Perhaps the author might want to take a look at the "New Weather Interface" I devised for FS2004, which allows much more sophisticated localised control of the weather. The old "one world one weather" methods used in FS2002 and before don't seem to be very good with FS2004. Regards, Pete

I just had a quick look. I spotted what might be the reason for the problem, assuming it was me messing it up making it work properly on FS2004. I've really not got time to set it up on FS2002 and test it here, so I attach it (Esound 2.571). Can you please try it and let me know? If it is okay, I'll release it properly. If not it'll have to wait a week or so. Okay? Thanks, Pete esound2571.zip

Yes, I realise that -- it was a problem which I thought I'd fixed. Ah, yes. Now you mention it, the previous person reporting this was using FS2004. I don't think I re-tested on FS2002. Maybe the fix I made for FS2004 actually mucked it up for FS2002. I'll put it on my list to take a look. It may not be for a few days though. Sorry. Pete

Sorry, there is no way I know to force scenery reloads. I suspect you may well get texture reloads though -- if you change the time, or simulation rate. Moving in slew mode may well do the same, I don't know. It seems like experimentation is in order. With FS2004 it is actually possibly to set the aircraft position and so on in flight mode as well as in slew mode. That wasn't possible in previous versions -- except by pausing first, or setting a Sim Rate of 0. I think you will need to experiment with different ways of controlling FS2004 -- it probably isn't the same as FS2002, for which I expect the PS13 program was written? There's nothing in FSUIPC which will help by itself -- in this case it is being used purely as an interface into FS, it doesn't control this stuff. If you aren't the programmer of the interface then I suggest you get in touch with him and see if there's any work likely to be carried out to make it work well with FS2004. I think Luciano Napolitano may also be interested, as his WidevieW will presumably need the same solutions. Regards, Pete

Both AWI and NWI are documented in the latest FSUIPC SDK, but remember the NWI is only applicable to FS2004. It covers local and global weather. The AWI is applicable to FS2000-FS2004 but only deals with Global weather, and it is a command+data based system not memory-mapped, so it isn't so easy to program. It's been documented in the SDK for three or four years now! There are clear Weather commands available in both the AWI and NWI. For FS98 type weather commands FSUIPC tries to clear the weather as soon as the first such command arrives. However, typically when the weather you ask for doesn't become visible it seems to be down to it not clearing properly first, which is why I suggested clearing it manually. Also, the automatic clearing by FSUIPC is, in fact, an option -- it is defaulted on, but possibly it is turned off in your FSUIPC.INI? This is why I suggested trying it manually. Regards, Pete

Ah, you are using the FS98 interface. In that case FSUIPC should clear the weather for you when you start. You can check that in the FSUIPC Log. However, using the FS98 interface you must always set lower layers before upper. You should not try to set the Upper Cloud layer before setting a Lower one. If there's only one then it is "Lower" --- unless it is a thunderstorm, in which case you set that layer fiorst. In FS98 you could have three layers only provided the lowest was a thunderstorm. FS2000-FS2004 are not saddled with these restrictions, but the FS98 interface you are using was designed to maintain compatibility with FS98. Since FS2000 I provided the AWI (Advanced Weather Interface) which allows better advantage to be taken of the improved weather facilities in those versions. For FS2004 there's also now the NWI (New Weather Interface) which is more powerful and also allows local weather reading and setting. I don't expect this explains why you don't see the clouds, but just in case, before you run your program, clear all the weather (you can assign a hot key for this in FSUIPC's Hot Keys page). Do it twice to be sure -- the first time FSUIPC re-instates any previous FS98/AWI weather. Regards, Pete

I did provide a lengthy reply to this -- two in fact, one promising to check it and the second publishing the results. Both got lost along with the thread when SimFlight had to restore the database. I found that the repeat doesn't work at all for me, except on PFC buttons. I think this got screwed up some time ago, so I'm surprised you even found it repeating for 1 second (I can't even make it do that!). Anyway, I have fixed it here and it will be okay in the next version of FSUIPC (3.09) which I would expect to be released either this weekend or some time next week. Apologies for the inconvenience! Regards, Pete

That's the latest version of Esound, and I think it may need FSUIPC 3. Try 3.08. I update all my modules and try to maintain compatibility between them as I go, but I don't backdate them and don't re-test with old unsupported versions, only the current listed ones. Sorry. Regards, Pete

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