Pete Dowson

No, there's no such facility at present. No one has ever asked for anything like that. Why would you need it? All programs I know are happy to start up when FS is ready to deal with them, and that can be accomplished with the "RunReady" parameters in WideClient.ini. If you want some programs to start later than others you declare them in order (RunReady1, 2, 3 etc), and use the DelayReady parameters to put any number of seconds between them. I can certainly think about a way to do what you want, but I do like to understand the reasons first, as there are always so many other justified things to do. Regards, Pete

Ah, yes -- if it is using software emulation, not hardware acceleration, it will take a huge amount of processor time and not allow much for the other things, like Network operations! Good, glad it is resolved! Regards, Pete

It sounds like you have the "Auto Taxiwind" facility enabled. This reduces the wind to 1 knot when you are on the ground, to prevent the overdone "weather-vaning" that many aircraft a subject to. Just turn it off (in the Winds options of FSUIPC) if you don't like it. You don't say whether you are using FS2004 or an earlier version, but the other possibilities are that you have a low value set either for "Max Surface Wind" (FS2002 and before) or "Max wind speed up to 1000 feet" (FS2004). However in both of these cases the wind will be restricted well before your wheels touch the ground. No, it is certainly neither of those. I use 9.1 and AS2004 and there are most certainly ground winds. How are you measuring this, by the way? If it is from a properly programmed cockpit PFD wind indication, such as Project Magenta or PMDG 737, then the PFD wind indicator is not operable when on the ground and should be showing ---/--. Regards, Pete

But related to the networking operations, none the less. Did you check the IRQ assignments? Win98SE is very poor as sharing them. When you say "server hung" what is hanging? The whole system, or only FS? What exactly do you see? If the PC is hung it is almost certainly some driver level clash. Not really. I am still very very suspicious of mixing Win98SE and WinXP on the same Network, most especially when the Win98SE one is the Server. I had a load of problems which were unsolved till I changed the Server. It seems to work okay the other way round (i.e. one or more clients being Win98SE). Have you considered upgrading that PC to WinXP? Well, it creates a log file as soon as it is started. If that file isn't entering the file system on hard disk it certainly does sound like the whole PC is crashing, as otherwise the caching in memory would be flushed when the process closes/dies. I think you can tell Windows not to cache writes. It slows things up a bit but does ensure data isn't lost on crashes. BTW I don't know whether you've noticed, but the current supported versions are FSUIPC 3.45 and WideFS 6.45. Regards, Pete

Sorry, but you misunderstand something fundamental here. The data returned by FSUIPC has no types associated with it. How it is treated is entirely up to your code. If the 16-bit value is supposed to be signed it is up to YOU to read it into a signed variable. As far as the FSUIPC interface is concerned, its all just data, rows of bits if you like. There's no meaning at all associated with any of it until YOUR program determines what to do with it. Dim Success As Boolean Dim Data As Long Dim dwResult As Long Success = FSUIPC_Read(&H0E8C, 2, VarPtr(Data), dwResult) Well, I don't know VB at all, but your problem is staring at you -- you are reading 2 bytes (i.e. 16 bits) into a 4 byte (32-bit) variable. The top 16 bits of the 32 bit value should contain the propagated sign bit, but won't do so unless you make it. You can't and don't. You either need to declare the correct data type (a 16-bit signed value, not a 32-bit one), or work out a logical mthod of extending the sign bit into the top 16 bits, like "if value >= 32768 logically "OR" the value hex FFFF0000 into it". But I would hope that VB supported a 16-bit value, as the code will be better. Haven't you got any VB reference books? They surely must talk about number representations someplace, for learning VB programmers? Regards, Pete

Gauges have an interface to PANELS.DLL to draw themselves, values, needles and so on, of course. If you use those for your display then there should be no problems. But if it is going to be a visible gauge, why do you want a menu entry? You can process mouseclicks for your selections. Another alternative to consider merely for getting information onto FS's screen is the Kneeboard. I notice some folks are even getting live web pages up on the kneeboard. But please don't ask me how all that's done -- it must be via some links in CFG files, or probably just files in the right format in the right folders. Regards, Pete

I would have been very surprised if it was operating system related in any case. There are two possibilities as far as I can see: 1. Other installed programs or services in Windows which are running and possible interfering with programs like FS. There are some -- WindowBlinds for instance -- which actually hook into the window structures and menus of other programs and change them in subtle ways. WindowBlinds was responsible for many difficulties with getting any add-on program using FS's menu correctly. Another example is the driver for the Kensington Mouse, which seems to have a disastrous effect on some add-ins, particularly FSUIPC. I'm not saying it is either of these, but just illustrating the sorts of things which, though apparently outside FS, do have a strong influence. 2. Other installed gauges or DLLs in your FS installation may be affecting how that F16 gauge operates. Even, possibly, how its constituent parts are configured in the PANEL.CFG file may change what it is doing. I did try various things but couldn't get it to go wrong at all here, but there's no way I could be 100% sure. So, how to proceed? Well, on that last point, perhaps you could both show the section of the relevant Panel.CFG file which utilises the F16 gauge. I can try exactly the same entries here. Mine were actually derived from Eric's F16 panel itself, so they are probably the same, but you never know for sure. Also, I had no F16 to use the panel with, so I sort-of "adapted" it. Do either of you have a complete aircraft? If so, maybe you should Zip is up and send it to me at petedowson@btconnect.com, so I can see if I can make it fail that way. Apart from these points, look for other add-in DLLs, other than FSUIPC.DLL. Temporarily remove them. Now there are two of you, perhaps comparing notes on the add-ins you have will identify common things which may be clues. (Come to think of it, the same comparing notes idea should be applied to other things installed on your respective Windows systems). All I need to be able to do is reproduce it here to work out what is going on. Whether I can fix it or not is another matter -- but, evidently, because it works fine here and for others, there is a way to configure things to make them work, and maybe once I can see what is happening I can determine how to configure it so it doesn't. Mind you, with all this hassle and difficulty you may end up wishing you'd paid for FSUIPC User Registration after all, then none of the F16 registration checking would be applied in any case! :wink: Regards, Pete

In FSUIPC's Logging page, turn on IPC read and write logging, close FS. Reload FS, making sure you have no other FSUIPC using DLLs installed, and with default aircraft only -- otherwise the Log may become full of other program's reads and writes and make it bigger and more difficult to see what you are doing. Run FS to the point where you'd expect your Menu entry to be there. Close FS. Show me the Log. From the actual details of what FSUIPC sees being read and written from the appropriate offsets, it is easy enough to see what may be wrong with what you are doing. BTW these things are much easier to do from an external EXE program, and in that case you can use almost any language. Gauges and Modules inside FS are much more difficult, and often there's no good reason to write them this way. With an external program you have an additional advantage, that it can be run on a separate PC using WideFS. Even with a gauge or module, you will find it very difficult indeed to display a Window on top of FS when the latter is in full screen mode, unless you are using DirectX for your display. An if you really do mean "MessageBox" then you should realise that that type of Window is modal -- i.e. it stops the rest of the program whilst displayed. Regards, Pete

Sorry, I've not found a way to directly change the pressure. If I could find it I'd implement pressure smoothing like the visibility and wind smoothing. Regards, Pete

And what version number is that, please? Everyone says they have the "latest version" but often this just means the latest one they downloaded. Sometimes folks have said that and the version has been many months out of date! If you have any problems with such things, please run FS, get the problem, close FS and show me the FSUIPC.LOG. If you have registered FSUIPC then are you sure you used a legitimate Key? Some similar problems are caused by the use of bad keys. If you want me to check, Zip up the LOG and the FSUIPC.KEY files (both from the FS Modules folder) and send them to me at petedowson@btconnect.com. Pete

Actually, you need not bother with the KEY file now either -- Katy from PM Support has sent me the details, and this has enabled me to locate the problem. Many apologies. I am sending a fixed interim version of FSUIPC to you now. But please replace it with the next official issue when available (probably late February). I think you would be better off with the current WideFS (6.45) rather than the 6.44 version you are using. Check http://www.schiratti.com/dowson. Regards, Pete

I wrote to PM support after posting my last reply here, and they supplied me with the Logs which you supplied them but forgot to supply me. It looks almost certain that either or both of the FSUIPC and WideFS keys you are using are not correct. They test out as counterfeit, which is worrying. Please Zip up your FSUIPC.KEY file and send it to me by email (see previous message), but you need not bother about the Log files now. BTW the Logs do show that you are a little out of date. Current FSUIPC is 3.45 and WideFS is 6.45. Regards, Pete

Hmmm. Think about this: as the value is contained in only 16 bits (2 bytes) it is impossible for it to contain a positive value of anything greater than 31767, which after dividing by 256 would give you 124 degrees C, no where near your 250. So I assume that the temperature is below zero, maybe only slightly, and you are wrongly treating the number as unsigned! Please look in the FSUIPC SDK and find the program called FSInterrogate. ALWAYS check your results against those shown by FSInterrogate. If you get something different you have an error in your program. You can also use FSUIPC Logging. Go to the FSUIPC options, find the Logging tab and select IPC read logging. This will show the values actualy being supplied to your program. Regards Pete

I've no idea, sorry. I've not made any such keys, so anything could be happening. I don't know anything about the demos at all. This is really 100% a matter for the PM support folks. I assume you are not using a registered FSUIPC? If you want me to take a look then I'd need to see the FSUIPC Log file. Oh, I just noticed you say you are running on TWO PCs. With WideFS? If you have WideFS and it is connecting okay, then you must have paid for it. If you are running all of the PM programs on the client PC then none of them need any keys in any case. Anyway, the same file should have helped PM Support work out what's wrong too. Didn't they ask? Have you tried the PM support website? Please also check that you are using current supported versions of FSUIPC and WideFS -- there's a list near the top of this forum. [LATER] It just occurred to me that these time-limited keys you are talking about might have been for FSUIPC and WideFS, not for the PM applications themselves. Is this so? I'm afraid your message is ambiguous in this regard. Anyway, if it is so, and you want me to investigate (rather than PM Support?), then try it all again, then close down FS, and Zip up the FSUIPC.LOG and FSUIPC.KEY files you will find in the FS Modules folder. Send the Zip to me at petedowson@btconnect.com. Regards, Pete

FS only appears to do this if the key is not assigned to anything. By default it seems to be assigned to the Kneeboard. If I delete that assignment in FS I get the effect you are describing, but if I then assign a function to it in FSUIPC's Keys page, that works correctly and FS doesn't appear to go into that mode. Have you tried that? I'm not sure exactly what you are trying to do with it. Keys assigned in FS or FSUIPC do not get passed on to Windows' default message handling routines, and I think it is those, not FS itself, which enter this menu selection type of limbo (not the FS-implemented Pause, of course). If you simply want F10 to do nothing, try assigning it to an FS control which does nothing. I think there are plenty non-working controls in FS, listed in FSUIPC's drop-downs, but you'd need to try one and see. Regards, Pete

Yes, via parameters in the PFC.INI file. Just look in the PFC.DLL User Guide, in the section on the INI file near the end. You'll see two parameters which you can change to achieve whatever you like. Regards, Pete

Yes, assuming Program 2948 is your program (that will be identified earlier in the Log file), then FSUIPC is most certainly supplying your program the correct data. So, I'm afraid there is something wrong in your code. But you need someone who knows Delphi to help. Maybe it is all to do with differences between passing things by value instead of address or vice versa, but I really don't know. Sorry. Regards, Pete

Thanks for the suggestion. The brake problem appears to only occur if you have calibrated the separate Throttle 1 in FSUIPC's Joysticks section. I have now found the error -- a silly typo -- and fixed it. It will be okay in the next release, but if you want an interim update with it fixed, let me know. I cannot attach it here I'm afraid, it just exceeds the limit of file sizes in the Forum. Regards, Pete

Ah, but WidevieW isn't mine either! It's by Luciano Napolitano. See http://www.wideview.it/index.htm. :wink: Regards, Pete

Please check things out with FSInterrogate. You'll find it in the FSUIPC SDK. It is provided so folks can cross-check their own programming. Also use the FSUIPC IPC logging -- just checking the Log for your Reads will show what is actually being supplied to your program. Then you will know how to look. BTW FSInterrogate was written in Delphi. FSUIPC can do that for you, whether you are doing it from a Module or an external program. Check the section in the Programmer's Guide entitled "MODULES MENU access for Applications". There are step by step instructions there. You shouldn't need anyone else to actually code it for you, it's that detailed it's almost code already. :wink: Regards, Pete

Good. thanks for letting me know. Regards, Pete

Not my subject, sorry. Maybe someone here may know, but it seems more a general programming question. Perhaps something in http://www.gamedev.net/reference/programming may help? Regards, Pete

FSUIPC doesn't feed anyone anything. It provides an interface that a program can use to get such information, but the programs have to actively ask for it. There are not only pitch bank and heading values but also velocities and accelerations in all six axes. For a motion platform I would have thought it was the accelerations you'd be interested in more than actual positions. Download the FSUIPC SDK (from http://www.schiratti.com/dowson) and browse the information therein. That's the best way for you to determine answers to such questions. Regards, Pete

Not here at all, you are in the wrong place! Try http://www.wideview.it/index.htm Regards, Pete

With DLL 3.45 you mean :wink: Okay. The other person who reported this found the same a while ago and tried disabling each Joystick calibration in turn. It seems that the problem occurs if you calibrate the separate throttle 1 setting, nothing else. This was a good clue which helped me locate a typo in the code. I sent him a version to try, but I don't expect I'll hear back from him till tomorrow (we are both in the UK and it is getting late). So I'm emailing you a copy to try too. Please let me know. You are now mixing up INI and DLL files. You said you installed 2 DLLs, not INIs. :) Anyway, let me know how you get on with the update and your original INI. Regards, Pete Regards, Pete