PhilippM
-
Posts
23 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by PhilippM
-
-
Good evening,
I'm trying to figure out how to read the deflection of various control surfaces from FS.
For the ailerons, offset 2ea8 (Aileron deflection, in radians, as a double (FLOAT64). Right turn positive, left turn negative.) seems to be appropriate. However, most modern aircraft have differential ailerons, where the upward deflection is larger than the downward deflection. That means, left and right aileron have different deflection angles, not only in sign, but in magnitude.
How can I read the deflection for left and right ailerons separately?
Regards,
Philipp
-
-
Hi folks,
today I wrapped myself around a really daunting task: Porting my C++ project on Windows from MinGW to Visual C++ Express 2010.
During this, I encountered the problem that the FSUIPC_User.lib that is shipped with the SDK causes a linker error, because it relies on libc.lib being linked as importlib. Unfortunately, libc.lib is not any longer part of Visual C++ since version 2008.
The problem has been discussed without a solution here.
Well, the solution is actually easy: You have to recompile the FSUIPC_User.lib itself using MSVC 2010. This can be done by creating a library project and importing the two files IPCUser.h and IPCUser.c out of the Lib_source.zip in the UIPC_SDK_C.zip. Then you build it, and use this library as a replacement for the FSUIPC_User.lib out of the UIPC_SDK_C.zip
Then building with MSVC 2010 works flawlessly.
If it's okay with Pete, I can also upload the VC2010-build FSUIPC_User.lib here.
Regards,
Philipp
-
'kay, thanks. :)
Subject to further investigation, then.
-
Hi Pete,
I have a question regarding those two offsets.
What is the relation between the "turn coordinator ball position" and the "side-slip angle". Theoretically, it is up to the gauge designer on how much sideslip means full scale on the gauge. One could vary the curvature of the glass tube to vary this relation. But I don't believe this is modelled in FS, so in some way there is an aircraft-independant correlation of 0x036e and 0x2ed8.
Unfortunately, getting enough samples (by carefully trimming an aircraft in various amounts of sideslip) and plotting them is hard, especially if the correlation is a sine or tangent, which seems most natural to me.
So, can you tell me the exact correlation in FS?
Regards,
Philipp
-
Whew, you should be nominated for the "fastest support ever"-award. :)
-
To tell this long story short, he found the option using my instruction. But he complained that the instruction was too short :)
-
Ahhhh... I got the error.
I didn't remeber the "contiguous memory" thing correctly. I had to look it up in my copy of "Effective STL". std::vector is guaranteed to be stored in contiguous memory, std::string is not. So the trick is to read the bytes into a std::vector and then construct the string from the iterators. What I was seeing was the result of undefined behaviour: std::string reserved a 256 character string made of whitespaces and then some of the bytes got overwritten by this call. Nevertheless, the string was 256 characters long from the C++ standpoint.
Sorry for the hickup. I always stumble over those easy things at the border line between C and C++, because these languages ARE different.
Thank you for the fast answer, good nite :)
Philipp
-
I just use the standard "strlen" function, which does a compact loop looking for the first zero byte (which is how ASCIIZ strings are terminated by definition).
Hmm, apparently either me or my compiler misinterprets what "contiguous memory" means, cause this is what the string is guaranteed to be stored in, according to the C++03 Standard. I tried a strlen on title.c_str() and got 256. Hmm.
Given the fact that substantially more people work on my compiler, I think the mistake is on my side :(
Really? What you call "white space" should be zeroes, which are NULLs in ASCII. Although there is no guarantee that there will be any more than one byte of zero, to terminate the string. The rest might be rubbish from a previous longer name.Sounds reasonable, but apparantly I'm not getting this 0x0-character.
Sorry, I don't know what language you are using nor how it manasges to interpret a zero terminator for a standard Windows ASCIIZ string as a space, let along so many of them.
This is all C++/STL.
Of course. It is a standard zero-terminated ASCII string, usually termed as ASCIIZ. Exactly as used universally in C and C++. You should certainly not be using any characters past the first zero.This is exactly what I expected. It's just that I don't get a terminating 0 when reading it into memory.
Thanks for fast reply, I'm going to digg deeper.
-
Erwin,
Probier mal Projekt Eigenschaften -> Konfigurationseigenschaften -> Linker -> Eingabe -> Bestimmte Standardbibliotheken Ignorieren und dort die libc.lib eintragen.
Ich würde aber vorschlagen, statt dem Monster Visual Studio beizubringen was du willst, schreib lieber ein Makefile, was dir die benötigten Libraries und Headers einbindet. Das sind keine 20 Zeilen Code und das versteht nmake genauso wie GNU make und du kannst es später auch nach MSVC importieren.
Du lernst ja auch nicht auf einem A380 fliegen und steigst dann auf Cessna 152 um :)
Gruß,
Philipp
(I told him where to find the option in the German version of MSVC, but suggested he should write a small Makefile instead of dealing with a monster like MSVC. Writing a Makefile is like learning to fly on a Cessna 152. Hacking this stuff into MSVC is like flying an A380).
-
Hi Pete,
simple question: how to obtian the string length of the aircraft name?
At the moment, I'm doing something like this:
std::string title; title.resize(256); FSUIPC_read(0x3d00, 256, &(title[0]), &error);
which yields a string like
title == "Cessna 172 (white space characters until 256) "
Simple matter, just apply some trim function to the string and get rid of the spaces.
I tried:
#include boost::algorithm::trim(title);
and also
void trim(std::string& str) { std::string::size_type pos = str.find_last_not_of(' '); if(pos != std::string::npos) { str.erase(pos + 1); pos = str.find_first_not_of(' '); if(pos != std::string::npos) str.erase(0, pos); } else str.erase(str.begin(), str.end()); } trim(title);but whatever I try, title is always displayed as "Cessna Skyhawk (many spaces) ".
What kind of padding characters are these, that fill up to byte 256? The fact that I can't get rid of them by trimming whitespaces, these appear to be not the ASCII " " character. Can you confirm the string is in fact a C-String?
Philipp
-
Meanwhile, the option does work if you use "READY" as well as CLOSE, the only difference then being that your program won't launch until FSX is ready to fly.
Confirmed.
Thanks for fixing.
Philipp
-
Hi,
when using the run external program feature of FSUIPC, I'm unable to get it working with FSX.
Iappended these two lines to the FSUIPC.ini in FS9 and the FSUIPC4.ini in FSX:
[Programs] Run1=CLOSE,C:\Example\example.exe
Strangely enough, FS9 startup triggers the exe to start up, FSX doesn't. Hugh? This is FSUIPC.log of FSX:
********* FSUIPC4, Version 4.60a by Pete Dowson ********* Reading options from "C:\FSX\Modules\FSUIPC4.ini" Trying to connect to SimConnect Acc/SP2 Oct07 ... User Name="" User Addr="" FSUIPC4 not user registered WIDEFS7 not user registered, or expired Running inside FSX on Windows 7 (using SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed DebugStatus=0 172 System time = 26/06/2010 21:23:45 187 FLT UNC path = "\\NOTEBOOK3\Users\Philipp\Documents\Flight Simulator X Files\" 187 FS UNC path = "C:\FSX\" 1014 LogOptions=00000000 00000001 1014 SimConnect_Open succeeded: waiting to check version okay 3479 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 3479 Initialising SimConnect data requests now 3479 FSUIPC Menu entry added 3526 C:\FSX\FLIGHTS\OTHER\FLTSIM.FLT 3526 C:\FSX\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.AIR 52744 System time = 26/06/2010 21:24:38, Simulator time = 21:23:49 (04:23Z) 53602 Advanced Weather Interface Enabled 76924 Sim stopped: average frame rate for last 24 secs = 19.9 fps 82993 System time = 26/06/2010 21:25:08, Simulator time = 21:24:07 (04:24Z) 82993 *** FSUIPC log file being closed Average frame rate for running time of 24 secs = 19.9 fps Memory managed: 14 Allocs, 13 Freed ********* FSUIPC Log file closed ***********Could it be that Program startup is restricted to the registered version of FSUIPC 4, but not in version 3 ? If this is the case, why a silent fail instead of an error message?
Regards,
Philipp
-
Hi Pete,
wow, I appreciate your offer to enhance FSUIPC just for me :)
But I just managed to create an invisible window that catches your close message and it WORKS!
So I consider this problem solved now.
Thanks for your help!
Philipp
-
Hi Pete,
thank you very much for your fast support.
Unfortunately, the "kill" in windows doesn't generate any signals as it would on Unix. On Unix, you can't ignore a SIGKILL either, but at least you are notified of your imminent death. On windows it's like being hit by a mini-nuke wthout further ado.
So the Close signal is far more promising for what I want: A graceful shutdown.
I managed to catch the Close-Signal of the Console. One can define a function to handle a Ctrl-C, Ctrl-Close, Ctrl-Break, etc events : http://msdn.microsoft.com/en-us/library/ms683242 and register it with the SetConsoleCtrlHandler http://msdn.microsoft.com/en-us/library/ms686016. I inserted this into my code.
Now, when I click the "X" on the CMDline window that opens when FSUIPC starts my program, my programm catches a Ctrl-Close event, does the cleanup work and exits. Great.
But when I shutdown FS, FSUIPC won't close the Console window it opened.
So in summary: If i click the Console window to Close, it works okay, but apparently FSUIPC does something different.
How do you know which window to send the WM_Close message to? I assume you use the FindWindow method to locate the application you spawned. Then perhaps this problem might be related to obtaining the right HWND for the console: http://support.microsoft.com/kb/124103/
Philipp
-
I don't know what they are. Where do you get them from? What are they?
These are POSIX Signal handlers. http://en.wikipedia.org/wiki/Signal_%28computing%29
But they are supported by windows also, at least for commandline applications
Maybe yours is not a Windows program? If you never register a Window class and create a Window, even a message window (it needn't be visible), then I've no idea how it gets terminated.Yes, my program is indeed a command-line only programm that runs as a service in backround with no GUI whatsoever. So my only chance to get messages are POSIX-signals.
The other possibility would be to introduce some WinAPI-Code to create an invisible window, as you suggested.
-
Hi,
I'm using the [Programs] Run command to start an application I wrote along with the simulator (as Pete advised me to do so here).
I want to terminate my application gracefully when FS is shut down.
For that, I tried inserting the options CLOSE or KILL before the path.
KILL quits my application but doesn't let me do cleanup work, CLOSE doesn't seem to effect my application at all.
I installed the following signal handlers:
signal(SIGTERM, &signal_handler); signal(SIGINT, &signal_handler); signal(SIGBREAK, &signal_handler); signal(SIGABRT, &signal_handler);
But I don't seem to receive any of those signals, neither with KILL nor close.
How can my application notice an FSUIPC-issued close request ?
Regards,
Philipp
-
That's not really a good reason for implementing it as a DLL. You can do what you want to do by having it started and ended automatically by a parameter in the FSUIPC INI file in any case
Thanks for pointing me at this option. Is this "program start"-capability also available to users of the unregistered version?
The main problem I sense with this approach is that 90% of the users won't read the manual where I instruct them to edit the .ini file. And from the remaining 10% who read the manual, 90% will stumble over getting the editing right, forget parameters and so on. Yes, I read about the program by Jose Olivera, but thats another tool the user would have to downlaod and deploy. I'm looking for an absolutely fool-proof solution that is totally invisible to the end-user. In a perfect world, the installer of my application would append the parameter to the FSUIPC.ini.
Writing a program to run in the same process as FS means taking great care to avoid affecting its performance. You don't have the benefit of windows operating its timesharing capabilities, nor will your code necessarily run on a different core.I totally agree on that and I'm aware of how difficult "in-the-flightloop"-applications are to develop. Been there and done that in the X-Plane world.
It depends on whether you are talking about FS9 and before or FSX. For FS9 and before, loadable DLLs are like Gauges but with filetype DLL instead of GAU. Try writing a gauge in C and you'll get the idea. For FSX you'll find information on your questions in the SimConnect SDK.So there is no generic approach for both sims?
Than to sum it up:
External app:
pros:
-easier on the performance
-same approach for FS9 and FSX
cons:
-modifying fsuipc.ini is beyond most users capabilities
Internal module:
pros:
-transparent to the user
cons:
-performance issues
-Separate modules for FS9 and X needed.
So if you/others have an idea how to get the "external program startup" transparent to the end-user it would be greatly appreciated.
Philipp
-
Hi developers,
at the moment my application is a separate .exe file that uses the FSUIPC.lib and has to be started once FS is running and to be stopped when FS is shut down.
Now I want to integrate the application as a module (dll) into the FS process itself rather than requiring the user to start it.
I found the MoudleUser.lib to be the preferred way of accessing FSUIPC data in that case, but I have a much more basic question: With exactly what callbacks do I have to replace my "main()" function? What callbacks must my FS-module expose to runtime linkage so it is called in FS startup ?
Philipp
-
Hello Pete,
The 29th FSUIPC_SDK.zip download from the 11th Jan. is missing the FSUIPC Access Registration Guide.doc file mentioned in the ReadMe.txt.
Meanwhile, I found the code snippet in the UIPC_SDK_C.zip/UIPCHello.c.
Also, where can I find pricing information for a developer's license?
Regards,
Philipp
How does Offset 0x2EA8 (aileron deflection) behave for differential ailerons
in FSUIPC Support Pete Dowson Modules
Posted
Hi Pete,
this is awesome! Thank you so much.
Cheers,
Philipp