Pete Dowson

So don't you make any time for any other process (apart from the process switches enforced by the FSUIPC Process calls)? That's why I thought a message or timer based system best. Where do you get to process Windows messages, or is this loop in its own thread? What's the key got to do with it? Don't bother with that. Just check the slew mode flag at the appropriate FS offset. Regards, Pete

So don't you make any time for any other process (apart from the process switches enforced by the FSUIPC Process calls)? That's why I though a message or timer based system best. Where do you get to process Windows messages, or is this loop in its own thread? What's the key got to do with it? Don't bother with that. Just check the slew mode flag at the appropriate FS offset. You seem to be trying to make it difficult for yourself :) Regards, Pete

Version 3.08 is way out of date now. I would be advising you to update FSUIPC to 3.11, but now you might as well wait a few days for 3.12 (and a new TrafficLook) which I hope to release over the weekend. Why are you editing the INI file? You have a registered copy of FSUIPC. Just go to the Technical page in the FSUIPC Options (ALT M F) and make your selection there. However, Airline + Tail number is not an option I provide. the Airline name goes with the Flight number -- that's how they are referred to by ATC. Only the GA aircraft will have the tail number in that mode. That's correct. If you are using FS2004, wait for FSUIPC 3.12 and the updated TrafficLook. This provides departure and arrival airports (ICAO ids) for all aircraft, both airborne and ground. You would also find TrafficBoard very useful. The version for FS2002 was really good, and the one for FS2004 is being prepared now, I understand. It's derived from the FS reference number for that aircraft, and is unique. It is actually the negative of the ID in the FSUIPC slot, which is used by TCAS programs, TrafficBoard and Radar Contact, amongst others, to keep track of things. I've not really got much time to spend on applications -- TrafficLook and WeatherSet were really just written to test FSUIPC's data, and as an example of what can be done. However, in the new version of TrafficLook you can move the columns around and re-size them, and all that is remembered. The printout is in the same order, terminating according to page width (landscape) -- so you could do what you want to that way. Alternatively you could "print to file" and get a text representation. Anyway, have a play with it when it is released (with FSUIPC 3.12) and if you still want a "copy to clipboard" facility let me know and I'll put it on the list. It'll only get done when I'm held up on one of the many other things I have to do, though! Oh dear. Please check the Announcements at the top of the forum now and then. FSUIPC 3.11 was released on the 10th October, over a month ago now! Regards, Pete

I thought that timeout only applied to conflicts -- i.e. where two aircraft are facing each other and not able to move. The time was reduced in response to complaints about this in FS2002. It is a possibility, if only it could be found. I'm not sure how to do such a thing, but I will make a note in case I come across a way. Regards, Pete

Yes, just enter the registration again. Copying the key file is not enough. There is no back-handed spying by FSUIPC. Regards, Pete

I calculated 512 Bytes because each FLOAT64 is 8 bytes len. In 512 Bytes there are space for (only!) 64 FLOAT64 variables. Use 32 bit floats (C !"float" type). They are most certainly accurate enough for most purposes. In fact for most gauges you can use words or even bytes -- Fs's turn coordinator and slip ball use one byte each! Depending on how fast you want to update these, and whether you are running on the FS PC or via WideFS, you can re-use the same few bytes for many gauges. You just write the gauge number and its indication, wait for the gauge number to be cleared in acknowledgement, then write the next. I'm not saying you should do this, but some gauges need fast updates, some don't. Multiple fuel gauges, for instance, are an example where a serial update would be fine. Regards, Pete

It's just that if FSUIPC does all these "little" things, it will be huge and slow. I have to resist them, I give in to too many as it is. When something is so easily possible without a fiddle in FSUIPC, then I resist more strongly. This is one such. If an external autopilot can control FS precisely, split second by split second, it must be very easy to "fix" any change in Sim Rate. If your users are getting away with it for a whple second, or even a significant proportion of one, your timing is too lax. I don't know what you mean exactly by a loop, but I would certainly implement it all as a TimerProc, entered very frequently (even up to 55 mSecs -- one timer tick), counting entries, and doing different things at different intervals, eg "AND" the count with 3 for something repeated every 220 mSecs, and so on. Where did you learn that? There are (or used to be) a limited number of timers, but FS works on timers, quite fundamentally. All you need is one SetTimer specifying a TimerProc, then base all your other actions on multiples of the entries to that Procedure, i.e a count. Sorry if this is in C terms and you use VB or Delphi, but I'm sure the facilities are the same. You can certainly check for slew mode the same as you can check for a Sim Rate change, and stop it directly. Checking for a sudden change of location (not by slew but by direct placement) is another matter. I'm sure you can do that too -- if you check position every 10 mSecs or so and compare positions you should be able to calculate an impossible speed. Just calculate the distance between them and allow a maximum speed. There's no other way. Regards, Pete

Use 6420-661F for now. I'd prefer this to be smaller. Most applications (greedy Project Magenta excepted) manage on a lot less. If others need allocations yours will be split. But 512 bytes for inter-module communications is quite big. I'd advice against sending text data or complete flight plans this way. It is better to have files in a common folder and just use the communication here to synchronise and signal. And multiple uses of other areas can be signalled by "data type" indications in one location, and a handshake from the recipient in another. The area 6420-661F inclusive is currently marked "temporary" for you. If I need some of it before you release it, I will be back! :lol: Regards, Pete

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