Pete Dowson

Sorry, it has already been updated to 4.834. the point is not the specific version, but a version later than the one you have! Press the Windows key on your keyboard, the one with a Windows label to the left but one of the space bar (normally). In the space for entering search requests (normally with a faint "search programs and files" text), type "event viewer" and press the Enter key. In the resulting window select "windows Logs" on the left then double click "Application" on the right. This should bring up an event log giving details of all of the application events you've had. You need to find one with "Level" equal to "error" (red exclamation), describing the FSUIPC installer as the source. Ah. You never said that before. How do you reply to that? Me too! But I have tried to provide constructive replies to each of your posts nevertheless. I am away after tonight until Monday, so that'll be a break for us both. ;-) There's evidently a problem specific to your system, but finding it might take more exchanges yet. One of the steps I've suggested is still outstanding from your side, that of using the later version of FSUIPC4 in order to get to a point where you can do a manual save of the log. Regards Pete

Sorry. That's actually not correct. It can't write the log to disk till later because it doesn't know where and what versions of FS there will be, nor even if there's a Modules folder yet. So it doesn't actually write the log till later -- just when you close the Registration dialogue, in fact. The registration dialogue writes the Key file and on exit the log file is written. So, it sounds very much like the Installer is actually crashing before it finishes. Which is mighty odd. Can you please check the Win7 Application log for an error? There must surely be one recorded. If so, I need the module name, offset/address and error code. Also, try running the Installer and simply clciking "Cancel" in the Registration dialogue, without entering anything at all. Does that produce an Install log? Regards Pete

Hmmm. As am I. But without seeing the Install log i don't know how I can help. That file has all the information. When you run the installer, don't you see the Log scrolling on screen, and still there when it gets to the Registration prompt? The log is created right at the beginning. As the entries are made in that screen window, they are also being written to the disk. Try this, please. Download the 4.833 version of the DLL from the Download Links subforum, and copy the DLL into the P3D Modules folder. Then re-run the Installer. It will come up with a message saying that it has not overwritten the DLL because it is later. Before "OKaying" that message, click "save As" in the menu bar of the Windw showing the log, and save the log somewhere where you can find it later. Then let the installer continue. Find the log and paste it here please. Regards Pete

Same here. All my WideFS clients are using XP, whilst my FSX PC is win7 64. Not really. From time to time I've had difficulties with Networking, but i get around them by trial and error. I suspect the user name you need is the one you log in with on the Win7 PC, and the password will be blank if you never specified one. When you created the Netwrok on the Windows 7 PC I hope you didn't let W7 do its thing with the "HomeGroup". If the Win7 network is "HomeGroup" then I don't think it is possible to connect from anything other than Win7 PCs. It's very specific to Win7. You'd need to delete it altogether and start again, avoiding "HomeGroup" like the plague! Apart from that I'm afraid I don't know how to help. I'm far from being an expert on setting up Networks. Once i get one going i leave well alone. Once you do have a working network, using WideFS is not a problem. Regards Pete

The only thing the Registration part of the Installer does is create the KEY file. That's it's sole purpose. You only need the Key file for a registrered install. If there is no Install log file then the Installer could not have placed those files there -- you must have put the DLL files there manually! The Installer creates a log directly it starts -- it is also displayed on screen whilst it is operating. Dod you not see any of that? I cannot help without seeing the Install log. Also: This is an extract from the FSUIPC4 log file you posted. But you removed the first line which includes the Version number. Why? I always need to see the complete file, not part of it. The install log is called "FSUIP4 Install.log" I think you need to do a search for that to find out where you actually installed FSUIPC and the generated Key file. Regards Pete

Are you following the instructions and executing the Installer by "run as ... administrator"? Look in the P3D Modules folder. Can you see the FSUIPC files. There should be an Install log, an FSUIPC4 run time log, an FSUIPC4 ini file ("configuration settings") and an FSUIPC4 key file (probably denoted as a reg file). The last is your registration. Tell me what files you do see, and paste here the Install log and the FSUIPC4 log (NOT the others). Make sure P3D is closed down first. Regards Pete

Yes, you can do it using a Lua plug-in. Please see the Lua library documents in your FSUIPC documents subfolder (in Modules). Regards Pete

I assume you did change ALL the "Lua" assignments for this to "LuaValue"? Otherwise that would be the sort of problem you'd see, Otherwise I suspect that either multiple "LuaValue" executions are happening, or, more likely, the LVar write is taking longer, so it reads back differently. See if it works with the line reading the L:Var is commented out. I notice you had ipc.sleep(10)[/CODE] in your original, just after writing the L:Var. Maybe we need to take care of this possibility. Try changing the Select function, thus: [CODE] function Select(val) switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State if val == 1 then if switch > 0 then -- limits encoder switch from going below 0 switch = switch - 1 ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left end elseif val == 2 then if switch < 3 then -- limits encoder switch from going above 3 switch = switch + 1 ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right end end ipc.sleep(10) end [/CODE] You may need to experiment with the Sleep value. For use on arcraft in general you'd need to remove noth L:Var reads. Regards Pete

Okay, try this. (I've not tested it for real of course as I don't have your setup, but I've "dry run" it to be sure it's okay in my opinion). For this you must load it via ipcReady, as the comment stated in your original, but that's it. The one copy stays running all the time. You must change your assignments to use LuaValue <name> instead of Lua <name>, with parameters 1 and 2 as before. This causes the "param" event, which calls the "Select" function. The displays are updated when necessary on a timer event. I've set that for 250 mSecs, or 4 times per second. You can adjust that to get the results you want. Note that it also assumes that the L:Var "DME_Switch" actually exists -- the Select function updates it and the PollSwitch function reads it. If you want this to work will all aircraft, including those without that switch, just delete the line switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State[/CODE] and it'll use the internally maintained "switch" value directly, instead. Here's the code: [CODE]-- Launched from ipcReady.lua -- Initialize GFunit = 1 gfd.SetBright(GF166,GFunit,15) prevswitch = -1 switch = -1 min1 = 0 min2 = 0 miles1 = 0 miles2 = 0 kts1 = 0 kts2 = 0 local function ConvertTime(value) min = value / 10 -- convert data to seconds min = min / 60 -- convert seconds to minutes if min == 16.665 then min = 0 else min = math.floor(min) -- rounds decimal down end return min end -- functions -- all called by events function Select(val) if val == 1 then if switch > 0 then -- limits encoder switch from going below 0 switch = switch - 1 ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left end elseif val == 2 then if switch < 3 then -- limits encoder switch from going above 3 switch = switch + 1 ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right end end end function Time1(offset, value) min1 = ConvertTime(value) prevswitch = -1 end function Time2(offset, value) min2 = ConvertTime(value) prevswitch = -1 end function Distance1(offset, value) miles1 = "2 " .. value -- Formats DME1 Display prevswitch = -1 end function Distance2(offset, value) miles2 = "2 " .. value -- Formats DME2 Display prevswitch = -1 end function Speed1(offset, value) kts1 = value -- Reads DME2 Speed prevswitch = -1 end function Speed2(offset, value) kts2 = value -- Reads DME2 Speed prevswitch = -1 end function PollSwitch() switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State if switch ~= prevswitch then if switch == 0 then gfd.SetDisplay(GF166, GFunit, 0, "") gfd.SetDisplay(GF166, GFunit, 1, "") elseif switch == 1 then ipc.writeUW("0378", 1) -- Set to DME1 gfd.SetDisplay(GF166, GFunit, 0, miles1) -- Display DME1/NM L Window gfd.SetDisplay(GF166, GFunit, 1, kts1 .. (string.format(" %02.f", min1))) -- Display DME1 KTS/MIN in R Window elseif switch == 2 then gfd.SetDisplay(GF166, GFunit, 0, "H ---") gfd.SetDisplay(GF166, GFunit, 1, "--- --") elseif switch == 3 then ipc.writeUW("0378", 2) -- Set to DME2 gfd.SetDisplay(GF166, GFunit, 0, miles2) -- Display DME2/NM L Window gfd.SetDisplay(GF166, GFunit, 1, kts2 .. (string.format(" %02.f", min2))) -- Display DME2 KTS/MIN in R Window end prevswitch = switch end end event.offset("0C29", "STR", 4, "Distance1") event.offset("0C2E", "STR", 3, "Speed1") event.offset("0304", "UW", "Time1") event.offset("0C33", "STR", 4, "Distance2") event.offset("0C38", "STR", 3, "Speed2") event.offset("030A", "UW", "Time2") event.param("Select") event.timer(250, "PollSwitch") -- Allows 4 updates per sec -- adjust as needed [/CODE] Don't hesitate to ask questions if there's anything you don't understand, or if it doesn't do what you want. Regards Pete

Found and fixed the bug causing the crash anyway ... 4.834 or 3.999n now in the Download Links sub-forum. If you'd still like me to revise the plug-in for better operation, though, please say so. Regards Pete

In an attempt to understand this script i've tidied up the layout a little: -- Launched from ipcReady.lua -- Initialize GFunit = 1 switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State gfd.SetBright(GF166,GFunit,15) if ipcPARAM == 1 then if switch > 0 then -- limits encoder switch from going below 0 switch = switch - 1 ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left ipcPARAM=0 -- Clears ipcPARAM end ipc.sleep(10) end if ipcPARAM == 2 then if switch < 3 then -- limits encoder switch from going above 3 switch = switch + 1 ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right ipcPARAM=0 -- Clears ipcPARAM end ipc.sleep(10) end if switch == 0 then function Distance(offset, value) end function Speed(offset, value) end function Time(offset, value) end gfd.SetDisplay(GF166, GFunit, 0, "") gfd.SetDisplay(GF166, GFunit, 1, "") end if switch == 1 then gfd.SetBright(GF166,GFunit,15) ipc.writeUW("0378", 1) -- Set to DME1 function Distance(offset, value) miles = ipc.readSTR("0C29", 4) -- Reads DME1 NM miles = "1 " .. miles -- Formats DME1 Distance Display end function Speed(offset, value) kts = ipc.readSTR("0C2E", 3) -- Reads DME1 Speed end function Time(offset, value) min = ipc.readUW("0304", 2) -- Reads DME1 MIN min = min / 10 -- convert data to seconds min = min / 60 -- convert seconds to minutes if min == 16.665 then min = 0 else min = math.floor(min) -- rounds decimal down end gfd.SetDisplay(GF166, GFunit, 0, miles) -- Display DME1/NM L Window gfd.SetDisplay(GF166, GFunit, 1, kts .. (string.format(" %02.f", min))) -- Display DME1 KTS/MIN in R Window end end if switch == 2 then function Distance(offset, value) end function Speed(offset, value) end function Time(offset, value) end gfd.SetDisplay(GF166, GFunit, 0, "H ---") gfd.SetDisplay(GF166, GFunit, 1, "--- --") end if switch == 3 then ipc.writeUW("0378", 2) -- Set to DME2 function Distance(offset, value) miles = ipc.readSTR("0C33", 4) -- Reads DME2 NM miles = "2 " .. miles -- Formats DME2 Display end function Speed(offset, value) kts = ipc.readSTR("0C38", 3) -- Reads DME2 Speed end function Time(offset, value) min = ipc.readUW("030A", 2) -- Reads DME2 MIN min = min / 10 -- convert data to seconds min = min / 60 -- convert seconds to minutes if min == 16.665 then min = 0 else min = math.floor(min) -- rounds decimal down end gfd.SetDisplay(GF166, GFunit, 0, miles) -- Display DME2/NM L Window gfd.SetDisplay(GF166, GFunit, 1, kts .. (string.format(" %02.f", min))) -- Display DME2 KTS/MIN in R Window end end event.offset("0C29", "STR", 4, "Distance") event.offset("0C2E", "STR", 3, "Speed") event.offset("0304", "STR", 2, "Time") event.offset("0C33", "STR", 4, "Distance") event.offset("0C38", "STR", 3, "Speed") event.offset("030A", "STR", 2, "Time") [/CODE] First, as i said earlier, I'm actually rather amazed that Lua can make sense of this. In my 49 years of programming I've never actually seen conditional redefinition of functions like this. It may be a really well-known and powerful feature of Lua, but it is new to me. If I wanted those functions to do different things according to a switch setting I would test the switch setting inside the functions, not make the switch setting redfine the functions completely. Second, since the encoder you are using looks like it is merely selecting a DME display mode, why on Earth does it need to be rotated quickly enough to generate a CTD? Third, apart from the odd function methods, and the fact that it is a resident program which is continually recompiled and reloaded, there are definite mistakes. For instance offsets 0304 and 030A are 16 bit integers NOT 2-byte strings. Your events for these are wrong. I notice you realise they are numbers in the Time functions. Fourth, the events supply the changing values as parameter "value", yet you are reading them again in the functions. That is really very inefficient. Why read them twice? Fifth, the DME switch setting is only read when you operate the encoder or whatever is sending the ipcPARAM changes. Shouldn't that be read regularly? ---------------------- Would you like me to attempt to revise the program for you? Regards Pete

There are some strange things in this Lua script which make no sense to me. Did you write it? Could you explain things for me, please? 1. It says at the top that it is run by ipcReady. The fact that it contains events (monitoring all sorts of things) means it is then resident -- i.e. always running, waiting for changes in the offsets it is monitoring. Yet you say "The ipcPARAMs 1 & 2 are assigned to the GF-166 encoder". Are those encoder actions to re-run this continuously running Lua, or merely to provide the Parameter (ipcPARAM) value via the "LuaValue" assignment? It is rather odd, not to say downright dangerous, to have an event-based plug-in restarting at frequent intervals. If this is what you are doing then I'm amazed you never saw any problems with older versions of FSUIPC. It is very difficult to make the processing of these 100% foolproof against rogue programs. I do try, but there comes a point where the reduction in efficiency outwiighs the avoidance of wrong programming techniques. It looks to be as if you really need two Lua programs, one to monitor offsets and maintain the displays, and the other to respond to your encoder. If you must put it into one you should use the LuaValue call for the encoder responses and the event.param function to process them. That way it is entirely event based and very safe. and probably 1000 times more efficient because it wouldn't need continuous reloading and recompilation. 2. What is meant by this section? if switch == 2 then function Distance(offset, value) end function Speed(offset, value) end function Time(offset, value) end gfd.SetDisplay(GF166, GFunit, 0, "H ---") gfd.SetDisplay(GF166, GFunit, 1, "--- --") end [/CODE] The function lines are declaring functions which are actually re-declared later, twice more. These declarations are devoid of code so effectively do nothing. I'm surprised that the Lua compiler allows this without complaint. Are you actually intentionally changing the functions being used by the Events instead of simply processing the parameters in the functions? Maybe this is a legitimate Lua programming technique? I know it would be nonsense in any other language -- a function definition remains for the duration, but here you seem to want to declared them based on variable values. It is very strange to me. 3. You have the sequence "else" then "end" in at least two places. Why? Just to slow loading down? Because that's the same as just "end". Why an "else" with nothing else to do? I would like to nail the CTD in any case, but quite honestly it might not be worth the extra inefficency in the interpreter. Regards Pete

Yes, but the best test (and quickest!) would have been to try. Did you not? Pete

Hmmm. That's very srange, because there were several ways such actions could crash in the earlier version which were fixed! I've not met so far any Lua programming which could make a CTD. If the access to the GoFlight 166 is commented out, so it doesn't need it, does it still crash? Because I'm going to need to be able to reprodce the problem. Maybe another GF device substituted will be needed? The other problem is the aircraft -- I do not have that aircraft, so will I be able to make it crash without it and without the L:Vars it is using? Also, I see that you are using LINDA. Can you use this Lua program without LINDA? If so, does it still CTD? Can you also please try GFDev 2.0.10.1 (the latest I have seen -- see the Download Links subforum here). When did 2.1.0.1 come out? Have you updated to that recently? Finally, the main information I need on any CTD is the offending module name, the offset/address, and the error code. These things should be available in the Windows error log. [LATER] Fixed the bug -- please use 4.834 or 3.999n now available. But please still note my comments in the other messages below. I think you'd be happier with a better performing plug-in. ;-) Regards Pete

It is as I thought. You deleted three lines instead of the two I said! You need to put this: <Launch.Addon> back in front of the line first mentioning FSUIPC4. Files like this are VERY fussy. You must be careful when editing them to do exactly as needed. I hate XML for this very reason -- INI and CFG files are much more flexible, but Microsoft chose to go down this XML route. :-( Pete

Yes, I understood this. But how will you get the axis to the brake part without passing through the rudder operation? This is what I pointed out. Pete

So why are you bothered about flaps settings on the non-flying aircraft? why? All you need to do is clear the assignment of the axis to Flaps or Flaps Set, on the left side of FSUIPC's axis tab, then use the RIGHT HAND SIDE (i.e. the side of that Tab display you've not yet used and seem reluctant to look at!). Just set a region for Flaps Down at one end, assigning that control for both directions, then one for each intermediate detente, assigning Flaps Incr for one direction and Flaps Decr for the other --- each detente will have the same assignments -- until you get to the Flaps Up position where you assign that for both directions. Once you've done that it will all work using just those controls -- the 4 associated with F4-F5-F6-F7. You'd need to start by moving the lever to full flaps up or down, in order to get the positions matched, but then it will be no trouble. It is very easy to do. I don't know why you ignore this possibility. Have you even looked at it? I really can't help any more. If you don't see what I'm talking about, I'll have to give up. Sorry. Pete

I thought you'd worked out a way to do that? I've never heard of using one axis for two such diverse functions, and I don't see how you can make it work properly. In order to press the brakes the rudder would have to first be fully deflected. If you wanted to press both brakes (which would be the normal case) you'd have to tell FS first to move the rudder both full right and full left. They'll be in conflict and the rudder will probably swing wildly until one of them won the battle. I thnk you'd be far better off assigning buttons for brakes. But if you want to try axis assignment you must surely have noticed that you can make up to 4 axis assignments to each axis? Pete

Which PC has the aircraft which is flying? Surely the first one, with the operating flaps? Why do you care about flaps in a non-flying aircraft? But is this because of the Keypress, or because of the control it sends? You can't use both an axis control AND the separate FS flap controls. One or the other. If you need to use only the controls, do that. Do NOT assign the axis to the axis control (on the left part of the axis tab), but only assign the relevant ranges (detentes) to controls on the right-hand side. I have suggested this before, probably more than once, but you ignore this suggestion. Why? Pete

You are now contradicting your own statement earlier, this one: Mind you, that one contradicted the earlier one where you said the flaps control was on the same PC with the yoke, spoilers, rudders and tiller. Why? If it is a flaps axis, like an elevator axis or rudder axis, then assign it as an axis and calibrate there!!! I really understand nothing now, because each time you post here you contradict things you sent before! Why on Earth would you want an axis controlling the flaps and FS controls at the same time? That would be a nonsense! There'd be all sorts of conflicts. EITHER use the axis with a single axis control -- normal assignment followed by calibration, like most normal users, OR use the range assignments instead to assign to controls! Do not use both together. That will be chaos! Sorry, I've no idea where this statement arises. If you've done it all why are you still asking questions? Sorry, no, not at all. You contradict yourself in so many places I can't make sense of it. Sorry. Pete

Well, they are no use there at all. If there are no INI files in the Modules folder, next to FSUIPC itself, then that FSUIPC has never been runt least the DLL, the INI and the LOG file, all in the Modules folder, and a subfolder called FSUIPC Documents. Good, that's where they should be. They are the only ones used. Pete

There are no files related to FSUIPC in any of those folders. the ONLY files related to FSUIPC are in the Modules subfolder. I've no idea what you are doing with INI files in the main FS folders, but they are not going to be read by FSUIPC. I don't know why you have two separate installations of FSX, but it won't matter providing you are running the correct one! FSUIPC doesn't use any files outside of the Modules folder for whichever copy of whichever sm you run. Pete

Er, no!! There a hundreds of entries in the drop down! You have already told me you can't use FS controls, you must use keypresses like F4 - F7. So why are you looking at Flap controls? The are key press/release controls, and if you add macros into the Modules folder those will be listed too!!! Pete

"Only"? Proper aircraft rudders are normally a single pot, as it controls only one surface. Do you mean the left and right work independently, like car driving pedals -- left brake, right accelerator (gas)? Er. Hang on: you are trying to use one pedal for both rudder control and brake? Phew! Well obviously it must, if it is sending the same range of values. You need it to operate -16384 to 0 in the opposite direction. You can use the multipler on the axis assignment line in FSUIPC's INI file for this -- see the Advanced User's manual. Just add ,*-1 Pete

In all FSUIPC's calibration sections the numbers MUST increase left to right, NEVER the other way around. So, yes, REVERSE the axis (REV button) before calibration. Spoilers, flaps and tow brakes almost always need reversing as their operation is in the reverse direction of things like throttles. No, you merely need to reverse the axis before you start!! But you said "where all axes are connected : yokes, rudders, flaps, spoilers, stiller.", so this problem must also apply to yokes, rudders, spoilers and tiller! How are you solving that. Sorry, but it isn't making sense. Either you want to drive the flaps by an axis, on the FS PC, or by buttons. In the latter case use FLAPS SET with specific parameters for each position. Well, yes, if you must use keypresses. But is that how you control elevator, ailerons nad rudders too? It seems a very heavy price to pay to use "Multicrew" program! I think I'd rather discard that program and fly with good controls! If you want to do that sort of thing you have to assign the ranges on the right-hand side of the Axis Assignments tab -- NOT to the FLAPS axis at all! The drop down for assignment of up to 10 axis regions includes the FSUIPC control to send a keypress, but to send multiiples you'll probably need to assign to a macro. Regards Pete