Pete Dowson

I know this is addressed to JD, but I have to butt in and say how amazed I am that VB has so much difficulty handling things as basic and simple as strings. As long ago as 1978 I remember using the very earliest forms of Basic, and their handling of strings was exemplary. I really can't understand what Microsoft has done to it all. :cry: Anyway, just in case your comment causes more confusion, please note that the FSUIPC_Read and _Write procedures themselves do not care one iota what the data is. The form of the data can be absolutely anything you like. It is most certainly not just a "long". What you are confusing the DATA with is the pointer TO the data. That's all FSUIPC needs -- the pointer to wherever the data is, in memory, and of course its length, in bytes. After all, all the interface has to do is move stuff from one place to another (one process to another, or in the case of WideFS one PC to another). In most languages pointers appear to be quite fundamental and straight forward. They are simply addresses in memory, something fundamental to computers almost since Babbage. I don't know what VB has done to them but they are evidently a continuous cause of pain. Since much of the Windows API depends on pointers too, I really can't understand how folks actually manage to make VB programs do anything useful. :wink: Sorry, I can't be more helpful, but this is so disparaging. :cry: Regards, Pete

For either multiplayer or wideview you really need two or more good computers. For my own program, WideFS, you need one good computer running FS and the other computers can be anything to suit whatever programs you want to run on them. Many such programs are quite happy with very mediocre PCs. Regards, Pete

Ah. I see. The D3D rendering is irrelevant to WideFS as it doesn't deal with graphics at all. It only links one FS computer to others not running FS so that other application programs (not FS views) can link to FS from client PCs. I don't know of any program which send FS graphics to client PCs. WidevieW (not WideFS) is similar to Multiplayer in that it links several PCs all running FS. Regards, Pete

I don't remember how long the Button Pulse holds the flag for the button. Up until recently FSUIPC polled the joysticks once every 55 mSecs (i.e. 18 times per second), though that changed to 30 mSecs default in FSUIPC 3.22 and will be slightly faster still in the next version. You can speed it up by adding the PollInterval parameter to the main [buttons] section in the INI file (as described in the Advanced Users Guide), but you need to take care not to impair FS's performance. The joystick API doesn't do anything with the buttons except set the flag or clear it, as a button is pressed or released. The application of Button Pulse in EPIC was to simplify the original sequence which was "Button On -- Delay -- Button Off". Obviously having the delay in-line in EPL code made programming more difficult when sequences and other actions were required. In other words, the answer to your question is "it depends". I hope I've given you enough information to decide for yourself or experiment wisely! Regards, Pete

I'm sorry, I don't understand. Rendering of what, please? Regards, Pete

The order of the joysticks in FS's list doesn't necessarily reflect their numbering in the Windows joystick software, only the way they are listed in the registry. Compare the order in Game Controllers. In Windows 95/98 the USB Epic was a nightmare, because almost every time it was connected the order of the joysticks would be different, and even the numbers as seen in Windows were different. At least using Win2000 or XP has sorted that, but there are still some oddities. FS uses DirectInput for its joystick access, whilst I use the original Windows Joystick API. The joystick API is actually a subset of the full DirectInput (for instance supporting only 32 buttons per joystick instead of DirectInput's 64), so it is possible to have connections which aren't seen by FSUIPC, but I've not come across any yet. The work involved in moving to DirectInput is too horrendous to contemplate, and doing so would actually lose some of the flexibility I have (e.g. with treating POV inputs as up to 8 buttons). There's no need to observe or anyicipate anything, is there? Using FSUIPC you don't really need to worry about the joystick/button number. Just press and program. However, if you ever use any of my other EPIC supporting programs, like EPICINFO, you'd need the joystick numbers as seen by FSUIPC, not whatever FS seems to imply. Regards, Pete

Because that data is a character string not a number. I hope JD's answer helps you. Regards, Pete

Try 31A0. In fact, try writing to any or most of the assorted velocities and accelerations in offsets 3060-30B8 and 3178-31D0. FSUIPC does route these through to the Sim Engine. I don't know what effects you can generate, but certainly it is by manipulating things here that applications like carrier hooks and catapults have been implemented. I'm reasonably confident you'd be able to do something, but I don't know enough to advise you in detail I'm afraid. You will have to experiment. I doubt that you could add thrust on a glider because the internal data sections referring to engine behaviour and performance simply don't exist when there are no engines pre-defined. You'd need to fiddle it by constantly writing accelerations and/or velocities. Just ways of purpose-written scenery to interact with programs and vice-versa. The BGL can read/write those as well as a program. Regards, Pete

There are basically two ways -- the easy sledgehammer way (which actually my own TrafficLook uses) and the "correct way". The correct way is by reading the table size data and calculating which bits to read and which not. Then reading them, but only when flagged as changed. This is difficult and loong-winded to program, but very efficient at run time because you are causing minimum work. However, the brute-force method seems to work pretty well (try TrafficLook and see). This is simple declaring arrays of enough TCAS_DATA structures for all the aircraft, and reading them all, in one read per table. If you are only interested in the "bState" you are only interested in the two main tables, the traffic entries only, from E080 for ground and F080 for airborne traffic. So, your "pseudo code" (C to me, sorry) would be (omitting error checks for now: TCAS_DATA ground[96]; TCAS_DATA airborne[96]; DWORD dwResult; FSUIPC_Read (0xE080, 96 * sizeof(TCAS_DATA), (BYTE *) ground, &result); FSUIPC_Read (0xF080, 96 * sizeof(TCAS_DATA), (BYTE *) airborne, &result); FSUIPC_Process ... Now you have all the data in nice local tables in your memory and can access them as and how you like. This is exactly what TrafficLook does. Regards, Pete

Ah! rightsorry, I didn't see the "Traffic" part, which I now see was in your subject line but not in the message. It's just a number. I assume you are managing to find the TCAS entry you want? Please, what is then the problem? It sounds like you've done most of it if you've got that far. Regards, Pete

Okay, then now you are definitely into Project Magenta support areas. All FSUIPC does it toggle the bits in the offsets PM is using, It is then up to the PM software to see this and obey. I don't know what builds you are using from PM, but if you are not using the PM MCP then these controls need very recent builds. Even then I think some things might be broken. Please check with PM support. Sorry, I don't know, and I cannot really offer PM support. It works here with the builds I have (GC414, CDU351, MCP382). Can you check with PM support, please? All FSUIPC needs to do is waggle the bits, it is very simple. The rest is up to PM. Regards, Pete

What is the "bState" value? I'm not able to help with C# I'm afraid, so I hope someone else will jump in -- I assume the C# part of the SDK isn't sufficient? However, I don't even understand the value you want. :? Regards, Pete

There is no way I know to get locations of any actual buildings, roads, tectures, etc etc in FS's BGLs at run time. The "tower location" you can read in FSUIPC is a moveable thing -- you can set it in the Map dialogue. It you want it to coicide with the actual tower building, you can move it there and save the Flight. Regards, Pete

None at all, sorry. I've found no way at all to influence FS's local weather other than the visibility. this is actually mentioned in the documentation, and has been discussed a lot. I dearly wish I could intervene as I was able to in FS2002 and FS2000, but I've found no way at all. Check out FSMeteo and ActiveSky. I suspect that they provide wind limiting options, but in any case you can then apply some filtering in FSUIPC. Regards, Pete

If you are using a P4 3 GHz or better with hyperthreading enabled, just assign FS to one virtual CPU and everything else to another. If you are using an Athlon 64 FX53 or better you are probably going to be okay anyway. Anything else you are really going to be better off moving as much as you can off the FS PC. Just bear in mind that there is always an unavoidable latency when driving things over a LAN. This may only be 10-30 milliseconds much of the time, but there will be occasions when it is longer. I would never advise having the main FS flight controls on anything other than the main FS PC. The latency might not matter quite so much with heavy airliners but it certainly would make flying, for example, aerobatic aircraft, fighters and especially helicopters more difficult. So, consider if you can split things and if so how you'd split it. Regards, Pete

Well you can determine that by trying whatever it is you are thinking or running on a Client PC on the FS PC first, instead. If you like whatever it is you are running (assuming it is a separate program using the FSUIPC interface), and you'd prefer to have it running on a separate PC, then WideFS is justified. If you don't mind running it on the same screen as FS, or if you have two monitors and can run it with its Windows on the second monitor, then you don't need or want WideFS. Installing and setting up WideFS is not something I'd encourage unless you need it, and certainly I'm not really willing and able to support experiments "just to see", so I'm afraid there are no trial offers. Sorry. If you tell me what you are considering it for I might be able to advise on how useful it may be. Regards, Pete

Please find the Caps Lock key on your keyboard, and turn it off. All CAPS is harder to read and comes across as shouting. When you load WideClient is will display "Waiting for a Connection" until you load and run FS on the server, with WideServer installed. This is perfectly normal. Just proceed and run FS on the server. Regards, Pete

You are mixing up two completely different things. The "49" value for the PM interface is a parameter used for the direct PM interface. There's no Keysends, no alteration of WideClient.INI, no Keypresses at all involved with that. You say you've read the documentation, so please PLEASE tell me how you mix KeySends (which are for activating KeyPresses on Client PCs using WideFS) with explicit PM controls supported by FSUIPC directly and not involving WideFS whatsoever? Where are you linking these things together? Either use KeyPresses (and therefore WideFS's KeySend), or use the direct controls provided. It's probably better to use the controls -- the keypresses are intended for programs which, unlike PM, are not operated through PM offsets. That's more a question for PM support I'm afraid. But I would recommend you scrap all that anyway and use the PM controls as provided. Just delete the stuff you added to WideClient. Go to FSUIPC's Buttons page, press your button, find the PM control in the drop down list. If you look more carefully you will see you don't even need the "49" you found, you simply need one of these: Pm Nd Range Dec Pm Nd Range Inc Pm Nd2 Range Dec Pm Nd2 Range Inc You don't need any parameter with those, they are simple direct controls. I think it is just a matter that you ploughed into the Advanced User;s documentation and misunderstood it all. That is for Advanced users. Beginners should really stick to the easier stuff :wink: Next time you want a control, look through the list first to see if it there. I know it is long but it will be quicker! If you use KeySend, then, yes. The parameter in FSUIPC provides the KeySend number. With up to 255 different KeySends possible, there has to be some way to link them, do you see? Oddly enough, it is for providing parameters -- for those controls which use then, like the KeySend facilities, some of the PM facilities, and of course for those FS controls which need a value (mostly those ending with "Set"). Parameters are extra qualifying data, that's all. Your "72" is a Key stroke code and used wherever you want to define the key press 'H'. Your "49" was obviously (if you go look again) listed as a parameter for the PM GC Controls (By Param) facility, which you would only need to use if there was a function there you needed which wasn't listed separately as a PM control in any case. You may have read the documents but you seem to have linked several parts which are not linked either by narrative or reference. I really don't understand why or how you have done this, but you seem to have rather gone out of your way to make it seem as complicated as possible when, in fact, there was a listed control directly applicable to your needs which you didn't find. :( :( :? :cry: Pete

FSUIPC cannot smooth winds in local weather, and AS2004 uses local weather. In fact the only smoothing option in FSUIPC which works usefully in FS2004 is the one for visibility. Global weather control is problematic in FS2004 (see some of the notes about it above and in the docs, not to mention all the threads! :wink: ). Regards Pete

Okay, thanks. Actually I just checked, and it looks to be some default scaling value which is really messed up, way out of range. I expect it to be easy to fix, and would do it straight-away if it were not for the inconvenience of having too much other code half-baked as yet. For now you could try using the control with the reverse range included (PropPitchR12) and just calibrate the reverse zone to be negligible or non-existent. Regards, Pete

No, not axes at present. Only buttons and switches. For flight control axes it isn't a good idea because of the latency (delays involved), but I suppose it could be useful for other axis assignments, like flap setting perhaps. But it isn't a facility high on my list. Sorry. You could check out FS Communicator http://www.flightsimulator.at/frm_fscom.htm. I think it might be able to do this and more. Regards, Pete

No, not at present. Only buttons and switches. For flight control axes it isn't a good idea because of the latency (delays involved), but I suppose it could be useful for other axis assignments, like flap setting perhaps. But it isn't a facility high on my list. Sorry. Regards, Pete

If you bought it from SimMarket, go to http://www.simmarket.com and open your account. If you got it anywhere else you need to contact the supplier. Next time you register you should consider keeping a copy off the PC, maybe printout the FSUIPC.KEY file or keep a copy on a diskette or something. Regards, Pete

Er .. I have no "Prop RPM 1-2" controls listed. Do you mean "PropPitch12" or "PropPitchR12"? I can check it out here if you let me know. The version and registered state of FSUIPC is nothing to do with PFC.DLL. It's a shame you didn't report it earlier, as I am in the middle of massive changes to PFC.DLL and cannot possibly release an update for several weeks. If I can reproduce the problem I will do, but the next release is likely to be in July or later now. Sorry. Please confirm which control it is you are attempting to assign. Regards, Pete

If it is freeware it may already have a Key for FSUIPC -- check the Freeware Keys sticky thread above. If you never want any such problem in future you can of course purchase a registration for FSUIPC yourself. Full details of what you get are found in the User Guide documentation within the FSUIPC.ZIP. If you are not interested in any of the facilities offered, but just want to run freeware, then the keys wil be in the list for those I've been asked about and know. For others it depends whether they are "alive" (still maintained by their authors) or not. If they are, it is more polite to ask the author first. I have supplied very many freeware authors with keys for their programs, and many of them make this process automatic -- invisible to the user. That is the best way. Regards, Pete