Pete Dowson

There's some stuff for Java in the current FSUIPC SDK (on http://www.schiratti.com/dowson). This was kindly contributed by Mark Burton. I don't know anything about Java, but he says he's provided Java sources for Class-based access to FSUIPC. There's a lot of stuff in the ZIP he provided, including Help in html format. Regards, Pete

Of course. That is the sole and only "point" of GPSout. What did you think it was for? It can't do anything else. I thought you must have already known that, from its description, and that you were asking only if GPSout needed FSUIPC. Regards, Pete

Since the word at 0D0C contains one bit for each light switch you need to apply a mask. For instance, for the Strobes (as an example), which are switched by bit 4, you'd need 9=VW0D0C.0010=X0010,6,0 Bit 4 is the 4th bit up counting from 0: in binary 1 0 0 0 0, in hex 10. This is 16 in decimal (2^4 = 16). So, the mask of 0010 is applied, so that only that one bit is selected, then you compare the result with 0010, which is what you'll get if the switch is on. Et cetera. Regards, Pete

It sounds like you need to set the frame rate limiter in FS2004 a bit lower, otherwise it is grabbing all the processor it can, so that when a third party program does get control it has more to catch up on. If FS is forced to relinquish more often because it hits the limiter, then the third party activities will be spread out better. There are no synchronisation objects between apps and FSUIPC. It's a simple message passing/message processing interface. There's no difference -- data arrives at FSUIPC in exactly the same format, whether routed by a Message from another process in the same PC, or from WideServer. they all go through exactly the same code. Of course WideServer isn't switching processes all the time, only threads. As far back as I can remember it has ALWAYS been beneficial to FS's smooth performance to move all of the other processes you might want to run off that PC. It really isn't anything at all specific to the NWI, it wouldn't make any difference what the other processes were doing with FS, it is what they are doing with the processor and other scarce resources which matters. It may seem worse with programs using the NWI rather than any of the older methods of weather control, but that is only because they are doing a lot more. Before the NWI, programs could only set one global set of weather data. With the NWI they can and do set all the nearby weather stations, separately. Regards, Pete

Re-check that 5408 is being written incorrectly by FSCommunicator first -- do that with IPC Write logging. I don't know if it runs when PM isn't running, but best to just run FS with FSCommunicator, then you know that it is it, not something else. If FSCommunicator is writing bad Heading values to 5408 you can't really blame MCP.EXE for falling over -- even if it didn't, it would go wrong. I expect Enrico doesn't like checking all parameters because of the possible performance overheads. So, you really need to find out WHERE FSCommunicator is getting the bad data, or is it the program itself going wrong? Are you feeding the data from the EPIC? Maybe the EPIC interface is going wrong, or the EPL itself? You need to track back one stage at a time. If you were using EPICINFO I'd recommend that you enable its logging and see what the heading value was at the interfaces there -- from EPIC ot EPICINFO then EPICINFO to FSUIPC. But with FS communicator you'll need to use whatever aids it comes with. Regards, Pete

One further observation. If I understand this part right: "I noticed the value of offset 5409 is the same a 5408 when 2 byte size is used in FS Communicator." you mean that the logging shows FS Communicator writing the same value to both 5408 and 5409? Since the offset 5408 is used by the MCP to allow programs to set its Heading register, the range is presumably 0 to 359, or possibly 1 to 360. So the largest value which can possibly be valid in 5409 (the high byte of the 16-bit value) is 1. (360 = hex 168). Any more than 1 in 5409 would not be valid. Now, perhaps MCP.EXE should be resilient to such errors, but really I think you need to look at how or why FS Communicator is doing this. Trace it back. WHERE is the data coming from? Regards, Pete

Neither of those locations are touched or used at all by FSUIPC. They are purely for Project Magenta talking to various parts of itself and for programs to interface to it, via FSUIPC's application-allocated address space. I'm not really sure what you mean here, as it is a little ambiguous. The "byte size" where? Surely not in the monitoring function (you are using the on-line Monitor facilities in FSUIPC, aren't you? Much easier than poring over a lengthy log file afterwards, unless you need the 'evidence' of course :) ). I assume this is something to do with FS Communicator? I dont know FS communicator at all, I'm afraid, but this question really sounds as if it needs addressing to someone who does. But even more important, since it is the MCP program which is crashing, if it is reproducible then you should most certainly be talking to Project Magenta support. I too use all the latest Project Magenta modules along with, of course, FSUIPC and WideFs, but I don't use FS Communicator. But certainly, if I had a crash in one of Enrico's modules I'd be getting the data together and sending it to him immediately. However, I know he's a bit behind at present after some time in the states and at the AVSIM conference last weekend. Please let me know what the outcome is. Regards, Pete

Congratulations. It's an excellent, although very expensive, program. You can use my FStarRC with that, you know. Even if you don't use Radar Contact, it does provide FS plans as well as Squawkbox and Project magenta plans from those you prepare in FliteMap. GPSout 2.52 doesn't actually need FSUIPC. Earlier versions did, but only in FS2002. It was an oversight, a mistake, not a design! :) Regards, Pete

Sorry, but I don't know any way to implement the taxi wind facility in FS2004 at present. I did spend quite a lot od time on this, and was hopeful at one time, but failed miserably. i am hoping that Microsoft will one day realse some information which may help. Regards, Pete

I expect Jose, the author, will answer you better than I, but the reason is likely to be that the Multiplayer Protocol for FS is different in FS2004 than FS2002, and the Microsoft SDK for it isn't available yet to enable such programs to be made compatible. Regards, Pete

Hi Ulisses, I attach a corrected version of the FS2004 controls list. Sorry. The first version had the second table (supposedly in numerical order) in almost a random order by the looks of things! :oops: Regards, Pete FS2004controls.Zip

Yes, the registration belongs to you, for use on any of your PCs. I do not charge per installation, and in fact FSUIPC on one PC has no knowledge of any FSUIPC installed on another! Just enter exactly the same details on each -- the name, email and Key must be exactly the same for each installation. If it worked for you on one PC it must work on all the others, otherwise you are making a typing error in the entries somewhere. Regards, Pete

If it is freeware then I'd need details as laid out in the access registration document, now part of the FSUIPC SDK. I would normally expect the author to apply, though if he is no longer interested in his work I could try to deal with it separately. Take a look at the "sticky" thread about FreeWare keys above. Certainly if you register your FSUIPC then it won't be a problem. With the way some Gauges accessed FSUIPC in the past it may not be possible to grant it an access key even if it is freeware -- too many were written as if they are external applications, and that's not valid for internal parts of FS. You can tell by looking at the FSUIPC LOG file -- if it says a Gauge or DLL is trying to access FSUIPC, then it would be okay. If it says FS itself is, then it is not resolvable without software changes in the gauge, except by registering FSUIPC, that is. Regards, Pete

No, they don't interact. Though, for supporting purposes it would really be better to use the latest versions always. You don't need to do anything other than copy the two DLL's and the FSUIPC.KEY file from your FS2004 modules folder to your FS2002 modules folder. Regards, Pete

Sorry, no. I don't use Esound, I haven't for years, and I can't really support it. Are you using a standard FS-supplied sound or one of your own creation? If the latter, please try a standard FS sound first, in case it is merely due to some incompatible sound format. If you tell me which version of Esound you are using, and attach a ZIP of your Esound.cfg file, I can try it here and see if it is something obvious. Regards, Pete

The errors seem to be related to specific AI aircraft IDs -- Speed Bird 2466 Speed bird 8085 Speed Bird 1485 Speed bird 2738 etc. The common thing (apart from them all being British Airways) is that they are all 15 characters long, which is rather odd since FSUIPC 3 should be only allowing them to be 14 characters at maximum -- the other character has been stolen for use in providing the "status" indication. It looks like there's a bug in the way FSUIPC itself is providing the string data for the names. Sorry about this -- it is very odd it hasn't cropped up before, as it must have been like this for over two months now. I will check it and fix it in the next version (3.11), within a week or two. Thanks for the notification! Regards, Pete

Did you re-install it, or just copy everything across? I might try it here. Not that I want to use it, just to see why this is different. I am wondering now if this is a different cause of "spikes", not the ones fixed by FSUIPC, because, as I said, the actual part of the code which those options enable makes no differentiation at all between FS2002 and FS2004. I'll take a look some time this week (a bit tied up now). To save me some time, could your get the thing doing it, and save a Flight, please? ZIP it and its WX file (and FMC file if there is one), along with your FSUIPC.INI file and FSUIPC.LOG file -- all in one ZIP -- send it to petedowson@btconnect.com. I can't promise anything, because this may not be easily fixable, but I'll take a look. Regards, Pete

Have Wilco released a version of 767PIC which works with FS2004? I wouldn't have thought the FS2002 version would work properly in any case. The action within FSUIPC is identical for this option, whether you are using FS2002 or FS2004, so I don't know what is going on there, unless it is a revised version of 767PIC which is doing something different. I assume you are using a user-registered copy of FSUIPC and have enabled the facility in the Technical page of FSUIPC options? Can you tell me which version of FSUIPC you are using? If it isn't 3.10, try that first. Regards, Pete

Hi Stuart, The flaps stuff was pretty easy to do so I've already sent to a Beta to check out, by email. Let me know. Thanks. Pete

Ahapologies. I really don't know without studying it further, whether it can or cannot be done, but I will put it on my list of things to look at soon -- maybe later this week or early next week. No promises, though. Regards, Pete

I don't know what a "cueing algorithm" is, but what values is the EPIC card getting which you can't get direct from CFS2? I don't understand where the EPIC comes in. Check the FSUIPC SDK (available at http://www.schiratti.com/dowson) and see if the data you need is listed. I'm afraid I cannot guarantee much for CFS2 -- FSUIPC is really aimed at FS and it is only by coincidence that some things are okay in CFS1 and (more so) in CFS2. Regards, Pete

I assume you mean 3.08 and 3.04, respectively? Can you first try 3.10, now available, just in case? I am not aware of anything I do which will affect trim or autopilot, but so I can compare your results, perhaps you can enable IPC write logging (in the Logging page of FSUIPC options), and Zip up a Log from FSUIPC 3.04 when it is okay, and one of FSUIPC 3.10 if it is not. I'll try to work out why it should be any different. Please also include your FSUIPC.INI file -- Zip them all up and send to petedowson@btconnect.com. Thanks. Pete

I don't know of one, though I do recall someone providing a reference to some basic examples before. Have you done a search here? It is probably still in the Forum somewhere. Basically, I normally advise to start by writing a Gauge, for which there are MS SDKs. Gauges are DLLs with the same sort of module linkage, but loaded by PANELS.DLL instead of by the FS EXE at initilialisation. Once you have a working gauge written in C you are over half way there. (Don't use XML, that won't help). Regards, Pete

Yes, of course. As detailed in the announcements here, I do offer free registration of FSUIPC for those who donated enough early on. But I don't have the mechanism here. Can you please send the details to my email address petedowson@btconnect.com? Thanks. Regards, Pete

Ouch :wink: Sorry, I haven't the patience to work through that, I'm afraid -- at least, not unless I realy have to! :) If you are talking Buttons, then you should note that, as mentioned in the Release Notes for FSUIPC 3.10 in the Announcements above, there's been a bug in recent versions of FSUIPC that stopped the repeat option working. Try again with version 3.10, which is now available. It should work with any button programming system -- at least there's nothing I've put in to stop it doing so. Regards, Pete