pilotjohn

How are folks handling launching the sim into a state that does not agree with current control settings? Large, full-motion flight sims will pause the sim until you put all switches etc. into the right state for the loaded scenario. Are there any plans for such functionality, or is this up to us to implement (through some Lua for example)? I'm building a rig (in preparation for MSFS2020), with a custom panel that I expect to have lots on "ON/OFF" style toggles. This means that the toggle state may not be in the position that the simulator is in when loaded (e.g. battery toggle is on, but should be off). In large flight sims this is handled by a pause and prompt to get the controls into the right state. Otherwise, if for example, you're starting some in-flight challenge, and everything is off, you'll be in for a surprise.

I have published my complete set of Lua scripts for FSX/P3D on GitHub. They are available here: https://github.com/techiejohn/SimTools FlightCritic: judges how you fly (the early proof-of-concept code that evolved into REX Latitude) RandomWeather: generate random realistic weather scenarios and share them with others GoFlight: tools to use GoFlight RP48 panels for all sorts of things like AP, radios, engine starts etc. Saitek: scripts to improve Satek panel functions running through SPAD (for JS41 for example) Miscellaneous: many other scripts for some of which you'll find posts around these forums Enjoy, and feel free to evolve as you see fit.

There isn't. I disconnect throttles and resend based on the "state" (forward/reverse).

I went to global [Auto] route and my "default" Lua was testing wether to include the others, but I'll check out the profiles.

Pete, I have several GF devices for which I developed logic to control "generic" aircraft. This is loaded in the [Auto] section. It's made to be extensible (e.g. override functions) so for specific aircraft (DukeT, JS41, ERJ) I develop a new Lua that "requires" the base logic, and simply overrides some functions as needed (for example a ToggleIgnition function for a DukeT). The problem I'm running into is that the "default" logic is loaded for all planes, AND the specific is loaded for the custom aircraft. That is, they are BOTH loaded. Is there a way to auto-load a Lua when something doesn't match rather than match? Or, is there a way to kill the "default" Lua loaded in the [Auto] section, from within a Lua loaded from within an [Auto.XXX] section? Or, is there some other logic/mechanism that can accomplish this? Thanks, John

This update adds a delay to reverse toggle to avoid accidental triggering. The trigger button has to be pushed (in-range) for 1 second by default (configurable) in order for the toggle to occur. WARNING: This version requires the Lua socket libraries (used for timing): http://luaforge.net/...ects/luasocket/ and now requires both press and release triggers. ThrottleManager.txt

Sweet! I'll post an update... some of the Saitek throttles are noisy, and would trigger reverse prematurely when pulled to idle quickly. I made an update that allows the reverse to be triggered after a delay. This may help you as well in case you move into the reverse range accidentally.

You may be able to run a Lua to toggle the flag (that's what toggle does) using ipc.toggleflag. I don't remember if flag are local to Luas, I think they are, so you may have to add some code to the manager that check the PARAM given in runlua and then just toggles that flag.

Hmm... You can't really "run" ThrottleManager since it's running as an event listener all the time. It really would need to be completely modified. I can't think of quick way of doing it, since that concept is already used for the "auto" toggle to forward, so it would need to be a high/low water mark logic. If you're willing to give up part of the throttle range for reverse why not just make that real reverse?

I've not seen this behavior. The only odd thing I've seen is that the heading bug continually syncs to your current heading as your manuever. It sounds like it might be related to that, but I haven't been able to pinpoint what causes the behavior. This is really a band-aid for something that PMDG should have fixed (and clearly could have if a script can), but there's no chance of that. It relies on so many kludges that I'm surprised it works as well as it does. If you follow the steps in the first few posts it should just works. Google SPAD FSX, and install it, while uninstalling (or at least disabling the Saitek clients in exe.xml).

I'm confirming that I have the same problem after upgrading from 4.843 to 4.85. No [Auto] scripts are loaded during the first flight. However, upon switching planes, all [Auto] scripts are loaded. So it appears there's some logic bug that ignores or skips to the "first flight of the day".

I am doing this, FSX doesn't return all the airports it's supposed, and you don't know what airport someone may have installed. If you want to correctly match with what FSX is reporting, you can't use an offloaded list of airports without requiring users to sync every time they install new scenery especially things like Misty Mooring.

This seems like a fun project, but doesn't this remove all the fun out of the "flying". I guess it just shifts the fun from flying to developing. All you need now is an auto-takeoff and auto-land feature, and maybe a terrain following option. :)

No problem... just a quick questions about it. Is it a pure SimConnect fix with documented APIs, or does it include undocumented calls and/or FSX internal poking?

I noticed this in the latest module change documentation: The nearest six airports offsets (0658 ff) are now populated reliably with FSX. (Tested only in FSX+Acceleration in version 4.755: reports awaited for SP2). Currently this improvement does not apply to FSX RTM or SP1, nor ESP or P3D. Would you be willing to share how the fix was implemented? I'm playing with some SimConnect code, and seem to have the same issue: I SubscribeToFacilities then re-request with RequestFacilitiesList when a subscribe event is received to figure out what might have been deleted, but the airport at which I'm actually sitting is sometimes not in the list.

Update ThrottleManager attached (1.1.3) that includes sections for throttles 3 and 4. ThrottleManager.txt

The clips tie together physical throttle 1 and 2, but it's still 2 axes correct? if so then yes. Each axes is assigned to a throttle 1, 2, 3, 4 (although 1,2 and 3,4 move together because of the clip) so you still assign 4 axes as per the instructions. You just need to copy the engine sections, and change a few parameters so they affect engine 3 and 4. I'll attach an updated ThrottleManager that has sections for engines 3,4 as well. I'm not sure why you would want 1 axes to control 2 throttles, when you have two axes for it (just physically tied). You can select a second throttle in the FSUIPC Axis tab. However, to the toggle to reverse both throttles with 1 button is tricky and cannot be done in the GUI. You would have to edit FSUIPC.ini and copy the specific button line (duplicate) and change param 1 to 2 (which would cause the button click to affect 2 throttles).

I don't know... I haven't tried it.

It should not (but pick either ANSI or UTF8)... if after you place it into the Modules folder, run FSX, start a flight, exit FSX, it's not in FSUIPC.INI then for some reason FSUIPC is not seeing it. As a simple test, create a blank text file and save it in Modules called "test.lua" to see if that shows up in the LuaFiles section of the INI. The other thing you can do is duplicate one of the existing .lua file (in case it's an extensions issue) rename it to ThrottleManager.lua, edit with Notepad, and paste the contents of the attached text file into it. This is just in case there is some issue with extensions.

It should be in [Auto] that you create but FSUIPC would also add it to the [LuaFiles] section if it sees it in the directory. If it didn't update the INI with it, adding it to [Auto] won't do anything. You may want to post to the general forum to see if Pete can offer any ideas or ways to debug why it may not be seen. If its named .lua and it's in the same directory that ipcReady.lua is in (i see that in your INI) it should be visible and loading.

No, it's pre configured for the first two engines. If its not showing up in the section of the INI I mentined above tthen it's not in the Modules directory or it's not named .lua. You are not hiding extensions of known files are you, which could cause it to be named .lua.txt when you try to rename it?

In the FSUIPC GUI in FSX enable Lua logging which will create a separate log file for every Lua script. If it then doesn't create one for ThrottleManager (ThrottleManager.log) it didn't start it the script.. ThrottleManager.lua is in you FSX/Modules directory correct (and it is .lua not .lua.txt or .txt)? If ThrottleManager.lua were in there, this section: [LuaFiles] 1=ipcReady 2=linda would list it. That section gets updated with any new Lua scripts placed in Modules, so at least you can check whether FSUIPC sees ThrottleManager. That tells me it's likely that the extension is not correct.

You should turn on Lua logging in FSUIPC (GUI). That will tell you whether the ThrottleManager script is actually loaded and it should log changes in throttle behavior.

Yes, it has to be named .lua, not .lua.txt. You can right-click on it and rename. And in FSUIPC it should be: [auto] 1=Lua ThrottleManager You show "LuaToggle" which is for the Button+Switches assignment. And, yes, N is the engine number (e.g. 1 or 2) Everything after step 1, you do in FSX after a flight is loaded, since all the steps there are based on the FSX and FSUIPC GUIs. FSUIPC is accessed via Add-Ons->FSUIPC menu item. And just for the record, you do need a registered version of FSUIPC.

Correct... and place ThrottleManager and sounds in FSX\Modules. Then if FSUIPC is running you should have an Add-ons->FSUIPC menu entry and set everything else up there.