Combat Overhaul Alpha

Show off your mod creations or just a work in progress.
Post Reply
l3lessed
Posts: 1399
Joined: Mon Aug 12, 2019 4:32 pm
Contact:

Re: Combat Overhaul Alpha

Post by l3lessed »

Thanks man. About done with animations. The magic axe needs to be finished because of a bad index number in the cif files. Just haven't had or put time into it last week.

So, does UABE work with DFU or not? Sorry, but can't tell from your post. If I'm understanding you, your saying we need to recode the .dll compiler using intermediate language to get it to work with DFU? If that's the case, be honest, trying to sort that hot mess out would at the back of my list.

I plan on getting everything into a mod file if possible, but UABE, if working with DFU, could be an alternative method.
My Daggerfall Mod Github: l3lessed DFU Mod Github

My Beth Mods: l3lessed Nexus Page

Daggerfall Unity mods: Combat Overhaul Mod

Enjoy the free work I'm doing? Consider lending your support.

User avatar
Sandman
Posts: 7
Joined: Sat Aug 31, 2019 7:01 pm

Re: Combat Overhaul Alpha

Post by Sandman »

Yep, UABE works, but as I said, you can't replace scripts, only resources(text, textures etc).
To replace scripts we need only edit the Assembly-CSharp.dll file, rewrite scripts in it by using intermediate language. The easier option is to create the custom build and to use Assembly-CSharp.dll as "installer". I mean, to copy it from the custom build and to replace in original DFUnity.
Sorry for my English, it isn't my first language, and I never had to communicate on it. So there may be some problems about to express my thoughts :)

l3lessed
Posts: 1399
Joined: Mon Aug 12, 2019 4:32 pm
Contact:

Re: Combat Overhaul Alpha

Post by l3lessed »

Update

Finished the first pass of all weapon animations (outside the fists; Those are going to need some extra time and attention to detail).

I also figured out a rough formula to sync raycasting with the weapon animations speed, so hit detection roughly aligns with the animation no matter your attack speed; it uses the players attack speed as a base value to formulate the proper raycast offset distance for the attack speed. This ensures recoils will start at the proper time of the animation. There is a little miss alignment at the end of some animations because of basic variations my formula doesn't deal with currently. Nothing hugely noticeable though, as seen in the video. I plan on trying to refine it more, as I figured out this formula in a few minutes.

Weapon bobbing is now using the proper built in frame offset input variable to create the bob effect. In non-coding terms, this ensures bobbing scales properly, no matter screen resolution, stopping any cutoff sprite bugs. It also creates a cool side effect where the weapon stays in the position when the player stops moving instead of flashing back to default idle position. Makes movement feel more organic to me. Can see it in the video.

Lastly, weapon bobbing works with default enchanted weapons, since the idle spite was defaulted back to the base DF idle sprite. This ensures long term compatibility by using all default idle sprites, instead of grabbing sprite frames and ramming them into the idle animation; might look better, but not worth the trade off.

This means, I'm getting close to a first release build. Once fists are done, I then do basic debugging/optimization, move it to newest build, and release, followed by github drop.

Some known things I may or may not address before release:
  • Racycast alignment formula needs some touching up.
  • Item Weight inventory readout is broken. I need to fix it, as I broke it when I hijacked it for reading out weapon ranges.
  • Down attack raycasting needs some refining also, as the cast is to large of an arc, hitting the ground to quickly and easily, especially with longer range weapons.
Then I think I will stop developing of new stuff, focus on any bug smashing that pops up, and put time into trying to move this into a mod file, if possible, so it is easy for users to install and remove into default DFU.

Stab animation has been fixed, but is not shown in this video.
My Daggerfall Mod Github: l3lessed DFU Mod Github

My Beth Mods: l3lessed Nexus Page

Daggerfall Unity mods: Combat Overhaul Mod

Enjoy the free work I'm doing? Consider lending your support.

User avatar
King of Worms
Posts: 4751
Joined: Mon Oct 17, 2016 11:18 pm
Location: Scourg Barrow (CZ)
Contact:

Re: Combat Overhaul Alpha

Post by King of Worms »

Really nice progress!

I absolutely love the weapon bobbing and I will use that for sure. The swinging animations are nice, just the very slow movement of some of the weapons is accented with the fluent animations now, and it looks very off (because it unrealistic to swing any weapon as slow as the character swings some of em) - I know its not your fault, as you just recreate/enhance the original. Maybe with reflexes set to very high this will look better.

Only thing I dont like is the forward thrust animation (when you move the mouse away from you - or lets say upwards)

There is something off with that IMO. I think its that 1st movement towards the camera which should not be there?

This all can be polished tho, and the work behind this is really nicely executed, you did what I thought was impossible without adding additional animation frames. Plus the reaycasters getting stopped at the contact with walls, mobs etc... Great job!

User avatar
Rytelier
Posts: 23
Joined: Wed Jul 18, 2018 11:29 am

Re: Combat Overhaul Alpha

Post by Rytelier »

Here's what bothers me about weapon animations - they are too linear. They wouldn't hurt anyone that way.
What they need is anticipation phase (preparing to swing), easing in/out, arcs and recovery phase (after active attack).

User avatar
King of Worms
Posts: 4751
Joined: Mon Oct 17, 2016 11:18 pm
Location: Scourg Barrow (CZ)
Contact:

Re: Combat Overhaul Alpha

Post by King of Worms »

Rytelier wrote: Mon Oct 07, 2019 2:51 pm Here's what bothers me about weapon animations - they are too linear. They wouldn't hurt anyone that way.
What they need is anticipation phase (preparing to swing), easing in/out, arcs and recovery phase (after active attack).
I think this can be done relatively easily, compared to the base work which has been laid out here.
Some (optional?) refactoring of the weapon speed would be in order with this fluent movement we have now.
But still , this is great step forward and a thing upon which other tweaking can be done I guess / hope :)

I think the speed might be exponencial? Or maybe linear function? Im so bad at this math lol
CNX_Precalc_Figure_04_01_0042.jpg
CNX_Precalc_Figure_04_01_0042.jpg (33.15 KiB) Viewed 2833 times

l3lessed
Posts: 1399
Joined: Mon Aug 12, 2019 4:32 pm
Contact:

Re: Combat Overhaul Alpha

Post by l3lessed »

This could be done a number of ways with my current setup.

Right now, as the corutine is running, there is 12 returns based on the anime tick time being divided by 12.

We could put in a progressive increase in offset base numbers that upticks until the 6th return, then begins to slow down.

Or, you can do it by frame, like I have done with the down swing for weapons, and the left/right swing for flail. When it detects a certain frame being executed, it triggers a new frame offset switch that ups the attack speed during the animation frame by a set amount. Again, if you watch the down swings or the left/right on the flail, you can see it. On the down swing, it does get faster after each from change. However, this doesn't create a smooth linear speed increase, and instead creates a instant speed boost and slow down on the specific frame tick, which is unnatural looking to a degree. However, still far better than the 5 flashing base sprites.

I do want to point out, this does mean completely redoing the base offset position for each animation sprite to minimize frame skipping as it increases and decreases its offset placement/speed. So, this will not be in first or maybe even second release.

The larger issue at hand will be aligning the raycasts with the speed curve. It could be done by pulling the animation time from the fpsweapon script, running a delta.timer, and adjusting raycast distances based the current time of the animation; the closer to mid-animation time the faster/draw the raycast would move and the further away the slower the raycast would move/draw. However, there isn't currently a public way to pull individual animation tick times or the overall animation time. You can use getanimetime, but that merely pulls the animation time for each frame. As a result, you only get 5 updates, and they are dependent on what frame is being executed. However, I addressed this using a pretty inelegant solution; I copied the speed calculation formula from the fpsweapon script and dropped it into weapon managers.

I personally think there should be a public variable to call the differing animation timing numbers; There should be an easy method for pulling the total animation time, the individual animation tick times, and the current animation running time from the script. Not only do I need this, but future modders will need this feature if they want to execute anything at specific times in an animation.

I could put them in, but I don't want to add a bunch of things to the base script files if I'm moving to a mod file setup and they'll just get cleared on the next dev cycle release. If I'm just being a dumby and overlooking that this is already retrievable through the script, let me know.
My Daggerfall Mod Github: l3lessed DFU Mod Github

My Beth Mods: l3lessed Nexus Page

Daggerfall Unity mods: Combat Overhaul Mod

Enjoy the free work I'm doing? Consider lending your support.

l3lessed
Posts: 1399
Joined: Mon Aug 12, 2019 4:32 pm
Contact:

Re: Combat Overhaul Alpha

Post by l3lessed »

Also, there will always be a small amount of unnatural flow/feel to the base system. It is just the nature of the beast. It can ben greatly reduced by putting in a linear speed increase and decrease, but certain weapons with low agility speeds are always going to look unnatural because how slow and fast the base weapon speeds can be.

This will only get fixed by changing the base game and putting a low and high end cap on attack speeds to stop animations so slow or so fast they look completely ridiculous and broken.

Also, you may be surprised how slow some large two handed weapons actually swing. In real combat, with a number of large two-handed weapons, it's the weight actually doing more of the work than it is your strength/reflexes It's one of the reasons most two handed stances always start with the weapon held on the shoulder or above the head and then always go at a down angle on swing because the extra weight of the weapon is doing the extra work; this is constantly reflected in medieval fighting texts and why the large sword on the back seen in pop culture is actually completely unreal and a joke in real sword fighting. Light weapons, yes, they are more powered by the individuals muscle strength and reflexes because they lack the weight and leverage of a 4 to 5 foot sword/weapon. They rely far more on the users agility and direct muscle strength.
My Daggerfall Mod Github: l3lessed DFU Mod Github

My Beth Mods: l3lessed Nexus Page

Daggerfall Unity mods: Combat Overhaul Mod

Enjoy the free work I'm doing? Consider lending your support.

daggerdude
Posts: 241
Joined: Sat May 23, 2015 2:22 pm

Re: Combat Overhaul Alpha

Post by daggerdude »

I decided to play around in blender and I was able to come up with a cheezy model for a sword (3 hours). definitely room for more detail.
I could further develop this by uv wrap/unwrapping and texture baking; this would give you a model.
I could then keyframe this sword with a simple animation and render it in progression based on the type of attack; basically the vertical chop, diagonal chop, and horizontal chop would all be rendered using the same animation. The only thing different would be the stab.

If these were done with 6 frames at high rez it would still not be a burden on the system i'd imagine. But if double or triple or quadrupel the frames were rendered, it would cause major performance issues i'm sure; so there's still a very real need for interpolated animation, for sure.

we were also talking about the arena model for attacks/weapons. the same weapons can be used with a perspective render from the player, resulting in a "monster attack". theoretically the sky is the limit here.
sword1.png
sword1.png (27.22 KiB) Viewed 2735 times

daggerdude
Posts: 241
Joined: Sat May 23, 2015 2:22 pm

Re: Combat Overhaul Alpha

Post by daggerdude »

some more variations on the blade, just thought i'd do some real quick while i was in the program.
Attachments
swordmulti.png
swordmulti.png (53.06 KiB) Viewed 2733 times

Post Reply