bcs112

Hi, I've programmed my own N1 mode for my panel, directly controlling the throttle input. As long as the aircraft is on the ground though I want the pilot to still be able to cancel the take-off by moving the throttle input on the joystick to < 50% input. The problem is that if I don't disable (through FSUIPC) the joystick throttle axis, it will constantly interphere with the throttle inputs I give in code. If I do disable the axis, then I can not detect if the user has moved the throttle axis to < 50%. So is there an FSUIPC offset that allows me to read the joystick axis input even though I have disabled the throttle axis ? Thanks, Björn

Hi guys, In FSX (and I believe this is not as it used to be in previous versions of FS ?) when you switch off the engines the GENERAL_PANEL_CIRCUIT_ON variable goes to 0. Which is very unfortunate. So I was wondering if there is any way to control this variable through and FSX event or via FSUIPC ? The only way I have found to control this variable is by using keyboard commands but that's really not what I want. Thx, Björn

Thanks Pete, updating to the latest version did the job ! Björn

Hi Pete, ==> Hope you had a great time ! ==> Yeah, when you use the FS autothrottle it is done by itself. but the FSX autothrottle is so extremely sluggish that I had to reprogram it myself. This means I loose the built-in system off course. ==> FS updates every gauge approximately 18 times per second, this is called a "tick". ==> No I'm not, I want the panel to work for the standard user, "out of the box". Off course they need to have FSUIPC installed but that's basically all... I'll take a look at SimConnect again but I don't think there any features about disabling the joystick axes there... Thanks for the help ! Björn

Hi Pete, The question says it all really. I'm trying to programmatically disable the throttle axis in FSX whilst the A/P of my aircraft is taking control over the throttles. For that I send "8" to offset 310A every few ticks. But this doesn't seem to have any effect. Am I missing something here ? I'm using the Saitek X52 joystick, not sure if that may have naything to do with it though ? Any ideas? Thanks, Björn

Thx Pete, Need to think about an efficiant way to do something with the available data, I'm sure I wil find something in the end ;) Björn

Pete, I am planning on building a stormscope. For that I need to be able to detect and locate lightning strikes. From what I have read on this forum this not possible with FSUIPC, but is it possible to detect CB's ? If I could detect CB's however I could expect that there is some lightning activity going in inside this cloud and thus "guess" where the electrical discharges should be. So here's the question, can I detect and locate CD's using FSUIPC ? Thanks for the help, Björn

Thx Doug and Pete, like I said.... stupid question I only increased the size of the FsuipcMem BYTE array and forget to do the same with the buffer. I have also decreased the update frequency to approx 5 times per second, maybe I'll reduce even further, I'll see how it works out. Got it working now ! Björn

Hi Pete, Hope my question isn't to stupid but I've been trying to read the TCAS data and always come up with... nothing. This simple code counts to number of traffic found in the air (tested in FS2002). //variables TCAS_DATA TCAS_ARR[96] ; DWORD tid ; DWORD dwResult; BYTE FsuipcMem[4096]; //In connect to window FSUIPC_Open2(SIM_ANY, &dwResult, &FsuipcMem[0], 3008); FSUIPC_Process(&dwResult); FSUIPC_CONNECTION = dwResult ; //if connected, perfomed in PRE_UPDATE section FSUIPC_Read(0xF080, sizeof(TCAS_ARR), &TCAS_ARR, &dwResult); FSUIPC_Process(&dwResult) ; for (i=0; i < 96; i++) { tid = TCAS_ARR.id ; if (tid != 0 ){ counter++ ; } } => the counter always stays 0 so I presume no data is read. Any idea what's wrong here ? Thx for the help, Björn

Hi Trev, Well I'm not the inventor of the code, I simply edited and optimised it, so I'm not sure if I can share it. It's all pretty basic though, I use offsets 0B7C, 0B94 and 0B74 to get current fuel level and then reduce the level (first Read then Write the level - a number) every 9 ticks or so. In my aircraft (A300) only the center and main left and right tanks can jetisson fuel so the other tanks are not affected. That's it ! The only extra check I do is to make sure the fuel level doesn't go below 0 because then all hell brakes loose and your aircraft starts doing some really strange stuff. Incidentally you can also use these offsets (together with the offsets showing tank capacity) to upload fuel. Kind regards, Björn

Pete, The logging tip was the golden tip ! I found that no writing takes place only reading. I was finally able to track down the reason for this: I declared the broadcast dump var's twice as broadcast variables (in two different gauges), very stupid mistake, I know ! This caused the unpredictable results ! Thx for the help ! Björn

Pete, Will do the logging thing first thing tonight ! I'm also kinda unclear on the exact meaning of the "_process" function is. Should it be called after every read/write or after a sequence of read/writes. Or can I send a number of read/write fuctions and call "_process" in the end and then all the requests wil be processed at the same time ? Björn

Hi Pete and the rest, Let me start by saying that I am a simple amateur programmer who has spend most of his programming life working with VB and VBA to my own satisfaction. I only recently dared taking the step to Delphi and C because once you get into graphics stuff VB simply is too slow (and yes I bought the books...) So after apologizing for my shortcommings :wink: here's my question. I am working on a gauge which enables my aircraft to dump fuel. I prepared the code and after re-evaluating my connection procedure (checking dwResult every cycle to see if it's connected and if not trying to reconnect) I'm pretty sure my gauge is connected to FSUIPC (side Question: can you actually loose the connection after it's been established ?)... but now here's my problem. When I start the panel and I try to start dumping fuel, nothing happens ! But... and here's the strange part, if I open the Fuel dialog in FS2002 (via the menu options) and close that again, fuel dumping works fine ! And it keeps working fine until I restart FS. Does this ring any bells ? I don't have the actual code with me here, but I can post it tonight if necessary. Thx for the help, Björn

Hi all, If I understand the question correctly then the solution to your problem is real easyVB comes with a control specifically designed for this stuff. It is called MSComm32.ocx and uses a number of very basic properties and methods to read and write data to the COM ports. I've used it many times for all kinds of applications and it's really easy to use ! Look in the Components list and you'll find it there. Kind regards, Björn

Hi Mr King :wink: The problem with placing a program on top of FS is off course that FS will run in the background, all sound will disappear, image quality goes down considerably etc... so I'm afraid this is not an option. Would be interesting if FS dedicated an SDK to this "problem" so us simple people could use the modules option. Kind regards, Björn

Well I was just going to ask the same question ! Peter, can you use VB6 DLL as an FS module ? Or is it the same problem as with writing guages, that you have to do this in C++ ? I have worked out a preliminary version of a LTN072 INS in VB which is going to work through FSUIPC, it would however be great if I could use the same program as a DLL in FS thus allowing people who don't have a network at home (yes they do exist :? ) to use this INS in all their panels. I know how to write my basic FS gauge, but writing an INS is a little more complicated ! Can you "simply" create an FS gauge, change the extension to DLL and place it in the modules folder ? Thanks for the help ! Björn