Pete Dowson

FSUIPC is an FS module. It loads into FS and becomes part of it. However, the interface which FSUIPC offers to local applications on the same PC as FS is extended to other PCs on a local network by WideFS. I'm not sure which I/O ypu want to run on a separate PC, but I would advise against even trying it for your main flight controls (elevator, ailerons, rudder and toe brakes) because the extra latenbcy that imposes makes precise control more difficult and sometimes downright dangerous! For that reason WideFS only supports button and switch assignments on client PCs -- as well as any applications which interface to FS through FSUIPC. With FSX, SimConnect can also provide an interface into FS across the Network. Some applications can make good use of this -- Active Sky (ASX or ASE) for example. Regards Pete

Good. Happy flying! ;-) Regards Pete

Because the runways are too short, as I keep telling you! I added a facility specifically for you to override the minimum of 1500 feet. If you insist on using such impossible short runways for your virtual airline (only Cessnas flown?) then simply use that facility. You need a space after the EXE of course. And in general it is better to place a shortcut on the desktop and add the parameter in the command line.there. The current folder must be the one where MakeRunways is, and you can't be sure of that with a "Run" entry. You'd have to open up a DOS window and do things there, or write a batch file. Shortcuts are much easier. Don't blame me if you get stupid ghost runways showing up for airports, often a long way from the airport they relate to! It was to get rid of those that a limit was imposed. Well, I can't see any reason you continue this thread. Don't you believe what I tell you? What's the picture for, by the way? Did you not notice that ALL of the runways you illustrated are over 1500 feet? Here's my results with version 4.45 and the />0 option: LE38,0150,40.605392,-1.266578,3332,154.400,1739,0,79,-2.000,40.603279,-1.265123,131 LE38,0330,40.601166,-1.263667,3332,334.400,1739,0,79,-2.000,40.603279,-1.265123,295 LE88,0080,41.114281,-3.735434,3828,78.668,984,0,66,-3.100,41.114616,-3.733699,0 LE88,0260,41.114952,-3.731964,3828,258.668,984,0,66,-3.100,41.114616,-3.733699,0 Regards Pete

Sounds like they aren't in the right place, then, or from a different version of FS (there were FS9 and FS9.1). Or, if you are using Vista or Win7, and let FS install into the default folder (the one in "Program Files", then you can't actually write into the real Modules folder without running Explorer "as administrator" (a right-click option). Windows protects all folders in Program Files. You see only an "aliassed" copy. No one has ever shown me any evidence of any FSUIPC corruption. Certainly if FSUIPC.DLL is corrupted it simply won't run. Maybe their install corrupted your registration, but then all that would happen is that you'd not get the user options. Sorry, I can't offer any better advice than I have already. Pete

First I've ever heard of that. Maybe they know something about their installer? What was the point of creating the folder for those files? The installer will provde you with FSUIPC.DLL. That's all of those that matters. Oddly you chose not to keep the KEY file, your registration? You don't need to re-register ever unless you delete your KEY file, or re-install Windows, or move to a different PC. Seems in the process of messing with the FS Modules folder, for no good reason at all, you've deleted half of Flight Sim. You'll need to reinstall. If you want to retain most of your current installation, rename the Flight Sim folder (the main one with FS9.EXE in it), do the installation, then just copy the complete Modules folder from the new installation to the old one. After that you can delete the new installation and rename the old one back. Alternatively, rename the new one "FS Backup" or similar so you always have a source for future repairs. BTW nothing in any of this is at all related to FSUIPC or any of my software. In future, just run the FSUIPC installer. The only files you might want to backup from the Modules folder are the INI file (your FSUIPC settings) and the KEY file (your registration -- plus any Macro (.mcro) and Lua (.lua) files you may have created. And there is no way FSUIPC.DLL can get "corrupted" and still run. It has a very foolproof check on any changes and will give you a specific error if any are detected. Regards Pete

No, there was no real problem at all. It was certainly only the lengths. Hmm. I think you might be correct. The BGL documentation I have definitely says both length and width are in metres, but it must be that I convert them in the program someplace I didn't spot. I told you the code is very old and I don't remember it all! ;-) I'll re-check, then change the "m"'s in the listing in MakeRunways to "ft". It does not change the fact that one was greater than 1500 feet and the other less. So the reason for the difference was and remains the lengths. I'll replace 4.44 with 4.45 in due course, but it doesn't change what you get in the files. [LATER] Okay, it's there now. As I said, the only correction is an "m" to "ft" in the TXT file, and the documentation says feet instead of metres. The results you get in the files produced won't be any different. Regards Pete

Okay, the "mystery" is resolved. It is so long since I examined MakeRunways data that I was fooled even myself! Look; Runway 15 /33 centre: N40:36:11.8059 W001:15:54.4421 3332ft Start 15 : N40:36:18.3172 W001:15:58.8772 3332ft Hdg: 152.4 true The length of the runway doesn't appear in these lines. The 3332 feet is the ALTITUDE! the length in these lines: *** Runway *** LE380150 Lat 40.605392 Long -1.266578 Alt 3332 Hdg 154 Len 1739 Wid 79 *** Runway *** LE380330 Lat 40.601166 Long -1.263667 Alt 3332 Hdg 334 Len 1739 Wid 79 is in METRES, so more than 1500! The length of the runways in the earlier example was actually only 984 metres. I'll change the line starting "Runway" to also show the length, in case others get confused. [LATER] Okay. I added the length, and provided a command line override facility so you can specify a lower length limit if you wish. Version 4.44 is now available in the Download Links subforum. Regards Pete

It's the offset (i.e. distance) of the threshold from the end of the runway. It's a parameter in the scenery files, often zero but not always. The pointlist format is defined in the Text document included in the ZIP with makerunways, just below where you got the first description of the format from. The taxi type numbers are listed in a table below that. The CSV files are to Radar Contact specifications, for the forthcoming version 5 of that program. Regards Pete

Maybe there's another L;var which actually does the job? If you've called the macro IgnitionSwitch.MCRO, why are you referring to "L:IgnitionSwitch" in the Macro function? The L: prefix was valid for L:Vars because that's how FS names them. You didn't name the macro that way -- and in fact you cannot because ':' is not allowed in filenames, it is used only after the drive name in paths. Pete

Oh, sorry. I didn't read further than the first few lines! Apologies. I don't know what is preventing the first example, and allowing the second. According to the code it should discard anything less than 1500 metres, but I assume there are exceptions for some reason. The code has become quite convoluted due to changes in the demands made of it, and changes in the BGL formats themselves between different versions of FS (MakeRunways dates origins back to FS95, 16 years ago!) In order to find out what is going on I would need the two BGL files you showed as test subjects, please. These were Addon Scenery\AirHispania SC\scenery\Torremocha de Jiloca_LE38_AF2.BGL Addon Scenery\AirHispania SC\scenery\Arcones_LE88_AF.BGL ZIP them and email as attachments to petedowson@btconnect.com. I should be able to tell you then what is going on. Regards Pete

Er, 1739 feet is still less than 1500 metres! 1500m = 4921 feet. Regards Pete

Sorry, by "triggers anything" do you mean "triggers nothing"? Otherwise I don't understand. So, how did you arrive at this name "L:FT_IgnitionSwitch". If it does nothing I'm not sure why you came up with it? Ah, so it doesn't use L:Vars after all? Didn't you use the "Log panel Lvars" control to get a list first? Was the L:Var a guess, or from a different aircraft? Each aircraft designer devises his own names. Yes, as before except instead of ipc.writeLvar you would use the ipc.macro function. Regards Pete

That's not old! I am 68 this year. Lua displays are created by Lua plug-ins to FSUIPC, but they are FS windows. I cannot control the colour or the font. But you can undock them -- that should help. Right click on the title and undock, same as any other FS window. That controls other displays, but I don't think it works on those Windows. Have you tried it? I might be wrong. Regards Pete

All shorter runways than 1500m? Right, and does this virtual airline fly airliners which can cope on such short runways? That's the main question I think. If not, then by definition it's the wrong runway. ;-) A facility, say a command line option like "/Rn" which tells MakeRunways to allow runways down to length n metres. If it is because of the length that won't make any difference. Let me know why you need it and I can add the facility. Regards Pete

But UT2 is for FSX, not FS9. If you wish to create your own AI in FSX you just need the SimConnect SDK, part of the FSX SDK installed with FSX DeLuxe or FSX Gold. Regards Pete

How strange. USB 3 is backwards compatible with USB 2 and USB 1. Are you sure the USB 3 facilities aren't disabled in your PC's BIOS settings? Oh, right. So they've got some USB incompatibility in the Control Manager? I have no idea how they managed that. They must be taking some short cuts and not following the correct protocols. If FS can see them, so will FSUIPC, because it uses the Windows joystick interfaces. It does not use any USB interface directly. It cannot even distinguish between a Game Port joystick and a USB joystick, let alone USB's 1, 2 and 3. Regards Pete

What version number of MakeRunways? If not 4.43 please update and try again. Is that the only one you found? It appears to be too short: Hdg: 255.568 true (MagVar -3.100), ASPHALT, 984 x 66 ft MakeRunways produces databases for airliner utilities like Radar Contact (its first user) and omits runways less than 1500 metres as well as heliports and water ports. What are you using it for? Maybe you need some sort of run-time override? In general I can't let folks include runways too short for IFR programs to assign. The xml and csv and rws files are all produced from the same data. The xml file is a recent addition, it isn't a source of the data as you imply here. Regards Pete

Okay. That's good then. I suspect it's a security setting in the Registry. Check out the thread entitled Help with FSUIPC4 code signature problem in the FAQ subforum. I also Googled the error number (0x80092026) and came up with this: http://support.microsoft.com/kb/555374 which looks relevant too. Regards Pete

And why on Earth could you not read how to do it in the first place? Is it because my documentation is in English and not your native language? If not that, please explain why you didn't understand it so i can possibly improve it in a later edition. In other words, where it says: The format is simply: RunN=(Options,)<full pathname of program to be run> then a few lines later: The Options you can use are as follows: ... CLOSE closes the program tidily (if possible) when FS is terminated. KILL forcibly terminates the program, if possible, when FS is terminated. How did you not consequently see the easy answer was to place a CLOSE, or KILL, in the (Options,) position as illustrated? In other words, what was causing this blindness to the answer even when I highlit the answers for you so explicitly and repeatedly? Andplease also tell me why you kept insisting on referring to WideServer throughout, even when I expressly pointed out it was [Programs], nothing to do with WideServer? How did that confusion possible arise? I can see nothing in the program or documentation which could lead to such a muddle so I am concerned. Ha ha! You fall back on that old nonsensical platitude even after certainly proving it totally incorrect? ;-) If my documentation is insufficient -- though this is certainly a first for this very simple section -- then it will only get improved by folks pointing out the parts they don't understand, not simply ignoring it as you did and wanting everything done for them. Pete

I'm not sure what that question was. You started a new thread. I'm afraid that's an area I know nothing about. Ican send then FS controls, some of which do things and many of which do nothing. It can also delete them. Sorry, no. It's an area of FS which is very complex and I've never hacked deep enough to work it out. You be better up moving up to FSX as the SimConnect interface which does this is well documented, and used, for instance, by Ultimste Traffic 2 for creating all of its AI traffic. Regards Pete

Okay, I had a chance to look at this tonight, just before going to bed. There's quite a long list of Local variables ("L:vars"). You can get those logged in the FSUIPC log file by using the FS control to "Log local variables". Here, I've done it for you (ignore the numbers on the left, that's just the elapsed time in milliseconds). : 543859 Aircraft="D75N1" 543859 Panel includes these local variables: 543859 L:EmergencyThrottleInUse = 0.000000 543859 L:Engine1ThrottlePosition = 50.000000 543859 L:rotate = 0.000000 543859 L:inst_lt = 0.000000 543859 L:adf_pwr = 1.000000 543859 L:kma20_comm_select = 0.000000 543859 L:reset_g = 0.000000 543859 L:stopwatch_knob = 0.000000 543859 L:dg_gyro_cage = 0.000000 543859 L:range_scale = 0.000000 543859 L:purge_valve = 0.000000 543859 L:xpndr_knob = 2.000000 543859 L:comm_switch = 1.000000 543859 L:comm_knob_lg = 0.000000 543859 L:kt76_knob_1 = 0.000000 543859 L:comm_knob = 0.000000 543859 L:nav_switch = 1.000000 543859 L:kt76_knob_10 = 0.000000 543859 L:nav_knob_lg = 0.000000 543859 L:nav_knob = 0.000000 543859 L:kt76_knob_100 = 0.000000 543859 L:vol_knob = 0.000000 543859 L:vol_knob_nav = 0.000000 543859 L:adf_knob_lg = 0.000000 543859 L:kt76_knob_1000 = 0.000000 543859 L:adf_knob_sm_hundreds = 0.000000 543859 L:adf_knob_lg_tens = 0.000000 543859 L:adf_knob_sm = 0.000000 543859 L:adf_vol_knob = 0.000000 543859 L:adj_zero = 0.000000 543859 L:kma20_switch_auto = 0.000000 543859 L:kma20_switch_nav2 = 0.000000 543859 L:marker_hi_lo_test = 0.000000 543859 L:ampsadj = 0.000000 543859 L:voltsadj = 0.000000 543859 L:shake_high = 0.000000 543859 L:shake_low = 1.000000 543859 L:low = 1.000000 543859 L:high = 1.000000 543859 L:red min hand = 0.000000 543859 L:red hour hand = 0.000000 543859 L:stopwatch = 0.000000 543859 L:stopwatch_reset = 0.000000 543859 L:stopwatch8 = 0.000000 543859 L:stopwatch3 = 0.000000 543859 L:adj_airtemp_zero = 0.000000 543859 L:insliteout = 1.000000 543859 L:carburant = 0.000000 543859 L:stall_warning = 0.000000 543859 L:vac_warning = 0.000000 543859 L:ident_on = 0.000000 543859 L:ident = 0.000000 543859 L:pulse = 0.000000 543859 L:lift_hornet_guard = 0.000000 543859 L:speed_radial_sw = 0.000000 543859 L:ki265_kts_tts = 0.000000 543859 L:ident_2 = 0.000000 543859 L:run_ltes = 0.000000 543859 L:flasstrbe = 0.000000 543859 L:cablites = 0.000000 543859 L:lachaleur = 0.000000 543859 L:bcn_lt = 0.000000 543859 L:landlamp = 0.000000 543859 L:brandstof = 0.000000 543859 L:radio_one_cb = 0.000000 543859 L:genalt = 0.000000 543859 L:radio_two_cb = 0.000000 543859 L:crankhornet = 0.000000 543859 L:strflash_sw = 0.000000 543859 L:beaconsw = 0.000000 543859 L:lamp_sw = 0.000000 543859 L:posit_sw = 0.000000 543859 L:air_filter = 0.000000 543859 L:cbnlts_sw = 0.000000 543859 L:pnlico = 0.000000 543859 L:maint_mode = 0.000000 543859 L:twist = 0.000000 543859 L:amorce = 0.000000 543859 L:einde = 0.000000 543859 L:trim_lt = 0.000000 543859 L:trim_rt = 0.000000 543859 L:friction = 0.000000 543859 L:chaleur = 0.000000 543859 L:altgen_sw = 1.000000 543859 L:no_refl = 0.000000 543859 L:hard_on_brakes = 0.000000 543859 L:chinstrap = 0.000000 543859 L:scarf = 1.000000 543859 L:collar = 1.000000 543859 L:revolve = 0.000000 543859 L:highpower = 0.000000 543859 L:sleeve = 0.000000 543859 L:shirt = 0.000000 543859 L:warnstl = 0.000000 543859 L:warnstlsnd = 0.000000 543859 L:backfire = 0.000000 543859 L:load_xpndrsw = 1.000000 543859 L:load_gensw = 1.000000 543859 L:load_adfsw = 1.000000 543859 L:load_commsw = 1.000000 543859 L:load_navsw = 1.000000 543859 L:paused = 0.000000 543859 L:EmergencyThrottlePosition = 0.000000 543859 L:GearLeverPos747 = 0.000000 543859 L:click = 1.000000 The ones controlling the Light switches are just these four: L:strflash_sw L:beaconsw L:lamp_sw L:posit_sw Now these reflect and control the switch positions, on screen. But the actual lights are still controlled by the standard FS controls, the ones you've probably already assigned. Those should work fine -- maybe you thought they weren't working because unfortunately the panel is implemented one-way -- i.e. the switches operate the FS controls, but the state of the lights isn't reflected in the switch positions (so, they can actually become unsynchronised). Additionally difficult is that operating those L:vars directly (in the way I'll show you in a moment) does NOT get the FS control sent. Only operating them with the mouse does that. However, changing the L:vars does change the visible switch position on screen. So, the solution is to have a little Lua plug-in file, one per light switch, which changes both the L:var AND sends the correct FS control. Here's this done for the Landing lights: n = ipc.readLvar("L:lamp_sw") if n ~= ipcPARAM then ipc.writeLvar("L:lamp_sw",ipcPARAM) ipc.control(65751) end 65751 is the "LANDING_LIGHTS_TOGGLE" control, and ipcPARAM is the value of the parameter you'll assign for your real switches. Save this in the FS Modules folder as, say, "stearman_LDG.lua". Then go to FSUIPC buttons & switches tab, "reload all buttons", then assign your switch as follows: For landing lights "on" assign to "Lua stearman_ldg" with a parameter of 1. For landing lights 'off' assign to 'Lua stearman_ldg" with a parameter of 0. Note that to maintain correct synchronisation with the switches and lights you need to start off with them synchronised. This is the problem with Toggle controls. (There's a more complex way to do it without using toggle controls, but i think this is as complex as you want to get at present). Okay? Now you can do the same for the other three (and any other switches as you wish). To ascertain which FS control is being sent just enable the Event logging in FSUIPC and check the log after operating the switch. You'll see entries like this: 1550234 FS Control Sent: Ctrl=65751, Param=0 1550234 *** EVENT: Cntrl= 65751 (0x000100d7), Param= 0 (0x00000000) LANDING_LIGHTS_TOGGLE The number you want is that "Cntrl" number. BTW, I did notice one oddity in this light switch set: the switch labelled 'BCN" uses the FS control "STROBES_TOGGLE" whilst the one labelled STR uses the "TOGGLE_BEACON_LIGHTS" control -- seems reversed. Maybe there's a reason? Ask the author. Regards Pete

I know you are referring to the facility in FSUIPC to start programs, via the [Programs] section. That was obvious from the start. Silly you is spot on, it seems, despite your attempt at sarcasm. First off, it is certainly NOT possible using any INI file of WideServer, because there simply is NO separate INI file for WideServer, as the WideServer facility is part of FSUIPC and its initialisation parameters are in the [WideServer] section of the FSUIPC4.INI file, as already made patently clear if you'd bothered to read my last reply. The running and closing of programs is handled by the [Programs] section of FSUIPC4.INI as you already know, not the [WideServer] section. I really cannot understand why you still obstinately refer to WideServer which has nothing whatsoever to do with anything you are asking about. Of course it is possible to get FSUIPC to close the programs it starts via the parameters you give above, and that is by the use of one of the two keywords documented for you -- CLOSE or KILL -- which you seem to have a complete blind spot for, despite even showing me the part of the documentation which lists and describes them, and even despite the fact that I pointed them out to you with their actions described in BIG BOLD RED LETTERS in my last reply. Why not simply insert one of those keywords in your Run parameters as instructed in the documentation? In other words just like [Programs] Run1=CLOSE,C:\BAKUP-INSTALL\IOCards\iocard.exe Run2=CLOSE,C:\BAKUP-INSTALL\OVERCLOCK\pmFBW46\pmFBW.exe As discussed in the documentation, which I really recommend you actually read rather than simply paste parts of into your messages, the KILL parameter will do the job if CLOSE doesn't, but it is a bit more drastic. This thread should be finished now. It is obviously futile giving you the answers, as you seem to refuse to recognise them even when presented to you on a plate! :roll: Pete

Okay, in that case it does seem that your Windows has a missing component or a corrupt cryptographic service. That's okay, it is just telling you what the signature is. But does it say it is correct or not.? You need to select it and click the "Details" button. It should say "this digital signature is ok" or words to that effect. I am not the signatory these days, it is Simflight, as you saw. Regards, Pete

Why would you call the [Programs] section of the FSUIPC.INI file the "WideServer" section? It is the "Programs" section. The [WideServer] section is the WideServer section! That's what they have those names, to distinguish them! :unsure: What on Earth are these two lines talking about then? Please, do actually read what you just extracted (completely unnecessarily I might add) from a document I not only wrote but still have copies of! Pete

1. Please NEVER use all CAPS! 2. You already posted this in a thread called "GPS" which I answered. Please don't keep posting the same questions. Read the answer already provided! Pete