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.

VAICOM seems to silence the AI radio messages for A-10C II when callsign is of pork series (BOAR, TUSK, HAWG, PIG) Changing the callsign brings the radio calls back, it also works when VAICOM isn't active.

In manual it says you can select FAC tasking weapon type as: Guided - Guided Bombs - Missiles However in editor, you can only select Guided and Guided Bombs. If player carries Mavericks and GBUs, are Mavericks always preferred over GBUs when Guided is selected?

At noon there are practically no tall shadows which makes everything bland and hard to see. When you have shadows, it's much easier to recognize stuff in the ground.

If you have Mode switch turned from MISSION to FL. PLAN it will follow the waypoints automatically. However, you cannot select other waypoints when in flight plan mode.

While I was testing if ground inhibit works, I noticed that if you attempt to do selective jettisoning on ground, taking off will not remove the inhibit for selective jettisoning after you've tried it once. I can't find any error message anywhere, but it just doesn't work after that. Emergency stores jettisoning button still works as expected. I wonder if it should be just like this. Pretty edge case though so not sure if it is even a bug, who in their right mind would first try SJET and then take off and SJET again.

If you look how KneeboardBuilder does the modification, you can modify it so that I believe it passes the integrity test, it just requires modifications to quite a few files. But I also have to modify UH-1 and MI-8 for also the AI Panels and Cargo Camera for same reasons just as they use texture coords instead of sane coordinates of actually rendered viewport for positioning.

Make sure you make most of your TrackIR yaw and pitch curves. When looking at the edge of your screen you should be viewing directly to back as much as head turns. If using 32:9 this should happen bit earlier, at around 20% from screen. Then because you usually look just bit over 90 degrees to side, you could have the rear wards portion much more non-linear and this way you don't have to turn your head that much.

If you double each FOV number, you get same vertical angle and views look similar to how they look on 16:9 with just stuff added to sides. Just tested that and I think it works pretty well. See attached screenshots. With out changing FOV, for example you can only see the keyboard of CDU but nothing else. I think this provides a quick solution to 32:9 users. It may seem initially they are distorted, but when in snapview, you only want important stuff in the middle and don't want to turn your head to sides anyway. As I use TrackIr, I'm not sure if Boresight or TriggerZoom can actually be triggered at all as I don't seem to get any changes when trying to modify FOV on "Default view" and cannot activate TriggerZoom via S3+TG1 My current snapviews for A-10C_2, just roughly doubled the FOVs, I think you can automate that in your build scripts. SnapViews["A-10C_2"] = { [1] = {-- player slot 1 [1] = {--LWin + Num0 : Snap View 0 viewAngle = 130.000000,--FOV hAngle = 0.000000, vAngle = -26.000000, x_trans = 0.000000, y_trans = 0.000000, z_trans = 0.000000, rollAngle = 0.000000, cockpit_version = 1, }, [2] = {--LWin + Num1 : Snap View 1 viewAngle = 126.740002,--FOV hAngle = 70.197182, vAngle = -58.828632, x_trans = 0.126559, y_trans = -0.052729, z_trans = -0.071945, rollAngle = 0.000000, cockpit_version = 1, }, [3] = {--LWin + Num2 : Snap View 2 viewAngle = 102.796501,--FOV hAngle = -59.177437, vAngle = -62.901718, x_trans = 0.088538, y_trans = 0.036120, z_trans = 0.059352, rollAngle = 0.000000, cockpit_version = 1, }, [4] = {--LWin + Num3 : Snap View 3 viewAngle = 64.296501,--FOV hAngle = 0.000000, vAngle = -80.000000, x_trans = 0.183838, y_trans = 0.014481, z_trans = 0.250000, rollAngle = 0.000000, cockpit_version = 1, }, [5] = {--LWin + Num4 : Snap View 4 viewAngle = 152.511101,--FOV hAngle = 0.000000, vAngle = -23.000000, x_trans = 0.402969, y_trans = -0.256181, z_trans = -0.117188, rollAngle = 0.000000, cockpit_version = 1, }, [6] = {--LWin + Num5 : Snap View 5 viewAngle = 164.227150,--FOV hAngle = 0.000000, vAngle = -21.213251, x_trans = 0.351388, y_trans = -0.259055, z_trans = -0.001991, rollAngle = 0.000000, cockpit_version = 1, }, [7] = {--LWin + Num6 : Snap View 6 viewAngle = 156.674400,--FOV hAngle = 0.000000, vAngle = -26.371302, x_trans = 0.402969, y_trans = -0.264311, z_trans = 0.122662, rollAngle = 0.000000, cockpit_version = 1, }, [8] = {--LWin + Num7 : Snap View 7 viewAngle = 136.982597,--FOV hAngle = 0.000000, vAngle = -62.194908, x_trans = 0.237730, y_trans = -0.300000, z_trans = -0.250000, rollAngle = 0.000000, cockpit_version = 1, }, [9] = {--LWin + Num8 : Snap View 8 viewAngle = 144.182503,--FOV hAngle = 0.000000, vAngle = -0.220625, x_trans = 0.360000, y_trans = -0.041337, z_trans = 0.000000, rollAngle = 0.000000, cockpit_version = 1, }, [10] = {--LWin + Num9 : Snap View 9 viewAngle = 136.982597,--FOV hAngle = -1.941612, vAngle = -67.146278, x_trans = 0.396876, y_trans = -0.300000, z_trans = 0.250000, rollAngle = 0.000000, cockpit_version = 1, }, [11] = {--look at left mirror viewAngle = 140.000000,--FOV hAngle = 20.000000, vAngle = 8.000000, x_trans = 0.360000, y_trans = -0.041337, z_trans = 0.000000, rollAngle = 0.000000, cockpit_version = 1, }, [12] = {--look at right mirror viewAngle = 140.000000,--FOV hAngle = -20.000000, vAngle = 8.000000, x_trans = 0.360000, y_trans = -0.041337, z_trans = 0.000000, rollAngle = 0.000000, cockpit_version = 1, }, [13] = {--default view viewAngle = 150.000000,--FOV hAngle = 0.000000, vAngle = -19.000000, x_trans = 0.157000, y_trans = -0.008000, z_trans = 0.000000, rollAngle = 0.000000, cockpit_version = 1, }, [14] = {--default view - VR viewAngle = 150.000000,--FOV hAngle = 0.000000, vAngle = -19.000000, x_trans = 0.157000, y_trans = -0.008000, z_trans = 0.000000, rollAngle = 0.000000, cockpit_version = 0, }, }, } EDIT: Disregard FOV for VR, I don't know how that works but I'd guess it doesn't need doubling as it works differently.

About SnapViews, I noticed that at least on A-10C, SnapViews.lua only works if cockpit_version=1 is set, otherwise it will ignore the snapview settings. Commentary on provided snapviews in general: They are bit too zoomed in for 32:9 (FOV has to be double a bit larger for similar vertical view vs 16:9 screen I believe) and at some point it could be useful to have better suited snapviews for 32:9 screens as own pack.

I have confirmed this only happens on A-10C II and not on the original A-10C If you do cold start and throttles are in cutoff position, you cannot move throttles into IDLE position until you cycle throttle out of idle value and back to idle. If using Warthog HOTAS, this means coming out of cutoff, then pushing throttles bit up, back to IDLE and then to cutoff, then it works. I believe this is because throttles are not internally set to 0 on Cold Start and will IDLE/Cutoff detent is inhibited until throttles are at 0, as throttles do show up visually as being at zero, but nothing is shown on controls indicator about position. Steps to reproduce: 1. Put throttles on IDLE 2. Start cold and dark mission 3. Try starting engines with keyboard bindings (RCtrl+Home / RAlt+Home) -> nothing happens 4. Cycle throttles up and down 5. Try starting engines again with keyboard bindings (RCtrl+Home / RAlt+Home) -> throttles will jump to IDLE detent as expected. Current workaround is to cycle throttles max and idle and back to cutoff on after start of the mission.