Pete Dowson

Ah, maybe, but there's plenty going down the Professional side ;-) Regards, Pete

Hi Frank, glad everything worked out well! Yes, he's a very nice gentleman. We had the pleasure of him staying with us recently and hope to again in the not too distant future! BTW, I spotted an advert in Computer Pilot from a company in the UK that does actually sell PFC gear -- see http://www.aviationsimulation.co.uk. I think they must be the ones who had a stand at Blackpool -- or it might have been the RC Simulations show down in Birmingham now I think about it! Best regards, Pete

Good. It is nice to have that confirmed. Great! This is the sort of message I like -- less work instead of more! :wink: Thanks, Pete

I am re-posting my reply to the message of yours which I so rudely, but unintentionally, destroyed above. I am doing this to make it clearer who is saying what! Sorry. They are the labels on the four positions on the Starter switch on Boeing aircraft, or at least on the 737NG. I would have thought them to be more widespread, but perhaps not: GND = Ground (Ground starting) - spring biassed back to Off but magnetically latched till combustion or a time limit. OFF = Off (Normal) CONT = Continuous ignition (used in critical periods like takeoff and landing, to prevent any chance of flameout I assume) FLT = Flight (restarting in flight). Regards, Pete

Why are you having the KeySends repeated for the whole time you are pressing the buttons? That's not good! Change the "R" to "P" in both cases. I think the chap who so kindly did the add-on document for PTT made an error and had the Repeat enabled there, so I need to amend that documernt. Perhaps that's what misled you? However, it doesn't really explain what nothing happens -- it is probably just very inefficient. UseSendInput=Yes KeySend1=123,16 ; Press F12 -------This is PVT KeySend2=123,24 ; Release F12 KeySend3=Rwon ----------- This is COM1 KeySend4=Rwoff The "Rwon" and "Rwoff" facility uses Registered Messages to send the requests to Roger Wilco (the name "Rw..." comes from Roger Wilco). Apparently AVC incorporated these into their code too, for compatibility, and I understand that AVC was adopted into SB3, so that's why the RWon and RWoff facilities still work there. The 'normal' Key method, however, was always problematic with Roger Wilco, may have been with AVC, and looks like it is with SB3. To try to get around the assorted methods different programs use to detect Key presses, WideClient offers at least THREE ways of doing it. Have you tried them all? First, you've elected to use "SendInput" I see. I'm not sure why you chose that method first (it was added for TeamSpeak, for which it does work), but since it doesn't work, try without it. When you omit "UseSendInput" (or set it to 'No') you need to tell WideClient what program to send key strokes to. There are TWO ways of doing that. The first (and oldest) is to provide the "class name" of the Window of the program to receive the keys. Examples are given for some programs, but not SB3 which I don't know. The easiest way, however, is to use Wideclient to load the program in the first place -- use Run1=or even RunReady1= (the latter will only run it when FS and WideServer are ready to talk). When you do that, Wideclient can identify the program more easily, and you can direct keystrokes by appending ",Run1" or ",RunReady1" to the KeySend paramter line (see the section "Directing Key Strokes more precisely"). Having done that, try it. Try both methods of sending the keys -- PostKeys=No and PostKeys=Yes. Once you've tried all these methods, if none of them work, then I'm afraid there is no way using the current keypress facilities in WideFS. Possibly the SB3 implementers have added more Registered Messages to operate these functions? If so, I could add these to a new version of WideFS without any trouble. You'd need to talk to the developers or get them to contact me. BTW I am away from tomorrow (Friday 17th) until next Wednesday (22nd June), so please forgive any delays in my response till then. Regards, Pete

Generally I don't think the rudder isn't used much by autopilots -- there's a sort of "autorudder" mechanism (which you can simulate by enabling it in FS), and a damper of course which operates rudder trim tabs to conteract adverse yaw. In fact I think in the current code I engage autorudder when the bank feedback control is used, then return it to its original state afterwards. This ensures turns are made with perfect balance without needing any rudder input from the autopilot. The actual yaw motion of the aircraft is, of course, affected as much if not more by aileron activity as by the little and occasional rudder needed, the main function of the latter being to prevent incorrect yaw rather than cause any -- unless you are a stunt pilot in which case autopilots aren't involved! Yaw is also caused by throttle changes in prop and turboprop aircraft, but normally the bank and pitch controls will counteract that quite quickly. Given all this I find it difficult to imagine exactly what I should be checking for yaw and how I should be attempting to control it, and also why I would do all this to start with. What would you suggest? On top of all this, there is the point of course that even the existing facilities I provided are still "experimental" and I have had almost no feedback at all -- so am I to assume that the existing provisions are not being used, or that they are all perfect? Regards, Pete

That jet/turbo switch action derives from the (unrealistic) FS implementation of the starter switch with "Start", "Gen" and "Off" positions, that's all. To switch your generators separately all you need on the starter are the "start" and "off" positions. FS only has starter on or off, so you'd have to set starter on again. For jets which typically have "GND-OFF-CONT-FLT" positions I have to use something like this: GND -> Start OFF -> Off CONT -> Off (CONT is only continuous ignition, ignition isn't simulated in FS) FLT -> Start This is obviously a compromise. You have to work out how to map "reality" onto FS's simplified systems. There's no need. After you write 1 to 0892 FSUIPC does the refreshing of the start for you, it keeps doing it till you write something else there. Regards, Pete

Well, I think once you start messing with the AI aircraft the inbuilt ATC can lose track of them. Once that happens I think the aircraft is "off the list" that I know about and is as good as gone. I've not really experimented much with this at all, so I'm really just reporting what I've learned from others who are using the option. Obviously it is easy enough to change things in the aircraft's flight attitude which will make it impossible for it to continue its intended flight. If you don't actually want to lose AI aircraft in this way I think you need to take great care what you do with them. I doubt that it is the sheer number of commands they get from you but more likely the nature of them and how much they may conflict with what ATC want them to do. Possibly keeping them in Slew mode too long may detach them from the normal control. You could try switching the slew mode off and on now and then. Regards, Pete

Just looking there I see there are two drivers -- only one needs HazardScripts: Why not try the simpler variant? It sounds like HazardScript isn't compatible with something else in your machine then. And if Game Controllers shows crazy buttons there's no way FSUIPC will be able to fix them. No. FSUIPC only uses standard Windows joystick calls to read the buttons, the same as Game Controllers does. Try the simpler drivers -- uninstall the others first of course. Odd that Saitek doesn't support all those operating systems? That website even says Win98SE isn't supported by Saitek! Are these joysticks that many years old they only got support for Windows 3.1? If they are really old Game Port connected devices they should be okay driven by one of the default drivers provided by Windows. There's nothing much simpler. Regards, Pete

I'm not sure what I'm supposed to be seeing. Why would you think that? I'm confused. According to your picture, a (probably spurious) value has arrived for Throttle 4 which, since it isn't being processed by FSUIPC, is passed though untouched. The fact that you are mapping 1 and 2 to 3 and 4 doesn't prevent the displays of IN/OUT reacting to received axis controls. If you want to see what Axis values are arriving in FS, check the Axis logging option in the Logging page. Regards Pete

Sorry, I don't understand what you are saying there. You need to batch reads/writes in the remote PC in any case. You surely don't want the overhead of the Ethernet protocols added to every single individual read and write? All I was suggesting is that your batch of reads and writes, arriving at the FS PC, are formatted for one FSUIPC_Process call, and the result forms the return block to the remote. How you convert from your block format to that needed by FSUIPC and back again is completely up to you -- you can use FSUIPC_Read and FSUIPC_Write, or you can make it more efficient and do the original blocks in an FSUIPC-compatible format in the first place. If you are, indeed, only sending one read or one write per block from the remote, then your code extract is probably fine. You won't be able to achieve an FSUIPC_Process frequency of more than about 20 per second (50 mSecs intervals) on average in any case, which won't have any noticeable impact on FS. It will have an impact on the program running in the Remore PC though, unless that has a very low data requirement. Regards Pete

WideFS isn't capable of queuing requests at either end. That symptom seems to always be a problem on the client where Windows is too busy doing something else to be bothered with incoming stuff on the Network, and the latter piles up in Winsock buffers. I think the last time it was reported it turned out to be video drivers, they were taking most of the processor time. Possibly the OpenGL drivers aren't up to scratch on that PC. But it could be down to other processes. Check whatever else is running. Also, for all PCs, check that the Network adapters aren't using an IRQ shared with anything else, and especially not the video card. This isn't supposed to matter so much with WinXP, but I've always found it much much better to keep the Network IRQ separate if possible (and it is essential on Win98/Me). I'll look at it, but it is unlikely to help. Your previous logs show no errors relating to your problems. It would mine. Some of the most frustrating periods in my PC life have been down to Network problems. I've thrown three network adapters and two hubs away in disgust in the last three years. Once I get things working I try to make no Network changes for fear of what may ensue. I have no Network experts to hand and have to rely, like you, on trial-and-error. And, yes, I've had to start from scratch on occasions and re-install everything from Windows up. It may be time for you to bite the bullet soon I fear. Regards, Pete

You are still performing a separate FSUIPC_Process for each individual Read and Write. If you are only interested in a couple of things this may not be too bad, but otherwise it will be terribly inefficient for the FS machine and probably painfully slow for whatever you are running on the remote PC. Each time you do an FSUIPC_Process you are actually causing a process switch into FS. Your program is then suspended waiting for the response. Each time the response is ready, you are generating a process switch out of FS. So both processes are suffering. This is all okay when they more or less coincide with a normal sort of timeslice in any case, but if you are reading, say 20 or 30 different items of information in one exchange on the Network, you are orcing everything to run too slowly. The 20 or 30 requests could build up to 2 or 3 seconds whereas your Network turn-round should be only 30-100 mSecs normally. The whole reason the FSUIPC_Process call is separated from the Read and Write calls is to allow a batch operation. The FSUIPC_Read and FSUIPC_Write calls do nothing but build up a data block containing all the requests, along with the space for the replies. They are all internal to your program and very very fast. Try to remove the Process calls and do one Process call per block of requests from the remote. Really, you'd be far better off formatting the blocks on your Network connection for FSUIPC_Process directly, and never use FSUIPC_Read and FSUIPC_Write in the FS PC. This should be easy enough for you to work out -- the source of the FSUIPC library you are using is provided. Take a look at what the Read and Write calls are doing, and do the same in the remote PC. Send the resulting block to the FS PC and use that block as it stands in an FSUIPC_Process call. Regards, Pete

Hmmm. Strange. FSUIPC doesn't actually do anything unless you ask it to. What does this "HazardScript" program actually do? Unless you are programming buttons in FSUIPC, it doesn't actually do anything with them, although it will of course be scanning them. There should most certainly be no reason why a call to Windows inquiring the state of buttons should reset anything. FSUIPC also checks to see if EPIC is installed so it knows whether to scan it for buttons as well. This does involve an initialisation check -- I'm wondering if this HazardScript program is using the same sort of interface and the EPIC inquiry is confusing it. To stop FSUIPC looking for an EPIC, add the line: PollEpicButtons=No to the [buttons] section in FSUIPC.INI (add the [buttons] line before it if it isn't already there). Incidentally, if there's no other solution, you could get FSUIPC to run HazardScript automatically for you each time to run FS. See the section entitled "Programs: facilities to load and run additional programs" in the FSUIPC Advanced Users guide. Regards Pete

When I try this. What am I doing wrong? Ah, sorry, that's probably my fault -- I didn't read your original well eoungh. Structs aren't the same as Arrays. You'll need to explicitly provide the pointer to it. i.e. not "(char *) fsData" but "(char *) &fsData". The "&" prefix means "address of" -- i.e. it makes a pointer to it, and you can cast pointers to one type into pointers of any other type. Pete

Nearly, but not quite. the cast is not (char) but (char *) -- i.e. you are providing a pointer to an array of characters, not a literal single character. As far as any byte-oriented procedures are concerned, the fact that your data is actually some complex mixture of bytes, WORDs, DWORDs, or all sorts of other types and structs is not relevant. To such procedures (and the FSUIPC ones are the same), data is data is data -- it isn't interpreting what it means, so it can be a string of bytes or anything you like. The value being passed is simply a pointer (i.e. memory address) to the first one. The size is always in bytes -- the value (address + size - 1) points to the last byte. Whatever the data is doesn't matter. Just be more careful when using casts like this, because you are effectively telling the compiler "I know best -- treat this value like this", so you don't get the value checked. For example, if your value "this_data" was not declared as an array but simply a DWORD: DWORD this_data; then the cast "(char *) this_data" would take the contents of this_data, not the address of it. You'd need to put "(char *) &this_data" to take the address of this_data (i.e. make a pointer to it). This is why, in my programming, I prefer to stick to the rule of naming variables with a prefix showing their type. e.g. "dwThisData" for the DWORD above, "chThisData" for a character I precede things with a 'p' if they are pointers, thus: DWORD *pdwThisData = &dwThisData; and so on. With arrays, like char chThisData[nSize]; The value "chThisData" is actually a pointer. However, I still tend to take the address of the first one when I want it to be very clear that it is a pointer, so: "&chThisData[0]" This is actually the same as "chThisData" but it is now completely obvious it is a pointer to the first element, and not an actual single character value. Regards, Pete

Well, maybebut I suspect MS will find many other things to do first. I think the latest version of SquawkBox (SB3) does utilise a couple of the positions on that switch, and has an FSUIPC offset which you can use to control them. But I don't have the details to hand -- if you are a Squawkbox user you probably know these already. Regards, Pete

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