ivanwfr

In case anyone is willing to dig into the topic Jason seems to have dropped, here's where I'm at as I look for ways to communicate simulation to the outside world using the export API. I created a public Github repository from which you can download a ZIP archive. Text gets highlighted by value change

Well, I'm not a Visual Studio expert myself as I used it only for a few C# projects. All those options you mention have only theoretical meaning for me. The name space access has to be adapted to the requirements, whatever they could be. But I won't be able to help you there and I hope someone with experience will read your message as this is clearly a matter of familiarity with the advanced configuration details. I have no idea as to what it means having to map a dll module for the editor. All I could experiment was having some results with a script calling a strstr() function that was only available when I added two sys.dll in the Plugin folder with two different names:

In case you did not try this: ---------------------------- Just drop you dll file into the C:\Program Files (x86)\Thrustmaster\TARGET\Plugins folder Then, when you start C:\Program Files (x86)\Thrustmaster\TARGET\x64\TARGETScriptEditor.exe the bottom log pane will show what has been loaded. As I understand it, as long as dll files seem=s to works just like UNIX shared objects (the libXXX.so), those files are loaded by the dynamic loader of each exe. All those dll files content will fill up the process global tables with all defined functions from those files. It happens only once, as the first dll containing a function will be the priority function source, other entries will be ignored. That's how we can override a system function on UNIX by PRELOADING a dynamic library before the standard ones. This means that you don't have to load anything yourself, just call your function and optionally add their signature (declaration) into an included file like C:/Program Files (x86)/Thrustmaster/TARGET/scripts/sys.tmh Try this and tell us how it goes... -ivan

Hi speedbird5, The SetShiftButton function defines all the IO and UMD modifiers keys all at once You should call it only when you want to change something. Try this modified version from my description in the first post and tell us if you get what you need. SetShiftButton( &Joystick, S4 // [i .. Paddle Switch] , &Throttle , MSL , MSD // [u .. MIC Switch Aft] , [D .. MIC Switch Down] , 0); You could think about it as if you were defining which will be the Shift, Control and Alt keys of a keyboard allowing for 6 different combinations for each of the other 30 + 18 other switches. The best place for more details is in the include/target.tmh file where you can see this: 1 define IOTOGGLE 1 2 define UDTOGGLE 2 3 int SetShiftButton( int devI=0 , int indexI=0 4 , int devUMD=0 , int indexU=0 , int indexD=0 5 , int flag=0) 6 { 7 alias io = devI, umd = devUMD; 8 layer_sw = 0; 9 if(devI) layer_sw[0] = &&io + (indexI << 1); 10 layer_sw[1] = flag & 1; 11 if(devUMD) layer_sw[3] = &&umd + (indexU << 1); 12 layer_sw[4] = flag >> 1; 13 if(devUMD) layer_sw[6] = &&umd + (indexD << 1); 14 layer_sw[7] = layer_sw[4]; 15 }

Hi dmonds, I have no idea how to send a query to the device. I too had to resort to waiting for an event to handle in order to initialize a parameter instead of applying some initial value. What I found best was to rely on some user activation to sense the current value while moving the device actuator. The only drawback is that this is a prerequisite for both the hardware and software values to get synchronized. This is typically one of the reason why I gave up adding features to my code. And now, I can see that the "Lua exporting in DCS" page I used to watch going nowhere back in 2011 has simply disappeared from ED site. So, when you will get stuck somewhere, it'll be for good ;( I had some contact with Guillemot at the time and I could get a bit of insight beyond the official TARGET book. And this is how I could get some dynamic data at work in util/util_GameCB.tmc from PNP_ivanwfr_111222.zip. Maybe you can get some launch-time state or run-time feedback from the sim this way...

Sorry dmonds, but as I'm not as involved as I used to be, all these mappings became nearly as alien to me as they were during my first encounter. Maybe you could get some clues from the code archive from my first post. There is something dealing with SetSCurve in axis_THR_SC_STICK.tmc. Maybe someone here could take over on this one... If you don't reach a solution for a few days, I could try harder once again.

Good point! You're quite right about using the return instruction to terminate the main function. I should have replaced this system call with a standard process status value. That was just a copy-paste from my hijacked main that I wanted to ignore its original task. And BTW, this is no C, it's a dialect of some sort where everything seems familiar but with a twist. Watch out for address (&) and pointers (alias alias). I used to work with C for decades and here, I'm just a newbie sometimes ;)

Hi dmonds ... for strcat: include "target.tmh" int main() { // \xa .. UNICODE HEX VALUE FOR LINEFEED printf("--------------------\xa"); alias s1 = " s1 "; // static string alias s2 = " s2 "; // static string char buf; // dynamic string Dim(&buf, 256); // memory allocation buf[0] = 0; // initialize as an empty string printf("buf=[%s]\xa", &buf); strcat(&buf, &s1); // strcat 1 printf("buf=[%s]\xa", &buf); strcat(&buf, &s2); // strcat 2 printf("buf=[%s]\xa", &buf); //---------------------------- // ... sprintf can do much better than strcat int number = 42; sprintf(&buf, "FORMATED: number=[%d] .. s1=[%s] .. s2=[%s]", number, &s1, &s2); printf("buf=[%s]\xa", &buf); printf("--------------------\xa"); exit(0); }

Good job! It looks you got it right. This level of using the script language is not the shortest way to get things done real quick but, unlike with intricated macros, you can reach a clean understanding of what happens behind your code.

You may try something like this: define CYCLE_INTERVAL = 500 int start_loop() { // FIRST CALL .. ON SOME EVENT handle_cycle(0); } int handle_cycle(int cycle_num) { // THIS CYCLE HANDLING // NEXT CYCLE LOOP DeferCall(CYCLE_INTERVAL , &handle_cycle, cycle_num + 1); }

You last conclusion is the right one... CHAIN is defined by Init, near line 200 in target.tmh. The only legal commands you can call before Init are the Exclude(&...) calls.

I do not remember quite well after all these years but I suggest you pick something else than the S4 button .. If you have it like me, serving as one of the URDL modifiers, this mapping may be the issue. If this is not the case, I'll have to refresh my memory before I can help further...

Well, I tried my best to find a way to make TARGET behave like it should. But when you have a function called GetMouseX() that returns 1459 nearly every time you call it, that's not going to happen! Quite like PlugMouse(NOT absolute) should result in something that makes sense and there is no way to get an idea of what happens. My conclusion is that this code is not clean enough to work out a solution that would track the current position of the pointer as would any mouse driver. I even tried the TrimDXAxis() hack ... same result, TARGET keeps working with its private pointer position instead of starting from the current screen coordinates. And you can't correct that when GetMouseX() and GetMouseY() are not working. I got many fancy functions working so far like an toggle-able auto-zoom between first and second trigger stages with a blinking led when it's on, auto cockpit views preset file storage, etc. But this issue is a lost cause as it requires a core rework (or more accurately finished work). Sorry, I'm going to find some better way to spend my time ... as you should ;) -ivan

Solbeamer, I think I found your escape route ... have a look into the target.tmh file you have already patched ... line 192 reads: [size="6"]PlugMouse([b][color="Blue"]1[/color][/b]);[/size] And that's absolute pointer coordinate mode, as you can see in the comment a few lines above. You should set an argument of 0 to have the relative pointer behavior you need: [size="6"]PlugMouse([b][color="Red"]0[/color][/b]);[/size] As I use SetCurve() with the virtual mouse, I did not test the AXIS(DirectX axis name, increment, delay before repeat); version in my code, I'll let you check this patch and wait your feedback to know how it goes. In any case, the relative mode is quite messy with SetCurve... If it works with AXIS(), I will also use it for Star Citizen. -ivan

Hi Solbeamer, I will definitely have a look but I'll have to rewind my brain to the time when it still made sense to me... (not much involved anymore). But as I also care about SC, I will have to face this issue eventually but it wont be before a few days. In the meantime, all I can say is that this cursor thing is very messy in many games and here, we have TARGET to make it worse. Maybe you could call AutoHotkey to the rescue to center the pointer with something like this: ^+!Delete:: MouseMove, 100,100 ; ... Ctrl-Shift-Alt-Delete

Your points only make me think we're not talking about the same skill level! If you take the time to understand what is attached in my first post, you will see there is no way to do it with any kind of user friendly wrapper. This kind of "opinion" can make some sense only if you keep as far as possible from any effective custom code. I did not start this thread to gossip about what could have been. This is about real hard job that works. It was not easy and I don't like TARGET any more than some others who have done some real work with it. I know that TM tried their best to access the many features of its device ... no way it could be simple ... and they could have done it better ... and I'm also sure they know that. Well, I worked with it and I got every single customization I could think of working as I wanted. If some are not happy with TARGET, I'm not on the list. And when you want to prove me something about how nice it is using an IDE, I know we're not on the same page... I will NEVER use and IDE like Visual Studio or even Eclipse to get serious job done. I will always use Vim and a few hundreds of custom macros I use to tune up since I started with ed and then vi back in the 80s. I need to own the day, every day, and I can say I do since then. Even with SharePoint ;) , I feed VS running in a VM from gvim running on the host. I do my job, VisualStudio does the plumbing. It knows how to deploy things to keep IIS happy and I don't care to understand how that kind of "works". And I have hundreds of reasons to explain why (even though I used to teach how to work with some IDEs when requested). First reason is that they tend to make users think they are mastering their subject, when they should realize that the tool is tutoring them. They don't even have to understand majors steps (how to do a good job with syntax,compiler,linker,loader,threads,...) leaving all the real work into the "hands" of some default development tool ... and it works! because MS and co. makes sure it does, they even get you certified to make an incentive so you're hooked for the long term. My job is quite about what others don't do, too late to change that... Look here for something no IDE will ever care about: ... http://ivanwfr.github.io/Twiddler3-Layout/ I googled in vain, looking for any forum, no luck, I'm currently alone on the subject. Once again, my own way to look at things would get me a hard time if I was looking for some consensus ;)

You can do without, relying on in-game handling. The same goes with planes, most could fly with less buttons on their dashboard, why bother? Learning a programming language is all about getting more control by choosing a high-end alternative. As a programmer, I don't use Notepad to do my job, TARGET and this pricey device deserve Emacs or Vim and a minimum skill requirement to boot. Now, non-programmers have two options, either give up or learn how it works, first is easy, second needs some work. DCS matter is not about those things anyone can do with no effort but I still have a hard time to understand why so many are ready to spend hundreds of hours on hardware and so few at mastering the software that obviously goes with it. Most comments about TARGET have to do with its very existence, many complaints and so few questions. But if you are looking for a cure instead of a way to proceed, your HOTAS's best place is on eBay. -ivan

...well, there is matter for some hours to spend/waste ;)

For those ready to get their hands dirty, here is a new scripting nightmare of mine based on AutoHotkey and Human Interface Device Windows API. This one makes a good complement to my previous thread about TARGET - Advanced programming. As a time saver for some, those who advise everyone with a problem to uninstall TARGET, they should stop reading right now :smilewink: All this is about looking for problems and try to solve some of them... Last update: 2013-08-26 HIDCONTROL.zip, HIDCONTROL_SOUND.zip, HIDCONTROL_PROFILE.zip

Could be this: (only a suggestion - from the manual): Aerial Refueling Contact (...) 4. For successive contacts, you must cycle the aerial refuel system by pressing the refuel/reset button (Nosewheel Steering button) or closing and opening the slipway door.

All I know is that you should go through the calibration sequence again and again knowing that the tool can do its job - but with a user interface dialog that is completely out of phase. I don't remember what I did on my last successful attempt but I could get to a plain 0 unit tolerance over 64k! Something wrong is happening at the worst time near the end, precisely when DFU mode (Device Firmware Update) should commit the required adjustments into the device firmware memory.

I'm not quite done with this because there may be some solution for each of those issues. But I'm not positively impressed with devs support either. Their "Lua exporting in DCS" page looks like an antique, a place that has been abandoned since ages. I know it's useless to ask for some controls insight as the only thing coming in return would be the echo of my own voice. I know this is not a constructive point but how else should that be said? The only alternative is to say nothing and quietly let this decay proceed on its way to nowhere. Maybe I should restate the fact that I like this sim enough to spend a fair amount of my time trying to get the most out of it... That's my construction and I'm not getting involved in money vaporware here, it's only a passionate matter. So no one has to remind me to keep a positive frame of mind or I'l simply quit for good. This one too will give some head scratching to our moderators, but each one of us should sometime reconsider how any blind support can be seen from the outside.

Replying to myself, as it looks I'm the only one who cares. I could find out that custom configuration files from 1.1.0.9 are not only incompatible with 1.1.1.1 (some LUA table dump change) but keeping them around silently removes TM Throttle axis entries from Controls window. Another trap hidden in this patch takes care of some TARGET DX Input ON-to-OFF transitions that are now ignored... Meaning you can't handle your flags, EAC and LASTE correctly... Also, trimming seams to be a problem... If someone can tell me how to report this in a constructive manner in order to comply with the "recommended" positive attitude enforced by this forum policy, I'm ready to rephrase everything.

? TARGET Virtual Joystick support dropped ? LUA export support has vanished from some previous patch and now it looks like TARGET Virtual Joystick support disappeared! I hope I'm wrong but I can't stand this patching process unreliability and the way I discover that all the time spent can be silently put to waste. As of right now, I suspect that TARGET support about axis mapping has been hit by pach 1111. I'll have a look in these forums to check if there are some discussion I should read in order to get some workaround... You could check that too and if you find something, then let me know... If it happens that there is no solution, I'll report about this unworthy job from ED's team... Look, if you had a liner captain that would prepare his flight like this, you could be worried about your safety once airborne... TARGET virtual joystick support should be part of their check list at patch release time! I hope for some solution to be found or at least some explanation ! Ivan

This is one of those MS traps you need to get sucked in once in a lifetime, then you're good to go... ;)