Loophole

Mate, I am *desperately* waiting for the next open beta! I want to get my hands on that FCR! I will also let you know how the power lever is behaving!

So, for the last few versions I have started to get an issue with the Power Levers when in the CPG cockpit: I have "Power: Both" bound to an analogue axis for AH-64D CP/G There is no other axis bound to that function for AH-64D CP/G There are no DirectX button binds for any of the Power Lever actions There are no axis binds or DirectX button binds for any of the Power Lever actions for AH-64D Pilot. The axis input shows as smooth and non-jittery under Tune Combo Axis, so I don't think there is any real noise. When the Power Lever axis is at 100%, the lever is stable and in the "Fly" position. If I position the Power Lever axis anywhere between 100% and 0%, the lever position in the cockpit jitters by maybe 10-20%, and always towards the FLY position from where I have the lever actually set. If I pull the Power Lever axis back to 0%, the Power Lever position jumps immediately up to the FLY position and stays there. It is acting as if some other binding is trying to push the lever to 100%, but as I said, there does not appear to be any other binding for that axis. Furthermore, if I remove the CPG binding, then go to the pilot position and re-bind the same axis in the same way for the pilot's Power Levers, they work fine and smoothly - the problem seems to be unique to the CPG position. I wonder if George-as-pilot might be trying to push the levers up to 100% when they shouldn't be allowed to? If while CPG I hand control over to George-as-pilot, he certainly does push the power levers back up to FLY immediately (but then I'd expect him to do that) My CPG axis bindings, just for reference...

It would be nice to see these issues resolved. A while ago I made a fun mission that involved tracking down and disabling a train, then landing troops to recover cargo from the undamaged carriages, but in the end had to shelve it because of the multiplayer issues with trains. (I tried switching the train for a truck convoy, but those idiots kept getting stuck on bridges or jamming on other AI vehicles).

The tooltip for the Improved Spotting Dot setting in the UI just says "$improvedSpottingDot_tooltip". That could probably be improved - maybe expanded to describe how the Improved Spotting Dot actually behaves? Thanks!

Oh yeah! As of DCS Open Beta 2.9.0.46801 George now trims the controls before handing them back to you! Hallelujah! It didn't make it into the release notes, but it did get fixed!

I recently spent some time learning the Mi-24, and guess what? Petrovich as pilot trims the controls before handing them back to you - so the Mi-24 works perfectly in that regard! So all that needs to be done for the Apache is exactly whatever was implemented for the Mi-24!

Checked the update 2.8.8.43489 - still no trim on handover from George as Pilot. It works fine if you hand over from a human pilot to a human CPG; it just needs George to click that "trim" button on handover. Surely that could be added and enabled through a "Special" settings option?

Just tested the latest Beta 2.8.7.42538, and George is still neglecting his responsibility to trim the aircraft before handover. The fact that it works for handover from human pilots shows that if the trim *was* set it would carry across correctly. All it probably needs is a single line of code in the 'handover' logic.

Just tested the latest Beta 2.8.5.40170 - sadly, George still thinks its not his responsibility to trim the aircraft before handover.

Sadly this doesn't seem to work for me. I set up a VA profile and bound the "C" keypress to a command. When George hands control back to me they still dump all the trim. Perhaps there is some other way to set this up, not using the keybind? Looking closer at the controls indicator in game I can see that the root of the problem is that George - being an AI with unlimited strength and stamina - actually doesn't use trim at all; they just hold the controls in the desired position - exactly the way that a human pilot doesn't. The trim is actually *not* dumped when George hands control back; it is dumped at the moment you hand control *over* to George. At the same time George perfectly matches your control positions and effortlessly takes over. Sadly, when it comes time to hand control back to you, you don't have George's magical ability to perfectly replicate the control positions, and the trim has been zeroed - hence the potential for loss of control. George just needs to press that "Trim" button before handing back control.

Does that work in the free version of VA? I'll have to try it. If it works I'd love to know how it manages it. I would have thought that in the end VA has to go through the same cockpit API that we use for keybinds, and for integrations like Helios and physical simpits. If there is some sequence of API calls that can achieve a trimmed handover from George then somebody please tell me so I can make use of them!

I just ran a test in the latest Open Beta version 2.8.4.38947. Although there have been some small changes around the controls indicator, and possibly a minor change to the handover behaviour, the issue in general still remains. What I observe now - and this might have always been the case, but I hadn't noticed before - is that when you take control back from George the controls remain in the position George had them. However, as soon as the tiniest input is received from any control it once again dumps all the trim. Since it is pretty much inevitable that you are going to be applying some tiny degree of stick deflection if you have your hands on the controls, it still ends up dumping all trim as soon as you ask for control back. Even if you manage not to move anything, you then have to review the control indicator and make a best-guess as to where you are going to have to (hurriedly) position the controls if you want to have any hope of retaining control. Hopefully this is just still a WIP, and we aren't seeing the final solution yet. What I hope gets implemented as the final solution - at least in "Instant Trim" trimmer mode - would be that: - George (effectively) hits their "Force Trim - Up" button prior to handing over control, and - That "Force Trim" setting is carried over to the CPG, i.e. so it acts as if the CPG had just pressed "Force Trim - Up" with their controls in that exact same position. Everything can then continue as normal. The effect should be that: - If the CPG has the cyclic and rudder close to neutral, the handover will have little to no disruption of the flight. The collective, however, would need to be adjusted to match - which is where it would help to have a 'ghost' mark persist on the Controls Indicator for a few seconds showing where George had it positioned. - If the CPG is desperately trying to initiate evasive action as they take control, those inputs will immediately be applied on top of George's trimmed control positions, hopefully resulting in the desired response without having to also fight to find the "trimmed" position. - Having "Ghost indicators" showing the CPG control positions while George is in control would be an added help; an ideal solution might include these in addition to the above behaviour. Apologies for the long post - I just want to be sure the developers have a clear understanding of the issue and of what a solution might look like.

The "Trim without moving stick" doesn't work, sadly; George sets all trim to zero as he hands over control. Unless I am very carefully prepared, there is a high probability I'll end up in an uncontrollable state. Since George has no clue about evading threats you need to really take control quickly when attacked, but mostly that seems to end in a n out-of-control situation

I encounter this handover-trim issue a lot, as I fly as CPG and use George as a glorified autopilot. I'll have to try the "hit trim without moving the stick" workaround, but the likelihood of my accidentally moving the stick while doing that is high. Having deadzones wouldn't suit my setup. However, it is interesting to note that this problem doesn't arise when handing control between a human pilot and a human CPG - in that case the stick trim settings seem to be carried across and it works great! I don't find adjusting the cyclic a much of an issue, though a 'ghost' indicator would be nice!

For those of you who use it - I have updated my little utility to include command-line support now. Hope you find it helpful! See: https://www.digitalcombatsimulator.com/en/files/3322208/

As of Jan. 2023, this issue seem to still be present. You cannot getGroup() on the event.initiator of a UNIT_LOST if the unit was a ground unit. Seems to work for aircraft (probably due to timing - the aircraft is likely still in the process of crashing and is still a valid unit)

I have a multimonitor setup, with a 3840x2160 above a 1920x1080. The default Controls Indicator generally never appears anywhere on screen for me, and I have to modify the ControlsIndicator_page.lua for every mod to change the base.init_pos as follows: base.init_pos = {0,0.5} -- {0,-(1 - 1.5*size)} This sets the indicator in the middle-left of the main screen, for me. The kneeboard is also poorly positioned, being partially off-screen in the lower-right corner - but at least I can drag that into view.

I'm also encountering multiplayer problems with non-late-activated trains. I've spent several weeks developing a train-attack mission and testing parts of it with a friend, and it worked fine. Tried running it with 6-7 people and only half of them could see the train. Indeed, in that test even I *as the mission host* could not see the train - though I could see the smoke where the train apparently was, once somebody (who could see it) had disabled it, and the scripts that caused troops to deploy from the damaged train also worked. Mission example: https://www.dropbox.com/s/vgymc6bhb6l7vbm/Great Train Heist v0.miz?dl=1

Train synchronization seems to be erratic in multiplayer. I've spent several weeks developing a train-attack mission and testing parts of it with a friend, and it worked fine. Tried running it with 6-7 people and only half of them could see the train. Indeed, even I *as the mission host* could not see the train - though I could see the smoke where it was supposed to be, and the scripts that caused troops to deploy from the damaged train apparently also worked.

groupObj:getUnits() for a train group only ever returns one unitObj, even if the train consists of multiple carriages. Yet events like hit or dead will return different unitObj for different carriages in the train.

Sigh. Still an issue in 2023...

If '...' is the Group object, then in theory you should also be able to do something like: ...:destroy() or even ....destroy(...) which makes me shudder to even write! (and probably wouldn't parse anyway!) I think Grime's recommendation is good, and I'd be able to sleep at night writing code that way. Thank you for the confirmation! @Grimes, Do you know if '...' is only available in scripts run as Advanced Waypoint actions of a Group? Or is it also available in scripts executed by the Triggered Actions of a Group?

@Elphaba - sorry, but I can't see how that works. As I understand it, the text we put into the script specified in the "Run Script" is itself actually a function - we just don't have any visibility to the "function XXX(yyy) ... end that wraps it. My understanding of the above tooltip is that this wrapper has some (yyy) parameter passed, with the Group of the triggering unit - but in order to access it, we'd need to know its name. E.g. we should be able to do something like below, if we knew what name to use in place of "thisGroup" Indeed, maybe the magic name is "this"? Hmm, or maybe it uses the LUA vararg construct - "..." So the script could be: Group.destroy(...) That rings a bell from something I read several years ago. I'll have to run some tests on that one!

I just discovered an amazingly useful feature in the mission editor! When you set an Advanced Waypoint Action, and select "Perform Command" -> "Run Script", according to the tooltip, you can access the Group of the triggering unit as a parameter passed in to the script! This is amazingly useful. There is so much that could be done with this! ... at least, there *would* be, if there was any documentation as to WHAT THIS PARAMETER IS CALLED! Maybe its "_"? Maybe its not! I could start at "a" and work my way through to "zzzzz99999" until I hit on the correct variable name - or maybe Eagle Dynamics could actually write it down in a manual somewhere? Or add some text to the ME UI? Pretty please?? Just teasing us that there is a variable that we *could* use if only they told us what it was is just plain cruel!

Currently the "Link Unit" feature appears to only allows you to link Static Objects to Ship Units. I guess it was created specifically to allow placement of static decorations on the decks of moving carriers. However, there are more things that could be done with the feature if it allowed it: Link active Ground Units to Ships; allowing mission designers to add AAA defences to cargo ships, or even park live tank battalions on carrier decks. Naturally such linked units would not be allowed to have waypoints of their own, and would need to be blocked from any sort of movement (no dispersing when under attack, etc) Link active Ground Units to Trains. Now that trains can be created in the mission editor, it would be nice to be able to attach AAA defences to them, or even mount an artillery unit to simulate one of those WW2 train-mounted cannons. Link Statics to active Ground Units. Now I really don't know why you would want to do this, but the idea of being able to attach a building to an APC and having it driving around the map just has to be a good idea!