spokes2112 Posted November 1, 2017 Report Posted November 1, 2017 Hi Pete, Been putzing around with a little trick found on FSDeveloper regarding corrected fuel flow & keeping turboprops running away during start and other conditions. It uses (>C:SIMVARS:TURB ENG CORRECTED FF:1, pounds per hour) through the XMLTools.dll interface. It works well but needs gauge coding per aircraft. I was trying to get this to work using lua by writing to 0x2020 (& the 3 others) so it could work globally on all turboprops. The feedback is --- doesn't work. Quote ?-SimC Mapped to SimConnect variables, but validity unknown. Needs checking and feedback please. The following code was inside of a while - do loop which does work perfectly but there was no return as wanted via logging. ipc.writeDBL(0x2020, 200) Tested some others too w/ ?-SimC in the write column - no go. I guess "it is what it is", just feedback is all. I know you're busy with all the P3Dv4 stuff, but if you ever get around to looking into it, getting the "Turbine Engine # corrected fuel flow" & "Reciprocating engine # starter torque" (another trick) working, both ?-SimC for writes, would be "the cat's meow" ;-) FSX Acceleration / FSUIPC v4.971b Regards, Roman
Pete Dowson Posted November 2, 2017 Report Posted November 2, 2017 14 hours ago, spokes2112 said: I was inside of a while - do loop which does work perfectly but there was no return as wanted via logging. ipc.writeDBL(0x2020, 200) Sorry, what were you logging and expecting to see? According to the notes on this variable in my code, it accepted writes to it without error. And this is confirmed in the Simconnect reference, here: TURB ENG CORRECTED FF:index Corrected fuel flow Pounds per hour Y - That is the variable represented in offset 2020, with index set to 1. The 'Y' in the 4th column means "Settable" according to the column heading, so it should be working. I really can't do any more than use the facilities available and assume they work as documented. Maybe the rest of the simulating engine is working so much faster and so overwriting it. How frequently was the "(>C:SIMVARS:TURB ENG CORRECTED FF:1, pounds per hour) through the XMLTools.dll interface" action being performed? BTW I'm interested in that "C:SIMVARS:" way of accessing SimVars. Do you have the XML source for that? I'd like to know how it interfaces to P3D. It might be something I could add to FSUIPC5 in the future. Pete
spokes2112 Posted November 2, 2017 Author Report Posted November 2, 2017 Hi Pete, Went through the tests again. It seems that the write within the original while-do wasn't fast enough, too many other things going on. Tried a while-do in it's own thread and the result is that the write occurs - sorry 'bout that.. But, the updates are factors slower than XMLTools. while 1 do ipc.writeDBL(0x2020, 123) end Quote Maybe the rest of the simulating engine is working so much faster and so overwriting it. Yes that is exactly what's happening. XMLTools seems to have a fast enough update to make it usable. 5 hours ago, Pete Dowson said: BTW I'm interested in that "C:SIMVARS:" way of accessing SimVars. Do you have the XML source for that? I'd like to know how it interfaces to P3D. It might be something I could add to FSUIPC5 in the future Tom Taguilo's .dlls are here - http://www.fsdeveloper.com/forum/search/13164829/?q=XMLTools&t=resource_update&o=date The P3Dv4 package does not include documentation, refer to the P3Dv3 package for the docs. The XML interface to his .dll is there, also included are some other things that are way over my pay grade ;-), specifically "XMLTools.h" & "XMLTools Class for C++ projects.pdf". Maybe that will help. Roman
Pete Dowson Posted November 6, 2017 Report Posted November 6, 2017 On 11/2/2017 at 4:01 PM, spokes2112 said: Tried a while-do in it's own thread and the result is that the write occurs - sorry 'bout that.. But, the updates are factors slower than XMLTools. FSUIPC does not run Lua plug-ins at the sort of speed a dedicated separate program, DLL or FSUIPC application will tun. This is deliberate because the plug-ins are running in-process, and there can be very many of them. They are excellent for prototyping a design before code is written, and doing things like updating dispays, and I have supplied demos even synchronizing two copies of FS across a Network. but really they are unsuitable for fine control and will never manage speeds much higher than the FS frame rate. many internal processes in FS operate at higher rates. When FSUIPC used to do direct wind control (at the aircraft) it did this by hooking directly into the FS code, it didn't use SimConnect. Thanks for the info relating to C:SIMVARS. I may look at that when I get some time. Pete
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now