Pete Dowson

You could certainly do that very easily in Lua. You'd send the actions using ipc.control or ipc.keypress depending on whether they are FS/FSUIPC controls or keypresses, and use ipc.sleep(500) between each one to delay half a second. If those operations are macros themselves, you'd need to send the macro name, instead of using ipc.control or ipc.keypress using ipc.writeString(0x0D70,"macro name") where the macro name is the same "filename:macroname" string you see in the FSUIPC dropdown when assigning keys or buttons to macros. I think I ought to add another ipc function to Lua, to execute Macros without folks needing to know about offsets like 0x0D70. I may also add one for pressing "virtual buttons". Regards Pete

I've re-compressed the FSInterrogate2std.exe item with my newer compressor -- it actually does a better job, so the package is even smaller than before. Nothing else has been changed. Try downloading it -- use the link in the Updates Announcement above. I can send it to Enrico Schiratti to rpelace on his site too if needed, but I remain pretty sure the problem on the former one would have been a false positive. Let me know please. Regards Pete

You must have something screwedI've tested the new options here using two paddles on one game pad (a Saitek wireless one as it happens), and I can easily get it so the left paddle does the left rudder and the right paddle the right rudder. It works fine provided only one paddle is used at a time. When you apply both then you get random switching depends which is depressed furthest. This is the arbitration taking effect. Please show me both the relevant [Axes...] and [JoystickCalibration ...] sections from your INI file. Pete

Well, there are, several. It is a collection of tools and examples, most of which have not been changed for years. Is this the first time you've tried to get the SDK? Classifying any LIB, DLL and EXE as executable, there are: FSInterrogate2std.exe Zips containing UIPChello.exe examples compiled in different languages Zips containing LIB files for the IPC interface Zips containing DLLs used by some language interfaces Mostly it is Zips withing the Zip. The FSInterrogate2std.exe may be compressed with Petite. It hasn't been changed in the SDK Zip, though, since 2007. Is this worm you detected that old? Neither Norton AV (full commercial version) nor AVG find anything wrong with it, but if necessary I can recompress the original using my current compressor instead. The only times any virus report has been made in the past it has proven to be a false positive, just resulting from the odd bit patterns you get from compression. I don't remember anyone ever reporting one on the SDK at all. Regards Pete

No. But you could do this (and all sorts of other things) using Lua plug-ins. Quite easily. What would be the application? Regards Pete

I have not used Petite for a long time now. What "executable" in the SDK are you referring to? Pete

Sorry, please clarify. These "pulses" are what, joystick buttons flashing on and off? Well, the buttons are most certainly assigned in more than one place that is for sure. Have you explicitly disabled the buttons in FS? It assigns things like brakes and views automatically. Out of date and not supported. Please install 4.50. Regards Pete

Sounds like there's been some code changes and things have moved. You'll need to re-create the macros. The way these macros work is by finding out where, in actual code, the mouse clicking actually gets any action done. The number stuff recorded in the Macro file is merely an offset into a named Gauge file where FSUIPC has to actually jump to to make the action occur. The first two bytes of the location it jumps to are also recorded so that FSUIPC can check that this is still the correct place when, as you've done, the Gauge code is replaced by different code. It may be that the code has only moved a little way, but there is no safe way for my code to automatically find it. The only way it can find the right place is to trap and record the real, correct, places by hooking the actual mouse operations -- which is exactly what mouse macro creation does. Sorry, you need to create them again. At least you know about the more complicated ones now, and what to do. Regards Pete

I don't know because I have no details and I cannot even look you up because I assume "ddfsx" is not your REAL name? Why on Earth keep yourself so totally anonymous and expect folks to know how to help? Are you sure you are entering it correctly, and not mixing up 1's and I's or O's and 0's, or even 2's and Z's? Best to cut and paste to be sure. If you can't sort it out, send me your registration details privately (not here), to petedowson@btconnect.com and I will check them. Include the FSUIPC.LOG and FSUIPC.KEY files, Zipped please. No, that is totally unrelated. Pete

FSUIPC doesn't touch any switch or axis unless you or a program asks it to. You've probably assigned something to make it happen. Remove your FSUIPC INI file and run FS again so it generates a default setting with nothing assigned. Pete

How does one read messages displayed in graphics on screen? Seems like quite a lot of graphical analysisand made next to impossible if there's other red pixels around? No. Why would I? As far as I know there's been almost zero demand for those old offsets to be supported. Memory locations? Are you going back to the days of text-based screen buffers? Regards Pete

I'm sorry, it's been one of those days. People moaning and saying nasty things. I must admit it makes one "tetchy" sometimes. I still don't understand where you are coming from with this, but i did overreact. Apologies. Please take my word for it. As Documented, no harm is being done. I wrote it all up in the documentation especially to avoid rather inane exchanges like this one. Pete

You assign them and calibrate them just like all the others. There's no mystery. They are all the same, just axes with values, to be assigned and calibrated. Pete

But you could look and find the side-by-side errors directly after FSX is fully started, as they occur when FSUIPC is initialised, right at the start. They are not real errors. I don't know why you don't believe me... what on Earth have I done to deserve it? What's all this about "living with it? What the blazes is it costing you? A few bytes of disk space in a log file? complain to MS about their stinking systems if you really feel so angry, but I would suggest you just ignore them as they are of absolutely no consequence! Gee. If you don't like the look of them, don't ***** look at them!!! :-( Pete

You need to send it direct to FSUIPC calibration, for both. Then you need to actually calibrate the rudder, in FSUIPC. You seem to have missed that vital step! Pete

Does it? It's never done that to me. It should be checking the version! Of course. They are not only spurious, but they are fully explained in the documentation so that they wouldn't worry you. There's even a listing in the Contents. Nonsense! They are absolutely nothing to do with CTD and Screen freezes. They occur when FSUIPC initially runs whilst it is checking for the version of SimConnect it can use best. Please read what I write about these. There is no way you can stop them and they do absolutely no harm at all. There is no way I can program around them -- I complained to Microsoft about it three years ago and they confessed it was a weakness in Windows, which throws the error when a program "probes" for a side-by-side library to see if it can be used, even though such probing is the official way of doing it and provided in the Windows SDK. It is nothing to do with your problem. You need to look elsewhere. Pete

Hmm... have you checked with EPICUSB support? Isn't it still an active product? What's "LoadEPIC"? Is that a program supplied by RR to install the EPIC software? If your EPIC programming is designed to provide standard Windows-detectable button presses, then WideClient should see them and be able to send them to FSUIPC for programming. In fact Wideclient may be able to read them direct, I don't recall. If it is the axis facilities in an EPIC then I don't think there's anything which will work on those from a Networked PC. But I may be wrong. I haven't worked with or used an EPIC now for over ten years, except for updating my EPICINFO for FSX (an update actually untested by me on any real EPIC). I don't think there's anything in this forum about EPIC at all, really. Have you tried anywhere else? Isn't there a website from EPIC these days? I think it was hosted by FlightLink. There was also a user forum, some name similar to "bluesideup"? Regards Pete

There was never any such reply! You are twisting the whole thread ridiculously. All you said was that the default autopilot wasn't so good and that, with the PMDG example, it could be better. And i agreed, it can be. As I explained, it just takes skill and timeand money therefore. I have neither the skill nor the time. Neither have you by the sound of it. You need to pursue your vendetta elsewhere. Good. I don't really want to hear from you again in any case. You either don't read or severely misread replies in any case, so it is a waste of effort. This has developed into a most unpleasant experience.

Ah, something completely different! WidevieW is by Luciano Napolitano and not anything of mine. Perhaps you mean WideFS? Why are you re-registering in any case? Updating the version is merely a matter of copying in the newer DLL. It doesn't affect Registration at all. Ah .. is this because of "i had to reload and format my hard drive", I just noticed? When you say it doesn't accept your registration, do you mean it actually rejects it when you enter it in the dialogue, or that it is accepted there but then FS still shows as unregistered next time you run it? If the former, then you are most certainly making a mistake. Maybe you are spelling your name differently, or your email address is not right? As the documentation points out, all three parts of what you enter MUST be correct, exactly as you were first informed. The name and email address are part of how it identifies you, uniquely. It amazes me how many ways folks have of mis-spelling their own names! ;-) Regards Pete

Okay, that is of course true of most add=on aircraft. The PMDG and Level D examples, where the autopilot is pretty much completely replaced, are in the minority. No, I most certainly do not profess any such thing! All my developments for FS, over all these years, have been to enable others, who DO know what they are doing, to develop such capabilities. I have only ever provided the access into FS, the wherewithall to link solution to simulation. And in FSX, with Simconnect taking over thsat role, I don't even do that except for backward compatibility. You obviously severely misunderstand the part my programs play in the FS world! I think your attitude is extremely poor. You misunderstand things and blame others. If you read this thread again you can see that I've only tried to explain why you see what you see. I've not told you to build anything, as you appear to be telling me! In fact I specifically said "IF" in the only place where I was pointing out that it isn't easy: "If you have the skills and hours to spend you can most certainly do the same. Evidently you haven't, and neither have I, but you should not be venting your frustration about that here. It is not appropriate. Pete

Can you elaborate, please? Be more explicit? Are you assigning keypresses to FS or FSUIPC controls, in the "Keys" tab in FSUIPC options, or are you using joystick buttons and assigning keystrokes to them, in the "buttons" tab? As well as distinguishing between these, can you also give some explicit examples, please. i cannot really help in a vacuum. i have to understand what exactly you are trying to do and what it is you get as a result. Yes, it is of simFlight, my publishers -- they own this website and run SimMarket. The "Peter L. Dowson" signature expires this August, after which the program will not work at all. None of the certificate authorities now sell certificates to individuals, only Companies, so simFlight kindly stepped in and purchased the certificate for me. I have changed this early so there is a good overlap -- hopefully not too many folks will get a sudden problem in August. Regards Pete Thanks.........Robert

I've had a look at my code. It turned out that it didn't look too hard to change all the smoothing to operate based on the "ELAPSED TIME" values which i nowadays read as a Gauge variable -- the one provided at offset 04A8. I don't think this is as accurate as the Windows timer I normally use for everything. It is probably only at most as accurate as the 55mSec (1/18th second) ticker in FS, or possibly the frame rate. I don't think it is updated more often than the frame rate in any case. This may make it a little more uneven in how it smooths the wind. The only advantage this timer does have is that it stops whilst FS in in menus, or paused, and, Ithink, runs faster or slower according to the FS Simulation Rate. So, maybe it will do the job you want of it. Try it and let me know. I'm afraid I won't have the opportunity to do any proper testing of this till next week. It is provided as a session mode, selected via an INI file [General] parameter: SmoothBySimTime=Yes (defaults to No at present -- I may change the default if the results look really good). The wind smoothing is still reset when you load a new flight, or move the aircraft location via menu, or change the weather mode (theme <-> user <-> real, etc). download http://fsuipc.simflight.com/beta/FSUIPC4504.zip now (please make sure you've installed 4.50 first, though). Let me know, please. Regards Pete

It's operating in "digital" mode, then, like the 4-way rocker on a Game Pad. It will be to do with the way the driver is configured in the registry, which derives either from its own driver, or, if using a generic driver from Microsoft, from the USB "HID" (Human interface Device) data the device itself is providing. This is certainly something you need advice from the makers about. Probably either a driver, or a registry patch (maybe via an .INF or .REG file). Regards Pete

Pretty much all the testing on the smoothing in FSUIPC4 was done with the PMDG 747X, and it has been okay now for over a year. Suddenly it is a problem? Are you sure this isn'yt something in ASA which is different from ASX? That seems to be more significant in this change of needs all of a sudden, doesn't it? Blimey! Really the facility wasn't designed to work that slowly, though of course the arithmetic will still work. At those sorts of rates you are never likely to get the predicted or stated winds, anywhere. Doesn't that cause problems with runway assignments and so on? I've always use a 1 for 1 rate with no significant problems. Pete

Can you not stop your time keeping when you see the user enter a menu. I sorry if this is a really stupid comment/question but I'm no programmer in any sense of the word, but I imagine from your response that it is a major thing I am asking for, and the last thing I want to do is create any more headaches for you Pete It may or may not be major, I've not looked at it yet. I am simply seriiously concerned about messing with it for little good reason. The earlier posting on this was actually mentioning a stupidly slow smoothing rate of some 1 degree /knot every 4 seconds. At such a rate the wind will almost never be what it should be. It's a wonder the AI traffic at airports aren't conflicting all the time with your own flights. With more sensible smoothing rates like 1 for 1, the Wind should never get that far behind what it should be that it is going to matter so much. But this was always a factor with the PMDG 747X as well, and it seemed to be all sorted, a year or two ago. Has all this new fuss come with the use of ASA in place of ASX? If so, isn't it in that direction you should be looking? That is actually pretty rare except when using a weather control program, and it is due to exactly the same bug in FSX as was in FS9. This has been going on for years and years. The smoothing is not the only need, the weather setting programs like ASX, and I presume ASA, were also changed to try to deal with it. During a flight? I never do. It definitely destroys the whole point of the realism I've strivern for. Because, presumably, the smoothing is continuing based on real time. I'll have a look when i get a moment. Maybe it can be changed to work on FS time, though that could be messy as all timing in FSUIPC, throughout, is based on the Windows "tick" time. Changing a whole section of code to work with different timers could be very error-prone. It is really this risk of introducing bugs in complex code which worries me more than the work involved. Regards Pete