Subferro

Is the readme the same thing that’s on github (https://github.com/ciribob/DCS-CTLD) because that’s where I started and couldn’t find any answers. I see the scripts for changing behavior wrt smoke, laser code etc. but that’s not what I’m looking for. I mean within the mission aside from “JTAC Status” on the F10 menu is there any way to communicate with the JTAC? That also doesn’t tell me what the radio frequency is used for aside from a cryptic “The JTAC can talk over SRS” and how it’s computed. Tuning the frequency doesn’t seem to give me any additional options, so what “talking” is the JTAC doing that’s different from the Status report?

I think I’m missing something with the JTAC system. Is there a way to interact with the JTAC besides requesting “JTAC Status” from the radio menu? Also what is the point of assigning a radio frequency to the JTAC, as I can get that status report that has target type and location on any frequency.

When adding an offset to an OAP, using the GRID option on the UFC produces strange results. Namely, the GRID coordinates of the offset do not match the entered coordinates. In this track I add an offset to waypoint 2 at GG 331 334 but the result is GG 340 333. I then use the same procedure to edit waypoint 3 (oops, meant to place the waypoint 11 that I had just inserted) to GG 331 334 and it ends up at the coordinates as entered, so this only seems to affect O/S entry. offsettest2.trk

First, thank you for the feedback. Glad to hear people enjoy this. For your question, are you talking about Strike or CAS/BAI missions? For strike the kneeboard will have precise lat/long, ignore any MGRS messages, that’s just leftover scripting and not really meant to be used. For BAI missions you should be doing bomb on target rather than bomb on coordinate, and the MGRS grid should get you in the vicinity, but then use your sensors to pinpoint your aiming. If you’re having trouble finding the target (more likely on CAS missions in urban settings), the JTAC can lase using the F10 menu (Not the standard JTAC comms!) and you can use the LST of your pod to find the target. For BAI missions your wingman can do the same once you get close enough.

https://www.digitalcombatsimulator.com/en/files/3313646/ An historical fiction that has you flying against a resurgent Syrian Regime after they are ousted in 2012. Essentially a sequel to my Coherent Force campaign with a lot of updates. More linear in nature regarding strike missions, but this has allowed me to incorporate much requested scoring and a debrief system. Lots of QOL updates as well, and it’s been migrated to the Supercarrier. Custom kneeboards for each mission and please read the briefing for instructions. A lot is done through the F10 menu (checking in, wingman buddy lasing, JTAC lasing). Im working on a quick update to make the AI SEAD escort more effective and based on your reports may rebalance some of the enemy air defenses. In most testing it wasn’t an issue, but I had one unlucky attempt where an SA-6 went ignored and ruined my day. Old campaign for reference:

Question regarding jtac and ip objects. Does anyone know what causes the jtac to reference an IP and what determines their choice of ip? I have a mission with two jtacs and two ip objects. Occasionally one jtac will reference the IP closest to the other JTAC, and he never references the IP closest to himself, so it isn’t based on proximity. The other jtac never gives an ip in his 9-line. Doesn’t seem to depend on control either as I’ve had that one jtac use it in both type 3 and type 2. Really just can’t figure out what causes them to reference an ip and in a mission with more than one how they choose which point to reference

Thank you for including this part. Everyone keeps posting thermal protection this, grey skin that... and I’m here looking at very green bombs. Glad to know I didn’t miss something with the update

Any update on this? Been requested multiple times. The textures already exist in the game, literally all this would take is adding a few lines of code to the description.lua of the default skins. Yes there are mods that do this, but it would be much easier to just make this part of the default game.

Been watching LANTIRN and WMD-7 videos on YouTube as I don’t have the -14 or Jeff. Why can ED not get us FLIR images that look like that? So much better than the effects we’re seeing with the LITENING... and the LANTIRN should be an inferior pod!

Then he or she would probably use mark points to save the coordinates. TOO mode is a way to get JDAMs pointed at your current target. Using it for anything else is outside the scope of its intent.

Ok interesting. I started to edit those, but they had names like INDICATION_COMMON_AMBER or INDICATION_COMMON_RED. I wasn’t sure if those would affect the caution lights on the cockpit itself or just the DDIs. Plus in the DDI subpage .luas, I see things like “MDG_EADI_RDR_SetYellowColor” (not exactly but similar), and I couldn’t find any reference to those in the other scripts so I assumed it was out of my control. I’ll try the other settings in the main materials.lua Oh and to be clear I did find the MDG_materials that controls the green on DDIs and I’m much happier with my values for that (posted above)

Ok now that we’ve sufficiently derailed... back to the topic: Do we know for sure what triggers the laser to shutoff? In autolase I think it makes sense for it to kill the laser ~5 seconds after TTI which seems to be about the case in game. For manual lase though I’m less convinced. Seems like then the cutoff should be based on either pilot input or if the laser is approaching its mask zone. Right now it still seems to operate on the ~5 seconds post TTI, which defeats some of the purpose of manual lazing

Ok I give up. I can’t find the controllers for red and yellow on the DDI/AMPCD. I can find references to it in the various subpages, but can’t actually find where the color is set.

You can’t get it to look back without making a new designation. Obviously this will mess up your bomb programming. Wait until the last bomb is off the rack, then hit WPDSG if you have a waypoint in the area. I do wonder if undesignating in area or point should leave the pod in place. And then you can return to snowplow by cycling to OPR. But that is speculation

I did something similar. I found just files for black DDIs and using the description.lua from someone else’s mod cockpit and the default textures made a SavedGames cockpit that only changes the DDIs, no additional reflection. A bigger difference came from editing the materials.lua. Interestingly they have a commented out line giving {204, 255, 0, 255} as the value specified for the real Hornet DDI color. I changed the one in use to {204, 350, 0, 255} and it’s much more readable. A little neon but not bad. Next I need to find a good balance for the amber and red to match.

I bring up mods less because of brightness but more because some of them seemed to change the DDI texture. Making the DDI more black and less green might also fix readability Like this: https://www.digitalcombatsimulator.com/en/files/3306396/

Do any of the mod cockpits help with this issue? Might work as a stopgap while waiting on an official plan. Are mod cockpits MP compatible even?

Maybe it isn't designed for you to program 8 individual TOO targets? Though what I would try is after you designate 1-4 on TOO1, undesignate then step through all bombs and select TOO2 without designating anything. At that point stepping through to designate targets should (I haven't actually tested this) keep the TOO2 selection so that now that's where the coordinates get saved. Mark your 4 TOO2 targets. Undesignate. Drop 4 in TOO2, step through each bomb and select TOO1, drop 4 more. I'll test that out, but just because the system doesn't have a smooth and easy workflow for saving 8 individual TOO targets, doesn't mean it's a bug. EDIT: another thought, do what he does in the video and designate TOO1 and then TOO2 on each station before stepping, when you hit the last station, undesignate. The only difference is he slews the pod before switching from TOO1 to TOO2. Don't do that. So workflow is WPDSG (or whatever to get the pod designating and pointing towards your target). Select STA 2 in TOO mode. Point to TOO1 and leave the pod there. Hit TOO2 (right now it will have the same coordinates at TOO1) and slew to the TOO2 target. Leave the pod there. Step to STA 3 TOO1 will have the same coordinates as TOO 2 on STA 2, slew pod to STA 3 TOO1, select TOO2 and slew to TOO2 target, step to next station and so forth.

It makes perfect sense. TOO mode reads its coordinates from the CURRENT aircraft designation. If you have a JDAM in TOO mode selected and an active aircraft designation, that designation becomes the bomb's target regardless of any prior action. Once you accept that as how TOO mode is intended to work, then its a lot easier to understand. There is a need to TDC depress to get the pod (or radar etc) into a designation mode rather than snowplow. You can also use WPDSG to get it into designation mode. Once it's designating, however, JDAM interprets its coordinates from the A/C designation. Just like using unguided bombs in AUTO mode, they will be cued to wherever you slew your designation. EDIT: And to clarify, the only way to not "lose" a TOO target is to not select that bomb when you have an active designation. If you undesignate, you can step between bombs at will and they will have stored the coordinates of the LAST designation that was active when THAT BOMB was selected AND in TOO mode. For instance, I WPDSG with STA 2 selected in TOO mode, that wpt is now saved, I step to STA 8 also in TOO mode and slew the pod 150 meters north, I don't have to hit TDC as the system was designating that whole time, and wherever I slew to is now STA 8 target. If I step back to STA 2, that bomb will take coordinates from my current designation. If I undesignate first, STA 8 and STA 2 will have different coordinates that I can drop on (as long as I don't designate anything else in the meantime). You can also switch TOO MSN if you're expecting to slew your designation, wherever you left MSN 1 should still be stored as long as you undesignate before opening it up.

I don’t think this is a bug. In TOO mode the JDAM gets coordinates from the aircraft designation point. There’s no reason to think this doesn’t happen in real time. If the designation moves, so does the JDAM target. Similarly, any active designation probably overwrites any stored coordinates, so pulling up a previously TOO targeted JDAM with an active designation should move the JDAM tgt to the current designation.

It’s a nice idea but I think we’re seeing that more complexity is not the answer. A simple return to the old readability would be fine.

Yeah there is no definite way to keep this from happening. Clearing fxo/metashaders, turning chimney smoke off, those may get it to stop temporarily, but after a few runs of DCS it always comes back

Watch the videos again. In WHOT it flashes white on the explosion, then the residual washout is a black background against white smoke. In DCS, if you look at smoke when in WHOT, the whole screen goes white when it should be dark against white smoke.

https://www.airuniversity.af.edu/Portals/10/AUPress/Books/B_0074_OWEN_DELIBERATE_FORCE.pdf Has a whole section on lessons learned regarding LGB employment in high winds. No mention of offsetting aim points, but in summary terminal end game lazing does not work in a high wind scenario, regardless of your fancy computer correcting for winds...

Were you using autolase? In the OP video it looks like laser starts firing at 10 seconds TTI. Against a moving target in high winds, that won’t cut it. Wind absolutely does affect lgb accuracy as has been demonstrated and documented multiple times in combat employment. I agree you don’t need to apply upwind lead to a stationary target, but you do need to change your lazing practice. Auto lase is probably not your friend in high winds.