Pete Dowson

Ah. You need to find out about the Multiplayer interface. I'm afraid it isn't something I know about, nor do any of my modules deal with it. There is an official Multiplayer SDK for FS2002, so you could work it out from that, though MP changed in FS2004 and the SDK isn't yet available. Regards, Pete

Yes please. Regards, Pete

Do you have any other add-in modules in your FS Modules folder? On my system the timing was critical. Just removing some of the others helped. I also modified AdvDisplay and PFC.DLL to help with this, but one of Lago's DLLs (ViMaCore2004.dll I think) also contributed to the problem for me. I think there's some sort of conflict between two things relating to DirectX and they are affected by slight differences in timings. Maybe even the order in which the Modules are loaded has an effect -- because the load order determines things like chained notifications and subclassing ordering. I don't think there will be a proper answer though, unless the problem will be fixed by an update to DirectX9b. The problem doesn't seem localised to FS2004 -- a number of DX9-level programs seems to suffer. Regards, Pete

Sorry, I don't understand. You can control the autopilot using a mouse on its panel, or by keystrokes assigned to controls, or by programming buttons. You can control it from an external program through the FSUIPC interface too -- see the FSUIPC SDK. I don't at all know what you mean by "spawn jet in the game" ("game"? do you mean "simulator"? :) ). Sorry. Pete

Despite it's being called FSUIPC.txt, it is not emanating from my module. Something else is doing that. I've never had anything in any of my modules which produces anything with such contents. It looks like you have some other module or gauge running which is, for some reason of its own, is creating this file, which looks like it simply contains linkage data. Maybe some other programmer was trying to sort some problem out and logs these details when it sees FSUIPC, then forgot to remove it when he published it? Or are you running any Beta or test version of anything for someone? Regards, Pete

Well it shouldn't make any difference at all if you calibrate the full range in FSUIPC, as whatever input FSUIPC sees from whatever axis you assign, it spreads the values to suit the purpose. Even if the axis only gave two values, 0 and 1, a proper calibration in FSUIPC should ensure that 0 is full trim one way and 1 is full trim the other. Note, however, that left and right do not necessarily correspond with minimum and maximum. Often it is the other way round. Regards, Pete

If you can find out how to influence the traffic programmatically, please let me know and I will add a special interface for it, as it would be very useful, but I have spent too much time already going half crazy trying to work through horribly convoluted C++ originated assembly code and getting absolutely nowhere. Maybe I'll have another go at it one day, when I've nothing else to do, but it is likely to take many many hours of not very enjoyable detective work. I'd also like to be able to intercept the ATC messages and reply to them, via a programmable interface, but I've not even managed that. Sorry. Regards, Pete

Because FS doesn't offer any AXIS controls for rudder and aileron trim, you have to assign your axes to some other axis controls (ones you don't need), then tell FSUIPC which they are, via the FSUIPC.INI file. Details of this are found in the Advanced Users guide, in the section "Assignment of additional controls". This uses the numbers of the controls, not the names. You will see a few of the more likely ones listed in the document. For a full list see http://www.schiratti.com/dowson Regards, Pete

I don't think there are any AI variables you can change. The AI traffic stuff is compiled into the Traffic BGL. Can you clarify? Pete

What do the WideClient and WideServer logs show? Do you have the FS frame rate limiter to to provide a sensible refresh rate for each client? Which of these is First Officer's PFD and which Captain's? When you say "serious" delay, what do you mean? There may be issues when running the MCP on the same PC as a PFD. It looks like the MCP changes values in the lower memory area of FSUIPC (04E0-0537) which may be needed by the PFD, but these, being in the FS "globals" area, are not updated locally, only in the FS PC and there sent to the other clients. I cannot reproduce any problem here with such an arrangement, but I think it may be possible. However, it would not be the explanation if, for instance, your PC with only the PFD/ND running suffered serious delays. That would almost certainly be some sort of queuing or block loss on the Network -- the logs should show something in that case. I have a test version of WideClient here which treats the 04E0-0537 area as 'special', like the FSUIPC application areas above 4000. I prepared it for someone else here who mentioned a problem, but he hasn't got back to me about it yet. I'll try to attach it here for you to try -- but if it isn't attached to this message, check your email instead. Regards, Pete WideClient6101.zip

It may not use messages, it may read the asynchronous keyboard state, in which case it bypasses most if not all of the ways to get the correct keys to it. That was the problem with Roger Wilco and why, in WideClient, I had to use the Registered Messages, which, luckily, it declared for the PTT operation. There are two ways WideClient provides for sending keyboard events to a program -- recorded playback, which should reproduce the exact same message sequence from Windows as pressing the key does, and PostKeys, which simply posts the KEYDOWN/KEYUP messages. If one doesn't work you could try the other, though as I say, it may well bypass these in any case. If it doesn't use the messages, monitoring them in any Spy program won't help -- naturally the messages will go to its Window, but that doesn't mean it uses them. If there is a Menu command for PTT then there is a possibility of Posting the WM_COMMAND message with the appropriate parameters. Let me know if you find anything like that. Maybe a message to the developers, explaining the predicament, might help? Message Spy programs tend to be provided as part of compiler packages, complementing the debugger. You could try looking at http://www.systeminternals.com, or otherwise searching the Microsoft sites, or do a Google-type search -- the words "Windows Message Spy" might help narrow it down. Regards, Pete

Sorry. I merely list the controls which are provided in CONTROLS.DLL, and (mostly) also listed in the Gauges SDK. Whether they work, and even what they do, I've had to give up discovering since FS2000 days. I was instrumental getting many of them added (for use in EPIC cockpits mostly) in FS98, thanks to friendly contacts in the FS team (Tim Gregson being my main one then), but as the FS team changed I think many of the controls got disconnected. The fuel transfer forward/aft controls were probably peculiar to the Concorde when that was part of the official release -- there are Concorde Visor controls in there too, still. As for the crossfeed ones, I don't know why they are there. I think the fuel selector switches are the real controls in this area. Experimentation is key. Regards, Pete

No, but as I am not EPIC support I doubt anyone would send such reports to me. I don't even use EPIC much now -- I do have a USB version connected for a few buttons. PH's in the range 128 to 255 were'nt supported in any of the earlier firmware versions on the ISA board. I don't know the version number when they were added. You'd need to check with EPIC support. Sorry, Pete

This would be more useful if you could show me whatever fragment of an FSUIPC.LOG file you can find, please. Can you tell me how much main memory you have and what other programs are running at the time? Also are you using windows XP or 98 or Me? This does look like somehow CONTROLS.DLL is either getting corrupted or it is somehow not in the location FS tells me it is. I might send you a Beta test version of FSUIPC to try, mainly to get me more information. Check your email soon. Regards, Pete

There is no file named FSUIPC.CFG used by FSUIPC. It is most definitely called FSUIPC.INI. It sounds very much like you are not looking at the filenames with filetypes showing, but you have them hidden so you cannot tell what the true filename is. Windows probably describes any INI file as "configurastion settings" or somesuch. No, you cannot be. FSUIPC would simply re-create one if you deleted it. You are simply getting confused between a Windows file description and a proper filename, which it sounds like you have hidden. If you want to see the real filenames so you can recognise things properly go to Window Explorer's Tools-Folder Options and select View, then uncheck "Hide extensions for known file types". (This is for Windows XP, but there are similar options in Windows 98 and Me). Regards, Pete

[quote name="RoC Arrived at the Hotel...for my surprise ' date='the Gericom have no RS232. [/quote] No serial port? Ouch. Does it have a USB port? You can get quite cheap USB serial port adapters. That's the only solution I can think of. What has an Ethernet cable got to do with 1394 (firewire) -- you need an Ethernet port for that. I thought you said you already had an Ethernet connection. But neither of those are any use for GPSout. Only a serial port will do. I don't understand any of this, when you said you had a serial port likn already, using COM3 or something, no? That would probably be the PFC Jet Cockpit, which does use Project Magenta. See http://www.flypfc.com. Regards, Pete

Well, please do let me know how you get on! Regards, Pete

So, you don't need the 56k modem. That shouldn't be relevant. What small icon? GPSout does not make one of those. It operates completely invisibly. It sounds like you have something els intercepting the serial port data! Okay, so what is the COM port cable being used for now? You do NOT want any modem involved in this at all! The link between the two COM ports is just a piece of wire. In fact it only needs three connections at each end -- 1-1, 2-3 and 3-2. There is NO Ethernet on these serial cables. You are getting mixed up between serial ports and Ethernet ports. Take your modem and put it safely away in a cupboard. Then get a serial port "null modem" cable ("null modem" means NO modem! :) ). Plug it in and try it. The "full" FSUIPC is available from http://www.schiratti.com/dowson too. There's only one current version, and the latest will always be on the Schiratti site first. For all the user facilities you have to register in any case. The version on the Radar Contact CD is the same, it won't give you the user facilities free. Radar Contact is accredited so that it runs on any version 3 FSUIPC. Regards, Pete

Hmmmnothing of mine has anything to do with multiplayer, and I really don't know anything about it. But there are some aircraft panels (like the 767PIC) which has exactly this problem, though not usually related to multiplayer. Does your problem occur with all aircraft or only specific add-on ones? If it is a specific panel problem then the "spike" removal facilities in FSUIPC may help -- they are on the Technical page. However, I have recently had to change that option to work properly in FS2004, and this fix is in version 3.11, due for release at the weekend. Can you try it then? Regards, Pete

Hmmmthat's a new one for me. :( . Does it do this with any key, or only specific keys? There's nothing here, in version 3 of FSUIPC, which hasn't been there in previous versions, right back to FS2000 times. I'm not sure how I can help youpossibly it is a video driver problem? Does it happen in both windowed and full screen modes? There was a problem in some versions of FSUIPC where the controls list, which it obtains from FS's own CONTROLS.DLL, was not available, or was in a different place from usual. However, I am sure I covered the possibilities there. Perhaps you could show me the FSUIPC Log file, or whatever there is of it, in case I can see anything there? I will be releasing version 3.11 of FSUIPC this weekend. Can you try that when you get it, and get back to me? If it is still a problem, I'll have to lead you through some diagnostics. Regards, Pete

Well, they are certainly not discarded by FSUIPC. They will be setting global weather, but in the vicinity of the aircraft all weather will have become localised. This is by now a well known phenomenon in FS. I don't think it is a bug, it is just the way the "real atmosphere" has been modelled. You must have completely missed the "IMPORTANT" announcements about this at the top of this forum, and even the section about this in the FSUIPC User guide? Here' I'll reproduce it here: This is but one big reason why both FSMeteo and ActiveSky are now using the local weather setting facilities in the NWI. Regards, Pete

Are you calibrating it in FSUIPC? You should be able to set the whole range there. The "Arm" part is quite small. The usual problem in FS2002 and FS2004 is that Arming the spoilers when on the ground sometimes (usually) deploys them to 100%. To check them you really need to be airborne. If you cannot get them working correctly using FS's own settings, then FSUIPC is not going to be able to fix it. Maybe you have the FS "sensitivity" slider set too low? That could explain it. Use maximum sensitivity for such controls. You could also try adding "stick_sensitivity_mode=0" to the [Controls] section of your FS CFG file, but that will affect all joystick inputs (but for the better, in my opinion! :) ) Regards, Pete

No need to apologise. It is possible to manipulate the values with two parts, derived from the two 32-bit values -- but you have to read them as regular integers not floating point, then convert them. The complication then comes in dealing correctly with the sign -- the high part is signed, the lower part is not, of course, but effectively has the same sign as the upper part. If Delphi supports 64-bit integers then it is definitely MUCH easier, so well done for finding that. I think some C/C++ compilers support a "long long" which I think is the same. Regards, Pete

You must have still got the previous version 2.3: try flushing your Internet Explorer cache. Pete

[quote="RoC I´ll try to install another connection for the COM ports....