shagrat

For whatever reason DCS does not like "Switched Condition" with "Do Script". I changed the Script trigger to "Contineous" and added an else condition to the script. local varUnit = Unit.getByName("CH47player") if varUnit:getDrawArgumentValue(86) >0.5 then trigger.action.setUserFlag("DOOR",1) else trigger.action.setUserFlag("DOOR",0) end Then two separate "switched condition" for the appropriate Flag "DOOR" is 1 (ramp lowered) and Flag "DOOR" is 0 (ramp raised)... But easier to see for yourself. I attach the MIZ file so you can see what exactly I did there. TEST_CH47_RAMP_TRIGGER.miz

Yes, and especially more of the map buildings! That would allow to add "specific target buildings" that actually blend in with the environment. The currently available "static buildings" for any of the middle eastern/afghan environment are absolutely outdated and stick out like a sore thumb. In addition it would be incredible to have at least a couple of the "AI traffic vehicles" available for mission creators to add deliberate "civilian" traffic or simulate VBIEDs that blend into the traffic, until they behave suspicious, etc. ...and just one(!) insurgent model without a weapon in his hand, that allows mission creators to enforce consequences Rules Of Engagements. ED, pretty please?

The default invite link for discord expires after 7 days. You can edit to "never", if you click on the "Edit invite link".

You can simply put the code into a switched condition "do script" trigger and use the Flag is true "DOOR" to do stuff like Message to coalition/group etc. Just reset the flag with a "set flag false" in the trigger, if you need to track multiple uses of the ramp. You only need to add the UNITNAME to the script in the get.unitByName("unitname") part. The moment the ramp is lowered more than half it should trigger the "DOOR" Flag as true.

You can use the Lua Script function "getDrawArgumentValue" to check a model argument. local varUnit = Unit.getByName("theCH-47s unitname here") if varUnit:getDrawArgumentValue(86) > 0.5 then trigger.action.setUserFlag("DOOR", 1) end Now you can use the Flag "DOOR" to trigger things as usual e.g. send messages etc. Reset the Flag by setting it to 0. Not tested, but should work.

Thanks for investing your time into the community. It's so incredibly helpful to get these infos first hand and "unfiltered" and have someone for questions, that come up.

Perfect stereotypical white caucasian males... John from Oklahoma and Bob from Wisconsin. We could argue the underrepresentation of the multicultural society of all kinds of ethnicities that is representative for the modern US, though.

The noise wasn't there a couple updates, ago. Same Mission. So no. It's not a beacon, or issue with something on the map. It typically happens, after a transmission per script is triggered and finished, as if the sender keeps the microphone open. Though it is not related to the squelch settings, from what I could check, so far.

Since some updates a triggered radio transmission will start to produce a static noise on the radio frequency selected, as if the sender doesn't stop transmitting. It is not related to squelch settings. In the AH-64D the noise can't be stopped by pulling the knob (radio to off). Master Volume affects the static noise, but not individual radio volumes. Only if you switch the frequency the static noise stops (so I suspect it is related to the specific frequency used in the trigger).

Can only say for the VPforce Rhino with TelemFFB, as that's what I have. There is no ForceTrim, yet (Emulation of the Centering Spring). What I get is the dampening effect like you would feel if moving the cyclic against the hydraulic fluid. TelemFFB (export of events from DCS) recognizes it as a helicopter and applies effects, like deceleration when hitting the brakes or rotor rumble and ETL.

There is FFB, though it is only the basic stuff. At least with the VPforce Rhino I have the dampening (hydraulic) stays in place and the generic helicopter effects through TelemFFB.

Up to 1.5 tons internal cargo capacity or up to 2 tons external as slingload seems to make a lot of sense to me...

Evtl. die Throttle-Achse(n) auf den/die Schubhebel-Achse(n) gemapped und in der Idle oder Cutoff position? Ich hab das, wenn ich bspw. nach dem Landen, alles ordentlich abschalte und die Throttle auf "Cutoff" stehen habe. Sobald man dann, beim nächsten DCS-Flug in einen Air- oder Hotstart springt, synchronisiert mein Virpil-Throttle die Achsen und die springen auf IDLE, bzw. Cutoff und die Triebwerke gehen aus. Ist man schnell genug, und schiebt die Schubhebel auf 100% ist nur das GPS unaligned (aligned aber innerhalb von ein paar Minuten) aber die Triebwerke kommen zügig und die Generatoren liefern Strom.

Pretty much answers everything itself, I gues...

In Google earth timeline 2010 you can clearly see Chinook Helicopters parked on the Pegasus ramp at Bastion Heliport. Currently those slots only allow smaller helicopters, to be placed. No big issue, but it would be cool to be fixed. So we can use the slots for the coming Chinook and already place blocking CH-47D on those slots.

Yeah, the Flight map is misspelled, it should actually be Girishk. That's a common problem with american translation to US English phonems. But at least it is a realistic representation.

Als Beispiel wurde hier von ED auf die Normandy 2.0 Map verwiesen. Im Multiplayer ist sie zu Normandy(1.0) kompatibel, es sind aber mit der 1.0 nur die niedrigen Texturen zu sehen und die Gebäude, obwohl alle vorhanden, nutzen eben das Klötzchen LOD ohne Details für die Teile der Map, die man nicht erworben hat. Es wird also ein "3. Gebäude von links" geben, aber ob ein Talk on mit "das Gebäude mit dem Flachdach an der Ostseite" funktioniert, oder "hinter dem Gebäude mit den Drei Fenstern an der Nordseite"... vermutlich eher nicht. Wobei ich denke gerade diese Map lohnt eben extrem als ganze Map, weil sie am Ende ein Riesengebiet abdecken wird.

Because, that file, may be multiple files, does exist in a framework and uses an API to get/send data from/to the DCS environment etc. or a bunch of other potential issues...

...and you are 100% sure that specific fix isn't causing one of the game breaking issues? So you can assure us ALL other modules are fine, if they do that? Or should they, maybe look at it and do some testing before rushing it out? Just saying...

...and in that exact post(s) he mentioned, he now has time to UPDATE the missions with the new assets. I guess that means he worked on the campaigns, added maybe a bit more than just a tent here and there and put the results into the branch for the current patch? And that's where he and the campaign testers likely tested the triggers work, the AI buddies don't kill you on taxiways, etc.

LOL I am waiting for Afghanistan since "DCS: A-10C Warthog public beta" back in 2009/10... So next week or in two weeks, we will get there.

That's how bugs make it into releases... And yes, they need to compile at least one new build and test/QA it with the beta testers if the bugs are fixed and no new critical bugs are introduced. So splitting this into two releases only adds more workload.

That doesn't work, as it means compiling a build minus with the campaigns and the current (!) DCS version that needs to be tested, to ensure the Campaigns at least work somehow decent enough... and that's assuming the Missions don't use any new script/trigger feature that requires the new build... The eternal circle of development hell.

That exactly was my suggestion. It's not even too many "irons", it's the self imposed pressure of release dates, way before a release is ready to be released. That doesn't mean there won't be any bugs in the patch, but it will stop the drama...

Not if there is no announcement that there is a plan. It will work for future patches. Simply announce a date AFTER you have a tested and release ready patch. ED could even delay the patch for weeks if necessary and as soon as they have a patch ready announce the "planned" release of that exact build in a week from then. The development isn't impacted as that is done in seperate branches anyway. Thus no delays, patch will always drop on the planned release date a week after it is done.