Pete Dowson

That's rather odd. The CDU shouldn't be trying to send all that much, certainly not as much as the MCP. Are the errors still on Send mostly? Do you need to use the MCP graphic itself? If not then try that on the FS PC with the graphic minimised. That works well for me. Otherwise I think it is better on the same PC as the CDU as there is likely to be a lot of interaction between them. Put CDU, MCP and EICAS on your fastest Client, PFD/ND on the other. Did you check the GC/EICAS graphics frame rates? (Press F). Make sure it is using hardware acceleration for OpenGL. You may get more advice about PM arrangements on the PM Newsgroup. Most of the experts hang out there and many folks have been working al this stuff out for years! Regards, Pete

But if it is for such a short time, would it matter? If it is on a joystick input, or asigned through FSUIPC as an FS control, FSUIPC can intercept it, but if it is a keyboard assignment in FS, I don't see it. I could do the same as you, watch it and set it back to 1 if it changes, and of course FSUIPC would be faster, but as you should be able to do it within milliseconds anyway I don't really see that it is needed in FSUIPC. Can you clarify more on the timing? Maybe your loop is fast enough for your other things, but not for checks like this. Maybe you should put all such checks into a faster loop, say every 110 or 220 mSecs (2 or 4 Windows TIMER ticks)? I'd really rather not 'clutter' FSUIPC with such odd things unnecessarily. Regards, Pete

All I do is toggle bit 2^0 in offset 510. The rest is up to Enrico's software. I'm sure you can monitor the value in 510 yourself to see what it does -- use the facility in the PM FMS, or the FSUIPC Monitor (on the Logging page). There are also FSUIPC PM controls which turn all on and turn all off -- these clear the bit and set the bit, respectively. They all worked fine when I implemented them, so maybe something's changed in the PM software? Please check the operation of the bit in 510 and if that looks good I'm afraid you need to ask Enrico. Regards, Pete

0x4D2 is precipitation control, just a little further down than the ones you found. But beware, FS weather is more complex and whilst you may be able to start rain this way, it may not stay. FS2004 is always dealing with localised weather and it changes. See the "IMPORTANT" notes in one of the Announcements above. Regards, Pete

It should have nothing whatsoever to do with the speed of the client. your client logs showed blocking on sends, which means the client is working fast enough to send that many messages to the Server that it isn't keeping up. If setting the Limiter to 20 doesn't fix this, you have certainly got something strange going on. Something is holding up messages leaving your client. In that case I am lost. i have no idea why your Server is not processing the incoming messages fast enough. It makes no sense. And how come you have two clients sending lots of messages TO the server in any case? Normally only control programs like Project Magentas MCP would be sending so many. What else it sending things? Most receive only. In fact WideServer is optimised to do a LOT more sending than receiving! Your log showed only a little data loss to the clients anyway, quite minor. It seems to be mainly the reverse problem you have, data being sent to the Server being blocked. What aps have you got sending data to the Server? BTW I still think 35 fps is too fast for this. :o Regards, Pete

I'm afraid I'm out of my depth already here. I only really ever programmed the ISA EPIC, I don't know much about all this stuff with the new USB EPIC and "virtual axes". Sorry. If no one else here can help I can only suggest getting onto EPIC support. Regards, Pete

Do you mean to say you didn't even bother to try reducing it to see if that was the problem? Why is 20 fps too slow? Surely 20 fps all the time, on your FS PC and your clients, nice and smooth, is far better than 35 fps sometimes dipping and with clients stuttering like crazy? I find 20 fps very smooth on FS2004. What's the problem with it? If you aren't even willing to try it, to see if the problems you are having are merely performance, why ask me to help? :( If it is okay at 20, raise it to 25, if okay at 25, raise it to 30. find the "sweet spot". IPX (actually it is SPX it uses) is a lot simpler in terms of implementation. There are a lot less levels involved, so it is more efficient. I've always preferred it. However, there is no doubt that is can be a pain with Windows NT/2K/XP. However, there are folks using it, so you could try. TCP/IP has the advantage that users will generally have it installed already, and it is less of a problem to set up on systems with any of WinNT/2K/XP involved. It is also the only one really being developed and supported by Microaoft in any case, so it gets better with each windows release (at least it is a lot better in XP than it was in NT). Most of the improvements I've made (and they are mostly timing changes, not fundamental things) in the last year or so have been aimed at getting WideFs running smoothly using TCP/IP. I think this has been achieved. The main change this year has been between FS2002 and FS2004. the demands on the processor from FS2004 are much greater. This leads to a greater need for WideFs to be set up well and given enough time. Please use the default values. Most of them took many weeks of testing and adjusting to get "just so". At least delete your "AutoUpdateTime" and "MaximumBlock" parameters. Why did you change them? Again, apart from adding your Server's name or IP address, please let the parameters default. Delete the "Timeout=0" line, that could certainly make a mess of the timings. I spent a lot of time trying to get the best, smoothest, performance on the majority of systems, and the defaults are set for that. ALWAYS use default values first, only adjust any when you find you need to, or under advice. Regards, Pete

I checked and Simmarket are down at present but should be back up within 2 hours. I have been told that all orders until 11pm last night (German time) have been processed, so if you placed yours on the 9th something else is wrong, and you should certainly get in touch with their Customer Services, as soon as they are back up. Regards, Pete

I've got some more information: "since 5am this morning (German time I assume) SimMarket is down with a domain resolution problem. it should be back up in the next 2 hours." Regards, Pete

I'm sorry, I am not at all involved in the SimMarket operations. I am the programmer and I do development and support. The whole of the sales side is by SimMarket. If you don't receive a Key within 24 hours of your order something may be wrong. Check with Customer services via http://www.simmarket.com. Regards, Pete

As it says on the site, allow 24 hours then write to their Customer Services (http://www.simmarket.com) in case something's gone wrong. I see from another message that the market part of the site was down recently (still is maybe, I'll go check), so that may be the reason. Regards, Pete

SimMarket is operated by SimFlight, same as these Forums, so it must be just temporary. Please try again later. I'll also ask the manager what is going on. Maybe it is merely maintenance, maybe a breakdown. Regards, Pete

Take care. Location 0x5600 is used by Project Magenta. If you need a work area in FSUIPC offset space you need to get it reserved first so it doesn't conflict with anyone else. Work out how much you need (try to keep it reasonably small please), and ask me for the area and I will mark it for your use. I am not surprised! The offset range 0000 to FFFF supported by FSUIPC is an illusion, not a coherent area of memory. Some is indeed in Globals.DLL, but not at those offsets. Some is in SIM1.DLL, some in FLIGHT.DLL, etc etc., but never at the same place - SIM1's structures for instance are completely reallocated and rebuilt each time you load an aircraft. Some doesn't exist as such, but invoke procedure calls which supply the data. There are more and more like that. Indeed, many locations now do different things when written to than when read. The only way to address FSUIPC offsets is through the interface provided by FSUIPC. That passes the request through the mapping procedures which get the access done, whatever it is. From an external program you use the regular Library (or at least its methods) as supplied by the SDK. This uses memory file mapping and message passing to transfer the data. From an internal FS module you use the internal module user's library, or equivalent code. This is also supplied in the SDK. The interface it provides is almost identical -- the only differences are in the FSUIPC_Open() call, now FSUIPC_Open2(), in which you also supply the transfer memory. There is no memory file as it isn't needed within the one process. There is still the message send by FSUIPC_Process. Regards, Pete

ALT M F gets you into FSUIPC options. Select "Buttons". Operate the Gear lever of the PFC. Allocate some other function to it. FSUIPC user guide documents contain information on programming buttons, but it should be pretty obvious in any case. I don't realy want to reproduce it here. Regards, Pete

Ah, yes it is! :wink: In version 3.07 I added a separate HotKey to do exactly what you are asking. Actually, I thought the coupling thing was only a problem with 3 Engined aircraft, it's always seemed consistent for others. Nevertheless, what you want is the HotKey called "Resume All-Engine Control". It's the bottom left one on the Hot Key page in FSUIPC options. As it says in the documents, mainly for more precise end points and null zones. However, for throttles the mapping on a single throttle to the (up tp) 4 separate throttles gives you a potential axis range with reverse as well as forward. You then calibrate the "centre" where you want the idle position to be, and make the "dead zone" there wide enough to find it reliably. Check the Joystick section in the documentation for more details, if this interests you. Regards, Pete

It sounds very much as if you have some mis-assigned keys there. Try FS's own Options-Controls-Assignments, and elect to restore defaults there. If you've been assigning keys in FSUIPC, either go into its Keys page and check them/ delete them. If al else fails, you may need to delete your FS9.CFG file to make FS restore everything as it should be. you can also delete the FSUIPC.INI file in the Modules folder, in case there are rogue assignments there, or just edit it and delete the appropriate sections. Regards, Pete

Throttle sync copies your throttle 1 input to the other throttles, ignoring your other throttle inputs. For this it needs multiple throttle inputs. How many throttles do you have -- are they calibrated in FSUIPC's multiple throttles page, in the Joysticks section? If you only have a single throttle lever then don't use "throttle sync", it isn't needed as your single throttle input will normally be used for all engines in any case, unless you've separated them by E+1, etc. If you've done this, re-sync them by E+1 2 3 4. Regards, Pete

Sorry. Actually I am almost the last person to ask, since I don't use MP. In fact I've never used it except for one experiment with it when it first appeared, back in, what, FS98 was it? Or FS2000? Can't even remember. There are others who pop in here who may know, though. Regards, Pete

Since version 3 of FSUIPC, programs need a key to access FSUIPC. This is freely provided to free programs like AFCAD, and in fact it is built into the latest version of AFCAD (for FS2004), but for the earlier version, which pre-dates FSUIPC 3, you have to enter the key manually. If you check the "sticky" thread near the top of this Forum, the one talking about Freeware Keys, you will find a 12-character key there for AFCAD. This is what you need. When you run FS, go into the FSUIPC options (via the Modules menu) and press the button near bottom right to register a program, then enter the program name (AFCAD) and the Key where shown. There's more explanation if you need it in the FSUIPC User Guide, which is provided in the FSUIPC Zip file in both PDF (Acrobat) and Word format. Regards, Pete

Okay. Two things about this. First, 512Kb was great for FS2002 but I think you'll find better performance with more memory -- and at present it is a pretty cheap upgrade, so well worthwhile. However, this depends on your Operating System, which you don't mention. You'd need Windows XP (or 2000). I think the "sweet spot" for FS alone is about 768Mb, but you are better off with 1Gb with other things (like WideServer, FSUIPC) running too. Second, I found WideFs ran best in FS2004 on my 2.4 Gb Pentium 4 with the frame rate limiter set at 25 or even 20. In fact I've now upgraded to a 3.2 Pentium and still have the limiter set to 20! This way I can have everything turned up max in FS and feed 4 WideClients smoothly at 20 fps too. FS stays at 19.9 fps most all the time (on my 2.4 GHz it dipped well below that now and then if I dared have all the settings to max). In other words, unless you have graphics and AI turned down I think 35 fps is still too high. But by all means experiment, see what you find. Your Server LOG shows no Netwrok problems, which makes me even more convinced it is just a performance bottleneck problem. Regards, Pete

Please read the Announcements at the top of this Forum, especially the ones about going Payware. Also, in the FSUIPC SDK (available on http://www.schiratti.com/dowson) there's an Access Registration document explaining more. If you are not interfacing any program to it, and not selling it as part of a product, then what there is left of it is 'free' -- user's cannot access most of the facilities unless it is registered in any case, and only Freeware programs with free access keys, and commercial programs with purchased access keys, can interface to it. For any other commercial arrangement you need to read the documents and contact me on petedowson@btconnect.com. Regards, Pete

No. CFS3 is a closed program. There is no way to add more modules. CFS1 and CFS2 were based on the FS design, so some parts of FSUIPC (and my other modules) did work on those, but CFS3 took a completely different dead-end direction and is as closed up as most 'games'. Regards, Pete

It is possibly a performance problem. It looks like the Server is not responding fast enough so messages from clients are piling up. How many clients do you have? What is the processor where FS + WideServer is running? What is your FS frame rate limiter set to? What is the Network - 10 or 100 Mbps, and is it via a hub or switch? A look at the WideServer.log may help too. Anyways, try, as an experiment, severely reducing your FS frame rate limit. If this helps, then the problem is that WideServer is not getting enough FS PC time to meet all the demans from the clients whilst also trying to send stuff out at FS's frame rates. You may find a "sweet spot" that suits your set up. There are some parameters to limit the Server actions so it doesn't send so much out, but in general it is better to achieve a balance without using those. Regards, Pete

Well, for recording I can see there are controls "DEMO_RECORD_1_SEC", "DEMO_RECORD_5_SEC", and "DEMO_STOP", but I don't see anything off-hand to start a playback, so I think maybe it isn't possible. As described in the WideFS documentation, keypresses on a Client, if received by WideClient (i.e. it must have keyboard focus), can be relayed to FS by setting "SendKeyPresses=Yes", but you cannot access Menus this way as that needs the ALT key. If you are writing a program with an FSUIPC interface, then key presses can be sent via offset 3200, and controls via 3110 (see the FSUIPC SDK). But, again, accessing the menu this way can be problematic because as soon as the Menu opens, FSUIPC is no longer running and so cannot send more keys. Regards, Pete

All the details are in the FSUIPC SDK, in the documentation about access registration. Also please see the "Sticky" message about Freeware Keys, above, which gives the email address for your application. Thanks, Pete