twistking

my bad... did not read your post properly it seems...

I have enough hours in the Viper that i'm familiar with CCRP symbology. Maybe you are right though. The thing that i got hung up on, was the fact that the HARM is not targeting SPI, while a SPI is generated but not targeted by the the active weapon. That goes against the Viper's dogma of only having one sensor point. That's the "reason" that you can't slave around your TGP while in CCIP f.e. It would often be nice to do so, but it's not possible. HARM POS mode seems exceptional in this regard. I would have expected the TGP to lock on the steerpoint a.k.a. the location of the steerpoint being SPI.

@NineLine@BIGNEWY If this is not yet reported internally, can you move it to the bug section. seems to be confirmed, that it is indeed one. thanks.

related to this?

ok. now it also got moved into the bug section. hope it get fixed soon. i'd think that they can just copy the config from the normal AIM-9M and just tweak that part where it does (not) fire...

This would make a lot of sense. However i would guess, that in order to be configurable via data bus, the 103 and 105 would need to be equipped with a digital fuse that would allow that. I don't know if DCS models such a fuse, or if it uses the same fuse as on the 87 and 97... Anecdotally i can only say that i got better and more reliable effect on target when not changing the burst parameters in cockpit. Therefore i believe that the 103 and 105 use the same (manually set) fuse as the 87 and 97... I did not test this scientifically, so i could very well be wrong...

When seeing pictures of those vintage transports, i always think of some CIA shenanigans going down on a remote airstrip somewhere in Laos...

this would be a neat feature for the upcoming dynamic campaign. for single sortie missions it seems unnecessary.

Yes. That's working. Basic functionality is all there.

Thanks for the replies. I know about VAICOM and while i haven't tested it myself, i did have a look at some youtube-content of guys using it with Jester. Sure, it gets rid of the GUI, but i feel that the interaction is still very robotic. It's not terrible... but i guess "immersion" is very subjective. For me it did not click. On this forum, you'll find many people who think the same by the way, but this is not about right or wrong... On the other hand, if Heatblur could improve their AI even more, everybody would appreciate that i think. Even those of you, who are already happy with the current version. By the way, if you look at ED's VoIP FAQ, you'll see that ED are at least investigating native voice recognition in DCS: They list AI not reacting to voice commands as "known issues and future features". Sounds promising. Native voice would maybe allow Heatblur to push it a bit further in that direction. GUI could always be a backup for people without MIC.

Ooops, i must confess, that we did not check for that. If i remember correctly the GUI shows encryption status, but of course it could still be WIP...

thanks!

i think burst altitude is set by ground crew - not from the cockpit. until we can change cbu fuses from the rearm/fusing menu, you are advised to not touch fuse altitude in the cockpit, becuase you'll create a missmatch bewteen FCS and actual fuse setting. that's at least the last information i got. correct me, if this has changed recently.

If i IFF my buddy and get a response (green blib), the FCR will not correlate that to the radar contact. Track stays white, HUD target box does not change. If i IFF a bandit, the track will stay white. I'd have assumed that the track turned yellow (?)... If i IFF a bandit and do a succesful NCTR ident (Mig21 - obviously hostile), the track stays white. It should turn red... no? Intended behaviour? User error? A bug? Place your bets!

CAP-9M does not interface with the avionics in a meaningful way. Doesn't give a tone, doesn't track. I was under the impression that it does have a working seeker for training purposes. If so, i can't get it to activate. Is this intended behaviour? User error, or bug?

Hello Heatblur, my favorite American jets are probably the A-6, the F-14 and the F-4, so i should be very happy with your roadmap... However, after having tested the Tomcat during a free trial, i did not buy it, even though the visuals and simulation are obviously very good! I would even say, that Jester AI is "good", but it was still the thing that ruined the module for me. Ruined is a strong word and i want to stress that i think Jester implementation is decent in itself and i'm sure it was a lot of work to develop it. For my enjoyment it was simply not good enough... and this was my fear already when the module was still in development. Interacting with a module in DCS is - for me - the most immersive kind of interacting with any game or sim. Interacting with a slightly robotic Ai through a (necessarily) intricate GUI just takes so much away from it, that the magic of DCS just vanishes to some degree for me. Having a human RIO/WSO does probably turn that upside down, but you at Heatblur figured out early that this is not a satisfactorily solution (and i agree), otherwise you would not have put so much effort into Jester. I'd therefore wish that you'd improve your RIO AI even further by replacing the GUI with voice recognition and making the AI more human-like so that interacting it with it feels less mechanical. I am aware that thereby you'd push Jester beyond anything we've seen in the gaming/sim space concerning Ai interaction, but i think you are generally capable of pushing boundaries with your modules, while at the same time big advancements in AI make a humanlike virtual flight buddy seem a way more reasonable expectation than only a few years ago. Thanks for reading!

It is. Thanks!

I've only heard complaints and so was hesitant to test it myself, but now i can happily say, that it is actually rather good. If you haven't yet, give it a try! It doesn't have feature parity with external solutions yet, but what is there already works well. User experience is nothing short of excellent: Easy to set up. The ingame voice config overlay (strg+shift+Tab) is very well thought out and easy to use. To my surprise integration with the aircraft radios is already working flawlessly. A lot of things are still missing, but it's already fully useable and in our (admittedly quite small) test mission, we did not encounter any bugs. If you haven't already, give it a try. That's all i wanna say basically! Thanks.

you should always have an up-tp-date manual in the game files. i just use the windows search function on the DCS folder with *.pdf ro show all pdf-files.

+1

Yes, i guess you could call it smarter self defense; If you put higher values for engage distance, it would function more as a type of CAP though, that's why my suggestion called for a CAP task, but of course it would functionally equally well as a new ROE option. I think your suggestion of an modified search than engage task (that lets you define which part of the flightpath counts for the task) would solve the same general problem... only coming at it from a slightly different direction... I don't think that "maximum distance from waypoint" would be a good trigger to stop pursuit though. First of all it would need to be "max distance from flightpath", but that might break if flight is not actually travelling along its path, because of other scripts or task (switch waypoint, racetrack orbit, falling back towards path after any location based push task). I think it should be something relative to leader's current position. I think a smaller distance setting for cold bandits with some seconds of timeout would solve that actually... don't you think?

Thanks for the answer. I have found a workaround for now: Basically checking if player unit is still alive and if in certain conditions and then with timers for delay just concluding (guessing) that enemies must be dead (or retreated). Simple and good enough for what i need. Your post make me a bit more interested in getting to start with LUA. Do you know a simple tutorial that simply recreates some triggers from the "trigger block". Basically just like "if condition x, then make AI do y and set flag a to b"? Also is there a database with scripting commands? I'm relatively used to scripting for ARMA and for that there is a very nice offical glossary with every command, explanation and even user commands/examples. Anything even remotely similar for DCS? Thanks.

I can agree with most of what you say, but i think even mentioning gunship operations is a bit of a stretch: The only similarity is with the airframe. A gunship would surely be an easier sell to a broader audience (not saying that a transport won't sell - it's just a bit more niche, i'd guess). I would also argue that cargo helicopters are more engaging for "average" combat sim flying, because the flight profile is more engaging. It's easier to come up with missions that throw a chinook pilot in crazy and daring raids... If you want to keep it somewhat realistic, a C-130's mission profile will always be less "daring" -whatever you wanna call it- than a transport heli's could potentially be. Not trying to argue against fixed wing transports in DCS in case you wonder: I'd welcome a vintage transport plane. I just wanted to also make clear that i'm (personally) not completely sold on them... Just in case devs actually use these threads to gauge user interest.

A very small item, that would help a lot with mission creation: A "search and engage" task for CAP (but maybe also other tasking types) that is valid for a moving zone of definable size on the the group leader (alternatively for multiple zones of definable size with one for each group member). In practice this would mean that CAP would only search and engage targets near to the CAP flights position. A similar behaviour could be archieved by adding a new ROE option ("defend aggresively") where the group is only "weapons free" for targets within a certain range. The result would be the same, but i think it's more elegant to have this as a continuous Task type. In practice you would often want to combine this new task with f.e. a "search and engage in zone", but you could make the zone much smaller, since the flight would still be somewhat aggresive while cruising to it's CAP area. There is the obvious problem that a CAP zone moving with the group would mean that the CAP flight will never disengage unless the bandit group is fast enough to build distance quickly. This is not terrible, but ideally there was another parameter to control disengage criteria: This would need some creative thinking: Maybe the engagement radius for "cold" bandits could be set manually. If set very small, the CAP flight would be quicker in disengaging from bandits turning cold and not pursue them endlessly as would be otherwise. Again: The goal would be to have the AI in a defensive, but still somewhat aggresive stance (without going full berserk, as they would do with ROE "open fire"). Thanks.