Pete Dowson

What? Is that the same? You did not mention that before! Can you tell me the version number of your FS2004 -- Help-About. Full build number, please? It sounds like it is NOT the same as the standard Gold release. This would make FSUIPC and most of my other modules incompatible too. Do you load any of my other modules? They all do the same thing on loading. Can you tell me the exact title bar text in FS2004, please? This is the title bar when you are in normal flight mode, in a window or maximised. Pete

Please see the Announcements at the top of the forum. WideFS had this problem in version 6.00 and it was fixed less than three days later in version 6.02. This is actually stated, as follows, in the IMPORTANT announcement under the release of WideFS 6.02 in July: "However, version 6.02 of WIDEFS fixes a problem where WideServer can complain that it isn't registered even though it is. This can happen when there is some delay between WideServer loading and FSUIPC finishing the initial registration checking." Always refer to the "latest versions" list, please. The current supported version of WideFS is 6.10. It would save us both time and trouble if you check these first. It is also advisable to review the "IMPORTANT" announcements occasionally, especially when the date in the title changes. Thanks, Pete

I attach a revised version of AutoSave which uses the SHFolder.dll in the FS2004 folder if there's none provided by the Operating System. Please try it and let me know if it fixes the problem. Regards, Pete AutoSave146.zip

Can you try the attached AutoSave.DLL? This should find the correct folder. But there's no change to fix any "crash" at all as I've no idea what is causing that. I think the only symptom of it not finding the folder is that it would never delete any files, so there would be more and more. Regards, Pete AutoSave146.zip

[quote name="jafred Thank's for the reply' date='I still need to know why it does not work and if there is so that I have to buy this program. [/quote] What does the FSUIPC Log file say? Do you get a Message Box saying that you are trying to run an unaccredited program? I am sorry, but I do not have, and cannot keep track of, every program that is written for FS. I have to respond to requests as they arise. And even then it isn't as if I have nothing to do but wait for these to come so I can jump to it! :( Okay, this means it is reading the location through FSUIPC. If AFCAD is freeware it is perfectly entitled to a free key to access FSUIPC. The only reason it hasn't got one already is that no one has asked for one, and no one has supplied the details for me to make one. If you look near the top of this Forum you will see a "sticky" thread about all this, which invites such application. Fine, but this would not be the case in FS2004, and FSUIPC version 2 is no longer supported. It would benefit folks more to get AFCAD issued with a Key. Normally I'd expect the author to do this, but perhaps he's too busy with the FS2004 version, or maybe no one has even asked him. Regards, Pete

All I need to do is get the "Flight Simulator Files" part from FS2004's own resource strings for this -- they are in its "Language.DLL". It is not a problem, I will do that within the next few days. But I need to know why it is crashing. It should not cause a crash just because the path isn't located. If you do add the "Flight Simulator Files" path it needs to be: C:\Documents and Settings\Administrateur\Mes documents\Flight Simulator Files as all the preceding parts are supplied to me by the system. BTW are you using an English/US edition of Win2000? I am surprised to see "Documents and Settings" on a French system. Regards, Pete

Further on the matter of path names, I've found the string number for the resource string FS2004 uses for the folder "Flight Simulator Files", so I can change AutoSave to get the right folder automatically. I'll do that within the next few days (I'm a bit inundated at present). Meanwhile we need to get more information on why it is actually crashing. I cannot see that getting the wrong path should crash anything. Can you get any more details? Possibly a DrWatson dump? (see the section "If FS crashes ..." in the FSUIPC documentation for how to do that). Regards. Pete

The path will be different in every case anyway, as it is based on your User Name. In a English version of Windows it will be (assuming C is your Windows drive): C:\Documents and Settings\\My Documents\Flight Simulator Files Now, of this my program only has to add the "Flight Simulator Files" part -- the rest is provided by a call to a Windows DLL called "SHFolder.dll" which should exist in your Windows System or System32 folder. Perhaps the French version of FS saves the files in a different subfolder? I'm not sure how I would be able to derive that. I may have to have an extra parameter in the CFG to tell me. If you could check please. However, if AutoSave cannot find the folder, it should not crash. All that would happen is that it cannot get to the correct folder to delete the old saved files when the number you specify to keep has been reached, so the number of files just grows and grows. Regards, Pete

Well, there's been no change in that part of the program. The change to make it work in FS2004 was needed to find the correct path for the FLT+WX files when they get saved, so that the older ones can be deleted. It sounds like it isn't finding that path on your system for some reason. It is quite complicated, finding the path, and involved using new facilities in the Microsoft operating systems. Can you tell me which operating system you are using, please? Maybe there are instances where the DLL which is needed isn't installed. It's called "SHFolder.DLL". Perhaps you could check your Windows System (and System32) folders to see if it is there, please? If not, I recently noticed that FS2004 does actually install an SHFolder.dll into its own folder, so maybe I can change AutoSave to find and use that copy if the System one is missing. Regards, Pete

I don't know, sorry. This is the first report of any problem. Are all the people with problems using Windows 2000? Are there some without problems using the French version of FS2004? The only thing which had to be rather different for FS2004 was finding the correct path for the FLT+WX files, so that the correct cycle can be maintained. That involves a call to a special DLL which is a standard part of Win98 and WinXP, and, as far as I know, also Win2000. But I will test it on an English version of Win2000 to make sure. If you can supply any other details, I'd be grateful. Regards, Pete

You need to write to Customer Services at http://www.simmarket.com. They will be able to deal with this. I don't think anyone here on the Support Forum can help as this is concerned with technical support, not sales. SimMarket themselves deal with all the Registrations. Don't worry, they will have you on record and will be able to re-issue the key if you have lost it. Regards, Pete

I'm sorry, but I know nothing at all about any USB yokes from PFC. All I can suggest is that you contact PFC. They presumably make and support these devices? I've not heard of them. All the PFC gear I have is COM port connected and uses my driver (PFC.DLL) for FS use, but I have nothing to do with any USB drivers. That said, I don't see how any yoke attachment can affect whether a cockpit appears on your screen or not. That's something else entirely. Regards, Pete

Can you tell me what AFCAD uses FSUIPC for? I thought it was for designing and editing airport taxi routes, holding points, and parking areas. If it uses FSUIPC simply for plotting positions then all that data is unchanged, so it should have no trouble. The same data is used widely by other programs without any fuss. Perhaps you have not registered FSUIPC 3 and therefore no program without an access key can use it? Please check the Log file produced by FSUIPC and see what it is telling you in this regard. Certainly no one has yet applied for such an access key. Perhaps you would like to scan some of the Announcements and Sticky messages at the top of this forum to see what goes on in this regard? Also you will find full details of both the payment scheme and the registration system in the documentation accompanying FSUIPC, in the ZIP. Regards, Pete

Currently FSUIPC offers only precise centering, with null zone at centre, and precise end points with null zones there if you wish. Proper calibration first, in Windows, will help precision, sensitivity can be adjusted by the slider in FS. Of course, if you make big null zones, the remaider of the movement has to be more sensitive to compensate, so I suppose you can say the FSUIPC adjustments also affect sensitivity. What you might be referring to, though, is the need for some more gentle arrangement near centre but without compromising the ability to reach the extremes. This can only really be done by a curved, not linear, response, such as the ones I provide as options in the PFC driver, and as made possible in the Joystick program for EPIC axes. I do have on my list some ideas for extending FSUIPC in that sort of direction, but it is a big job and slated for much later, probably next year at this rate. Regards, Pete

I don't think so. The range -16k to +16k is not the input from the hardware in any case. That range is the one that is established by calibration in Windows, and by FS scaling thereafter. You should be doing that anyway before even thinking about using FSUIPC, for example. To take one example, the ISA EPIC analogue inputs are 0 - 255 maximum, and calibrated to that by the EPIC Joystick program. Even then most pots won't give you even as many as 256 discrete measurable positions. The pots used on the PFC equipment (yokes, rudders, throttle quadrants) all give a maximum range of only 0-127 (usually significantly less), and of those there are only about 40 discrete positions (i.e the numbers jump in 3's). Check the numeric input from any joystick, I bet you'll find the same. Even if you got -16000 to +16000 you'll probably find the increment between positions is about 320 or more. In the end, what's important is how many different values your pots can provide The more the better, as that means more precision. It is for precision that many makers turns to optical systems rather than pots in the first place. Regards, Pete

Well the only adjustment you have is the sensitivity slider in FS. But really any throttle setting should be possible with any half decent throttle lever. When you watch the throttle positon on screen, can you see its positon? Does it "jump" from idle to some fast setting? If so it is faulty. Any throttle setting possible from keyboard should also be possible from a throttle lever -- well, almost. A typical lever might have 40-160 different measurable readings, maybe more for optical reading ones rather than potentiometers. There may be more (smaller) increments possible via keyboard, but I wouldn't have thought you'd need finer precision. The only thing I could do, eventually, in FSUIPC would be to provide a facility for setting a curved rather than linear response -- one that was less responsive in the lower area and more responsive in the higher area. (You can't have it less responsive all the way else you wouldn't reach full throttle). But I expect then there would be complaints that fine adjustment of cruise speeds wasn't possible, or some such. You can't have more in one place without less in another. This sort of curved response is useful sometimes for yoke and rudder controls, to give less control surface movement near centre, and more movement to the extremes. In fact I do that already in the PFC driver, via a range of selectable "S" curves. But I've never heard of a need for it on throttles at all, and it would worry me that it would make throttles less easy to use for the reason I just stated. If you use a good aircraft model in FS then there should be a recommended throttle setting for taxiing -- in terms of N1 or N2 or EPR or RPM or whatever the measure might be. You normally have to use a little more to start the thing moving of course, but then bring it back to the set level. On my lst of things to do in the future is a complete analogue axis assignment and calibration facility, by-passing the FS DirectInput system altogether, and providing much more detailed calibration facilities, even point-by-point so that curves can be applied. But I don't think I can get to this for months yet. Regards, Pete

Sorry, that is so system dependent. Trial and error perhaps? Regards, Pete

Do you program your "Button 1" to send a keystroke to Team Speak, using the "Buttons" page in FSUIPC? If so you should be able to apply the same technique via WideFS, but this time making KeySends do the job. You do not specify Keys to be pressed in WideServer! You CAN specify buttons in there, to be converted to KeySend numbers, but it is far easier to program the buttons in FSUIPC. Just program the button to send KeySend 1 when pressed and KeySend 2 when released. Please see the FSUIPC documentation. As far as having those parameters in WideClient.ini, they cannot possibly work! Key code "32" is the Space Bar! That cannot trigger PTT if it is programmed via F12! Please check the key list in the FSUIPC Advanced Guide -- you will see that F12 is keycode 123. Also, you need to refer to the WideFS document. You have to have special shift state values for separate "press" and "release" operations. In your case above KeySend1=32 just means "press space bar and release it" (but still needing ,8 to do that!), whilst the "32,17" in the second one means "press Shift+Space and hold them down"! Why do you want to do that? Please check the document -- you will see that the shift state needs to be 16 to press a key on its own and not release it, and 24 to release it. Regards, Pete

When you say "not connected", what do you mean? If you are connected -- i.e. if the FSUIPC_Reads and Writes work, then you are "connected". Or are you talking about WideClient being connected to WideServer? 0x337E was added for the latter purpose, and you can also of course read values like the FS timer at 0x0310. There's nothing else really. Regards, Pete

The only reason there's an example for FS2000 is that before FS2002 there was no support in FS's configuration for proportional toe brakes. The facilities in FSUIPC allowed the toe brakes to be used, but it needed some assignments manually adjusted in the CFG file. Since version 2002 FS has supported toe brakes properly in any case. There is no need to edit the CFG file -- indeed it is very difficult to do so these days. Please assign and calibrate everything using FS2004's own facilities for this. If you wish, you can then make final and more accurate settings for dead zones and centres in FSUIPC, but you need to get it right in FS first. Regards, Pete

Not sure where you read anything of mine saying that winds don't work. They seem fine here. Are you setting them manually in the FS weather dialogues, or downloading the weather from the Internet? The only thing I've said seems wrong with the downloaded weather is that when you are flying close to several different weather reporting stations, with conflicting wind details, the interpolation used by FS sometimes seems to produce violently changing wind directions instead of any smoothing. Some of this wind shear may well be genuine, but it seems wrong. Regards, Pete

Sorry, I really don't know much about WeatherCentre. Isn't it now taken over by Damian of ActiveSky fame? You will probably need to check with him. A slight stuttering is noticed in FS2004 even when FS itself updates its weather from its own downloads. I don't notice it here, but it probably depends on your machine and its loading. Certainly a one second stutter seems excessive. But also check your cloud settings -- there are some notes on that near the end of the FSUIPC documentation. Regards, Pete

Great! Thanks for letting me know! Pete

Yes, sorry. You have no such options at all if your FSUIPC is unregistered. If this 'fix' does work I will then change the defaults in FSUIPC so that it is =0 normally, and then it should (may?) work for you too. But I am not doing this till I know it is the best solution. BTW 3.06 is the current version. Regards, Pete

But oddly enough, on three different PCs, I've never had a freeze when toggling screen modes at all, not since early FS2004 Betas, and this is without taking any special precautions. Only since a change of motherboard, yesterday, have I been getting a black screen when changing from Windowed to Full Screen mode. And that isn't a freeze as such, either, though I suppose it would look like one. When it happens I can still access the menus, and going into Options-Settings-Display-Hardware and changing something there does recover the situation and give me proper full screen mode correctly operating. What you say is certainly interesting, but perhaps some greater detail from my findings might help. The fix for my particular black window problem, which of course may not be the same as yours, shows that it isn't anything FSUIPC is actually doing, EXCEPT that it is hooking into the main FS window subclass chain. Many add-in DLLs do that. But in FSUIPC, ADVDISPLAY and PFC I delay this subclassing for a number of seconds after FS starts. This seems to be a problem, in FS2004 only. Somehow the subclass chain is getting corrupted and something is getting left out. With my current ability to reproduce the problem at will, I actually eliminated everything FSUIPC was doing, so in fact it loaded but didn't hook anything, didn't do anything, was never called, nothing. Okay, no problem. Then I gradually added things back, one at a time. The only addition to cause a problem was the subclassing, and this still caused a problem even when my subclassed window was bypassed so that it did nothing at all but pass messages on! I experimented further and found that if I do the subclassing immediately my module is initialised then it works fine! So it's the delayed subclassing which is the problem. Why or how I have no idea. The same applied to ADVDISPLAY and PFC.DLL, but none of my other modules. It looks like the same applies to Lago's new "ViMaCore2004" module too, so I've written to them advising of the solution I found. Until I get feedback on the test I've asked folks to do (the "InitiDelay=0" parameter) I won't know if this is just a peculiarity of the problem I've seen and can reproduce, or whether it really does cover the other cases. Hopefully I will get feedback which will clarify this. Perhaps you could try the fix I suggest too (but take care not to get the issue confused by other add-in modules). Thanks! Pete