Pete Dowson

Yes, for some of the facilities -- the same things are not provided on both. Please see the examples and descriptions in the user guide. By the way, the current version is 3.135. Regards, Pete

WidevieW links multiple FS installations. If you are displaying scenery you really need the full FS installation on each such PC, and ideally they all need to have the same power -- otherwise the slower ones will be pretty jerky. I use a Parhelia card with three monitors on one PC. With most current video cards you can have two monitors. I don't think WidevieW is out yet for FS2004, but it is on its way. As far as the instruments are concerned, if you mean FS cockpits then, again, that's another full FS installation. Otherwise you are looking at external instrumentation systems like Project Magenta, or possibly FreeFD. Those will operate through WideFS with no addition FS installation. Regards, Pete

Not at present. The assorted links between two FS installations always have one of them as Master and the other Observer (WidevieW and MP in observer mode), or flying different aircraft (normal multiplayer). You could conceivably use the master/observer type link and have some programming to transmit the controls from one PC to the other, but I suspect the latency would make it a bit erratic. A better alternative would be to swap the master/observer roles when control is passed from one pilot to the other, but then you haven't really got dual controls as such. Regards, Pete

FSUIPC has facilities for up to 4 each of aileron, elevator, rudder, throttle, left and right brakes. Please see the section entitled "Multiple Joysticks" in the Advanced Users Guide supplied in the FSUIPC.ZIP package. You don't really get "independent" control -- that would be impossible, as there's only one set of ailerons, elevators, and so on to control, and why would one pilot want to climb/bank left whilst the other descended/banked right? :) FSUIPC takes the maximum deflection of each of the 4 connected controls in each case, so it is best if the non-flying pilot just left them alone. Regards, Pete

Sorry, all FSUIPC can do is pass on the weather settings to FS2004. There's nothing it will be doing to either change or fix winds. There's probably some settings in AS2004 -- I think most folks get too many nasty wind changes and this may possibly be part of the attempted fix for those. The wind shifts seem to be a problem inside FS2004 as I can get them with all weather sources, including FS's own weather downloads. You should be able to get some help in the AS2004 support areas/forums, I expect it's a matter of getting some settings right. Regards, Pete

Hmmm. I can't understand that. And doesn't it conflict with your other report about it crashing? It sounds like your parameter may be in the wrong part of the INI file. There's actually no number "29" anywhere in the program EXCEPT to define the default for that particular parameter. Whatever number is substituted is used to allocate the memory space for the checkpoint data. Looking through the code (which is many years old now and getting difficult for me to remember!) it looks like the only likely reason for a crash with too many waypoints would be the actual size of the output files. Currently it just pre-allocates rather more space than any (originally possibly) valid result would need. But an output requirement more than double that would possibly crash it. Additional waypoints a few above the 29 shouldn't, though. I'll need to do tests, next week. Whatever your problem is, it doesn't look a trivial job I'm afraid. The code isn't even completely compatible with the compiler I'm using now, so there's going to have to be a bit of a conversion job first. Pete

Hmmm. There's a lot of local climatological infomation built in then? I certainly didn't know that. How would it know to improve the weather or worsen it? It can't be at random, surely, as the supplied themes seem to change in a specific described direction. Yes, but if these are merely static weather sets, as WX files would be, what is the difference, the advantage of themes over any savesd set of FLT+WX files? Regards, Pete

Odd, most seem to manage okay. That system is about 6 years old now and the documentation has got better, not worse (or at least that's what I hoped and tried for). What does "holds the key" mean? Do you just want to use "Push To Talk"? If so, with Roger Wilco you don't need any key. The special keywords "RWon" and "RWoff" are provided, as explained in the documentation. If you want to use WideServer, you need to work out the button number to put there in place of ?????. But it is far easier to do in FSUIPC's Button's page. Check the FSUIPC User Guide, assign your button (which you only have to press for FSUIPC to identify) to the KeySend control, and set it with parameter 1 for press, 2 for release (for example). If all you want is Push To Talk in RW, assign RWon to the KeySend number allocated to the press (1 say) and RWoff to the KeySend number allocated to release (2 say). i.e KeySend1=RWon KeySend2=RWoff I'm not going to repeat the rest of the documentation here, but you should really have read enough to see that Roger Wilco PTT is treated specially, in both WideFS and FSUIPC documentation. These are the codes used in FSUIPC's INI file. Why do you want to know those? Please DO NOT BOTHER TRYING TO EDIT FSUIPC's INI file! I have gone to great lengths to make all that stuff as easy as possible in the Options screen. Just press ALT M F, find the Buttons page, and read the FSUIPC User Guide section on this (NOT the "Advanced" Users Guide, which is for Advanced users! :) ). Sorry. I do try my best with the documentation, which seems to work for most. I really do hope it is not really as complex as you make out -- you seem to have actually gone well out of your way to get so confused! I'm not sure how to improve it beyond explaining how to do things and giving examples as I do. Please read the easier stuff before the advanced stuff. To summarise: use FSUIPC's Buttons page. Do NOT even look in the FSUIPC.INI or WideServer.INI files. There is no need. It is all quite simple if you don't want to do clever things. Regards, Pete

Is there no limit in RC now? I didn't know that! No one tells me these things. I haven't got time this week -- I am back to programming work next week,, and I'll look then. I really wouln't be that surprised if FStarRC didn't allocate enough memory for as many waypoints. Regards, Pete

No, FSUIPC isn't contributing to that. The only reason for the different timing is the slight difference in memory arrangements and time processing messages. It sounds like something related to video drivers and interaction with DX9. I use a Parhelia too, but with no panel displayed, only scenery. The latest drivers (1.05 something) seem pretty reliable. But possibly some of the Display options in FS need changing? Sorry, I've really got no other ideas at present. Experimentation is the key I fear. Regards, Pete

You can try writing to anything, to see if it does anything, but I don't think you can change the aircraft's airspeed or grpondspeed like that -- the speed is a result of thrust and acceleration and is dynamically re-calculated each frame. You influence it by increasing thrust, or diving. You may be able to make a temporary effect by writing to some of the accelerations. I think this is how the catapult and braking applications work. Regards, Pete

I don't recall there being any of that when I used the beta theme generator, but not sure. What's the point of themes if they are just static weather? Isn't that the same as defining static weather? I though themes had moving fronts, developing storms, stuff like that. A sort of "weather script". If not, what is the point of them? It baffles me even further why you should need to develop weather in one form and convert it to another, especially if there's no programmatic element to it, like development over time. Colour me confused! :o Best Regards & Happy New Year! Pete

Possibly -- IPX/SPX should be okay with a 100% Win98SE set up. If you are using WinXP or WinMe I'd be very suspicious of IPX/SPX in any case. Smoothness shouldn't be a problem with TCP/IP, unless you have too much of the server processing time being hogged by FS, not allowing the (certainly less efficient) TCP/IP stuff to operate. Try reducing the FS frame rate limiter more. I hope you find the answer. Regards, Pete

To be honest I don't know anything about themes and scenarios. I thought they used rather different data internally than straight-forward WX files. The latter just contain a list of weather settings for Global and each of any number of weather stations by ICAO id. I thought the scenarios included data about how things are to develop. Is this not the case? When you've programmed a scenerio, where do you put it and how do you load it? Is this all via the Themes list in the ALT W W dialogue? :D No -- wrong scale anyway. my model railway is N-gauge (2mm to the foot), so the hoverfly would look monstrous. Anyway, while I learn to fly the thing properly I need lots of relatively unobstructed space! :lol: Best, Pete

If that is used as the limit for the process call then it is too big -- neither WideFS nor FSUIPC will handle that correctly. 32512 is correct (hex 7F00). the value 65568 is rather peculiar in any case, being 33 more than the largest possible 16-bit number. Okay. I hope it is easy to resolve. I look forward to hearing from you when it is! In case it helps, this the is active statement in the C code: m_pNext = m_pView; It actually does this BEFORE the call to FSUIPC, but after marking the end of the data with a 32-bit zero word, thus: ZeroMemory(m_pNext, 4); // Terminator Because it also then uses the same pointer to process the returns from READs, it resets the pointer to the beginning of the buffer again, just before the exit: m_pNext = m_pView; *pdwResult = FSUIPC_ERR_OK; return TRUE; Maybe this apparently redundant, but certainly not, repetition is omitted in the C# version? Incidentally, even this stuff isn't really my code. FSUIPC uses the original interface from FS5IPC/FS6IPC, and the code was written by Adam Szofran (it isn't my style, actually -- mine is rather more obscure! :) ). Regards, Pete

I'm sorry, but neither of those is a language I'm familiar with. Can you contact the author for clarification? It sounds like the pointer to the next free position in the memory file map is not being reset in whatever is the equivalent to the FSUIPC_Process call. I only programmed the C library code, of which the source is provided. I know that works. Also the Delphi package must work, as that is used in FSInterrogate. The VB stuff must work as most of the FSUIPC utilities folks write use that, so it is sounding now like there's a bug in the C# code. The FSUIPC/WideFS interface doesn't support block sizes larger than around 30-31k including all the red tape that is added. Even if your local C# code is changed to accept such, the Process call will go wrong in WideFS or FSUIPC -- I'm not sure what you'd get, probably just most of the block ignored. Where do you get this "default" buffer size from? In all my code the maximum block for FSUIPC_Porcess is defined by #define MAX_SIZE 0x7F00 // Largest data (kept below 32k to avoid // any possible 16-bit sign problems) (see the IPCuser.c file original Lib_source). There is no "default 64k buffer" in anything I've provided. For each individual read/write a number of bytes of red tape are added. See the header files for that. No necessarily. It may be an error in the C# code provided in the SDK. I'm afraid I just provide whatever is provided for me. If you understand C# please check it and let me know. You could compare it with known working code, like the C, VB and Delphi versions. Regards, Pete

Oh, good -- glad you found it! Did you see this via FSUIPC's logging? Regards, Pete

Sorry, you need to explain this further. Try FSInterrogate, set it to read 64k and it will read them all day. It isn't a good idea, of course, but it produces no errors. There is a limit of around 30k or so per single "Process" call. An FSUIPC_Read or FSUIPC_Write should return an error if you try more than that, but I cannot swear that all the language examples impose this. . It is nothing to do with that. There's an imposed limit on the amount of data processed by a single FSUIPC_Process call, that's all. It resets the pointers which FSUIPC_Process would also, once the transfer is complete. Yes, use FSUIPC_Process calls more often, at least once per 16k. Yes, it is called FSUIPC_Process -- you can see the code yourself and work out what is going on. FSInterrogate is the program to play with to see what is happening. Also my own TrafficLook transfers 16k at a time with no problems. Regards, Pete

It's working fine here. For example here are the log entries I got. ********* EPICINFO Module, Version 4.22 (9DEC03) by Pete Dowson Panel=AIRCRAFT\b737_400\panel\panel.cfg Epic Ref= Default CFG: Reading N:\FS9\EPICINFO.CFG ************************************************ CFG: Processing section [All] CFG: Log=1 CFG: Sets=CP ************************************************ 985 QP103 = Initialisation Done 1000 QP097 sent, orig val=32767 [0x40DFFFC000000000] PARKING_BRAKE_POS ... 12235 QP096 sent, orig val=0 [0x0000000000000000] PARKING_BRAKE_POS ... 13875 QP097 sent, orig val=32767 [0x40DFFFC000000000] PARKING_BRAKE_POS This is with FSUIPC 3.135 also installed, but i don't see how that makes any difference. the "PARKING_BRAKE_POS" token is working the same in FS2004 as it did in FS2002 and before, and that is all EpicInfo is using. That can be checked with FSLook. Also the same value is at offset 0BC8 in FSUIPC -- you can monitor that (as a U16 type value) in FSUIPC's monitoring facilities. I tested all this with default aircraft only. I'm sorry, I don't know what else I can do. Certainly none of that part of EPICINFO is any different to the way it has ever been, and it seems FS2004 is the same in that area too. Maybe you just aren't selecting these (set CP, or explicit selection)? Regards, Pete

There is nothing changed in FSUIPC which affects any of those things, unless (a) the Dream Fleet 737 does use FSUIPC for them (though I don't see why it would), and (b) you did not register your copy of FSUIPC and Dream Fleet provided no access key for FSUIPC. You see, since version 3.00, FSUIPC is only free for FreeWare access. If you register it and enter your Key then all the facilities are available to you and also, as a bonus, all programs will work with it without needing an access key. Many commercial add-ons are licensed for FSUIPC and do have an access key. You say "I never expected this because on your site dreamfleet 737-400 isnt standing in the list of software using FSUIPC.", but I do not list software using FSUIPC -- I have no way of knowing, as use of the SDK is free. This forum is my only "site", and I don't even try to list any programs. Possibly you are referring to the Enrico Schiratti page containing my software? I know he allows free listing of FSUIPC clients on that page, but I think they are by request of the publishers. You could easily test whether the DF737 needs FSUIPC by removing FSUIPC altogether and seeing if it all still works correctly. Also, if it is trying to use FSUIPC and you have version 3.135 installed, there should be some entry in the FSUIPC Log, and possibly a message box occurring telling you it isn't accredited, if indeed it is not. Regards, Pete

FSUIPC doesn't touch any of the axes unless asked to, so if it is okay with FSUIPC removed it sounds like something is actually using FSUIPC to do this. Is it the same with all aircraft? Is the Rudder section in FSUIPC options definitely showing "Set" in the leftmost button and not "Reset"? Switch on FSUIPC's IPC write logging, and also Monitor locations 0BBA, 0BBC and 332C (all as type "S16" in decimal) to the Log as well. Just run long enough to get the problem, then close FS, ZIP up the FSUIPC.LOG and FSUIPC.INI files, also the FS9.CFG file, and send them to petedowson@btconnect.com. I'll see if I can figure out what is going on. Regards, Pete

No. Two reasons -- no one ever asked and I don't see a reason for this as most folks are interested more in real weather, but much more importantly I have absolutely no idea how to do such a thing. What sort of use would you see of such a facility? No, unfortunatel not :? .... but I've saving my pennies and hope to get one this year! :D. Santa did bring me a Hoverfly helo though (http://www.snelflight.co.uk) which I've been crashing quite regularly these last few days whilst away from base. :D :shock: :D :shock: Happy New Year! Regards, Pete

No. Did you use the Logging facilities to find out what is going on? Is this with FS98, FS2000, FS2002 or FS2004, or all of them? I'll check here when I catch up with things (I was away for a few days). If it isn't listed, no. However, you can read/write anything in FSUIPC using the direct access FSUIPC facilities, if you need this. A happy new year to you too! Regards, Pete

It looks like you are getting occasional garbage on this connection -- this could be a LAN driver problem, but it could equally be a bad cable, bad connection or faulty network card. However, I doubt whether these odd few errors would give you any consistent lag in specific values being updated. Quite honestly I don't even know whether the V-speeds are updated through WideFS and FSUIPC or directly via the NetDir files mechanism PM uses. You really need to chat to the PM folks. Try the Newsgroup. Regards, Pete

Thank you very much! Happy New Year! Pete Dowson