Pete Dowson

FS doesn't simulate that switch. Regards, Pete

Ah .. you certainly do have a Networking problem, then. Sorry, in your shoes I would be trying things one at a time, with the most difficult (e.g. re-installing Windows and everything else) last. You need to undertake a process of elimination. Okay, good luck! Please keep us informed. It may help others. Regards, Pete

Actually, you are close. I don't know why no-one spotted it before, but the locations 05B0 to 05D3 inclusive (36 bytes) are LLAPBH (Latitude, Longitude, Altitude, Pitch, Bank, Heading) for the viewpoint. using exactly the same format and units as the LLAPBH for the aircraft (see offsets 0560 to 0583, 36 bytes). Thanks! I'll document that properly in the Guide and add them to the FSI file for FSInterrogator. Good find! Those are now explained by being parts of the values in the complete LLAPBH structure. Regards, Pete

Whilst there's nothing wrong with "converting" data from arrays of bytes into DWORDs or vice versa, it is not usually necessary. Why not just send them as DWORDs in the first place? I assume this is some sort of command header --for FSUIPC_Read? Is your other, non-Windows, PC using a 68000 processor or some other one which stores numbers with the high byte first (HI-LO) instead of last, like Intel (LO-HI)? If not, why not simply send the data as a sequence, or structure: BYTE command; // 0xF0 for Read? DWORD offset; DWORD size; Even if you can't do that in the other PC, if the order is LO-HI (not HI-LO as implied in your code) you can refer to the 4 bytes at buffer[1] as a DWORD simply by casting, thus: *((DWORD *) &buffer[1]) This is the actual offset value, assuming of course that the offset is in standard Intel Lo-Hi order. (Otherwise you do, indeed, have to reverse the bytes in the way you are doing). Same for the size of course. You are reading the data into a local array (x) then copying into this "buffer". Two questions. One, why not read directly into the buffer? Two, how do you know it (the buffer) is big enough? I think, for safety in case of data corruption somewhere, you ought to put a cap on the maximum size in any case. FSUIPC and its library certainly has a limit (about 30000) but that would be far bigger that you are ever likely to need in any case. Anyway, the above are only comments and suggestions on the programming, not the interface to FSUIPC, which looks okay. However, this is only for one read at one offset. Assuming you'd normally want to read more than one thing at a time, you really need to separate the FSUIPC_Process call. You'd need to loop around doing FSUIPC_Reads for each offset/size pair, THEN do one Process call. This is even more reason why you would need to have the Read executed to read back into the Buffer space allocated -- otherwise you'd not be able to sort out which read data was from which offset. In other words, if the block coming from your remote PC was structured: (header) offset1 size1 array of size1 bytes for result offset2 size2 array of size2 bytes for result ... (trailer) then instead of your 'x' to read the data in, the address used would to the place in this buffer of the relevant result area. After the Process you'd then ship the entire block back to the remote PC. This is more or less how WideFS started out, six or seven years ago. For the last few years, however, it has been streamlined considerably -- it doesn't need the data space in the incoming blocks and doesn't "Process" for every request. It simply adds the requested offsets/sizes to a list for that Client, then another part (in another thread) monitors those offsets in the FS PC and sends them when the values change. If they don't change, it doesn't send them (of course the first request is considered a "change"). That is, unless the remote PC gets disconnected, then they are all considered changed. WideClient, in the remote PC, maintains a "carbon copy" of the offset area and stores the changes being sent for any local applications which read them. Sorry, I've got carried away a bit. I hope this helps rather than confuses! Regards, Pete

No, I've never done anything like that. Oh, yes. I've seen those types. Always struck me as a big waste of axis inputs when buttons would have done. Well, it is certainly something that could be added to my list, but it doesn't really fit at present. FSUIPC currently doesn't handle any axes at all -- it does buttons and keys, but axis reading is a rather different matter. The only facilities that may look like axis processing are the Joystick page facilities, which in fact work upon FS axis controls rather than any actual inputs -- FS processes the axis inputs, they are assigned there. All FSUIPC is doing is intercepting the resulting controls inside FS and transforming the parameter values they include. I did always have in mind a possible joystick axis reading/assignment facility, probably in a separate module, only possibly in FSUIPC, but I've never had time to work on it. That could certainly include options for assigning controls or keypresses, not just at extremes but at any specific positions (for instance, turning a pot into a multi-positioned rotary switch). Maybe assigning "virtual button numbers" instead, which can then be programmed in the Buttons section would be a way of implementing this, I'd have to think about that. It does get a bit complicated because I'd want to allow the axes to be on WideFS clients too, just as I currently allow buttons from clients to be programmed. This is a biggish project to do properly, and I wouldn't like to do it piecemeal, and this is why it hasn't actually been scheduled yet. Well, from my side I would not say there is no hope, but at present I cannot commit to the facilities I've outlined, let alone give a date. All I can say at present is that it is certainly something I'm interested in doing at some stage, and it is now firmly on my list. There may be some other utilities out there which may either do the job already, or possibly could be adapted. Thank you for your appreciation. :) Regards, Pete

Like many things, systems and substems not implemented in FS can be added to your own system via pmSystems programming. A lot has been done for the 737NG that way as I can attest to in my own 737NG with partly (and increasingly) functioning overhead (thanks to Thomas Richter's great enhancements to the 737NG base work done by Enrico). However, back to your original question "is there an offset" for it, and the answer, as I said earlier, is no, not one from FSUIPC, because FSUIPC only supplies data from FS. If FS doesn't implement it, how can FSUIPC get it? If a third party aircraft like FDS (or PMDG) implements it, AND they provide access to it via a private FSUIPC offset, THEN you may be able to access it, but I do not maintain nor know nor document third party programs. Likewise, if you yourself programs support for it via pmSystems, it will be you who chooses the offset within pmSystems' own offset range, and then, of course, you will know it in any case. Right? Regards, Pete

That'll be implemented in the PMDG code. There isn't one in FS. You'd need to ask them, but I don't think they give such information I'm afraid, even if they have assigned one of their offsets for it. Regards, Pete .

What is it? Whereabouts in FS? Pete

sounds like you have some severe cross-interference. Well, there's really no realtion between the separate inputs to FS as far as FSUIPC is concerned. Try to record this in the Log with FSUIPC axis logging enabled. Take care though, the log can get VERY large. Only enable it for the short period you get the anomaly. Regards Pete

Yes. I originally faced this problem programming displays via EPIC (the original Flight-Link TR-1 and KR-1 avionics stacks, in fact) way back in FS98 -- before FSUIPC in fact. The only sensible way to do it is as follows: 1. When your dials are adjusted, update your displays locally with the new values as well as sending the new values to FS. 2. If the values are changing fast, don't try to send them all. It is probably best for the routine you use to send to FS to "sample" the current updated value every 250 or 500 mSecs and send the new values at that time. 3. Whilst the values are being updated locally, IGNORE changes being read from FS. 4. After a time (say 1 second or so -- experiment) from the last local change, THEN start reading FS values again for display. If you don't do it something like this you will find it very difficult to do adjustments accurately as the FS read-out will always run behind. You watch an MCP being adjusted in a real aircraft and you will see how fast you can "spin those numbers". Try to implement it locally like that. Just let everything catch up in FS when the value stabilises. Regards Pete

It's read-only becase I can't find a way to write it directly. You can easily wind it up and down using the appropriate controls, as you would in a real Cessna using the knob. I don't know why you'd need to specificaly set it directly? I think the Controls are called "ATTITUDE_BARS_POSITION_DOWN" and "... UP". You can either program them on a button or send them to FSUIPC via offset 3110. Regards, Pete

There aren't any. What would they say if thee were? There's not a particular limit on the number of simultaneous views in FS. If you only want to change the default window view, use an FS control. If you want to find out whether any open (and visible?) window contains a particular view, I think you need to be running on the same PC as FS, then try to analyse the assorted FS windows by ennumerating them. It certainly isn't easy. Regards, Pete

Don't forget that much of PM communication is via "NetDir". I assume you've run the PM checking program -- does that give everything a clean bill of health? It did? So, what has changed. Have you installed anything, removed anything? If you've changed nothing, and you are sure you have not acquired any viruses or worms, then the problem may well be hardware -- software doesn't "develop" faults, they are either there or they are not. However, the possiblilty of file corruption, somehow, does arise -- reinstallation is then usually needed (more below ...) Again this reference to "blindness". It sounds like the Netdir access for PM, not WideFs. Run the check program again. Your best bet for help with this is Katy Pluta of PM support. She helps me when I have Network Problems. Are you sure the when this happens the Glass Cockpit is actually really fully closed? Just because the window disappears doesn't mean it has gone -- check with the task manager (Ctrl-Alt-Del), look in the Process list. All the cases I know of with WideClient locking have actually been due to the application locking. If the PM process has gone completely, then the hang will be in the Windows networking routines or in the network driver. Try re-installing the network card -- in the Windows hardware manager uninstall it and reinstall it. If necessary, and it is a plug in (PCI) network card, actually deinstall it completely and re-install it. BTW, you aren't using "pmGetWeather" are you? I find this occasionally locks -- it takes 99% of the CPU when it does so and everything else on that PC grinds to a halt. Anyway, back to corruption: earlier this week something somehow corrupted something in my system. Upon booting up I was getting six or more consecutive crashes reported in "SVCHost", Windows Explorer took two minutes or so to open "My Computer" (every time!), and the whole PC reset itself now and then. I was going crazy. Katy suspected a worm or virus, but nothing was detected. Eventually, via the Event Log I found that the initial crashes were when Windows tried to start a service -- something about Image Acquisition. I found the service and disabled it -- and everything has been okay since! I suppose I still have a corrupt part of Windows, but, since it is a part I don't use, it now doesn't affect me. I expect that if I wanted to use this disabled service I would need to re-install Windows completely. Maybe this is what you will need to do? Regards Pete

The acknowledgement is automated I think. The registration requires humans. SimMarket are pretty quick -- almost always within 24 hours, as it says. Some things I register only guarantee 2-3 days ("working days" at that). What do you think will be "going on"? Has it been more than 24 hours? If so, raise a problem ticket. Yes of course. Didn't you read the details on the site? Perhpas when you ordered them folks were asleep in Germany (where SimMarket is based)? 24 hours is a pretty good turn-round, and it even applies most weekends, which is better than many. Regards, Pete

add WideServer.dll The wideFS bit there is just WideClient.exe. You can arrange for WideClient to load the other programs for you when FS is ready for them on PC 1. I do this, then put a shortcut ot Wideclient in the StartUp folder so it loads when the client PC boots up. It doesn't do much and doesn't take up much space whilst waiting for FS. Wideclient can also close the programs when FS is closed. It's the easiest to configure and it is installed by default, so, yes, it is supported by WideFS. For a long time I only supported IPX/SPX which is slimmer and faster (not needing to work on a world-wide Internet). I had to give in as Microsoft seemed to tail off their support. It does still work though -- in fact since SP1 Windows XP has been pretty good on IPX/SPX -- problematic before then though. Regards, Pete

You'd probably be better off putting ActiveSky on the second PC too. It wouyld releive some of the load on the PC you really want to keep clear for FS's needs. ActiveSky isn't a processor hog, but it may cause some jitters in FS when it is downloading weather every now and then. You only need WideFS. Check the documentation. There's not a lot to do. Come back if you get into trouble, but most folks just install it, tell the client what the Server name is, and that's it. Well, naturally I'd love for you to buy FSUIPC, but it isn't necessary -- you will have to buy WideFS though. Regards, Pete

Why? Why not use the value you just sent? Don't you believe it? Both the write and the read are being done in the same Process. That will only work (on the same PC as FS) where all FSUIPC has to do is copy the value into some memory, because obviously the memory will be just written in the same call. It will not work on a client PC because the process is being done by WideClient. It will send your Write over to FS, but it will give you the value for the read that it has in memory. Until WideServer sends it the update any reads on the Client will return the previous value. It will be two network cycles before you get an updates -- possibly 50 mSecs, more likely anything from 100 to 300 mSecs. More on a very busy system. If, for this particular value, FSUIPC cannot simply write to a memory location, but has to send the value to somewhere in FS for processing, then you cannot expect the value to be read back correctly in the same process call to FSUIPC. It cannot be done. You should write your program with cycles either approximating the FS frame rate, or regularly, say one FSUIPC_Process call every one or two or more "timer ticks" (each 55 mSecs). Requests sent on one cycle may be seen to be effective on a later one -- hopefully the very next one for something simple like this. For some weather and AI traffic reading requests there might be a longer delay. And of course, over a Network, through wideFS, you mst allow for much longer as a rule. Regards, Pete

The easiest way to see any offset is to use FSUIPC's Monitor -- see the right-hand side of the Logging options page. Add 02D4 as type U16 and check the Hex option, then check the "AdvDisplay" option below to see it in real time on screen. BTW, I've just tried it on the PMDG 737-600 cockpit and it is all working fine. Regards, Pete

The second ADF is only provided in FS2004, and then only if it is implemented in the Aircraft you are using. Check your Aircraft.CFG file and see if it has one or two ADFs. Pete

Yes, and the big advantage then is that you get ATC voiced through separate speakers (from the sound card on the Client PC), and can have it through a headset if you like. Regards, Pete

Check the sensitivities in FS (Options-Controls-Sensitivities). For some strange reason FS2004 seems to sometimes automatically initialise axes to ZERO sensitivity, giving exactly those symptoms. Whilst you are there, make ALL of the sensitivities maximum and all the null zones minimum if your are using FSUIPC calibration for everything. This will give you the best resolution and flexibility. As you are using the CH quadrant you will find Bob Church's notes helpful -- http://www.stickworks.com (Look for his CMNOTE02.ZIP), Regards, Pete

Have you tested your program direct to FSUIPC at all? What does the WideClient Log show? What versions of WideFS and FSUIPC are you using? It means that after a number of retries your program could not get an answer from WideClient or FSUIPC, whichever it is running on. It uses "SendMessageTimeout" and wants a response within a timeout period. when FS is really busy that timeout may occur, so the library code I provide does a number of retries. Provided FS is available within about 10-20 seconds it should work. Otherwise you get that error. However, in the case of WideClient, even if FS is busy or even if it isdn't actually running, the response to the SendMessageTimeout from WideClient.exe is nearly always immediate. If you are getting such failures on a client then it sounds like WideClient isn't running, or is hung, or has crashed. Regards, Pete

Not one number, two numbers. You want a structure or an array with two numbers. In C something like: int controls[2]; DWORD dwResult; controls[0] = 66507; controls[1] = 70; FSUIPC_Write(0x3310, 8, (BYTE *) controls, &dwResult); etc. You must be able to do that in any language, after adapting it to suit of course. Regards, Pete

I'm not clear what you mean: "did not appear" where? In the GFdisplay INI file? If you have your GF MCP installed on your FS PC, then it will be controlled by the GF MCP DLL installed in your FS Modules folder. If you want FSUIPC+GFdisplay to handle it you will have to remove that DLL. Pete

The Goflight MCP is not ideally suited to PM's MCP -- there aren't enough buttons to start with. Does your PM demo include the MCP or are you just using the PFD/ND/EICAS part? If the latter then the GoFlight MCP will be okay controlling the default FS autopilot. If you get seriously involved with PM and want to use it all with GoFlight equipment then there are two possibilities. One is to download my GFdisplay package (which is a free add-on for a "payware" FSUIPC). It already has example files ready to adapt to GoFlight hardware and PM. The other is to ask GoFlight if they have got around to supporting PM yet. I think it was mooted once. As far as the PM Demo possibilities are concerned you will have to talk to PM support. I'm not sure what sort of restrictions and differences there might be. Regards, Pete