AstonMartinDBS

Auch wenn ich (insb. aus Performancegründen) kein Freund von zusätzlicher Controller-Software bin, habe ich TARGET seit einigen Wochen problemlos in Verwendung, um mithilfe von Scripts (sh. https://forums.eagle.ru/showthread.php?t=210857) von der maximalen Funktionalität (jede einzelne Tasten-/Schalterposition ist als eigener Button gemappt) meines TM Warthog Throttle zu profitieren. TARGET verursacht auf meinem System (sh. Signatur) eine CPU-Last von < 1 %, das ist verkraftbar. Anfangs habe ich es auch mit dem Editieren der entsprechenden .lua versucht, was einerseits recht umständlich war und andererseits regelmäßige Pflege erfordert, da mit den offiziellen DCS-Updates Änderungen in den .lua-Files fallweise überschrieben werden. Man muss also quasi immer wieder Anpassungen vornehmen, um die manuell hinzugefügten Bindings wieder verfügbar zu machen. Die oben verlinkten Scripts musste ich hingegen lediglich einmal an meine Bedürfnisse anpassen (z. B. die TM TFRP vom Virtual Device ausschließen, da ich ausschließlich den Throttle über TARGET ansprechen will). Dann musste ich noch einmal jedes Muster für das Virtual Device konfigurieren, aber seit dem läuft alles und man läuft nicht Gefahr, dass man wieder mal in einer .lua herumfummeln muss, da nach einem Update wieder mal ein Binding futsch ist. Komplett falsche Einschätzung - sh. folgende Kommentare. Richtig, aber mithilfe des oben verlinkten Scripts wird das ursprüngliche Limit von 32 Buttons/8 Achsen umgangen und es können bis zu 120 Buttons/8 Achsen gemappt werden. Ebenso falsch. Durch Anpassung des Scripts können einzelne TM Controller vom Virtual Device ausgeschlossen werden, die dann - genauso wie ohne Verwendung von TARGET - in DCS direkt belegt werden können. DCS erkennt das Virtual Device sehr wohl, allerdings gibt es dafür keine vordefinierten Profile für die jeweiligen Muster. Man kann allerdings die vordefinierten Profile für bestimmte Eingabegeräte (z. B. TM Warthog Throttle) kopieren und entsprechend umbenennen, dann muss nicht das komplette Virtuelle Device in DCS, sondern nur die durch das Script zusätzlich generierten Buttons neu gemappt werden. Dass die Variante mit dem Editieren der .lua einfacher ist, würde ich nicht behaupten, da die auf Grund der DCS-Updates hin und wieder erneut angepasst werden müssen (sh. oben). Derartige Probleme hatte ich bislang noch nie. Ein einziges kleines Problemchen mit TARGET ließ sich aber nur durch einen Workaround lösen: Wenn TARGET nicht unmittelbar nach der Windows-Anmeldung gestartet wird, dann wird mein TM Warthog Throttle nicht aus der Liste der USB-Geräte entfernt und es gibt in DCS einen Konflikt, da sowohl die Eingaben vom Hardware- als auch vom Virtual-Device erkannt werden. Workaround: TARGET wird nun automatisch mit Windows gestartet und funktioniert somit wie beabsichtigt. Falls ich DCS nicht verwende, dann wird es eben manuell beendet... damit kann ich leben :)

With the today's OB Update 2.5.6.49718 the TGP got an Offset Cursor. Some things I found out so far: OPR - able to slew the TGP - TDC Depress = designates a target (i. e. transferring coordinates to selected JDAM station) [same behaviour as before] ATRK - unable to slew the TGP - TDC Depress = activates the offset cursor - Slew affects the cursor only - TDC Depress again = designates a target PTRK - works analogue to ATRK mode Undesignate doesn't undesignate a designated target anymore and the TGP stays in last position. I didn't find out, how to get the TGP back into boresight. Cage/Uncage stows the TGP @180° positon. I was also unable to re-designate (another) WP with the WPDSGN OSB via HSI. Last target designation seems to stay permanent. On a test run with 4 JDAMs on 4 stations (1 each) for 4 targets OPR mode worked as before. In ATRK mode (using the offset cursor for target designation) different coordinates have been transferred to each station but none of the 4 JDAMs hitted a target. I've forgot to save the track... :( It seems, the TGP is still tough WIP and I hope we'll get a tutorial soon.

Trees within the FARP are gone. Bug seems to be fixed. But it looks like in 3Star's first screenshot now (no trees far and wide). Is that Intended?

TGP ist still WIP. Let's wait for the next OB update (announced for 3rd June).

Try to follow the steps in Wags' tutorial:

Keep an eye on and all well be fine :)

Same here. Each request for refuelling on a FARP results in a crash. Current OB. 2 logs attached. dcs.log-20200525-185555.zip dcs.log-20200525-190703.zip

I know, but obviously it wasn't intended.

Due to the announcement in this thread the the Litening TGP shouldn't be able to AUTOLASE with the current OB. Hopefully the Litening will be completed with the next OB release as announced on 3rd June.

Here's the link to the Walleye tutorial from Wags: It's quite tricky to get a lock onto the desired target with the Walleye - the seeker needs a high contrast for a valid lock. Usually you'll use it for bigger targets (buildings). Altitude/distance depends especially on the target size and light conditions. I've got the best results at an altitude of ~25k ft or above.

Great idea! What about the "HARM Target Sequence / RAID / FLIR FOV" select button? Would be less critical than TRIGGER or PICKLE and never in use at takeoff or recovery. Currently I've bound the BALL CALL to IGN R @my Warthog Throttle, what means, that I have to remove my hand from the throttle shortly to send the ball call.

100 % agree! Please no further construction site!

According to https://forums.eagle.ru/showpost.php?p=4300736&postcount=185:

You can choose between sources in SP as well as in TOO mode. The main difference is AFAIK, that TOO mode uses the seeker from the HARM (viewing ahead/clearly arranged), and the SP mode the RWR (with it's 360° coverage) from the Hornet as source. I don't know, if there is any difference in accuracy between SP and TOO modes.

Did u request "ground power on" via radio menu prior to the following steps?

That worked for me well (several times).

The JDAMs are working as precise as usual - at least in TOO. But the announced features for the current OB are not working, or I'm doin' something wrong. Hard to say without any documentation/tutorial video.

Correct. The TRIG option is still available and manual lasing works after boxing TRIG; pressing trigger starts/stops lasing. For autolase it's not nessecary to box the TRIG option.

Great... :cry: But at least they've implemented AUTOLASE for the GBUs.

Yes, I miss something. Usually Wags presents new features shortly in front of the release. :(

Yeah! SA runs smooth again with driver version 445.75. Thx ED! :thumbup:

Yeah. By purchasing two other EA products from ED (Viper + SC) I supported the significant delay of developing the Hornet directly. So we could say it was our own fault, which resulted in the current situation. :music_whistling: As I purchased the Hornet in 02/2019 there was an appreciable progress in developing - until the Viper was released. And now our long expected SC swamps the developing resources. ED cannot deny this facts.

Hopefully they have at least fixed some bugs in the core when they don't bring new features for the Hornet. But I suspect, all energy went into the SC

A good question... I just tried to understand the style, how ED communicates with the (paying) community, but I failed obviously :( How should we understand this prase...? [...]will be delivered as expected (remember: expected was the "Completion of the Litening Targeting Pod"), but without five features...:megalol:

"to be delivered in next update" means to me clearly, that this feature has been already implemented and will become available with the next OB update. After 20th May we will know wether I was right or not. Let yourself be surprised and don't ask permanently if an already announced feature will be released or not ;)