-
Posts
38,265 -
Joined
-
Days Won
170
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Pete Dowson
-
Why, and how? There should be no need. Running FSX "as administrator" won't change whether FSUIPC4 is loaded and running or not. Did you install it (using the Installer)? Make sure you have the latest version (see the Download Links subforum). If there is an FSUIPC4.LOG file produced in the FSX Modules folder when you run FSX, then FSUIPC4 is being loaded, and is running, but probably cannot get a connection to SimConnect. In this case, show me the FSUIPC4.LOG file (paste it into a message here). If no log is being produced, then either FSUIPC4 is not installed or there is a SimConnect problem or a corruption in the DLL.XML file, which is what tells Simconnect to load FSUIPC4. In this case, show me the FSUIPC4 Install log file instead, and we'll take it from there. Regards Pete
-
Sorry, I've never heard of that simulator. If it was made by PFC for Jeppesen it is quite likely that it uses a protocol specific to Jeppesen and their proprietary property. Both Elite and Jeppesen originally did such things to force their users to stick to their own software. Possibly PFC can help, but it would probably need a firmware or hardware upgrade, likely both, and it wouldn't be cheap! Regards Pete
-
FSUIPC/Windows 7/AFCAD and others
Pete Dowson replied to kevtherev's topic in FSUIPC Support Pete Dowson Modules
I don't know any of those programs so I don't know what would cause those problems, but if it is due to an inability to connect to FSUIPC then that may be because you are running FS "as administrator" and the other programs not, or vice versa. Programs at different privilege level can't talk to each other using shared memory, which is how the FSUIPC interface works. Strictly it shouldn't be necessary to run any of it "as administrator", but with Windows 7 the "Program Files" folders are protected against writing, which is a problem for many programs written without Win7 awareness. Really it is best to install FS elsewhere, not in its default folders, but if it is too late for that you may need to run everything "as administator". Regards Pete -
FSUIPC in COMBO II BOEING
Pete Dowson replied to sudqui's topic in FSUIPC Support Pete Dowson Modules
Sorry, I see your second message, but it appears garbled. It looks like you are trying to say things about the INI file, but it would be better if you pasted the file into your message rather than try to put in bits which don't make sense on their own. Note that the order of the sections (headed like [xxxxx]) is irrelevant, in case that is your worry. If you are wanting to add a new section, you can add it at the end. If you do have a question about FSUIPC please tell me exactly which version -- if not the latest, 3.998q or 4.756, please update first in case your problem no longer exists. You can get the latest from Download Links subforum. Regards Pete -
Please download the FSUIPC SDK and use the offset lists provided for reference. I don't remember all these things in my head, I have to use the same documents as those you should be using. Regards Pete
-
wideserver wont start
Pete Dowson replied to Mr. Midnight's topic in FSUIPC Support Pete Dowson Modules
Robert, have you tried the logging as I requested yet? If there's an FSUIPC problem I need to fix I'd like to get it done, so I'd be grateful for some feedback on this, please. Regards Pete -
Ian is correct. It's the stall warning offset I use in my cockpit for the stick shakers. As to how you can make yours work, that presumably needs some sort of output digital to analogue device connection, and either a program to read the offset and drive the output device or, possibly, a Lua plug-in to do the same, assuming the output device is either serial port or USB connected. Regards Pete
-
Script to read LVAR too slow
Pete Dowson replied to Tiago Thiengo Vieira's topic in FSUIPC Support Pete Dowson Modules
Sorry, can you explain what you mean in a little more detail: 2 seconds for each ipc.write? I really can't believe that -- it's up to 1 millisecond assuming the offset write does not trigger further actions in FS as many do. If you mean that the whole cycle of 90 LVar reads and ipc.writes takes so long, then surely the majority of the time is spent in the Gauges of the specific aircraft getting the LVars? What aircraft is it? You could make the ipc.writing part much faster by reading all the LVars into a Lua array or individual variables, then writing the whole lot to offsets using one ipc.writeStruct. The writeStruct facility is much more efficient for multiple writes (just as also is the readStruct for reads). Certainly if the offset being written causes some further action, yes. Otherwise it would be better to use writeStruct. That depends. How are you running it? I assume it is loaded only once then running all the time -- if not, that's the man change to make, because loading and compiling a long script is going to take more time than its execution. But otherwise all you are doing is having many threads all trying to read LVars instead of one. If the LVar reading routine in FS is reentrant that might be faster, but otherwise it will be slower. You'd need to use the ipc.elapsedtime function to find that out. I've no idea, though I'd suspect reading the L:Vars is the one taking most time as the rest is only local code in FSUIPC and used in many very fast Lua plug-ins. Not at present. That would mean that FSUIPC would need to be in a loop reading LVars all the time in case one changed. I could consider adding such a facility, but if you used it for 90 LVars I would be concerned that, with the code then running in the main FS thread, it would affect FS performance. However, please do try the example Lua plug-in provided with FSUIPC which logs L:Vars and their changes. See how long that takes with your aircraft. Can you tell me which aircraft you are testing this with? I could try some experiments here, then, if you wished. [LATER] I've just done some testing on calling the L:Var reading routines directly, in the Lua thread, instead of via a message to the main thread (which I thought would be necessary as many FS routines aren't re-entrant so access to them has to be 'regimented' through the normal main thread). So far, with two separate threads reading L:Vars I can't make it crash or go wrong, but that doesn't mean it's safe so I'm not rushing into releasing such a version. But I will pursue it further. Would you like an interim update to test there? What FSUIPC version are you currently using? Regards Pete -
Question on Initial.lua I(Widefs)
Pete Dowson replied to cellular55's topic in FSUIPC Support Pete Dowson Modules
Sorry, I see no question. Are you talking about the subject of this thread? I think not. I suspect you are either in the wrong Forum, or you need to post in a new thread with an appropriate subject title, and posit a question rather than apologise for a question I don't yet appear to have received! I am here in this forum to answer questions, but you have to pose them properly first, with information, and in a thread of your own with a proper title. Please try again. And remember, I have no idea what you are talking about unless you explain yourself. Regards Pete -
The error is in this line: ipc.togglebitsUB(offset, thisbutton) That should be ipc.togglebitsUD(offset, thisbutton) because "UB" is an unsigned byte (8 bits) so is only coping with 2 x 4 buttons, your first two encoders. "UD" is an unsigned double word, which is 32-bits or 4 bytes. This is what is also assumed by the line: offset = offset + 4 which moves on by 4 bytes -- i.e. the 32 bits which should have been dealt with by then. Regards Pete
-
If you are talking about assignment to an offset control in FSUIPC, then the correct format ix x9400. The "C" format 0x9400 will resut in x0000 being used, as you found, because of the leading 0. FSUIPC needs to first see the 'x' to know it is hexadecimal, not decimal. Okay. That shows that pressing button 12 on joystick 1 causes the 32-bit (4-byte or DWORD) offset x9400 to be set to the value x430, but then, on release, to the value x429. I don't know why you are doing this, but if that's what you intended. what is the problem? Presumably you then changed it: because now the same button sets x1AE when pressed and x1AD when released. If you put decimal 430 it will be identical to hexadecimal x1AE. They are identical values, no different at all. Likewise 429 = x1AD. The picture you added shows exactly what is actually occurring. I'm afraid I don't find any actual question to answer in your posting. Did you have one? Pete
-
Best way to find out if an engine is running
Pete Dowson replied to lordofwings's topic in FSUIPC Support Pete Dowson Modules
In what context? Pete -
Sorry, I don't have enough information. Is this the USB version of the cirrus, using PFCHIF.DLL, or the serial port version using PFCFSX.DLL? And what are you actually trying to assign. If you can explain what you are doing and how maybe I can help. It sounds like you mean PFCCSX, i.e. the serial port version. Yes, assignments in FSUIPC override the normal actions, but even if they didn't you'd get both actions -- the FSUIPC assignments aren't discarded if you've made them and the button operation is detected. Regards Pete
-
Encoders and keyboard hack
Pete Dowson replied to Basje's topic in FSUIPC Support Pete Dowson Modules
Ome thing. I notice there's a space in your macro calls: ipc.macro("LevelD767: ALTInc")[/CODE] I'm not sure whether spaces are discarded -- it may be looking for macro names with a space too. Try removing the spaces in both macro calls. In FSUIPC's logging options set the Lua logging option, so that it creates its own log. Close FS, and edit your Lua program, adding this line in the function, before the first 'if ...' line: [CODE]ipc.log("In function, keycode = " .. keycode .. " KeySeen = " .. KeySeen)[/CODE] Show me both the FSUIPC log and the Log for the Lua plugin. There's only ever one LuaFiles section. It simply gives FSUIPC the index number for every Lua file in your Modules folder. Those are only relevant when assigning a button or key to a Lua file, which doesn't apply in this case. Pete -
Encoders and keyboard hack
Pete Dowson replied to Basje's topic in FSUIPC Support Pete Dowson Modules
Yes, of course. They aren't assigned. If they do something in FS you don't want you'd need to assign them to something innocuous. The Lua event doesn't stop the keys, it just calls your function when the keys are seen. BTW keycode 186 is the ;: key, and 57 is the 9 key on the main keyboard. I assumed you'd changed from using A and B? Naturally the keycodes in the Lua must correspond to those sent from your contraption. Pete -
wideserver wont start
Pete Dowson replied to Mr. Midnight's topic in FSUIPC Support Pete Dowson Modules
Where's the rest of the Log? I asked you to close FSX before getting the log. It looks like instead you went into the Flight menu and loaded another flight? After the initialisation follwing the point where FSUIPC logs the FLT and AIR files, there should be entries in the log like this: 13781 System time = 11/01/2012 01:08:32, Simulator time = 01:08:25 (01:08Z) 20250 Starting everything now ... 21500 Advanced Weather Interface Enabled[/CODE] Without those it seems FSUIPC is not fully operational. It appears something is stalling FSX, so that Simconnect is not supplying the signals telling FSUIPC that the sim is actually 'ready to fly'. WideServer (and many other things in FSUIPC) do not start running until FSX is 'ready to fly'. The only thing different I can see is that you are loading FSX with a flight Plan already operational: [CODE]22667 C:\Users\R6bert C\Documents\Flight Simulator X Files\IFR McCarran Intl to Indianapolis Intl.PLN[/CODE] We might need to try with a different initial flight, as a check, but first I need more information. So, please, with FSX closed, add the following lines to the [General] section of the FSUIPC4.INI file: [CODE] Debug=Please LogExtras=x1 TestOptions=x800[/CODE] Then run FSX till it appears 'ready to fly', then CLOSE it down (please!), and only then get the log and paste it back here. After that, please try with a different initial flight, one without a PLN attached. Do the same and paste the log again. Thanks, Pete -
Encoders and keyboard hack
Pete Dowson replied to Basje's topic in FSUIPC Support Pete Dowson Modules
No, it is not optional in the event.key. That would imply matching to the keycode irrespective of any shifts set, and there is no such facility. Where things are optional in library functions the documentation states so, and the assumed value resulting. The syntax of a conditional test using if is if <condition> then <action> end[/CODE] I'm sure this is clear on the Lua website. The condition might be compound, made up of separate tests joined by "and" or "or", with optional parentheses () to make things clearer or join otherwise ambiguous parts. The action is a block of code which is performed if the condition is true. The code is executed in the order it is presented, if that's what you mean by 'over time'. More fully 'if' statements can have 'else' actions too (or elseif for further alternative conditions, see later): [CODE]if <condition> then <actiontrue> else <actionfalse> end[/CODE] Because it then contains the last keycode actually seen, no matter what it was, so that the sequence you are looking for can be detected. That's the purpose of KeySeen - to not only mark that a key was seen but to remember if it was an A or a B. Else how will you ever detect the A-B or B-A sequence you need. It is only reset to 0 to start a new sequence once you've seen a A-B or B-A. Don't you see that this is logical and necessary? The two conditions should certainly NOT be just on 186 or 57, but 186 when the last key (keyseen) was 57, and vice versa. You are trying to detect A-B and B-A, not simply A or B as those alone tell you nothing. Sorry, you don't. Who ever said you can't use 'and'? 'and' and 'or' are central to the idea of joint and alternative conditions! I see in your code you've used 'and' completely outside of any condition, which is wrong, but not where you want it, in the conditions! I'm going to have to do it for you as I can't really afford any more time on this: [CODE] KeySeen=0 function AltitudeChange(keycode) if keycode == 57 and KeySeen == 186 then ipc.macro("LevelD767: ALTInc") KeySeen = 0 elseif keycode == 186 and KeySeen == 57 then ipc.macro("LevelD767: ALTDec") KeySeen = 0 else KeySeen = keycode end end event.key(186, 8, "AltitudeChange") event.key(57, 8, "AltitudeChange") [/CODE] Regards Pete -
Question on Initial.lua I(Widefs)
Pete Dowson replied to cellular55's topic in FSUIPC Support Pete Dowson Modules
And please first update to FSUIPC 4.756 and Wideclient 6.90. Then you are using the same versions as me, and in any extra logging I ask you to do (probably in WideClient) I'll know we are on the same page. Regards Pete -
I don't think so. I don't know of any 'airport' controls. They are likely all autopilot related. The names of FS controls used in FSUIPC are obtained at run time from FS's own table of controls in its "CONTROLS.DLL" module, and are the same as it uses internally and in its CFG and XML files. If they seem illogical or inconsistent, which they often do, you need to lay that at Microsoft's door. ;-) Regards Pete
-
Best way to find out if an engine is running
Pete Dowson replied to lordofwings's topic in FSUIPC Support Pete Dowson Modules
The combustion flags, eg 0x0894 for Engine 1. That's exactly what they are for. BTW version 4.60a is very old now and completely unsupportable, so if you are going to continue to ask questions please update. I can't support anything earlier than 4.70 -- the current version is 4.756. Regards Pete -
For some reason you posted in the User Contributions subforum rather than here in the Support Forum, so you are lucky i spotted it. I've moved it for you. If you insist on assigning to "Autopilot On", then of course it will only turn the Autopilot On. It would be silly otherwise, don't you think? Not sure wehy any of those methods would be expected to tell you about specific FS controls. You simply want the same control as normally assigned to 'Z', which is 'AP MASTER'. You'll find a complete list of controls in your FSUIPC Documents folder, and you can always find out what FS controls are instigated by keypresses or mouse clicks by enabling FSUIPC's Event logging, using the key or switch, and checking the log. You'll get an entry like this when pressing 'Z': *** EVENT: Cntrl= 65580 (0x0001002c), Param= 0 (0x00000000) AP_MASTER Regards Pete
-
No need. I'm glad you got it sorted out. Regards Pete
-
How are you writing those values? I'm assuming you'd be assigning the throttles in FSUIPC rather than FS. FSUIPC (and even FS) only make changes if they receive a new value. Providing your throttle is not moved and isn't jittering then it won't interfere. However, Saitek throttles in particular seem to be very jittery, so for this to work you probably would need to park them someplace calibrated as a dead zone. Alternatively most analogue input methods are usually stable at their very maximum and minimum positions -- which should really be calibrated with a little dead zone in any case. If you are talking about some sort of fly-by-wire or external autothrottle implementation, though, and interfacing to FSUIPC via the offsets, please look up offset 310A which tells you how to do such things with the throttle inputs disconnected. Really? So not fly-by-wire or autothrottle then? For those axes you'd need to park the levers into a stable or dead zone. If you wanted to disconnect them instead you'd need to use a Lua plug-in and route the values through that so they can be stopped. Easy enough, though. You could do the same with the thottles if you wished. Regards Pete