Jalava

HMD->ALIGN cannot be initiated with cage/uncage button unless ground power 3B is active when doing HMD aligment on ground pre-cranking. Is this bug or do you need to have FLIR bus powered for cage/uncage button to work for HMD alignment?

Got RTBd after and put up 99X on TACAN which was then identified as D4J, it was quite far away.. anyway, took some fuel at Texaco nearby and flew to the 99X and there was absolutely nothing there, I thought I spied Mother near Texaco but..

Wait was there something you need to modify in defines.tmh to make virpil support TARGET Gui? Just found it out, you need to map pov hat to DX buttons and modify defines for H1 to match those buttons to fix, more info here for next: https://forum.virpil.com/index.php?/topic/3976-mt-50cm2-warthog-stick-and-target/

Nice! Gotta check that, I'm so in-depth locked in over the years with Home Fries profiles, I find it difficult of moving to anything else now that all kinds of problems start to pile up, all of them probably from 3rd party issues.

Just noticed, my trim, or rather POV hat is stuck up when running the TARGET script, looking at the joystick as regular everything read correct, but through TARGET script most of the stuff works except POV hat which is always up. I've seen someone else have this before, but haven't found a work around for it yet. This is probably issue with latest TARGET software as I haven't noticed this happen before, running Virpil base with spoofed IDs for joystick and no Cougar MFDs as I got Winwing Topgun MIP setup.

Ah, it's not actually unicode, it's 0xA0 or non-breaking space instead of regular space. Regardless, I doubt that is the issue there as modifying that won't fix it. I hope you find the gremlin.

Tried that, didn't work, for some reason it doesn't seem to find the correct spots in the DCS_World_Template.tmc to insert the variables. I have no idea what goes in your code, but as professional my hunch is either A) string matching regex fails for some reason or B) there is a function that has turned into asynchronous at some point and some data isn't yet loaded when things get inserted. EDIT: Also looks like other stuff gets inserted into correct spots, constants, Default menu and profile init, etc, so it is just the variables. I'm running latest Windows 11 with US English regional settings and language, so shouldn't be from that either.

Just setup my sim together again after about one year of not flying, updated CTS and TARGET as usual and now after build script and trying to run it, I get the Compile Error: Symbol not found: Custom_Master_LUA_F14 in DCS_World.tmc at line 159 error again. I see few users have had this error but no clear instruction on what causes it. Looking at the code, it seems that it includes the constant variables in the end of the script, could this cause the issue why variables would not be visible in the start of the script? Tried clean install, enabling and disabling various modules, but no avail. Including the dcs_world.tmc for you to take a look. edit: Running Windows 11. Copying configuration from bottom of dcs_world.tmc towards the top seems to fix issue, so it looks like there is some kind of issue with finding correct spot to insert into the script in the code. I do see this interesting unicode char in the comments, like this "//�Default Initial Configuration" when looking with notepad++ (char seems to be 0xA0). Could this be the issue? DCS_World_tmc.zip

I have a fix for this but it is very specific to my monitor setup. Basically crew indicator coordinates are in texture coords -1 .. 1 range instead of normal coordinates and you can just brute force all of the x-positions with a fixed value instead of the calculations.

I can confirm there is something strange with new kneeboard. As it stands with 5120x1440 and 1920x1280 screen side by side, it renders the kneeboard partially out of whole canvas. In addition the UI elements are not aligned with kneeboard. I can confirm this by changing ViewportHandling.lua#update_screenspace_displacement default_x into 3100 and then you can see the UI will render around right edge of the main viewport but kneeboard will render left of the UI at 3100px.

Same, now the kneeboard renders not only out of my main screen but out of the whole rendering area and I cannot move or resize it either.

Currently kneeboard builder doesn't seem to be able to move all elements of kneeboard to correct position. My main use for kneeboard builder is mainly to reposition the kneeboard builder as it with extra screen for MFDs, kneeboard will render out of view.

I stand corrected, you cannot set TOT into past hence it will assume 24 hours forwards in time for TOT. Setting the original TOT do some easy time bit forward in time from takeoff and then adjusting it back to push time works correctly.

On OB 2.5.6.57264 Using DTOT Adjust doesn't seem to update the new DTOTs for waypoints to all systems. Steps to reproduce (For sake of simplicity let's assume mission time is around 12:30:00 and distance to WP1 is around 50 miles or so to get relevant numbers): 1. Setup waypoint 1 on WP page DTOT to 00:00:00 2. On NAV page TIME subpage, Set DTOT Adjust to lets say 13:00:00 3. WP page now shows DTOT as 13:00:00 4. However, while TOT delta is shown correctly, the RIAS on CDU and on HUD will still show incorrect value like DTOT were still at 00:00:00, not in 30 minutes with 50 miles to go or around RIAS 100 We use this for setting times in waypoints when push time at WP1 is still unknown when starting up and adjust DTOT based on given push time to adjust the whole plan Workaround: For each waypoint after step 2. copy the time from DTOT for each waypoint into scratchpad and re-enter it as DTOT. After this RIAS is also corrected.

Still there, I wonder if this is a ED or Vaicom issue.