Pete Dowson

Check out pmSounds first, in the Project Magenta site. >> I've written the code in such a manner where the LED will flash if I need to turn on the Pitot Heat based on the outside air temp. So I thought a little beeping sound would be nice as well. << Surely you mean anti-ice, not pitot heat? You should ALWAYS have pitot heat on when flying! Regards Pete

That depends on what you want. There is no joystick axis management as such in FSUIPC at all. All the assignments for axes are in FS. If you want two throttles, two mixture axes and two pop pitch axes then you assign them that way in FS. If you want 4 of each I assume you need two CH TQs? For a 4 engined jet obviously you'd need to replace two of your prop-only controls by separate throttle controls. As a compromise you could consider using only a single mixture and a single prop control for both engines of a twin prop and allocate 4 throttles, or you can use FSUIPCs "mapping" facilities to map 2 to 4 in each case, thus giving you complete control but not individually for each engine. Regards, Pete

I cannot reproduce this at all the the default FS 747. In fact I don't see how it can occur, as when using a single throttle for all engines there' only one "reverse" operation really being performed, not 2 or 4. Check your FS axis assignments, make sure you don't have anything else set to adjust throttles. Let's take your experiments one at at time: But that would make FSUIPC revert to default actions, which would mena no throttle calibration and no reverse on your mixture axis. The only "FSUIPC" file of consequence is the DLL itself. The LOG file is produced each time, as is a default INI file. If you delete the only other file, the KEY file, you will need to re-register, but that is all. Once you have deleted the INI file you have destroyed your settings, which explains why nothing happens. You will have to set the reverser up again. When using a single throttle axis, they always do work together on the standard FS aircraft -- unless you use E+ 1 2 3 4 to select specific engines -- this is a standard FS facility. I don't know about third party aircraft though. Regards, Pete

No, FSUIPC is an FS module, and it doesn't use DirectX in any case. In fact it doesn't touch joystick axes at all -- only, optionally, manipulating the values in internal FS controls which can result for axis movements. Pete

They aren't automated -- only the initial response is, I think. Pete

This is more a question for the WidevieW forum really. There will be considerable difficculties getting weather to match exactly across clients in the way you wish. This wasn't really a problem in FS2002 and before, but in FS2004 all weather is "local". I really don't know how WidevieW deals with that, buty if it still operates as it used to in FS2002 and before, reading weather at the aircraft and setting it as "global" in the clients, then it will rarely correctly match the detailed weather AS is going to be setting individually, for all of the WX stations around you. One way for WidevieW to try to do that is to read weather at all the weather stations around you, as you fly, and copy them in the clients. To be accurate it would need to do this at about the same time as AS updates the server (i.e. just after). But I think there is a danger that this sort of process might create quite a load on all of the FS installations. It is something worth asking in the WidevieW forum, though. Another way would be for ActiveSky to supply the identical weather inputs on each of your clients too. That's quite a job though -- AS would need its own Network routines and client program running on each client. You'd then need to be able to tell WidevieW not to try copying the weather at all. Maybe suggestions to both WidevieW and ActiveSky developers? Regards, Pete

Okay, I don't know there is such a position on an ordinary jet -- there seems no reference to it in any of my manuals, even though the condition certainly still occurs. The rule normally is to abort the start attempt, switch the fuel levers back to cut-of, and not attempt again for a period of time. I assume this is for the fuel to dissipate naturally -- the N2 rotors will still be spinning for a time. The point as far as FS is concerned is that the "starter" switch starts and the fuel switch operates the fuel. There's no ignition switch in any case, and hot starts aren't actually ever going to occur because it doesn't simulate them. Now, for your purposes, the controls you have are just that, start and fuel. Whatever you want to simulate above and beyond that will be via your own indicators and gauges and switches, just utlising whatever FS can provide towards that. Of course you can have your own fuel switches on idle but the FS ones on cut-off if that's what you want. >> As well I though writing 0 to the offset of the lever might conflict with FS reading the position of the physical lever (if it is in "high idle" for example) << But there's no physical lever in FS -- you can control the position of your lever in your programming. If by "physical lever" you mean graphics on in some FS cockpit panel then, of course, the value will change that -- but surely for realism you don't use any FS panels? >> but actually in hot start fuel lever will be "cut off" anyway... << Ah, so it is as it is for Jets then. Regards, Pete

I think the ignition is powered by the battery, APU generator, or ground power, and the switch on a 737 is "left", "both" or "right", there's no "off". But if you have all the power sources off I think the only way to get N2 turning is with external air pressure. But I'm not even sure about that. You need to ask a real pilot. Why does it matter if it conflicts with the actual lever? I must admit that I'm a bit puzzled about what you are really trying to accomplish. This is to do with recovering from a "hot start", correct? How are you simulating that in any case -- FS doesn't do it for you, does it? They've moved to France now? The last one I went to (#7?) was at the Aviodome at Schiphol, as part of the "Green" teram -- a collection of enthusiasts who'd never met before except in FSFORUM on CompuServe. I think we came in last! :wink: Anyway, sorry, no, I won't be there. I don't get around so much these days, at least not alone, because of my very poor eyesight. When I do go to places it's because a friend also wants to go, or it is something my wife is interested in (the latter most certainly doesn't include Aviation! :wink: ) BTW I'm afraid after this my next message will not be till Tuesday night or Wednesday as I am away for a long weekend (with wife and youngest daughter). Regards, Pete

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