Daggerfall Workshop Forums

Posted: **Thu Aug 15, 2019 10:24 pm**

Kick is downswipe and upswipe for hand-to-hand, so those are controllable when not using click-to-attack.

Posted: **Thu Aug 15, 2019 10:44 pm**

Jay_H wrote: ↑Thu Aug 15, 2019 10:24 pm Kick is downswipe and upswipe for hand-to-hand, so those are controllable when not using click-to-attack.

Posted: **Thu Aug 15, 2019 11:19 pm**

I plan on creating a seperate Ui menu for combat options. I want to make as many features flippable as possible, as I want to support the originalists as much as I can.

also, slowdown on swing would not be a complete lock, just a large movement debuff to make it harder to easily kite and cheese npcs. Instead, reward individuals who position themselves properly in combat by allowing them to still get out of range, but not allow you to easily run in, hit, run out like now.

Just found the weapon fatigue area. see how complex it is and find out how much want to mess with it.

Posted: **Fri Aug 16, 2019 2:03 am**

Ommamar wrote: ↑Thu Aug 15, 2019 10:21 pmI don't know about being locked in position when using an attack, one of the things I like about click to attack is I am more mobile when using it.

He didn't say locked viewpoint or movement, he simply said movement speed penalty during swing. It's worth trying.

Posted: **Fri Aug 16, 2019 2:40 am**

BansheeXYZ wrote: ↑Fri Aug 16, 2019 2:03 am
Ommamar wrote: ↑Thu Aug 15, 2019 10:21 pmI don't know about being locked in position when using an attack, one of the things I like about click to attack is I am more mobile when using it.
He didn't say locked viewpoint or movement, he simply said movement speed penalty during swing. It's worth trying.

Posted: **Fri Aug 16, 2019 4:06 pm**

Yeah, I think you're understanding it different than I am thinking about it. However, again, I want all options to be toggle ready, so if you don't like one thing, you can toggle it off.

Also, found an interesting inefficiency in the code I think. Will see if "fixing" it causes any unknown errors. However, the original engine was computing weapon range on every single frame processed because the variable assignment was in a constant void/static method that was always running. I can't find any reason for it to be this way, and that seems like super overkill. I now have the range computing at the beginning of weapon equip change for both left and right; anytime you equip a weapon from either hand, it should set the weapon range and store it until you equip a weapon again or switch hands.

Also, good news. Fatigue mechanism will be easy to work with. Right now, it is similar to combat. It is merely a constant float variable with 11 assigned to it. So, once I fix the fist bug from my range update. I plan on moving on to the fatigue mechanism and assign a dynamic variable that is based on the weapons rate and range, so large, heavy weapons will cost more to swing.

After that, I will then see if I can create a dynamic weapon speed system.

Once those 3 main components are working, then I will implement a new attack method system to allow players to choose the attack they use, like in skyrim and all modern melee fighting games. I plan on trying two different systems, once a chamber system similar to mordhau and the other the standard skyrim strafe+attack to choose direction.

If you don't know Mordhau, watch a youtube video to get an idea of what I'm thinking (of course simplified to a degree). You move your mouse slightly off the center of the screen and it automatically moves you into that chamber attack so when you attack it executes it; this decouples the choice from strafe/movement and assigns it all to the mouse and which direction from center screen your looking.

Posted: **Fri Aug 16, 2019 4:17 pm**

l3lessed wrote: ↑Fri Aug 16, 2019 4:06 pm Also, found an interesting inefficiency in the code I think. Will see if "fixing" it causes any unknown errors. However, the original engine was computing weapon range on every single frame processed because the variable assignment was in a constant void/static method that was always running. I can't find any reason for it to be this way, and that seems like super overkill. I now have the range computing at the beginning of every swing/attack instead of every single dam processed frame.

Likely to be compatible with players who step in and out of combat frequently. If I were running toward the enemy and my strike distance were calculated too far ahead, I could be nose-to-nose with the enemy and still out of range. Your method of making the PC near-stationary could preclude a need for that calculation, as you've observed.

Posted: **Fri Aug 16, 2019 4:38 pm**

hmmm, didn't think of it that way. It could be a way to ensure proper ray trace every frame, no matter where the player moves. if that is the case, I need to turn it back no matter what I do with my code. It is critical to ensure rays are being cast accurately every frame for good, responsive combat.

Thanks for pointing this out. Check the code. Easy fix either way.

However, when I look at the raycasting formula, it doesn't seem to need an updated range every frame. The raycasting is a static method being ran every frame so that the ray is being shot from the current player position. The weapon reach variable is merely telling the engine how long the detection hit ray should be. I do not see how having it calculated every frame helps the ray casting system at all. Only way it would be needed, I can see, is if you are having active effects modify range on the fly and middle of combat, then yes, we need range calculated every frame.

However, if the range is merely telling the ray fire how far the ray should be shot from the players current position to detect a melee hit / damage, what is the point of continually updating the range value every frame? Here's the code I am talking about. The players current position is telling the engine where the ray is coming from, not the weapons range. That is merely telling the engine how far the ray should go out to detect a hit.

Code: Select all

        private void MeleeDamage(FPSWeapon weapon, out bool hitEnemy)
        {
            hitEnemy = false;

            if (!mainCamera || !weapon)
                return;

            // Fire ray along player facing using weapon range
            // Origin point of ray is set back slightly to fix issue where strikes against enemy capsules touching player capsule do not connect
            RaycastHit hit;
            Ray ray = new Ray(mainCamera.transform.position + -mainCamera.transform.forward * 0.1f, mainCamera.transform.forward);
            if (Physics.SphereCast(ray, SphereCastRadius, out hit, weapon.Reach - SphereCastRadius))
            {
                hitEnemy = WeaponDamage(hit, mainCamera.transform.forward);
            }
        }

Posted: **Fri Aug 16, 2019 4:45 pm**

Here is where my range update code is embedded.

Code: Select all

void UpdateHands()
        {
            // Get current items
            DaggerfallUnityItem rightHandItem = playerEntity.ItemEquipTable.GetItem(EquipSlots.RightHand);
            DaggerfallUnityItem leftHandItem = playerEntity.ItemEquipTable.GetItem(EquipSlots.LeftHand);

            // Handle shields
            holdingShield = false;
            if (leftHandItem != null && leftHandItem.IsShield)
            {
                usingRightHand = true;
                holdingShield = true;
                leftHandItem = null;
            }

            // Right-hand item changed
            if (!DaggerfallUnityItem.CompareItems(currentRightHandWeapon, rightHandItem))
                currentRightHandWeapon = rightHandItem;

            // Left-hand item changed
            if (!DaggerfallUnityItem.CompareItems(currentLeftHandWeapon, leftHandItem))
                currentLeftHandWeapon = leftHandItem;

            if (EquipCountdownRightHand > 0)
            {
                EquipCountdownRightHand -= Time.deltaTime * 980; // Approximating classic update time based off measuring video
                if (EquipCountdownRightHand <= 0)
                {
                    EquipCountdownRightHand = 0;
                    //pulls weapons range from template using itemhelper script as passthrough
                    ScreenWeapon.Reach = ItemHelper.getItemRange(currentRightHandWeapon);
                    //outputs message of equiped hand and weapon range.
                    string message = HardStrings.rightHandEquipped;
                    DaggerfallUI.Instance.PopupMessage(message);
                    DaggerfallUI.Instance.PopupMessage("Weapon Range: " + ScreenWeapon.Reach.ToString() + "f");
                }
            }
            if (EquipCountdownLeftHand > 0)
            {
                EquipCountdownLeftHand -= Time.deltaTime * 980; // Approximating classic update time based off measuring video
                if (EquipCountdownLeftHand <= 0)
                {
                    EquipCountdownLeftHand = 0;
                    //pulls weapons range from template using itemhelper script as passthrough
                    ScreenWeapon.Reach = ItemHelper.getItemRange(currentLeftHandWeapon);
                    //outputs message of equiped hand and weapon range.
                    string message = HardStrings.leftHandEquipped;
                    DaggerfallUI.Instance.PopupMessage(message);
                    DaggerfallUI.Instance.PopupMessage("Weapon Range: " + ScreenWeapon.Reach.ToString() + "f");
                }
            }

            // Apply weapon settings
            ApplyWeapon();
        }

Daggerfall Workshop Forums

Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat

Re: Cracking Open Combat