Jump to content

Bankler

Members
  • Posts

    325
  • Joined

  • Last visited

2 Followers

About Bankler

  • Birthday 03/30/2020

Personal Information

  • Flight Simulators
    DCS
  • Location
    Sweden
  • Interests
    Flying, music, programming
  • Occupation
    Game developer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Repro * Create an O/S from a waypoint or markpoint * Set R MFD to FLIR * Set L MFD to something else, that can be set as SOI (Laser Maverick page for instance) * Press WPDSG * Press O/S * SCS RIght to set FLIR as SOI * TDC Depress to make the FLIR designating sensor (don't go into Scene or Auto, remain in default Pointed mode) * Use TDC to fine tune the aim point, looking at intended target * SCS Left to set Mav (or whatever) to SOI * BUG: The Tpod will now reset the designation to the initial O/S position, instead of remaining at your fine tuned designation Remarks * This makes the behaviour really awkward when firing an AGM-65E, since that missile requires you to change SOI to Uncage (and as a result of that, will drop the designation). Now you will have to switch back to FLIR again, to fine tune the aim one more time. * The bug occurs regardless how you switch SOI, it's not tied to Maverick or the left MFD. Switching to SOI to JHMCS or anything else also causes the designation to be reset. TRACK INCLUDED Let me know if you need any more details! Cheers! Hornet_Offset_SOI_Bug.trk
  2. Typically you'd put it into: C:\Users\[YourComputerName]\Saved Games\DCS.openbeta\Missions
  3. @BIGNEWY Additional finding: It seems to work fine if you're pulling around 2.5 G or so when launching. This way I have able to fire several salvos of 4. It's an awkward workaround, but might be good to know when trying to find the underlying issue.
  4. After successfully firing a AGM-84 in BOL mode, the missile starts tracking the ship, but flies over the target instead of into the target. Repro: A/G Mode, select HPD Approach target from S, heading N Wait for Harpoon alignment Fire the Harpoon The missile flies over the target and hits the water behind Remarks: Due to the (other) bug where Harpoon missiles sometimes (but not always) explodes in mid air after launch, the track (at least in my case) needed to be ran 4 times before it actually had the missile separate from the aircraft. It's not deterministic. It's a very short track though, so just try a couple of times and you'll probably see it. Harpoon_SP_NoHit_Bug_CloseRange.trk
  5. In that thread, @BIGNEWYmentions firing from above 20000'. That workaround does not work. I just fired from 20.600' and the aircraft exploded. I then tried 24000', same result. So altitude isn't necessarily a component in what's causing the bug to happen. Be advised that the behavior doesn't seem to be deterministic. When I played back the 24000' .trk, the aircraft didn't explode, but that is what happened when I recorded it. Then I tried playing the .trk again and this time the aircraft DID explode. This means whatever you record, might play differently in the .trk, and may also play diffrently each time you play the track. From my testing, they indeed do not seem to explode when fired in R/BL mode though. So that workaround seems fine. Harpoon_SP_AircraftDestroyed_24000_Bug.trk Harpoon_SP_AircraftDestroyed_21000_Bug.trk
  6. VERSION 7.1.0 2022 SPRING UPDATE!! Log file support available! You can now download version 7.1.0 in the Original Post! It's been a while since the last update. I haven't felt the need to fiddle around with it too much. Super happy for the over 3200 downloads of v7.0.0! However, a couple of patches ago, something changed with the Hornet's HSI and UFC implementation. Now, certain times when you box TCN (or WYPT) in the HSI, the A/P menu is brought up on the UFC. This was not the case before. This change made my auto-cockpit setup scripts a little wrong. When it pressed the UFC (button 4 from the top), instead of removing the time from HUD, it engaged RALT autopilot. If you didn't realise this happened, you probably wondered why the aircraft started behaving crazy until you tapped the paddle switch. This has now been fixed! While I was at it, I thought I'd take take a look at logging. This has been requested many times since I first released the mission in 2018. Finally, it has been implemented! As you might already know, by default, DCS prohibits missions from writing files to your disk, which is a good thing. In order to allow the mission to write the log file, you must remove (or comment) three lines in MissionScripting.lua. It's very important to understand that if you do this, you open up write access for EVERY mission. This means that if you download and run a mission from someone you don't trust, it might start creating millions of junk files on your disk. So, there you have it. Warning. Be careful if you decide to fiddle around with this stuff. What's cool though, is that if this is enabled, a file in your saved games dir (Logs/BanklersCase1RecoveryTrainer.log) is created and will log your passes. And if you're running this on a dedicated server, everyone's scores will be in there. This might come in handy to track your own progress, or if your squadron is using this for any kinds of competitions or qualifications. Thanks a lot for the love and support I received through the years. All the kind replies here, as well as PMs on the forum and on Discord means the world. It's just a great feeling being able to contribute with something to this great community! Cheers, Bankler CHANGE LOG 7.1.0 * The score summary is now written to dcs.log. * The score summary (with a date and time) is now also optionally written to a file Logs/BanklersCase1RecoveryTrainer.log (requires desanitizing of os, ios and lfs lua modules in MissionScripting.lua). * Fixed auto cockpit setup timing to account for new behavior where boxing TCN engages the A/P menu. This resolves the problem where the aircraft went into RALT A/P instead of disabling the HUD Time. * Fixed minor problems with auto cockpit setup where some MFD buttons were left in the pressed state. * Tomcats should now have the Carrier TCN set to default. * The initial message is now much shorter. * Airborne aircraft have been slightly moved in order to be properly lined up on the initial. Enjoy! PS. If you decide to enable write access to allow the log to be created (READ THE WARNING ABOVE FIRST!), this is how your MissionScripting.lua needs to look. The required changed is the "--" before the three sanitizeModule lines (which disables those lines). Be advised that it resets every time DCS is updated. --Initialization script for the Mission lua Environment (SSE) dofile('Scripts/ScriptingSystem.lua') --Sanitize Mission Scripting environment --This makes unavailable some unsecure functions. --Mission downloaded from server to client may contain potentialy harmful lua code that may use these functions. --You can remove the code below and make availble these functions at your own risk. local function sanitizeModule(name) _G[name] = nil package.loaded[name] = nil end do --sanitizeModule('os') --sanitizeModule('io') --sanitizeModule('lfs') _G['require'] = nil _G['loadlib'] = nil _G['package'] = nil end
  7. Completely agree! In our community we use human marshal/approach/lso. Having to deal with the comms menu is cumbersome and a little immersion breaking. We opt to not use ACLS at this point. Please disconnect it from the comms menu. Swift's suggestion is great imho! Just like Coyle pointed out, even without ACLS, at least one person currently has to call inbound for the lights to turn on. This is also a little annoying, but at least the workaround isn't that hard. I guess the ultimate solution would be to allow a player to simply instantly toggle them on/off at any point. Or a sledgehammer approach adding a mission editor advanced waypoint action "Force lights on" (would love an on/off clickbox for this for normal airfields also btw). EDIT: Also, tying ACLS to comms doesn't really makes sense in the first place. AFAIK aircraft near the carrier gets ACLS regardless if they come from the marshal stack, from a bolter pattern, or any other kind of funky approach.
  8. Here's a track, @NineLine! Hornet_DL_TACAN_Bug.trk
  9. Tested this. There seems to be a bug here. But there's more to it: 1) JackFlash, be advised you now have to press the D/L button twice before pressing ON. This is not a bug (or at least it's not likely a bug). The first page is the new ACLS related D/L stuff. 2) D/L (in my test) work as intended, if you enable it from the correct D/L menu. 3) Even if D/L is NOT enabled, you now get D/L contacts if your TACAN is on. This is likely a bug.
  10. This was marked "correct as is". Some elaboration would be nice. Should A/A TACAN mode *not* be used for airborne tankers? Note, I have no idea how it should work, but I'm a bit surprised. Is A/A mode only a figher-to-fighter yardstick thing then? EDIT: Okay, apparently it's not correct, but it's already reported here, with KC-135 pilots commenting (arguably not a super big deal perhaps, since the workaround with just deselecting A/A is simple, but sure, still wrong):
  11. Could you post those please, Harker? ED, this is still not fixed despite the error being confirmed by multiple Hornet pilots. And no quotes from your own SMEs. It's a quite annoying bug since it stops you from setting up mission critical things while on the ground. If you still doubt that it's currently wrongly implemented, please let us know what kind of evidence you need to be convinced.
  12. This is indeed bugged, but I still struggle to find a repro. Since the patch before last patch, the DL is super wonky when we play missions online on our dedicated server. The symptom is typically that you don't see your flight members. Sometimes not at all. Sometimes you see them as unknown friendly DL contacts, but without the A, B, C, D letters. These missions (or at least the base for them) were created before the last few patches. But if I create a clean miz and test to isolate the issue, everything seems to work as expected. Has anyone found any patterns? I have tried offline and online, with AI and with player clients, with and without AWACS. No luck so far. On new missions it seems to work. Will try to investigate further.
  13. Yes. And my bug report says that this doesn't happen if you have accidently touched the TDC directional stick before pressing TDC Depress. Please try it.
  14. This bug is related to: But I submitted a new one, since I have clear repro, and these repro steps haven't been mention, also they explain why the bug happens less frequently on some hardware. Also I have a short .trk illustrating the problem. Bug: If you move the TDC stick before pressing TDC depress, the ATFLIR will not go into INR (ground stabilized mode), but instead start drifting in some kind of snowplow manner the next time you move the TDC stick. Repro steps: 1) Nav or A/G mode. ATFLIR in ordinary "Pointed Mode" (i.e not Scene nor Auto Track) 2) Press WPDSG 3) Move the TDC stick a little (nothing will really happen, as expected) 4) Press TDC depress (nothing will happen, though INR is expected) 5) Move the TDC stick again and the image will start drifting Remarks: A) If you don't touch the TDC stick, but press depress right away, it works as intended. B) Depending on harware and bindings, it might be very hard to depress without accidently pushing the TDC stick to the side a little. For instance if using the stock TM Warthog mini stick for TDC with that depress binded to TDC Depress. If you bind the TDC Depress to a completely different button, you will not really run into the bug (except by following the steps above). This explains why the bug happens to some people only. Track: In the track, after the first WPDSG, I go immediately TDC Depress. Note how I go into INR with no problems. Next WPDSG, I first move the TDC a little (guess it doesn't really show in the track though). Notice how INR fails and the drift starts after I TDC Depress and then try to slew. Hornet_INR_Bug.trk
  15. Left wheel brake affects right wheel and right brake affects left wheel. The left binding correctly moves the left pedal in the cockpit as intended, but the right wheel is affected. AH-64D_WheelBrakeBug.trk
×
×
  • Create New...