Pete Dowson

Sorry, I've no idea whether the FSUIPC acceleration fix is relevant to this or not, because I don't know what it is doing. You'll need advice from an existing user I think. Regards, Pete

FSUIPC doesn't really control any joystick inputs whatsoever. it merely operates like a filter on the final values INSIDE FF -- before that they've been calibrated by Windows and mucked about by FS. Erratic turns whilst taxying could be due to asymmetric thrust, poorly calibrated toe brakes (are they sticking on?), or just winds. Just press "reset" on all the "set" buttons in FSUIPC's Joystick pages and FSUIPC won't touch any of them. Get them working correctly in Windows and FS. Apply only finishing touches with FSUIPC if still needed. Regards, Pete

Sorry, I've no idea. I have nothing really to do with that side of things. You need to contact them. Regards, Pete

I'd love to be able to do that, but haven't found a way yet. Sorry. Pete

Yes, indeed, they both sound useful. Can you provide links to where they may be found, please? Thanks & Regards, Pete

No. It means that either you haven't entered the correct registration code or the name of the program or other details are incorrect. This is the entry from the Freeware Keys list: SquawkBox.exe Product: "SquawkBox 2.3", Company: "None" KEY = LWVQ 7I2V 9GPB But this is what FSUIPC is seeing Windows report as the pathname for your Squawkbox: 100281 Client Application: "SQUAWK~1" (Id=2568) 100281 C:\PROGRA~1\SQUAWK~1\SQUAWK~1.EXE That's the reason! "SQUAWK~1" is not the same as "SquawkBox"! I think this must be something to do with how you've installed the Squawkbox program. It looks like it is being reported with DOS-type shortened 8-character names. I've not seen those since Windows 95 days and before. Programs in all supported versions of Windows should be reported using their proper full path names and filenames. Try downloading the SB ZIP again, creating a folder in C: called just "SB" or similar, and placing the files in there. If SB comes with its own installer, then, sorry, you need to ask whoever is supplying it as it is then the installer which is somehow doing this. BTW you don't need to enter registration Keys more than once, unless you get them wrong, as they are saved in the FSUIPC.KEY file. You can check in there yourself. The program registrations are listed in the [Programs] section. Regards, Pete

No, no, it's easy enough. :wink: Regards, Pete

Why not use FSUIPC? FS2004 is all a mass of C++ classes and derived classes, with private data allocated from the heap containing this stuff. It isn't in any global memory in modules, and the memory is released and reallocated every time you load a new aircraft or flight. If you want to locate things like this you'll need to disassemble SIM1.DLL, find the routines which supply the "this" pointers for the appropriate aircraft Classes, then try to follow the pointers to the correct data. There's a LOT of code involved and it gets very *very* complicated, especially trying to keep it up to date as it moves. I use a mixture of C and ASM code and have to do some weird tricks to make it work. Good luck! Regards, Pete

I'm doing it by having an optional and adjustable delay after weather is cleared, however that may be done. Yours is the first ever such complaint I've received in the near five years the visibility smoothing has been provided! :cry: Regards, Pete

Sorry, FSNavigator is an FS module and only runs in FS. It is not an FSUIPC client program (it doesn't even use FSUIPC), nor can it, as an FS DLL, be run as an external program. If you want something similar to run on a client PC look for Ted Wright's freeware "NAV" program. Regards, Pete

It looks like it. Under test at present, hopefully for a release later next week. Regards, Pete

It's a totally different level, the one knows nothing about the other. The same will apply to the wind smoothing which should be working on all weather sources in the next FSUIPC version, soon. I'm not sure there's any one thing I could pick on to say "right, let the visibility jump direct to this new value, now". Maybe after a "clear all weather" call, assuming AS makes one. But it would still be complicated -- AS like FSMeteo will not be setting one weather, one visibility, which I can call the target. It sets all the METAR stations around, and this could take minutes in any case. How does FSUIPC know when to "kick in" the smoothing? The only thing I can think of it to stop smoothing on a "clear all weather" action, and not starting again for several minutes. Is that what you were thinking? Trouble is then, I'd be getting complaints from some folks saying the smoothing didn't work. If I worked out a way to do it, I'd have to make it optional and possibly have the delay set as a parameter in the INI file. BTW 10% over 30 seconds is a bit extreme, isn't it? Anyway, if you start AS off before you do your flight prep and so on it should still be okay by the time you're ready. No? Regards, Pete

I don't know SB, so I don't realy know the answer. But if it is playing a chime sound, then that will almost certainly only sound on the Client -- it would need something programmed for it on the Server otherwise, as FSUIPC doesn't offer any sound playing facilities. If you are missing the sound itself then you probably need the sound turned up on the client. (If using voice ATC of course you'd want your headset connected to that PC in any case). If it is a displayed message, then it depends how it is displaying it. If it is using its own window someplace, then that would presumably be on the Client. If it uses the FSUIPC facility to access the FS message window then it can appear either on the PC outside view, or wherever you like, via AdvDisplay and optionally ShowText. Not knowing what the chime alert truly is I can't really help further, but possibly other SB users may be able to comment here. Regards, Pete

No, that is not true. If you want to use WideFS you have to register it, but you do not need to register FSUIPC unless you want to use it's optional features. WideFS will run all FSUIPC client programs on the clients even if they are not accredited to run direct to FSUIPC on the Server. That second part is correct. If you do want to register both you make a saving but only if you purchase them at the same time. Regards, Pete

The defaults should be okay. There aren't any you can change which would affect CPU usage -- mostly they control things like whether the client sleeps a bit before returning control to the client application -- this is designed to prevent the applications hogging the processor, and in effect gives processor time away. But even setting that specific timeout to zero (so there are no such sleeps) should only mean the application is getting more time, not WideClient. When there's no application running Wideclient will be idling, just waking up to receive frames from the Server and, on timer calls, to send one to show it is still there. Certainly, though, you are right that I ought to have checked the INI files he is using -- I suppose I assumed he would leave them to default. Regards, Pete

I don't think Jose visits here often these days -- he replied earlier because I sent him a note. You might want to try contacying him via the "email" button on his message. Regards, Pete

Actually you are multiplying by 65536, but yes, the result would be the same if you did the computation AFTER casting it to a "short". Do all the computation first -- the bit of code I showed was supposed to be as it was, no intervening changes :wink: Regards, Pete

No, sorry. The last version of FS for which I managed to split the sounds was FS98. It was because I couldn't make it do that in FS2000, 2002 (and now 2004) that I dropped it, as for me that was it's main purpose - though in those days the ATC was only from Adventures. These days I use Radar Contact running on a separate PC via WideFS. Regards, Pete

This is because double heading; defines a double floating point value, 8 bytes in length, whereas: FSUIPC_Write(0x07CC, 2, &heading, &dwResult); is trying to write this to a 16-bit (two byte) "short". All you are succeeding in doing is writing the lowest 2 bytes of the 8 byte double, which will be pretty meaningless. You need to copy the double floating point heading to a fixed point short integer first, like this: short sHdg = (short) (heading + 0.5); FSUIPC_Write(0x07CC, 2, &sHdg, &dwResult); I've added 0.5 to round the value, for a little more accuracy :wink: Regards, Pete

Ah, right. In that case something is very much amiss. Well if it is only happening when Wideclient is running, then it must be the network, but it doesn't appear to be coming through to WideClient in any sort of failure report. Mind you, with less than 4 seconds of operation and apparently no application running, Wideclient wouldn't have had anything much to do in any case. When you actually run a WideClient application does that run normally or slow? Are there any errors in the Log then? Don't just look at the Client log -- there may be problems reported at the Server end. I really don't know what else to suggest. If you are using a Network card, try swapping it, or try uninstalling it and reinstalling it. See if there are later drivers, and so on. With no actual errors I can't understand what is holding things up, and as you say the same Network card and drivers operate okay when it is playing the part of the Server instead. Most odd. I think you may need to find a Network expert for this if you can't track it down yourself. Try Katy Pluta ober in the FS2004 Forum. She's been able to help me several times. Regards, Pete

What do you mean by "needs"? For instance, depending on PC type and some other things, FS "needs" 100% of PC cycles. I think "uses" is a better word than "needs" -- it soaks up idle time. You can only determine whether it "needs" those by seeing if other things run as well without it stopping or slowing significantly. Apart from calls from applications, WideClient also works off calls to it from Winsock (the network part of Windows), plus a 'watchdog' timer (WM_TIMER) message to keep track of responses. Between them these determine how much time it uses. Quite honestly I cannot understand why you are looking at CPU usage in any case. What is the actual problem you are trying to resolve? CPU usage is not a problem in itself -- it may help determine what is going on when there is a problem, but should otherwise be completely ignored. No, there's nothing shown wrong there -- it often happens that WideFS takes two tries to connect, as here, because of initial setup exchanges. That is nothing to worry about and only occurs in the first few seconds. It was perfectly connected at 20179 (20 seconds after loading), but then for some strange reason you closed it down almost immediately (23744, less than 4 seconds later), before anything but its own protocol data checks had been exchanged. Why bother to load it if you aren't using it? After loading WideClient try running your application program. Regards, Pete

Oh, I see. Even when you change aircraft not simply re-select the same one? There's also an FS control "reload user aircraft" or something like that. Doesn't that reload the textures either? No. But if you want to see what it is loading and unloading during startup you can see that, live, using "DebugView" from http://www.systeminternals.com. That utility will also show FSUIPC's logging, live, if you add "Debug=Please" to the [General] section of FSUIPC.INI, but you shouldn't do this normally as it invokes extra code in FSUIPC and therefore can impair performance (though this may not be measurable). BTW, I get a difference similar to your 48 seconds and 10 seconds, but not with FSUIPC installed or not. The first load takes about 40 seconds or so but all subsequent ones on the same PC takes 10 or less. This is with a 1 Gbyte memory. I don't have any PCs left with only 512Mb -- that was fine for FS2002 but I think WinXP + FS2004 really do need more. The "sweet spot" is more like 768Mb now, more with more things running. I'm still wondering if the difference on your system between FSUIPC installed or not is that -- the memory is spilling into virtual memory (and therefore swap disk space). There are ways to speed up virtual memory, like having fixed and equal top and bottom limits and making sure the disk is defragmented before Windows creates the resulting file, and so on. But in the end it is really best to avoid the need to swap out to disk. I suppose the memory chip prices have risen again now, but I took adbantage of the plummet inprices not long ago to upgrade all my PCs to 1 Gb minimum. You could try using something like EndItAll to kill all other unnecessary processes off before loading FS. If this helps then it is definitely lookingl ike memory. Regards, Pete

Hmmm, don't remember off-hand (this part is about 5 years old now), but I think it is pretty linear. Pete

No, sorry. All of its parameters are in the FSUIPC.INI file. Just delete that if you want it to start afresh. BTW I am sorry, I realy don't know what you've got going there, but I am a little astonished at how desperate you sound about it. How often are you starting FS each day? If you were loading it and closing it continuously it would make sense, is this what you are doing? Regards, Pete

Oh, good -- I shall annotate them appropriately in the documentation! Thanks, Pete