YokeM Posted October 31, 2014 Report Share Posted October 31, 2014 (sorry for the bad english, I´m not a native) Hello Pete, I´m writing a programm which should be able to to handle the contolls and enviromental settings of the cargo A400M from Roland Laborie. FSUIPC is a great interface which makes communication from and to FSX really easy. While I was able to get the enviromental data I was looking for out of FSX, starting the engines is another matter. I can pull the parking brake, but while attemting to set the Engine lever to RUN I came into the problem of simply not finding the right offset or maybe I´m putting the wrong variable into the right offset. As of now I can imagin that I´m doing something wrong somewhere. Whats the right offset for this lever and what variables have to be put into it? regards YokeM Link to comment Share on other sites More sharing options...
Pete Dowson Posted October 31, 2014 Report Share Posted October 31, 2014 While I was able to get the enviromental data I was looking for out of FSX, starting the engines is another matter. I can pull the parking brake, but while attemting to set the Engine lever to RUN I came into the problem of simply not finding the right offset or maybe I´m putting the wrong variable into the right offset. I'm afraid I cannot advise about things like that for an add-on aircraft. I don't even know whether an "A400M" is a jet, prop, or what -- the starting procedure is different even for each default aircraft type, and can be even more different for an add-on aircraft. First, you need to know how to start the engines with the usual methods -- keyboard and/or mouse. Perhaps you do, and if so, describe it here? You could also use the FSUIPC logging facilities, especially "event" logging, to see what might be going on internally. But be aware that add-on aircraft may not use FS events and may not be susceptible to the documented FSUIPC offsets. Pete Link to comment Share on other sites More sharing options...
YokeM Posted November 3, 2014 Author Report Share Posted November 3, 2014 Hey Pete, thanks for your answer :-) I almost assumed that duo to the "A400M" beeing a add-on aircraft it will be harder to get an interface for it but I still hope it can be addressed through FSUIPC-routines. I know the starting sequence it is as follows for automatic engines startup: 1 - Parking brake on.2 - Throttle levers 1-2-3-4 Mini. // I´m ingoring this in the logging process. It is for safety reasons and of no real effect on the overall process.3 - APU START on.4 - APU MASTER SW. on.5 - Rotary button ignition.6 - Engine 1 lever RUN , wait for the stabilization of engine before the starting of engine 2.7 - Engine 2 lever RUN , wait for the stabilization of engine before the starting of engine 3.8 - Engine 3 lever RUN , wait for the stabilization of engine before the starting of engine 4.9 - Engine 4 lever RUN . [Continuation log requested by user]Running inside Prepar3D v2 on Windows 7Module base=561B0000 415103 LogOptions changed, now 20000000 00000001 // This a loop that happens every second 415119 *** EVENT: Cntrl= 65794 (0x00010102), Param= 0 (0x00000000) PAUSE_ON 415571 *** EVENT: Cntrl= 65962 (0x000101aa), Param= 4 (0x00000004) FUEL_SELECTOR_SET 415571 *** EVENT: Cntrl= 66576 (0x00010410), Param= 5 (0x00000005) FUEL_SELECTOR_4_SET 415571 *** EVENT: Cntrl= 66523 (0x000103db), Param= 2 (0x00000002) FUEL_SELECTOR_2_SET 415571 *** EVENT: Cntrl= 66568 (0x00010408), Param= 3 (0x00000003) FUEL_SELECTOR_3_SET 415571 *** EVENT: Cntrl= 66886 (0x00010546), Param= 0 (0x00000000) BLEED_AIR_SOURCE_CONTROL_SET // loop end 418176 *** EVENT: Cntrl= 65561 (0x00010019), Param= 0 (0x00000000) PAUSE_TOGGLE 419767 *** EVENT: Cntrl= 65752 (0x000100d8), Param= 0 (0x00000000) PARKING_BRAKES // Step 1 427801 *** EVENT: Cntrl= 66704 (0x00010490), Param= 0 (0x00000000) APU_STARTER // Step 3 431623 *** EVENT: Cntrl= 66706 (0x00010492), Param= 1 (0x00000001) APU_GENERATOR_SWITCH_TOGGLE // Step 4 // Here should stand an ingnition starter event as described in step 5. The eventlog didn´t show anything like that. Without it the engines won´t start. // Step 6 - 9 435570 *** EVENT: Cntrl= 66300 (0x000102fc), Param= 1 (0x00000001) TOGGLE_STARTER1 438566 *** EVENT: Cntrl= 66301 (0x000102fd), Param= 1 (0x00000001) TOGGLE_STARTER2 439580 *** EVENT: Cntrl= 66302 (0x000102fe), Param= 1 (0x00000001) TOGGLE_STARTER3 441592 *** EVENT: Cntrl= 66494 (0x000103be), Param= 1 (0x00000001) TOGGLE_FUEL_VALVE_ENG1 441592 *** EVENT: Cntrl= 66303 (0x000102ff), Param= 1 (0x00000001) TOGGLE_STARTER4 444587 *** EVENT: Cntrl= 66495 (0x000103bf), Param= 1 (0x00000001) TOGGLE_FUEL_VALVE_ENG2 445617 *** EVENT: Cntrl= 66496 (0x000103c0), Param= 1 (0x00000001) TOGGLE_FUEL_VALVE_ENG3 447629 *** EVENT: Cntrl= 66497 (0x000103c1), Param= 1 (0x00000001) TOGGLE_FUEL_VALVE_ENG4 455429 *** EVENT: Cntrl= 65561 (0x00010019), Param= 0 (0x00000000) PAUSE_TOGGLE Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 3, 2014 Report Share Posted November 3, 2014 I almost assumed that duo to the "A400M" beeing a add-on aircraft it will be harder to get an interface for it but I still hope it can be addressed through FSUIPC-routines. Maybe, maybe not. At least it looks like you have most of the controls you need there then. The loop which happens every second is probably just to make sure certain things are set certain ways, and will be automnomous in any case so you can ignore that. A lot of these add-ons seems to waste a lot of processing that way when they only need to check if it has changed first. On the part where you say // Here should stand an ingnition starter event as described in step 5. The eventlog didn´t show anything like that. Without it the engines won´t start. That looks like something internal to their code. I can only suggest you investigate the possibility of use local panel variables, or mouse macros. One or the other might just possibly be useful (not both). If neither then I'm afraid I've no idea. Are you getting any help from the add-=on makers? They'd really know all this better than someone like myself who knows little about any add-on aircraft. All i can do is point to the tools available. Pete Link to comment Share on other sites More sharing options...
YokeM Posted November 3, 2014 Author Report Share Posted November 3, 2014 (edited) Maybe, maybe not. At least it looks like you have most of the controls you need there then. The loop which happens every second is probably just to make sure certain things are set certain ways, and will be automnomous in any case so you can ignore that. A lot of these add-ons seems to waste a lot of processing that way when they only need to check if it has changed first. Ok thank you. If I understood correctly, every event that can be displayed by the FSUIPC-logger can be addressed be an FSUIPC-offset and I just have to find the right one? Or do I have to use SimConnect to address them? That looks like something internal to their code. I can only suggest you investigate the possibility of use local panel variables, or mouse macros. One or the other might just possibly be useful (not both). If neither then I'm afraid I've no idea. Are you getting any help from the add-=on makers? They'd really know all this better than someone like myself who knows little about any add-on aircraft. All i can do is point to the tools available. Pete Thank you. Using macros would have been the way to go if I couldn´t adress some of the panels via FSUIPC or SimConnect. If they aren´t shown in the event-logger, does that mean that SimConnect can´t address them too? I didn´t want to use SimConnect since your tool (which uses SimConnect I imagin) made my life really easy in regards of interfacing. I´m not getting any help from the add-on makers right now, but it´s a good idea to ask them. Edited November 3, 2014 by YokeM Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 3, 2014 Report Share Posted November 3, 2014 Ok thank you. If I understood correctly, every event that can be displayed by the FSUIPC-logger can be addressed be an FSUIPC-offset and I just have to find the right one? Or do I have to use SimConnect to address them? You are misunderstanding. Offsets hold data, sometimes input data sometimes output data. They are no "events". Events are actions, and initiated by controls with a control number and a parameter. Controls are assigned. You CAN send controls via offsets -- see offset 3110. The names and control numbers you saw in the log relate to the controls/events you need to use. FSUIPC sends some controls via SmConnect, and some directly to FS's wnindow. It varies according to function. Using macros would have been the way to go if I couldn´t adress some of the panels via FSUIPC or SimConnect. If they aren´t shown in the event-logger, does that mean that SimConnect can´t address them too? It varies enormously. Add-on writers implement things which aren't, in their opinion, simulated properly or at all in FS. For those aspects, SimConnect doesn't help because it is just an interface into the simulator which they are programming around because of those shortfalls. Do you see? Maybe, underneath, the add-on code does use built-in FS actions, but being effectively made part of FS (loaded as one of its gauges, for example) it doesn't need always to use controls as such. Mouse macros in FSUIPC only operate on Gauges which are written in C/C++ to strict rules laid down in one of Microsoft's SDKs. Even most of FS's default aircraft don't supportthem. More and more aircraft these days use Local Variables instead. This is especially true of XML gauges. Pete Link to comment Share on other sites More sharing options...
YokeM Posted January 19, 2015 Author Report Share Posted January 19, 2015 Hello Pete, sorry for my late reply. Work hit hard before christmas and now for the first time in a while, I´m able to give this little project of mine some time. As far as I can see, the creator of the simualtion model has used xml-gauges. They are inside the model-folder, but packed inside a rar file. I don´t know if P3D uses this packed files or gets them from somewhere else. Is there any way to see how this gauges are changed during the simulation or change them without clicking manualy on a panel in P3D? Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 19, 2015 Report Share Posted January 19, 2015 Hello Pete, sorry for my late reply. Work hit hard before christmas and now for the first time in a while, I´m able to give this little project of mine some time. As far as I can see, the creator of the simualtion model has used xml-gauges. They are inside the model-folder, but packed inside a rar file. I don´t know if P3D uses this packed files or gets them from somewhere else. Is there any way to see how this gauges are changed during the simulation or change them without clicking manualy on a panel in P3D? Just log the L:Vars (local panel variables) to see if you can find one you can use. You can list them using the add-on FSUIPC contorl provided, or you can use the supplied Lua plug-in for logging them live as they change, on screen. Pete Link to comment Share on other sites More sharing options...
YokeM Posted January 20, 2015 Author Report Share Posted January 20, 2015 Thanks Pete, I can log them now. I tried to change them via my programm, using the offset 3110 but the change didn´t happen in P3D. Is there another way to change these or did I do something wrong? Here is what I did: FsuipcProxy* fsuipcProxy = new FsuipcProxy; int n = 65923, p = -16383; if (!FSUIPC_Write(0x3110, 8, &n, &fsuipcProxy->dwResult)) { cout << "Fehler" << endl; } if (!FSUIPC_Write(0x3110, 8, &p, &fsuipcProxy->dwResult)) { cout << "Fehler" << endl; } FSUIPC_Process(&fsuipcProxy->dwResult); Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 20, 2015 Report Share Posted January 20, 2015 Thanks Pete, I can log them now. I tried to change them via my programm, using the offset 3110 but the change didn´t happen in P3D. Is there another way to change these or did I do something wrong? Offset 3110 is for sending controls -- ones having a number and a parameter. "L:Vars" have names. You can only send them either by using Macros, or by Lua plug-ins. There's no place in the control number system for names. You seem to have changed the subject completely since your last message I replied to, above! You code seems to be trying to send control 65923, which is the axis control "Prop pitch1 Set". Not sure why you'd send that. It needs a parameter to tell the prop #1 what pitch value to set. You appear to be addressing variable n, a 32-bit (== 4 byte) value as an 8 byte value. What do you think that will do? If you are trying to send the control and the parameter in one Write, you need a structure. If you don't understand structures just set the parameter first (3114) then the control. Pete Link to comment Share on other sites More sharing options...
YokeM Posted January 20, 2015 Author Report Share Posted January 20, 2015 The fact, that I didn´t even formulate my question understandable is a good indicator to how little I know about your software and P3D. Sorry about that, I will take some more time to learn more about both. I´m trying to operate the controls in the A400M-model without having to klick on them inside of P3D. e.g.: If I click on a button in my software, the parking brake in the simulation should be put to "ON". Or the "Prop pitch 1" should be set to the given parameter.. Etc, etc.... In "offset status" is written: 3110: Operates a facility to send any ‘controls’ to Flight simulator.This works with all versions of FS & CFS. Write all 8 bytes forcontrols which use a value (axes and all _SET controls), but just4 will do for ‘button’ types.This is really two 32-bit integers. The first contains the Controlnumber (normally 65536 upwards), as seen in my FS Controlslists. The second integer is used for the parameter, such as thescaled axis value, where this is appropriate. Always write all 8bytes in one IPC block if a parameter is used, as FSUIPC willfire the control when you write to 3110.Since version 3.40, FSUIPC-added controls (other than the offsetones) can be used via these offsets too. See the Advanced User’sGuide for a current list. So I thought I have to send a 8 byte control, even if I only use a 4 Byte integer as value. Here I´m tying to set the "Prop pitch 1" which I adressed in "n" to the parameter given in "p". This should put them into "Mini" or "RUN" (16383). It seems that I don´t understand structures enough to use them in here. Also what do you mean I should the parameter first? I Thought you need to have the control first, then the parameter. What do you mean with "3114"? If thats an offset, I can´t find it. Can you give me an example to how you would set "Prop pitch 1" to the value of 16383? Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 20, 2015 Report Share Posted January 20, 2015 I´m trying to operate the controls in the A400M-model without having to klick on them inside of P3D. e.g.: If I click on a button in my software, the parking brake in the simulation should be put to "ON". Or the "Prop pitch 1" should be set to the given parameter.. Etc, etc.... Yes, I understood that from way back. But you said this: Using macros would have been the way to go if I couldn´t adress some of the panels via FSUIPC or SimConnect. If they aren´t shown in the event-logger, does that mean that SimConnect can´t address them too? From this I understood you to mean that you had tried using the normal controls and that, because this aircraft "does its own thing", you couldn't operate everything you needed that way, and were about to resort to mouse macros. I then replied saying mouse macros may not work with many aircraft and explained why. You said that the gauges were written in XML which confirmed that mouse macros would not work, so I suggested that local panel variables might (L:Vars), and that if you logged these you might find ones which would do what you wanted. If I click on a button in my software, the parking brake in the simulation should be put to "ON". Or the "Prop pitch 1" should be set to the given parameter.. Etc, etc.... And are those examples of where your aircraft does not obey the normal FS controls? It would be very unusual. Even the more sophisticated aircraft normally use the standard Parking Brake and Prop Pitch controls! In "offset status" is written: Why on Earth include my own documentation in your message? !!!! So I thought I have to send a 8 byte control, even if I only use a 4 Byte integer as value. Yes. You can send 8 bytes, but your "&n" is the address of a 4-byte value!!! Sorry, but if you are programming you need to learn programming. To send 8 bytes containing 2 4-byte values you'd need a structure or an array, for example: int n[2]; n[0] = 65923; n[1] = -16384; FSUIPC_Write(0x3110, 8, &n[0], &fsuipcProxy->dwResult); or, using structures: struct { int control; int parameter; } n; n.control = 65923; n.parameter = -16384; FSUIPC_Write(0x3110, 8, &n, &fsuipcProxy->dwResult); However all of this pre-supposes that your aircraft does, after all, obey normal FS controls, so how did the subject get onto other things like macros? BTW I'm not a good teacher (not enough patience nor time), so won't be trying to tech you programming any further than this! ;-) An easy alternative, if you don't understand arrays or structures, would be to set the parameter in one Write and the control in the next write, then do the Process call. In any case, FSUIPC doesn't do anything when you write the parameter, only when you write the control. Pete Link to comment Share on other sites More sharing options...
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