shagrat

Won't work, as some parts of the dead event has changed since a while.

DCS places them on top of objects, as long as the icon is on top of a shelter etc. You can try to move the center icon just outside the shelter. Works at least with static aircraft.

Could solve it with some help from the guys over at MOOSE. You need to use the eventdata.initiator:getPoint() on the dead event now. Seems the ID still points to the right object. This still isn't perfect, but good enough for now.

I'll check if this will do the trick. Though I think it would be a brilliant idea for ED to simply fire one of the three events related to dying units before(!) that change happens and thus give us a chance to extract relevant data from the database with the getGroup(), getPoint() etc. functions.

This is really breaking a lot of stuff. I use landmines in a couple missions, to "kill" patrols of vehicles randomly roaming the area. In the past, I simply used the dead event and verified the coalition and then fetched the unit and used getPoint() to spawn casualties for MEDEVAC and or defending ground troops and ambushes etc. based on the location of the dead/killed unit(!). This does no longer work, as a lot of the get-functions do no longer work? Can't we just get one(!) event that fires before that change to static happens? Maybe s_event_unit_lost or s_event_kill and then switch to the static object and fire the dead event? This is utterly frustrating and as others pointed out, it affects a lot of useful scripts in mission building and especially more dynamic multiplayer missions. I can't see, why this is difficult to fix, we just need one of the three(!) events related to a dying/dead unit to remain the information to provide with getGroup(), getCategory(), getPoint(), getTypeName(), getAttributes() etc. Please, give us a way to monitor and use dead units in scripts, again, without crazy workarounds ( to monitor position before a dead event we would need to update the position A LOT and that's definitely hitting performance, especially in larger MP missions).

Thanks. That's brutal. The script should monitor events, as it is intended for MP missions with large amount of randomized patrols that are dynamically spawned. Storing position updates on hit events is incredible inconvenient. I would rather hope @Eagle Dynamics could fire the s_event_unit_lost, when the unit is still part of the group, position information is in the database and give us time to store the position and other stuff like the parent group in variables, before the data/reference is purged and s_event_dead and/or s_event_kill are fired. Just give us a chance to store the necessary info with getPoint(), get group() etc. the moment a unit is lost before purging the unit/related data and fire the next event.

I try to get the point from a Unit that has run into a landmine and exploded. I want to spawn casualties and an ambush around that point. But it seems I can no longer get the point with Unit.getByName(initiator.name):get point(). Neither with s_event_dead, s_event_kill or s_event_unit_lost. (Did switch to target, where necessary). Does anyone have any idea how to get the point/coordinates from a dead object? I am at a total loss. If I am not suffering from dementia this worked with the dead event a couple years ago!

What a legend! RIP.

Ensure you have TADS as acquisition source.

That would be very helpful for newcomers, especially, but also help compare between setups. I am on the fence, with a Pico4 and getting an idea of the settings would help, a lot.

A normal dual-throttle is perfect. As Yurgon already mentioned, you actually use the 2+2 throttle setup as left + right engines and other than in an emergency (engine failure) you use them like on any dual engine aircraft. There are no additional reverse thrust levers, or flaps levers so our typical trusty Warthog or Virpil throttle works pretty well. Edit: to be clear, there are flaps levers, but they are separate from (behind) the throttle quadrant.

Actually it's the PTT button disabling the squelch filter and static coming through, as the gain opens, until the voice triggers the ducking, but yep, that's the effect we need.

It's a "click", the "beep" is on a digital radio with encryption. Edit: private message? I may get Alzheimer's

That's fine, until you are in the front seat and grab the TEDAC controls, instead of flying the helicopter. You either let go of your stick to grab the controller/or other controls assigned to the TEDAC grips, or you use the stick as part of the TEDAC grips/controls. Either way you are likely not able to keep the physical stick in the position that George will put it in, when he hovers/flys the aircraft. As soon as you request the controls again, your physical inputs do no longer match the input George used to control the aircraft. If the controls position George put in would be either trimmed (so you could simply trim reset to go back to untrimmed) or gradually move to your physical stick position like if you hold the force trim release, this would at least smooth the violent jerking of the controls. As always a way to make this an option to choose as personal preference may differ would be the perfect solution.

In real life there's an audible click/hiss/crack/beep/feep/bleep... whatever, when the squelch threshold opens and closes. A sound that is audible, whenever the radio transmits and even when the pilot simply presses the PTT. There was even a common practice in real live to simply acknowledge a transmission, by quickly giving two clicks with the PTT switch. If I am not mistaken the encrypted (digital) radios even use a signalling sound to indicate the channel is secure... That's what people refer to as a the "beep" or "click" that's needed. And that's pretty much what real life radios do.

Really easy would be to have a Head Mounted Display with a Display-Port, using a cable to display content on the screens, instead of hoops & loops to jump through, to get it to work. The Pico 4 had me on the fence myself, to try VR, again (First try was an Oculus Rift, but motion sickness on top of screen door effect and sh... resolution and FOV made me go back). Reading about the setup with Steam, SteamVR maybe OpenXR, oh and composite or a toolkit, gives me the creeps. Add the confusion about the connection options with Streaming Assistant, VR Desktop and now ALVR, I am reconsidering to NOT go through all this laboratory setup and experimentation phase. I read DCS now supports OpenXR native, the Pico 4 now supports OpenXR, as well. Is there at least a way to get rid of Steam (I do not want Steam/Valve Store, Origin Rootkit, EA tracker, UbiSoft spy etc. on my PC) and install something similar to a good old "driver" (VR composer) and connect the Pico 4 headset through a cable?

The in-game OSB buttons are basically hard coded into the cougar MFD Lua files, so as soon as DCS detects a cougar MFD 1 the only buttons you can bind are Left MFCD OSB 1-20 and the ADJ, BRT, SYM and CON rockers.

It's not "what the USMC use", but what can be safely loaded together on neighboring stations... Personally, I would prefer to be able to load everything that fits on the racks and model separation issues, flutter/vibrations, collisions etc. so you damage the plane or blow yourself up, if you don't follow safe loadout restrictions. But I guess the "bug" report flood and need to explain/train loadout limitations is more pain, than putting predefined "proper" loadouts reflecting safe loadouts.

I have created a separate bug report for this topic and linked to the discussion here: https://forum.dcs.world/topic/323021-cannot-create-offsets-for-markpoints-odu-select-option-switches-to-tgpt-instead/#comment-5188796

After you created a markpoint (MPD OSB "MK0-10") you can not create an offset for it. To reproduce (tested in 2.8 MT): - SSS down twice to activate DMT in TV - slew DMT over any ground feature and designate - press the OSB labeled "MK0" on the EHSD to create a markpoint (M0) or press multiple times to create M1-xx (tested with M1 as well) - press and hold WINC or OSB option select until Quick Access menu is showing on the ODU - select ":MKPT", enter No. on scratchpad ("0" the markpoint you have created), press "ENT" and verify the EHSD shows "M0" between the arrows - press OSB "DATA" to edit the markpoint. ODU option 1 will show ":WYPT" - press OSB select 1 and it will switch from ":WYPT" to ":TGPT"(!) instead of the correct ":WO/S". It should be the same offset functionality, as is already implemented for waypoints. So if pressing OSB select 1 it should switch to ":WO/S" and show the "BRG", "ELEV", "RNG", "UTM" entries for the offset, not switch to ":TGPT" (as this is performed by selecting WYPT or WO/S and pressing DESG on the EHSD. I link a video (not mine) for details. Discussion leading to this bug report here: Markpoint offset discussion https://youtu.be/ErWQoFJzZ9A

Yes, that is correct AND as in the real aircraft. And if you think about it, where would you have use for an offset(!) of 100NM or more, instead of creating a proper waypoint? At 300kts it would take you about 20 minutes to fly from your "offset" to the waypoint. As for limiting an offset for an explosive weapon to 100m, does make a lot of sense, considering minimum safe distance for "danger close" drops is at least on paper more than 100m for any A/G weapon I can think of.

Can confirm, it's not implemented, correctly. ODU option switches between MKPT and TGPT instead of offset.

It's a while since I programmed way/markpoints in the AV-8B, but it should switch the ODU option from :WYPT to :WO/S, if you are in DATA mode. Select the markpoint (it's just a specifically named waypoint) on the right between the up/down arrows and box DATA. Now the ODU option 1 should display :WYPT. Press the option select button 1 and it should say :WO/S. If that's not showing, it is not correct/a bug/missing. Range for offset should be recognized during entry as meters (if you enter an integer higher than 100) and as NM if equal or below 100. Note NM can have decimals for fractions of a mile. Pressing the associated option select button for RNG should cycle the display entry between NM and meters, for verification/or conversion. I may find the time tomorrow to verify this and try myself, but that is how it should work.

Yeah, sorry. The wording is a bit misleading, in this case. Targetpoints in the mission computer are typically designations for weapons. I was more thinking in the direction of a "target" waypoint of a preplanned flightplan, where the point (target location) is a landmark you can easily recognize and then use the offset to designate the actual target. Creating a Target Point via TOO (T1, T2... Tn) creates target coordinates for weapons release. Typically waypoints and offset as a target designation will be preplanned. Think of a flight of four strikers that follow a route to a target. They approach a planned, easy recognizable waypoint like a landmark (e.g. a big tower) and now have to pop up and drop on 4 different DMPI (e.g. 4 different buildings in the area of the tower), each aircraft will have his individual offset for the target designation, but the tower as the waypoint. Each pilot switches to his offset and designates and gets attack cues for his target. Then all aircraft steer to the egress waypoint in their flightplan and get the hell outta Dodge. For a target of opportunity like that smoke marker, you want to use the Markpoints (OSB on the HSD bottom row labeled "MK1" ( MK and next free markpoint no.) A markpoint can have an offset, too, so you could mark the smoke, or a building, or a crossing, where allied forces are taking cover and enter a Bearing-Range as an offset point, to designate the actual target, if they radio "Enemy position 800 meters, bearing 170".

The major improvement is likely related to the immense increase in fps through the introduction of MultiThreading. Now, what has fps to do with the flight model? Nothing, but it impacts the visual feedback loop between corrective movement of the cyclic stick (joystick) in your hand and noticable reaction on the screen. Say we had 40 fps before and now stable 80 fps. For subconscious corrections you typically do with the cyclic to stabilize the helicopter it takes now half the time (actually time between frame changes, but let's simply say "time") to get a visual recognizable feedback on the screen. The movement seen on the screen is smoother and way more granular. 1/40th of a second vs. 1/80th of a second. As for us sim-pilots there is no feedback from our inner ears movement sensor, but only the very limited 70-90° visual feedback of the screen, without peripheral vision, this "feels" now like the inputs are more controllable/smooth and responsive. ...and of course the fact we now fly the Apache for quite some time and training and muscle memory getting better. From my personal experience now my confidence will increase, I get a bit too cocky until I mess up more regular, again and increase my experience in addition to a good muscle memory and instinct, which let's me omit precarious situations before I am required to test my confidence and muscle memory in the first place.