FAForever Forums
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Login
    The current pre-release of the client ("pioneer" in the version) is only compatible to itself. So you can only play with other testers. Please be aware!

    SMD Not Firing

    Scheduled Pinned Locked Moved Game Issues and Gameplay questions
    3 Posts 3 Posters 61 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R Offline
      Rama
      last edited by

      Had a survival game where SMD did not fire on correctly, allowing one to hit, even though there were multiple loaded SMD. People have warned that this has happened before, and to not trust the Mobile SMD unit.

      https://replay.faforever.com/27341539

      About 4 nukes were launched at fanatazgara, who had multiple loaded SMD, and one hit. There were also two loaded Mobile SMD in-range. I don't know how FAF decides what SMD fires on what nuke, when coverage overlaps. I was also in the game, and my Mobile SMD fired on incoming nukes, as did the stationary SMD nearby me.

      I don't know if the Mobile SMD unit is causing an issue and preventing stationary SMD from not firing. I tried recreating the issue in testing, but both Mobile and stationary SMD would fire properly.

      The Mobile SMD uses the following script.

      local SShieldHoverLandUnit = import('/lua/seraphimunits.lua').SShieldHoverLandUnit
      local SIFHuAntiNukeWeapon = import("/lua/seraphimweapons.lua").SIFHuAntiNukeWeapon
      --local nukeFiredOnGotTarget = false
      
      MANTINUKE = Class(SShieldHoverLandUnit) {
      
      	Weapons = {
              MissileRack = ClassWeapon(SIFHuAntiNukeWeapon) {
      
                  IdleState = State(SIFHuAntiNukeWeapon.IdleState) {
      
                      OnGotTarget = function(self)
                          local bp = self.Blueprint
                          if (bp.WeaponUnpackLockMotion != true or (bp.WeaponUnpackLocksMotion == true and not self.unit:IsUnitState('Moving'))) then
                              if (bp.CountedProjectile == false) or self:CanFire() then
                                   nukeFiredOnGotTarget = true
                              end
                          end
                          SIFHuAntiNukeWeapon.IdleState.OnGotTarget(self)
                      end,
      
                      OnFire = function(self)
                          if not nukeFiredOnGotTarget then
                              SIFHuAntiNukeWeapon.IdleState.OnFire(self)
                          end
                          nukeFiredOnGotTarget = false
      
                          self.Trash:Add(ForkThread(function()
                              self.unit:SetBusy(true)
                              WaitSeconds(1/self.unit.Blueprint.Weapon[1].RateOfFire + .2)
                              self.unit:SetBusy(false)
                          end,self))
                      end,
                  },
      		},
      	},
      

      I noticed that I'd commented out:
      local nukeFiredOnGotTarget = false

      I tried testing both with this line restored and tested with the line commented out, and the SMD behaved the same in both tests, as far as I could tell. Testing involved various combinations of stationary and mobile SMD interception swarms of nukes. Test were done without unit waves, just nukes, so much less going on during the tests than during a normal survival game.

      1 Reply Last reply Reply Quote 0
      • S Online
        Sprouto
        last edited by

        You hit the nail on the head - nukes have a targeting limit - and once targeted by a 'ready' anti-nuke, other anti-nukes will NOT fire at that missile. This is what keeps your anti-nukes from all firing at the first nuke to come in range.

        If however, that anti-nuke should miss - or be unready to fire - while still targeted on the nuke - you get this result.

        As I recall, going to Idle State will NOT break the target lock, leaving you vulnerable.

        1 Reply Last reply Reply Quote 0
        • N Offline
          Nomander Balance Team
          last edited by

          FAF uses the desired shooter cap to decide who gets to fire on what, which is engine behavior where once a weapon locks on to a target, it adds towards the cap, and weapons can't target entities whose shooter cap is full. The issue is that the weapon takes up the cap while it is targeting, so if it misses or is reloading then its still taking up the cap. We fixed these issues with TMDs; try using DisableWhileReloading = true (used by tmd) or TargetResetWhenReady = true (used by antitorps) in the weapon blueprint.

          1 Reply Last reply Reply Quote 0

          Hello! It looks like you're interested in this conversation, but you don't have an account yet.

          Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

          With your input, this post could be even better 💗

          Register Login
          • First post
            Last post