Jump to content

Loophole

Members
  • Posts

    155
  • Joined

  • Last visited

Everything posted by Loophole

  1. I have to say I was also a little confused as to what I now had installed, as the folder is still named DCS Open Beta. After reading through some of the other threads I gather that it doesn't matter whether you are Open Beta or Stable; both update to the same version, and in the future they will do something about standardising the folder name. (but right now we can just carry on with whatever "branch" we were on, as they are both the same.
  2. Bug is still present in Feb 2024 - encountered while trying to STORE a target selected using the TADS from about 4km away. The stored position was consistently several hundred meters west of the targeted spot (ownship heading roughly 180 at the time). This is in the latest Open Beta build at the time.
  3. I couldn't find any other mention of the issue; my apologies if this is a re-post! I have noticed that the IAT function of the TADS - similar to many other optical targeting systems implemented in DCS, will only lock on to a live vehicle target. If the target is dead, it will no longer lock on (providing a cheaty way to determine if that dark blob is a live target or not). It also won't lock on to an arbitrary spot, even if that spot provides a nice contrast-y image (e.g. a house or a parked vehicle that is just a map object). Presumably this is all a limitation of the implementation; its simply checking if the TADS LOS is looking at a live unit in the unit list, not actually analysing the image. Simulating IAT "properly" would clearly be impractical, but given the effort put into so many other details in the sim it seems like perhaps some more work needs to be done on this mechanism, to bring it a bit closer to realistic behaviour? I'm thinking: - Lock on to vehicles regardless of whether they are alive or dead. - Lock on to any map object. - Lock on to arbitrary locations on the ground. If you wanted to get really clever you could do a quick & dirty analysis of the image rendered on the TADS (or other sight - I imagine this logic could eventually be ported to all optical sensor systems) to see if it has enough contrast to plausibly allow image tracking, but the cost-benefit of doing that is probably not worth it.
  4. The recent patch notes mentioned "FLIR. Moon looks more natural in FLIR devices.". While the moon's surface does indeed look awesome when closely examined in the AH-64D TADS, somebody seems to have put it in a box! See the attached image: It looks fine in normal TV mode, so I'm guessing its the new thermal texture isn't quite right?
  5. Ok, I re-did the test using my "normal" DCS configuration rather than the windowed setup I use for mission editing. I just used my standard control bindings in this case, as the previous test that I videoed seems to have eliminated "other bindings" as a potential source of the issue. This time the TRK file saved just fine - see attached. Let me know if there are any other tests or data you would like from me. POWERLEVER.trk When I replayed the Trk file it clearly reproduced the "jittering" I am seeing.
  6. I've captured a video showing both the physical actuation of the control, and the in-game response. For this I used a windowed copy of DCS, and explicitly cleared ALL bindings for all my HOTAS devices, then only bound the one axis to Power Lever (both); initially for just CPG, and then after confirming the issue still replicated I also bound it for the Pilot then captured this video. I was using the standard Instant-Action "Ready for Takeoff" mission, and running the Multi-Threaded open beta. I was not able to save a TRK file of the mission - when I tried to save it at the end it reported an error that it couldn't read the LastMission.trk file, and after checking in the reported folder I confirmed that the file did not exist - don't know what was going on there. I thought I would upload the video for you first, before trying to re-capture a TRK file. It will be interesting to see if a TRK captures the control jittering. Video file is here: https://www.dropbox.com/s/4ih0qyv3avuz7ru/VID_20231221_152649.mp4?dl=1 I forgot to attach the Config files I used in the above test, just in case they are relevant. Here they are... Input.zip
  7. @Lord Vader, thank you for releasing the new open beta a day earlier than expected. You didn't need to do it just because I asked, but I appreciate it! Sadly, the Power Lever issue seems to still be evident in the new open beta. George has also developed some piloting issues, but I'll start a new thread for that if nobody else has mentioned it yet.
  8. 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!
  9. 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...
  10. 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).
  11. 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!
  12. 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!
  13. 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!
  14. 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?
  15. 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.
  16. Just tested the latest Beta 2.8.5.40170 - sadly, George still thinks its not his responsibility to trim the aircraft before handover.
  17. 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.
  18. 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!
  19. 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.
  20. 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
  21. 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!
  22. 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/
  23. 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)
  24. 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.
  25. 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
×
×
  • Create New...