Pete Dowson

No. Inputs to the PC from EPIC cannot cause buffer overflows in EPIC. The scanning frequency has nothing to do with data going TO the PC from EPIC, only the other way round. The "POVs" have to be seen as POVs through the Windows joystick interface. When you go to Game Controllers in Windows, do you see EPIC as 16 joysticks, or only 1? Each joystick entry has only one POV visible in the Windows joystick interface -- POV0 for the first, POV1 for the second, and so on. It sounds like your EPIC is only defining one or two joystick entries. POVs are also not so usable in FS2002 or FS2004 as they were in previous releases. This is because FS was changed in FS2002 to use DirectInput, instead of the joystick interface which all my software has always used. POVs in DirectInput are restricted to the angles 0-359 degrees, or, if defined differently, 0-35900 1/100ths of a degree. This stops them being useful for many of the things that I used them for in FS95, FS98 and even FS2000. You can use "soft axes" instead. If you define them properly in EPL you should be able to get 6 axes for each of your 16 possible joysticks (though I've a feeling that the USB implementation limits you to 8 joysticks, doesn't it? At least it did when I last looked at it, when it first appeared). Of these 96 (or 48) possible axes only 16 real ones are supported (or at least they were in ISA EPIC days), but the others can be used to send any 16-bit values, and so are much more flexible than POVs. Note that I seem to recall that my originally named "soft axes" (in EPIC95 days) were re-named "virtual axes" by R&R in the USB incarnation. I'm sorry that I'm really unable to help much in this area at all these days. I think there are some good places for assistance -- check the link someone provided in that other thread, for instance. For all matters related to the USB EPIC and the new EPL system I was completely dependent upon assistance from Ralph Robinson (the designer and owner of R&R) just to get what I had working on ISA EPIC working on the new units. Regards, Pete

Okay. It's on my list. Regards, Pete

It must be simply the limit on the data sent, then, to protect the EPIC from hanging due to buffer overflow. Can you manage okay using the FSUIPC_Read methods? Otherwise it looks like a matter of reducing the amount of data you need. If I get time I can try to look at the code to see if there's any way to relax the limit, but without being able to test things here properly I am a little reluctant to fiddle with code I am now so unfamiliar with. Let me know. If it is desperate I can see if I can try something if you don't mind testing things and risking crashes. Regards, Pete

Hmmm. Sorry, but currently FSUIPC only handles the axes which you can see, the main flight-related ones. It is a lot of work adding calibration tables and extra option pages for each axis and not something I would do in a hurry, expecially for something never requested before. I'm not even sure what the "pan axes" are -- in all my experience with FS since FS4 I've only ever uses either the direct views (forward, left, right, etc), or a "point of view" hat. Are you talking about AXIS_PAN_HEADING AXIS_PAN_PITCH AXIS_PAN_TILT ? I could add them to my list of things for future versions if you like, but I cannot commit to doing this in any particular time frame. So far you are the only person to even hint at such a need. Regards, Pete

No, sorry. it is purely a graphics thing. I've not really noticed anything as bad as what you are saying, though. Make sure you have 100% 3D clouds set, and see if putting most or all the sliders full right in the Options-Settings-Display-Weather tab in FS will help. Another place to seek help with this sort of thing is the FS2004 Forum. Chris Willis visits there a lot and is THE cloud expert. See if you can get advice from him. Maybe some of his replacement cloud textures will help. Regards, Pete

Okay. Somehow, something extra is installed on your system. The "Internal" entry doesn't appear on any of my XP PCs at all. Both the Internal and Loopback Adapter entries have the same strange Network Number, but this is not the same one as I and others get for the "Loopback Adapter", which is interesting. The value "a38a721d" gives you your 35491.7538 (hex 8AA3 and 1D72 respectively). The correct ServerNode which would give you a direct connection to the Server in IPX/SPX mode is the "LAN" one: 00000000 0030847acf89 which would have provided: ServerNode=0.0.12288.31364.35279 At present, in WideServer 6.44, I only run IPXROUTE to get the list when the ServerNode Windows gives me is the one I knew about as "LoopBack Adapter" (13330.61389.0.0.512). It looks like I should run it whenever the Network Number provided is something non-zero. I am making some small changes to WideFS at present, so maybe i can send you a version to try in due course. Yes, this is like all the others I've seen. If this had been your Server, WideServer would have run IPXROUTE for you and obtained the Local Area Connect 2 entry as correct. Trouble is I don't like things I don't understand. I can only guess that the extra "Internal" entry you have on the Server is somehow doing this. It couldn't be Internet Connection Sharing, could it? Or do you have something special installed on the Server? Regards, Pete

Right, so the problem seems to be that there's too much initialisation data, or at least there would be for an ISA EPIC. As far as I can see from looking at the documentation myself, yes, that is all you do. It is just another EPICINFO.CFG parameter. Well, I expect it would have had a serious impact when EPICINFO was first written, for FS95. How much impact it might have now I don't know. Assuming you are using a USB EPIC and not an ISA one I should think the EPIC could cope, but I cannot be sure. I'd try it here for you if I could, but I think the easiest thing is for you to try it and see. You could always try other values then, between 1 and 30. Regards, Pete

It is "Dowson", actually, but call me Pete. Yes. The registration belongs to you, the user, not to the PC. I have no objection to you using it on more than one PC. In fact I don't really like those systems which stipulate such restrictions. Regards, Pete

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