Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Well the PTT transmit on/off is being sent, as the log shows: Control 1001 is PTT on, 1002 is PTT off. However, keeping it pressed for less than half a second probably wouldn't be noticed on SB by the time the network has put them together. In other cases you are releasing it within 300 milliseconds! Far too short to say anything, surely? There are even many cases of less than a tenth of a second! :roll: There appears to be no case recorded in that log where you held the button down long enough for SB to even bother switching its listening on! Pete
  2. Okay. I also found that my "problem" in FSX wasn't a real one. I'd forgotten I had some other controls configured with "direct" assignment -- when direct assignment is being used in FSUIPC4, it doesn't intercept the normal FS controls (because they should be unused), and so therefore cannot disable them! In fact it used to intercept them, but this gave real problems for fly-by-wire addons. Okay. Best Regards Pete
  3. Sorry, I don't know how to do that in FS2004. For FSX, SimConnect provided the facility so it is supported in FSUIPC4. Regards Pete
  4. Thanks. I have a couple of RP48's so I can test here and see what is happening. I'll get to it before the weekend. Regards Pete
  5. Actually, there were more changes than I expected -- the MCP Pro has a lot more LEDs than anything else, and of course 6 digital displays compared with the MCP's 5. I've also added the single digit for the GF-ATC. Because of all these changes, and the fact that i don't know whether the digital displays are still numbered left to right, as in the MCP, I can't release the update till some testing has been done for me. So, the update is a Beta, 1.241, and is attached. Please do try every LED and every display, and tell me what goes on. Thanks. Pete GFdisplay1241.zip
  6. just to clarify: is this a functionality which can be triggered programatically using the FSUIPC interface? Yes. Any FS controls (or added FSUIPC ones) can be sent via offset 3110, with the optional parameter written in the same write, or immediately before, in 3114. You use the numeric equivalent of the controls, as listed in the "List of FS controls" I publish, for FS, or in the Advanced User's document, for FSUIPC. Pete
  7. Well, it shouldn't be, but I'd better get a copy to check, and maybe replace the one above. Is it easy to find, on its own? Can you give me a link? Else perhaps you could ZIP it and send it as an email attachment to me at petedowson@btconnect.com ? Thanks, Pete
  8. Here's a very professional tutorial document prepared by 'SimSamurai' (see http://www.simsamurai.net ), dealing mostly with the job of assigning and calibrating your controls using FSUIPC. Thanks Jeff! http://fsuipc.simflight.com/beta/SIMSAMTORIAL.pdf I've put a copy in the "Updates & Goodies" Announcement too, to make it even more easy to find. Queries, comments, and letters of thanks and congratulations to SimSamurai please. Not me! I'd make a lousy teacher! ;-) Best Regards Pete
  9. Sorry, I don't know. But the answer would not be specific to your GoFlight controls, it would apply to any sort of button or key assignment. If that add-on provides keyboard short-cuts for manipulating the Altitude and V/S values, then you could assign to those. Or else you might find the FSUIPC mouse macro facility is able to operate on the panel dials, and therefore be used for FSUIPC assignments. Finally, if both of those fail, you might, just, be able to do it via L-var access in a Lua plug-in program. But that gets complicated. FSUIPC is not different just because you use different items of hardware. I understand that the VRInsight units send keypresses instead of joystick button presses, so it means that you are assigning in a different FSUIPC options tab, but otherwise the problem is the same -- i.e. does the add-on you are trying to use provide any means for you to control it other than by mouse? I can't answer that question. I don't have any Wilco aircradft, and in general I cannot be expected to have every add-on with which folks might want to use FSUIPC. You may find more help in other threads here -- search on "Wilco" and "Airbus", see what you come up with. But mainly what you need is more information on your Wilco aircraft. It should come with documentation telling you alternative ways of controlling it -- i.e. keyboard shortcuts rather than mouse clicks. Regards Pete
  10. Hmm. That's strange. I'll get a GoFlight unit hooked up here and check it -- I might not be able to get to it till the weekend thoguh. I'll see when I can fit it in. No, provided it isn't a button you reuse. You might want to instigate it by a call in the ipcReady.lua, or you can use the new facilities for Automatically running macros or Lua plugins when aircraft are loaded -- the [Auto ...] feature added recently. I'll get back to you about GoFlight rotaries when I've had a look here. Can you give me the version number of FSUIPC you are using please? Regards Pete
  11. When you use a Lua script you need to understand that each time it is activated, the Lua file is read by the Lua interpreter, compiled into an intermediate language, then interpreted and actioned. ON top of that, so that no Lua program can bring FS to its knees by monopolising the FS process, FSUIPC imposes a small (1 millisecond) delay between each line being executed. Furthermore, if you start a Lua program which is already running, the earlier one is forcibly terminated, so it may not have finished whatever it is doing. Yes, there's nothing changed there except that REPEATED actions (Lua program executions instigated by a button or keypress being held and thus repeated) now simply refuse to start an already-running Lua program, so don't forcibly terminate things. This wouldn't be happening with a rotary -- that looks like a button going on and off repeatedly, not one being held down. Yes, exactly. Why have such a function, which simply equates "buttonpressed" with "ipc.testbutton"? Why not just use the latter directly? Much faster & smaller code. Sorry, I don't understand what you are saying. If the rotary dial "pseudo-buttons" always appear to be "on", they cannot be used at all, even directly in FSUIPC, as they will not be recognised. FSUIPC only sees them when they change from "off" to "on". Maybe you could try using the Button logging in FSUIPC to check what is happening? BTW, how are you starting this program? In the "ipcReady.lua", so it runs from the session start? Regards Pete
  12. You can show/hide it using the FS ATC control (the same as normally mapped to the ' or # key), and you can select items from it by using the other FS ATC controls (ATC menu 0 to 9), but I'm afraid I don't know of any way of reading the text from the menus. Sorry. Regards Pete
  13. Whilst awaiting your reply, I've just tried using this little Lua plug-in: while true do ipc.writeUB(ox310a,8) ipc.sleep(5000) end with the very latest incremental releases of FSUIPC as found in the Updates announcement here. I've found a problem in FSX, but not yours in either FSX or FS9: Assigning in FS: the inhibits work as specified in FS9, but not at all in FSX (i.e. they fail to inhibit! Ouch! Assigning to FS controls in FSUIPC: the inhibits work as specified in FS9, but not at all in FSX (i.e. they fail to inhibit! Ouch! Assigning in FSUIPC direct to FSUIPC calibration: the inhibits work as specified in both FS9 and FSX. So, I've some some investigation to do, but I cannot reproduce your case. I'm guessing that what you have shown me, your code, is an extract and the value of "fcon" is not 8 as you expected, but 9. The use of this: fcon |= 1 << 3; to set a value of 8 suggests as much -- why "OR" the bit in if you expect it to stay zero? Regards Pete
  14. Could you possibly tell me a bit more, like the version of FS and the version of FSUIPC? I can't really do much without such information. Additionally, please enable FSUIPC's IPC write logging, for the duration of your test, and let me see that part of the log. Actually, also monitor 310A in the monitoring section, right-hand side of the Logging tab, and check the "normal log" option. Oh, I could also do with knowing how the controls (throttles, elevator) are assigned and calibrated -- assigned in FS or FSUIPC? Assigned direct to FSUIPC calibration, or via FS controls? Calibrated in FSUIPC? Regards Pete
  15. Can you please find the "Caps Lock" key on your keyboard and press it, so you don't post messages with ALL CAPS? Thank you. If your FSUIPC4 is not registered, it isn't doing anything itself. Nothing much in the FSUIPC INI file is active if you haven't registered, so it is no surprise fiddling with an unknown mystery parameter called "ELEV DISC INSTR" (?) does nothing. If your problem only happens when it is running then something is using it to provide your mystery force. FSUIPC is predominantly an interface for other applications or add-ons to interface to FS. Pete
  16. There should be no trouble getting the parameter simply by reference to ipcPARAM. Does the log show any errors in your program? If not then ipcPARAM is certainly defined okay -- so what value does it have? BTW what version of FS and FSUIPC are you using? If I am to test things myself in answer to such questions I do need to know such things. Regards Pete
  17. Sorry, I just checked. I was mixed up before with the similar code in WideClient and FSUIPC for reading the GoFlight devices. Both of those were updated for the MCPPro, but I've just checked, and you are correct. I never did update GFdisplay. :roll: :x I've made a note to see to that, and will do so as soon as I can get to it -- maybe later this week. Keep an eye out on the Updates announcement (date change in the title) for a newer version. I don't have any way of testing changes to GFdisplay here, so I will have to rely on your feedback. Regards Pete
  18. You are not reading the correct offset, or you have another error, then. Use FSInterrogate to compare what you are reading with the correct value. FSInterrogate can display it in hex, decimal and it will do the computations too. Pete
  19. Hmm. Sorry, no idea what could cause that. I think HiFi simulation did a lot of work on smoothing, but you are using a very old program. All of their improvements went into ASA (Active Sky Advanced). You may want to take a look at that instead. They will no doubt answer your questions on AS 6 or 6.5, but they certainly haven't been developing it for many years. They moved to ASX for FSX then ASA for both FS9 and FSX. That's the one that should eliminate most of the artificial (cardboard cut-out) clouds and those are the ones which pop up and disappear most often. Regards Pete
  20. Ah, you wanted the drift correction. Sorry, I misunderstood. Pete
  21. The changes are listed in the History document. That is why it is supplied. All of the FS weather settings are merely filters for tweaking to user's taste. There's no "best" or "recommended" settings. Use what you like, don't use what you don't like. I don't know of any reason for "conflict", but why not just try Active Sky as it is first, without filtering? It is only supposed to reduce the wind, not remove it, and that's only to help newcomers, unused to flying, or at least FS, more easily overcome FS's tendency to weathervane too much. If you mean clouds, not visibility, then that's mostly a function of FS. You should find it happens much less if you make sure all of the Weather display sliders are full right. They may hit your frame rates a bit though. The 3D cloud slider (I think it's called something like that -- the one on the right), if left set on the left, produces cardboard cutout clouds in a ring around you which pop like crazy sometimes There's nothing FSUIPC or anything esle can do with the weather graphics. I've no idea what a "screen glitch" looks like. Sorry. Regards Pete
  22. Is is not the same language? Surely Microsoft don't redesign the language every three years or so? The C compiler still compiles C, why doesn't the VB compiler compile VB?Pete
  23. Because your line 210 changes offset 66C1 but your conditions are on 66C0. Because the syntax for macros is one used in Macro files, not in button definitions. Make some macros, and you'll get a Macro file. Assign buttons to it and you'll get the macro references in the Button assignments in the FSUIPC INI. Not directly because mouse macro values appear only in Macro files. But you can use the offset conditions in front of any valid Button or Key assignment. Since you can most certainly assign buttons to macros, you can use conditions on them. Regards Pete
  24. The "actual heading", i.e. the way the nose is pointing, is adjusted by using ailerons and rudder, or letting the autopilot follow the bug. The bug is of course adjusted by the heading bug controls. If you mean adjusting the heading in slew mode you need to use the slew controls. There's a pair for each direction / axis. If you want to find controls in FS, just enable FSUIPC event logging, operate the control, and check the log. Pete
  25. Hi Guenter For now I made it "sticky". I have to go out soon. When I get a chance I will read it carefully and make any tiny corrections. ;-) Thanks! Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.