Pete Dowson

What sort of macro do you think "FA_IFLY737" is? There's nothng there to tell FSUIPC whether it's a KeyPress, a Control, a mouse macro or a Lua plug-in to be run. If you want to run a Lua program you have to give the command: 1=Lua FA_IFLY737 Didn't you check the format or look at any examples first? Regards Pete

There are three priorities WideClient uses for its three threads (receiving, sending and processing application requests and responses) -- please look up the "Priority" parameter in the WideFS Technical document. By default the reception is set at mid-prioriy (#2), below transmission (#1). That has always seemed to work best, but you could try swapping those two, or making them both high. Pete

Norton appears to be a **** nuisance -- another userreported totally different behaviour -- only NAV seems to have the problem. Sorry, but I use AVG and it says it's fine. Please see the existing thread in which I explain why it's a false positive: http://forum.simflig...rus-and-3999z2/ You'll see they reported that it was only the Installation file in any case. Pete

Actually they are all trivial compared to the CWP. But maybe it isn't the demands on WideClient that gives the problem. maybe something is preventing WideClient getting enough processor time, or at least it's Ethernet transmission thread. Possibly a bad video driver or one with bad settings? One thing you could to it try running the programs manually, one at a time, leaving the system running long enough in between to be sure it is running well. Maybe you'll find the culprit that way -- always assuming, of course, that it really isn't a LAN or LAN driver problem. Did you try UDP yet? That would be my first test. I use a netwrok of 8 PCs on my cockpit, all using UDP. Pete

Use your FSUIPC3 key for FSUIPC3. If you have it registered already you don't need to register again, just click "Cancel" when the installer asks you. (It does tell you this in the Installation guide in the ZIP). Unless you've moved things around manually, the installers will locate them correctly from the Registry entries. I you've moved them you wouuld need to tell the installer where to find the FS "EXE" files, as that tells it both the version and the location. it will be obvious when you run the installers. Pete

Of course not, because being momentary, The Press is immediately followed by a Release! So it sets 1 for on then 0 for off immediately. I wrote the documentation to explain these things. Have you looked? I don't mind helping you understand what is written, but it seems to me you have not even bothered to look? Please check the section "Compound button conditions" in the Advanced User's Guide (indexed in the contents as "compound button controls"). Take a look, THEN come back. So far I seem to have been wasting my time pointing you to the answers. I don't think it is correct for me to solve all folks' problems, because that way I have to do it all of the time. It is much better if folks learn to do it, then they can do it again, and so on. This is why there is documentation and not only a place where I can do all the work again and again. Do you see? I'll help, but you must try a bit, please. Pete

No, you MUST use the email you originally purchased the KEY with. The KEY is inextricably related to your name and email, exactly as stated. That can not be changed and never needs to be changed. Pete

If one of the PMDG controls does not work I'm afraid it is PMDG you need to report this to. To change the action of a momentary button into a toggle you only need to make the button's "press" action dependent upon its own flag. So it is two "P" lines in the INI, one with condition flag set and the the other with cofdition flag not set. The button's own flag switches on or off with each press. Check the examples in the manual. What part do you not understand? Regards Pete

The only files you should backup are you registration file (the FSUIPC KEY file) and your settings (the FSUIPC INI file). The rest are reinstallable -- though if you've made your own Macro or Lua plug-in flies you should vback those up too. No, all of FSUIPC-related files are in the one place, the Modules folder in FS. Pete

It looks like the PC you running all this on, and/or the Network link, is simply not up to the task. WideClient is simply not getting to run often enough. Look at all the things presumably soaking it with demands: I've never seen anything like that! You have first 8 then 9 different applications presumably all trying to send their own stuff. Withing 40 seconds that was enough for the backlog of requests waiting to be sent to amount to 100. But the main "culprit" is identified here, the very first application loaded, before you closed down and restarted: 156 New Client Application: "Jet45_CWP_Driver" (Id=2252) ... 1709006 Client 2252 requests: 489131 (Ave 338/sec), Data: 97489176 bytes (67513/sec), Average 199 bytes/Process 97 megabytes at 67513 per second!? That's 540 kbps all on its own, and with the TCP redtape it's a lot more. Either the PC itself can't cope, or the speed of your Ethernet connection isn't up to it. The queuing appears to be all at the Client end, otherwise I'd suspect that your FS was overloaded instead. Is perhaps the main load on the client PC doing screen graphics? That can be a problem as things can get held up. Is it a built-in motherboard video card or a good fast add-in one? Try Protocol=UDP, which is the protocol used by Windows explorer and most other programs. it is more efficient but also less likely to recover erroneous bloakc, so if things are really wrong it will lose data before it clogs up. Aslo see if any of those programs you are running can be regulated better, especially JET45_CWP. Please also check with the support folks for the programs you are using. They may be able to give specific advice on using their programs. They may well be designed for use on separate PCs, not all on one client. Pete

The installation file is a packed and encrypted conglomerate of the FSUIPC program itself and all of the documentation and Lua files, as well as the installer program itself. There is no identifiable code in it until it is run other that the same unpacker as included in the installed FSUIPC. Therefore it is a false identification .You simply need to tell Norton so they can extend the number of bytes they actually check for that virus. The trouble is they cast such a wide net by using as few recognition bytes as they think they can get away with. When confronted with semi-random data they make false identifications. Pete

Ah, sorry. i just click on messages marked as not yet read. I always tend to expect them to contain the subject. My shortcoming. Pete

I have never heard of hasving two completely separate networks which cannot talk to each other yet are using the same computers! That's truly a first for me. Why would you set it up like that? Just to have everything wireless or everything wired, no one knowing about the other? No wonder things get confused. I'm amazed that it (almost) works! If you want a simple life I would change your wireless network to use IP addresses in the same subnet, i.e. 192.168.0.xxx. Regards Pete

You don't say which package, but both the FSUIPC3 and FSUIPC4 packages check out here, and my whole PC checks out with no viruses. it is going to be a false alarm. The binaries are encrypted to ensure they can have code viruses attached and are only de-scrypted when run, so the base encrypted versions look nothing like the real code. Regards Pete

Did you register before, if so why again? You never need to register again except on another PC. If this is the first time, then you are making a mistake. -- all three parts must be correct. Use cut-and-paste, as advised, if you aren't sure. Pete

Well, you said that already, but you didn't say whether you were writing your own driver program to interface to FSUIPC! That's what I asked. So, you are using FSUIPC assignments, not writing your own program. We discover that now. And here 70004 isn't an Offset, but a Control number. You said you were programming with FSUIPC OFFSET! No, you are assigning to a control! No offset is involved! The FSUIPC Offset byte togglebits control is a control you can assign in the dropdown list. But for that you need an offset! If you are only using controls you need to use conditional (compound) control assignments, as documented in the FSUIPC advanced users manual. You can easily use the button's own flag as the condition to make the button act like a toggle switch. Please do read up on this and ask questions afterwards if you still don't understand. Pete

Sorry, but those two addresses can never belong to the same LAN. I really don't know what you are up to. I said DO NOT DO ANYTHING IN THE SERVER INI!!! In that case you got it wrong! The protocol undecided can only occur if you let the Client find the Server automatically. Yes, it means there are over 250 frames queued waiting to be sent over the network which is obviously just not accepting any of them! It does actually say that. Pete

Just the default FSX 738 but with the figures adjusted to make the performance more exactly like the real thing. Pete

Do NOT make any changes to the Server INI! It knows where it is. Only the Client needs to know where it is!!! Also, in your earlier log the Server's IP address was 4368 ... Okay, IP Address = 10.0.0.18 Now you are trying to use ServerIPAddr=192.168.0.1 Those two cannot even be in the same Netwrok! LAN IP addresses abide by a Network Mask, almost always 255.255.255.0, which means that the first 3 parts must be the same throught the network! Additionally, if you specify the ServerIPaddr you must also specify the Protocol. i told you that! :-( Pete

You did not post any INI. The INI file is the file containing settings, like the IP address and protocol parameters I mentioned. You posted the WideServer.LOG file most recently, but the more informative original post had both the server and client log fies. They are named accordingly, not all "wideclient.ini" as you seem to refer to them as. Please don't confuse matters by using both wrong filenames and wrong file types. Errors detected at one end of a connection won't necessarily also be detected at the other end! The two directions have different frames going in different directions! They are not the same frame received by both! That would make no sense! Think of a telphone connection. How often do you get bad reception whilst the other guy says he can hear you perfectly? In any case the WideClient log you showed certainly had severe errors blocking the connection badly at one point: What do you think these are? 1453821 WARNING! Send() request depth is over 100! 1456426 ERROR!! Send() request depth is over 250! Queue flushed! 1460357 WARNING! Send() request depth is over 100! Pete

How are you programming -- with an actual program, or using FSUIPC assignments to "Offset" controls? Why not simply use the Offset togglebits control, with value 1. Then it will alternately set and clear the 1. Again, there's the Offset inc and dec controls. What is wrong with using those? Pete

Sumcheck errors can only possibly occur if there's a [rpb;e on your Network. TCP is supposed to guarantee the frames, so a block arriving in error means either a hardware or driver problem. I've only ever seen them when my LAN adapaterwas faulty -- replacing it fixed it. If it's a motherboard LAN then that's more problematic, maybe disabling it and installing a working one. That's even more indicative of a real problem -- it's the once-per-second broadcast (IP=255.255.255.255 means broadcast) so that other clients can detect the server. I'd strongly suspect the LAN hardware or driver on your main FS PC. Pete

Best never to use Wifi for what you need to be an almost continuous flow of data in both directions. Also, it would be much more efficient to use the UDP protocol instead of TCP. It is more prone to lost blocks, however. Set the correct (non-WiFi) IP address explicitly in the WideClient.INI, and also set the protocol (whether TCP ot UDP). Regards Pete

There is no difference in the way FSUIPC handles the spoiler axis from any other. But you should always calibrate it when in the air, because when on the ground FS tends to activate the 100% apeed brake setting whenever the axis passes through the ARMed value. If you have an axis misbehaving oddly the most usual explanation is that you have conflicting assignments, possibly both in FS and FSUIPC. The INI file contains all of your FSUIPC settings and selections, so, yes, if you don't want to use FSUIPC at all, delete the INI and it will use default settings. But I don't know how or why that is said to have anything at all to do with NGX flaps. If the aircraft panel itself, in FS, shows the correct flap setting, then obviously your misbehaving aircraft is not doing so because of flaps but something else entirely. I'm afraid you need to look elsewhere. Seems you've changed something, then, or installed something else which is affecting things. Are you sure it isn't all because you have assignments in both FS and FSUIPC, conflicting with each other? Pete

The Macallan was always my favourite, but I don't touch spirits these days! ;-) Pete