Daggerfall Workshop Forums

l3lessed wrote: ↑Sun Sep 15, 2019 5:24 am Looky, Looky. Determination and some basic ingenuity can pay off. This is just a technical first attempt, so there is frame stepping. I show the issue off on purpose with some animations. This can be fixed easily with some number adjustments and y coordinate adjustments for the offsets.

Outside the frame stepping, it should match 60 fps. It is running 12 offset frames for each animation frame. There are 5 animation frames. 5 * 12 = 60 frame updates.

Thoughts, feedback, what ya think?

Looks great! Looking forward to see the final result

Here is my second pass. Most noticeable frame jumping has been dealt with with all sword weapons, and majority of war hammer. I mainly wanted to test and ensure this could be implemented for all attack types, even the downward ones, which have tall slender frame sizes and lots of cut off sprites. Didn't want to dump tons of time into something not worth it, especially because this will be replaced one day with 3d models; its just a question of when.

I ended up hijacking, yet again, one of the stab animations, and using it for the first two frames of the downward attack. This dealt with the issue of cutoff sprites appearing on those frames. And using a good offset formula, the frame transition is not noticeable in my opinion. Looks like part of the animation.

I also experimented with creating a new, more realistic stab animation. This means, you will actually pull your weapon into your body first to prep for a proper stab/trust, after a short moment, you will stab forward at an accelerated rate.

Check out this video to see it in action.


Now, on to the boring grueling stuff, coding optimization, raycasting offset programming, debugging, and finish smooth animations.

One issue I'm terrified of and have avoided is the weapon enchantment animations and how may coding hack won't work properly with them. I have yet to figure out a solution in my head to properly animate the enchantment effect while using the proper stab and weapon bob frames/sprites for my offset frames/trickery. The idle weapon bob animation will use a attack enchantment frame instead of the default glowing one showing the static crackling effect. Also, the stab animations rely on a single frame, so the enchantment animation won't change on stab attacks and will show a static crackle enchantment effect.

If this works with modded weapons than my DREAM weapons have static aura around the magic weapons. So that will work at least:) very nice progress!

Oh, great. Yes, this is all hard coded directly into the fpsweapon script. I have not modified one sprite or animation. So, whatever replaces the original sprites/art should run this just fine, including your hd sprites.

I've merely hijacked certain frames and rammed them into the animation loops, and I only did that for a few frames/animations that had cutoff issues.
The left and right attack animations are 100% default animation with offset frames added between the original sprites.
The downward one just hijacks the first two frames and uses a stab sprite in place to deal with cutoff issues.
The stab animation will be the problem, as it uses one sprite only and just offsets it the whole animation; this will lead to a single static sprite during stab attacks. I'm going to have to find a way to get in all stab frames while dealing with cutoff issues offsetting causes them.

This was intentional, as I wanted to ensure this would work with any mod that is replacing default weapon sprites. As long as the sprites largely follow the same animation look and path, there should not be any real frame stepping. It will only be an issue if you make large changes to the actual animation weapon paths, as the offset formulas are programmed for the default sprite animation placement.

This is very clever solution, really impressive work!

I'm hoping one day to see bounce back (quickly reversed) animations for blocked attacks.

That would be an easy trigger to put in.

But what do you even mean by "blocked" attacks? Default DF unity has no "block" mechanism in any traditional sense. It is all based on a mere 100 dice roll probability. The better you are at a skill, the less likely you roll the 100 dice below your skill level, and the higher chance you succeed.

Combat is no different. At the end of everything, it comes down to a mere 100 dice roll. If that dice roll is lower than your current skill level, you hit. If not, you miss (even if you hit them with the actual raycast hit detection). It actually drives me insane now, despite me not having an issue with it as a kid when I first played this game. However, in modern gaming, it is so confusing at times. Did I hit the actual target and just miss my dice role? Did I completely miss the target? It's actually horrible design, as it creates a confusing feedback system that doesn't clearly tell the player what is happening on attacks.

Anyways, right now, all attacks, on successfully hitting an object (doesn't matter if the 100 dice role is a success or not) the sword recoil animation and system kicks in. No one, no matter what movies and shows show, can cut clean through a body and continue their attack. Neck/decaps are about the only real life exception, and those are still rare, as the blade has to hit between the vertebrae to detached the spine completely and allow the blade to continue. If the blade is off by a few centimeters, it will hit a spinal bone and lose most its momentum and energy forcing the attacker to pull the weapon straight out.

Blocked as in failed to penetrate armor or was parried. A dodged attack would not bounce back. I'm unsure how DFU handles these things but you can hear a clang as a weapon is blocked. Thinking about it, it would be a good idea to vary somewhat, where in the animation sequence a block occurs by a small amount.

I think what you are talking about is when you actually land the raytrace on an enemy hit box but fail the 100 sided dice roll that proceeds. In traditional DF, armor/shields do nothing but add to your hit chance making it harder for an enemy to actually hit you when they roll their 100 dice chance (I know, sounds backwards, but it isn't).

When you hear that sound, what is happening on the back end, is your are getting a successful raycast hit. So the game sends out a line in front of you to simulate a weapon, then registered you aimed properly and hit the target with that short line. However, your attack skill was to low, so the game engine says, "Nope, you actually don't hit the enemy, even though you aimed properly and hit them with the raycast you sent out." It registers 0 damage and then, to simulate what a block/parry is, it plays the armor sound.

So, you want it to recoil when the raycast hits a target, but you fail your chance roll; guess what, already in their for you.

However, I personally want any successful raycast to recoil from the enemy, just as it would in real life. Physical objects should have weight and matter that your weapons are affect by.

Right now, it recoils if you hit with a raycast and roll a successfully chance roll; it does a normal push back and blood sprite, and does the recoil animation; I plan on changing this to a reverse stab animation to simulate a proper weapon pull back. When successfully landing a weapon into an opponent, it actually doesn't usually recoil directly; it gets semi-stuck in flesh, cloths, and metal, forcing the attack to pull out and back, keeping the weapon close and leveraging the enemies body.

If you hit with a raycast and fail your dice roll, it also recoils, but without the sprite. Instead, it plays the armor sound, simulating a block of some time.

You can see it in the videos posted to this forum thread dedicated to my combated mod.
viewtopic.php?f=14&t=2533

Bear in mind with many enemies you will just plain miss. This may be due to a lack of skill or because your enemy dodged the attack. Rats and bats are 2 enemies that spring to mind that will primarily dodge your attacks. Of course this is very difficult to properly simulate in Daggerfall. Perhaps the weapon could be used to push the enemy out ot the way. Perhaps all the ray tracing could be done before the animation plays allowing the enemy to predict the path of the weapon and move.

The primary problem I see is that most of this requires very sophisticated animations to properly simulate. My proposed solution was Verbose Combat the idea being that you could give the player some descriptive feedback of what was happening instead of relying on purely visual and auditory information which is pretty inadequate.