Pete Dowson

3.3 is out of date and unsupported. Please download 3.44. The method of registration is described in the first few pages of the User documentation, which is supplied within the ZIP you download. there is also a link to take you directly to the correct SimMarket page where you can purchase the registration key. Regards, Pete

It's Dowson, actually, but call me Pete. As stated in the documentation, it would be valid for all versions 3.xxx. There won't be a version 4 until the next version of FS, whenever that might be. It I do manage to produce a version for the next FS, which is by no means a certainty, then arrangements for upgrades and so on from 3.xxx to whatever will be determined according to a number of things at the time, such as how much work is involved in supporting the new version of FS. There's really not much else I can say at this stage. Only to re-state what is says in the documentation. Regards, Pete

That's a very odd "ServerNode". The first two numbers are the "Network Number" and the last three the MAC address -- theoretically at least. The MAC address is the actual hardware identity of a Network Interface Card. It looks like you have something installed which is converting that non-hardware Server Node addressing into something for the Internet connection and wrapping the data for the internet. Weird. This is all a bit beyond me I'm afraid. Is this on WinXP? Try running "IPXROUTE config" from a DOS window and see what get's listed. Check the section in the current WideFS document entitled 2. Server Node may need specifying for IPX/SPX. I'd be most interested to see what IPXROUTE says. Every case so far of an incorrect Server Node, the one reported has actually been this one: 13330.61389.0.0.512 which appears to be some sort of Loopback Adapter installed by XP. The current WideServer implementation looks for this one specifically and runs IPXROUTE itself to find the "true" local server node. Regards, Pete

No. The FS9.CFG file is in your Windows system somewhere. Everything changed in FS2004, when Microsoft made it "politically correct" to match stated MS policies. If you are using WinXP try the FS9 folder inside Documents and Settings\\Application Data\Microsoft. Ah, if FS doesn't see them, then nor will FSUIPC. In that case, it does sound as if they are bypassing the joystick system completely and doing their own thing. I'm afraid I cannot help much with that. Even if they are using FSUIPC to accomplish this (which does not necessarily follow), I cannot "fix" their code to make it do things they are not doing correctly. Either they are using FSUIPC to set these things, but not allowing the correct values to be written, or, more likely, they are using the FS axis controls and have used the wrong ones, ones which do not provide the reverse/feather ranges. There are a number of alternatives, you see, some dating back from FS98 days and before, and others added later. Whichever way they have chosen to do it, it sounds as if they have got it wrong and, worse, have not even bothered to test on FS2004. Maybe they got it right on FS2002 and just assumed things would stay the same. I'm sorry, but given everything you say this is 100% a matter for Elite. I can't see how anyone else can possibly help if they aren't going to do anything about it. I tend to think they only care about their own simulator and FS is a minor annoying throwaway interest for them. I've always provided full technical help for all developers who've bothered to ask, and I can, but they need to debug their own code. I am not doing that for them. If they have questions, then I can try to answer them. But I cannot solve their problems. As I said before, I am not disposed well towards them in the first place because of their track record in shoving off their problems and blaming FSUIPC. Regards, Pete

Thanks, but that is actually fixed in the current Programmer's guide (4th October 2004). Are you perhaps using an out of date copy? Regards, Pete

All the named values are listed in a table, and they are all treated the same EXCEPT for a priority value, which tells EpicInfo how often to scan them. I've just checked, and see that all the Fuel values are listed as "Very Low" in priority. I think this is because, unlike flying instruments, they do not need close monitoring for every small change. The reason for the priority system dates back to the ISA version of EPIC, which was (and still is) very limited in its capacity to receive information. It was easy to swamp it, and it could actually hang and need resetting. I'm wondering if this makes it late in the initialisation and actually misses the blocks being sent then. Certainly, if your have a lot of data being sent during initialisation, it will be the lower priority ones which miss out. As a test you could set the CFG up so that those two are the ONLY items of information being sent. If that works, then the reason is the prioritisation, and the amount of data you are actually requesting. The other thing you could try, probably more usefully, is reducing the MaxScanFrequency parameter. As you will see from the documentation, by default the lowest priority items are only checked every 30 frames -- you can reduce that all the way down to 1, making them all effectively the same, top, priority. Sorry I haven't mentioned this stuff before, but it is because I don't remember any of it. I think it dates back about 7 or 8 years now, for the most part! I suspect the FSUIPC_Read/Write options are automatically placed at top priority. Regards, Pete

I'll have a look. Regards, Pete

But why not simply program the button action to give your CTRL+E? I'm sorry, I'm lost again. If you are not wanting keystrokes to result from button operations, which is one of FSUIPC's button programming facilities, what is it you are wanting to do? We seem to be going in circles, don't we? In what way? You have too few in your hardware? You can use conditionals and flags in FSUIPC to multiply them, you know. In the extreme you can make n buttons operate 2^n different actions, even separately for each aircraft model and even with differences for things like on the ground/airborne, engines running, flaps extended, etc etc. There's almost no limit -- but for much of that flexibility I'm afraid you have to resort to INI editing rather than simple entries into the dialogue. Well, I'm sure I could help if I understood what you wanted, if it isn't what seems obvious from your questions. Regards, Pete

Please see the thread near the top of the Forum entitled: READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys Regards, Pete

Interesting way to do it. I wasn't aware that IPX/SPX could be used over the Internet. I suppose something must be putting an IP wrapper around it? How do you sort the addressing out -- for IPX/SPX I don't give an IP address or server name, there's no place for them, only for the local network number and network adapter's MAC address (=serverNode). Hmm. Regards, Pete

No, none of my programs can force a system crash. You have to have privileges like drivers to be able to do that. The only time I've ever seen exactly that message it eventually transpired that I had a faulty memory stick. If you have more than 512Mb and more than one memory stick, try removing one at a time, see if it fixes it. It is definitely going to be one of the three: 1. Hardware problem, most likely memory or overheating, or 2. Driver problem, or, least likely: 3. Corruption in Windows. Regards, Pete

Sorry, I don't understand much of that. Where do R/C circuits come into it please? Almost everyone who programs key presses in FSUIPC's Buttons page will be using a combination of Ctrl, Shift, Tab, Win and/or Menu with a normal graphic or cursor or function key -- this is normal because most if not all single key presses are already used. Erstaggering? No. For all windows applications, if you want CTRL+E, say, you hold CTRL first then press E. That's how you program FSUIPC in the Buttons page. But the key sequences it then generates aren't specifically staggered. It is simply a sequence of windows messages -- CTRL key down, E key down, E key up, CTRL key up. I am really bewildered as to what you are looking for. Just program the keypresses in the Buttons page. Why do you specifically need the documentation for that? Go the Buttons tab, operate your button, select Key Press programming instead of controls, press your key combination, see it recorded, then confirm and OK your way out. Isn't that simple? If not, what am I missing? Regards, Pete

I don't know. I would need to have some way to identify the data -- i.e. see it changing in FS - so I can find it. How is "wing fold" changed, for instance? There seems to be a couple of variables I should be able to map, if I can test them: LEFT_FOLDING_WING_PERCENT RIGHT_FOLDING_WING_PERCENT How quickly would they change and be needed to be checked. If I have to read them procedurally I don't want to have to do it on every frame if I can avoid it. It would be better if I can map them directly, but I'd need to see them changing for that. How do I do that? I can't find anything which is likely to tell me if there's a tailhook or not -- in FS2004, at least, I think those things which are present are present, and those things which are not, are not. I don't know if the existing mapped "tailhok position" at 3BA0 can tell you? Regards, Pete

Nor do I, and I can't really help without Logs to look at. I don't use EPIC these days I'm afraid, I haven't for quite a while. Are you sure it simply isn't being missed at the EPIC end? If the Log shows the correct PH value being sent, I don't think there's anyway it can't be. Are the values before and after being seen? Regards, Pete

Sorry, I don't understand. Do you mean that even when the ActiveSky METAR says you have rain or snow, you get none? There's nothing in FSUIPC which will stop rain or snow, it is completely under the control of the weather source, whether it be an add-on program or FS's own weather. And what is "that awful blue ring"? I don't know that one. Sorry. Oh, you mean the sky! Why not call it sky? :) FS only draws clouds to the visibility limit, that's why. FS2000 and FS2004 are much better. FS2002 was the worst for visibility effects. Ugh. Best to simply use the FSUIPC options to limit visibility in different circumstances. FS won't put anything in if ActiveSky is running. That'll be an error in ActiveSky, or simply that you are interpreting its weather incorrectly somehow. The latest supported FSUIPC version is 3.44, and has been for a couple of weeks or more. Sorry, I don't know if you've forgetten anything. Best to go through either FSUIPC or ActiveSky options and check. There most certainly isn't anything in FSUIPC to stop rain and snow. And, sorry, I don't know anything about any "vis red box". Maybe you need to talk to the AS guys? Regards, Pete

EpicInfo does this already, for the selection of values you have chosen. If you are using EpicInfo (you don't say), just enable the logging and you will see. Pete

Because 332E provides a copy of the throttle axis input value -- i.e. the value coming from the assigned throttle axis. Why do you want to write to it? To change it, just move your throttle axis. Sorry, I don't understand what you want to do. By default the standard single throttle axis controls all engines specified by offset 0888. If you want to input throttle values and disconnect the throttle axis input, you set bit 3 in 310A and write to the throttle values (e.g. 088C fir Engine 1). You can still read the axis input at 332E. If you read the write-up against offset 310A you will see the explanation of the use of all these things, e.g. for fly-by-wire. Regards, Pete

Sorry, I'm not even really sure what a "profile" is in this context. Is it something to do with the Saitek drivers supplied? Have you tried the Saitek website, if they have one? Otherwise, you may be luckier asking on the FS2004 Forum. Regards, Pete

Offset 3110 (control number) and 3114 (parameter, if any) is where you write ANY control -- be it a standard FS control, or an added FSUIPC control. It has nothing specifically to do with any aspect of FS. Please check it in the table. Writing to FSUIPC offsets from EPL is not an easy thing in any case. Are you using EpicInfo for this? You can only write 16 bits at a time via "soft axes", so it gets very complex (you need up to 64 bits for controls, for instance). I would have thought there would be better ways of spending time programming EPL, really. :wink: You don't need to if you control the timing of the button state changes in EPL. For that matter it isn't any different doing offsets of button programming except the latter much much easier. Regards, Pete

Sorry, I really have no idea why FS would do that. FSUIPC is only passing on the information it gets. In fact I think that those locations are mapped directly into FS's own data areas. You mention 3070, 3078 and 31D0 and call them "pitch" accelerations, but the Z axis in FS is the longitudinal one -- forward/backward. The FS team name them in terms of screen-type orientation, Y up/down, X left/right, Z forward/back. Both 3070 and 31D0 are Z-axis, not pitch values. 3078 is a pitch acceleration. Is that the one you mean? Maybe you need to add some form of digital filtering into the values to smooth out the spikes? Regards, Pete

Sorry, it is an offer from SimMarket when purchasing both together -- it saves some work and acts as an incentive. There's no mechanism for discounting separate purchases. Regards, Pete

They are not offsets! How did you arrive at such a misconception, please? Surely my documentation is not that bad? :cry: They are FS control numbers -- you are looking in the FSUIPC added control numbers list. Controls are programmed to Keys or Button presses. Please review the text at the start of the list in the Advanced User's documentation. You can send then to FSUIPC across the IPC interface if you wish -- use offset 3110, as documented. But from an EPIC you seem to be going about it in a very odd and complex manner. Going back to your first message: If the rotaries are producing button presses, simply go to FSUIPC's Buttons page and program the controls there. That's what it is all about. I used EPIC up till a few years ago, and most all of the facilities for buttons I ever added were intended to be used this way. Why are you trying to find offsets? More puzzling is that you go on to say: In fact all of those offsets most certainly DO work -- when written to with the correct values, those values will change on the FS A/P MCP displays. But you need to get the units correct, of course. As documented: 07CC is a 16bit word arranged so that the full range 0-FFFF gives 0-359.999... (this is a standard way of representing headings in FS). 07D4 is a 32 bit value with metres in the high 16 bits and 1/65536ths of metres in the low 16 bits (i.e. the whole value is 65536 x metres). and so on. If you are simply trying to increment or decrement values like this by 1, obviously they won't change very fast -- the heading will change to 360/65536ths of a degree, and the altitude by 1/65536th of a metre, for each such increment/decrement. I don't understand why you want offsets when you so clearly can use either the standard FS controls or the extensions added by FSUIPC which you have found and listed. Simply program the buttons. Regards, Pete

Sorry, this is 100% a question for PM support. The flaps display is completely under PM module control. There's nothing in any of my code anywhere that can in any way affect any graphics in PM software. Regards, Pete

The only way to do that is to put a shortcut to WideClient in your Windows "startup" folder, so that Windows runs it after loading. Have your PM programs started by the "RunReady" parameters in WideClient.ini. Then WideClient will sit idling in the Client PC, and will connect only when it sees the Server and then run the PM programs. Of course. There's no way the link \\CDUis going to get the program actually running in the client. That's just a path telling Windows where to get the program to be run. So it will be running (very inefficiently) from the folder on the client, but within the current PC -- the one running FS. Since WideClient cannot normally run in the same system as FS, you get that error. I don't know of any way of getting a program to run in a Networked PC without having something there which is ready to run it for you. In this case, that "something" would be WideClient, which you need to have running first. Regards, Pete

Okay, found the problem and fixed it. It was recent additions, refinements, using a couple of FS variables not actually present in FS98. Sorry about that. Please use the attached version 2.571 of GPSout. Incidentally, you don't need FSUIPC installed in FS98 to make GPSout work. Regards, Pete GPSout2571.zip