Unfortunately, my idea of negative velocity to Z didn't work. After doing some testing, I have confirmed that the landing animation issue in AVF 1.51 is caused by both/either of the following factors: Negative velocity to Z applied when on the ground, or gravity applied when on the ground.
For me, AVF 1.4 seems better than 1.51. AVF 1.4 does not spam the landing animation with gravity when the actor is on the ground, and negative velocity to Z is available for sliding downhill. So both are more functional on the ground.
Sorry if it looks like I'm complaining, I'm just having trouble reporting the issue correctly. (That said, it would be nice if you could keep these as two different velocity functions in your framework.)
Okay I think it should work fine now but for safety I'll just mark both 1.4 and 1.52 as main files and state that 1.4 is the stable version and 1.52 is an experimental version.
Wow, thank you very much. I will switch my mod to AVF 1.52 and test your framework/my mod. If this works well I would release it as an "experimental version" first, like you are doing :)
For gravity/negative Z tests and FPS Dodge, it seems to work almost perfectly and I didn't even need to change the values for different framework versions. I see a difference in framework behavior, but it only slightly affects my mods, at least. However, power armor is still angry and often triggers impact landing animations.
I tried to dig into the condition function related to velocity and would like to share it with you.
Spoiler:
Show
In short, the impact landing animation issue seems to be caused by the behavior of AVF 1.5+ and the too high low value output to "VelocityZ" in AnimationVariable/GraphVariable, but I haven't come up with a workaround.
In idle animation, "GetGraphVariableFloat VelocityZ < -900" is used for impact landing. I compared it to "GetVelocity Z" that jump fall had. It seems like GetGraphVariableFloat VelocityZ returns the last z and GetVelocity Z returns the current z.
The following tests were done with AVF function gravity = true, or velocity z -500. Tested with 1st/3rd person, with/without power armor.
Gravity: GetGraphVariableFloat VelocityZ returned about -5000. GetVelocityZ returned about -200. (This begins to trigger while moving.) Z -500: GetGraphVariableFloat VelocityZ returned between -5000 and -30000. GetVelocityZ returned about -500.
Thank you for your great work, this framework allowed me to create First Person Dodge. I'm sure this update is great too, but I encountered an issue with version 1.5.
Gravity in version 1.5 seemed to be over applied. As an example gravity can continue to be applied downhill and velocity can reach almost teleport. I think (at least in version 1.4) gravity is intended to be applied in the air, not on the ground, right? Could you please confirm if this is the intended behavior in version 1.5?
By the way, I also tested "ActorVelocityFramework.SetVelocity(PlayerRef, 0.0, 0.0, 0.0, 3.0, 0.0, 0.0, 0.0, true)", i.e. applying gravity for 3 seconds. Movement is severely restricted while gravity is applied, and it looks very incorrect when the player takes a step downhill.
EDIT: You're right. I forgot to convert Fallout 4 units to Havok units. Movements should feel the same as before (I've tested with your mod) except the gravity but I feel like the current version is more similar to actual gravity in Fallout 4 so I'll just leave it as it is.
I changed the way AVF works slightly because of two reasons: 1. It was using the jetpack flag on Fallout 4's character controller, which caused the character to float a bit. 2. It was using character movement finish event, which didn't match up with the actual character position update.
The mod now uses the game engine's actor update event and modifies the character's Havok object directly. Those changes caused the mod to use Havok units and ignore player mid-air control inputs.
Thanks for the update! Looks like I can update my mod with minimal changes. If you have time, could you please advise me about the function that returns your AVF version? It shows 1 or 1.000000 and I'm not sure if it's related to your AVF dll file version having 1.0.0.0. Perhaps I'm misunderstanding about F4SE's GetPluginVersion function?
Well I think it's okay. I can simply define AVF 1.51 or not in a property and upload two mods on one mod page for different behavior of slides. It works as long as I remember to edit the esp properties before uploading the mod.
So far, the buggy things I've experienced with AVF 1.51 are related to gravity and power armor. The script I posted the other day to test gravity for three seconds spams an impact landing animation with power armor. It can happen in either 3rd or 1st person, especially in 1st person, where it makes so much noise that it could make someone's heart explode. In FPS Dodge slide it happens sometimes but not often.
In AVF 1.51, I'm going to do things without gravity parameters. I think this option was a bit redundant for my mod in the first place, so don't worry about it.
Im not sure this framework is meant for the idea i have, im not a scripter so i dont really know what this dose in that regard but ill explain what i was hoping for
Acceleration and deacceleration, mainly for robots or which the 'drivable' car mods are built upon Two issues these mods have they turn on the spot(when using A and D) and they instantly stop and start The turning issue can be negated by blocking the use if A and D so you have to use the mouse to turn which would prevent the stupid turning
For the stop and start i was hoping for when you let go of W or S the actor(drivable/robot) takes some time to decrease/increase velocity, maybe accompanied with a sound effect for audio feedback so you know your coming to a stop when letting go of W
Is a velocity based acceleration/deceleration possible?
Another idea i had which i think would also be based on velocity to some degree is 'drifting' depending on the mouse turn arch and the current speed of the actor(drivable/robots) velocity it negates the movement direction of the crosshair for a small amount of time. As in you continue to travel in the direction you was traveling even though you have turned, AKA a drift
These two velocity adjustments in the absence of actually vehicle physics would make drivable feel way better and vanilla robots in general, wheeled robots atleast, and even the airboard ones like mr handys they should stop instantly either and seeing them drift around would also be cool and realistic.
Only other thing i can think of that again kinda rolls into velocity mechanics is upward velocity, for doing jumps with a fading acceleration effect and a bounce like effect when in a downward velocity when at a certain speed. Basically if you have a downward verlocity over a certain speed it cause several upward velocity movements in succession AKA a bounce, fall height and velocity speed taking in to a calculation of how high of and upward velocity you get and how many in succession you get. Small drop you get a low bounce and less of them, a higher drop a higher bounce with more of them in decreasing heights
As i say i envision these effects for the drivable mods but should defiantly apply to the vanilla wheeled and airbord robots making them way more dynamic in movement and less stiff and rigged
So in Creation Engine, Havok takes two parts: Animation and Physics. The error you're having right now is related to the animation part. Could you try playidle console command to check the animation?
Thing is I'm not playing any animations with PlayIdle or anything like that, its pretty weird, I've noticed that sometimes when you set the velocity during a jump the player can get stuck in the "fall" state, do you think something like that could be related?
Here's my mod in action anyway:
If you can think of anything you'd like me to try to help you troubleshoot just let me know!
What method are you using right now for animations? Your crash log afaik, implies that it has failed to generate blending between animation transitions.
Player getting stuck in a fall state is a technical limit in the behavior graph. Bethesda didn't make any transition between jump start to land, only mid-land exists so the "land" event gets ignored during short hops.
Oh, ahahaha XD I see. I thought you were playing around with the animations as well. I just watched your videos and damn, that looks hella fun! Nice implementation and thanks a lot for testing out my stuff. I've been using this framework for like 3 months and I finished a playthrough with DoomFist as well so I don't think it will have any serious issues, but if you find any, or need function improvements then please post here. I'll be checking regularly.
Unfortunately man after playing with it for some time I can all but confirm that its causing extreamly frequent and varied crashes, the most being related to various actor physics variables, speed being the most common one, something isn't being done in a safe way somewhere and the game doesn't like it.
Aight, I'll test your mod and try to see what's happening in there. You can just drop a link here, pm me or add me on discord: Bingle#5128.
Edit : I've read your log again and it's pointing a vicious dog (60BFD) placed in Commonwealth. I could locate it through Creation Kit and it's placed around that area, so I have to ask. Do you have any file edits related to the dogs? I don't see anything directly related to them in your load order, but well it doesn't hurt to check I guess.
Totally missed that mod. Many thanks for the link. Will check it out :) Crossing my fingers that you can dodge in power armor.
Edit: After playing with that mod for a day, I'm gonna give it a pass and uninstalled. Ran into some problems I couldn't ignore (most probably bc of my PC + load order). Perhaps I'll try it again when its out of beta.
one of the biggest issues i have with that mod, and a majority of tooun's mods in general, is the ungodly script lag that happens when the game is trying to keep a large amount of actors in motion. it could very well be an issue with AI package mods like PACE or PANPC, but as soon as you get a bunch of actors in a cell and try to have them act independently, you're going to be counting the seconds between pressing a key and having something change on screen. for instance, the item wheel mod can take anywhere between three and six seconds to open when you use it in a crowded combat scenario where multiple npc's are hostile, and that issue compounds the more script-intensive mods you have, like tactical action extension and even kill tips and hit sounds. since that appears to all be done with f4se and script functions, there's multiple seconds between you pressing a button and your desired effect taking place, either from sliding in TAEP or something as simple as slowing down time or hearing a hit sound in KT/HS. how's that for responsive? what would be ideal is an engine-level sliding mechanic akin to Simple Impact's engine-level hit registration. however, we've already heard from hitman47101 that trying to develop such a mechanic was proving to be difficult. hopefully he and the OP figure something out, as i'm a huge fan of these kinds of movement options. hell, the uneducated shooter mod pretty much earned a permanent place in my load order, because leaning and crouching underneath objects are invaluable abilities to have. i also enjoy the movement flow in the newer call of duty titles, so being able to turn the commonwealth into a giant slip-n-slide adventure would really complete the package. but these are all merely ideas, and we all know what the opinion of an ideas guy with no programming expertise is worth.
I also figured out that it's possible to directly manipulate player's position and angle through Havok character proxy class. I need to test its limitations, but I'll be able to release it soon-ish.
I've updated the mod to feature three more functions : GetActorAngle, SetPositionQuick, and SetAngleQuick.
So for SetPositionQuick you can basically enter any number and it will send the actor to that position. I've tried sending the player to like 4000 units away and it works without any problem. However, if you try to send the player to unloaded cell then the game will freeze itself for a while and load it.
SetAngleQuick takes 3 floats: x, y, z. Thses are angles in each axis in radians, but y value doesn't do anything. x value should be a number between -1.396 and 1.396.
Please report if you have any issues with the functions.
; Have the statue face the player float zOffset = Statue.GetHeadingAngle(Game.GetPlayer()) Statue.SetAngle(Statue.GetAngleX(), Statue.GetAngleY(), Statue.GetAngleZ() + zOffset)
I'm trying to make the PlayerRef face the akTarget
I'm glad to hear that! Just let me know if there's any issues, or any features you wish to have (but they should be related to movements and velocity, to keep consistency of the mod haha XD)
57 comments
I'm expecting more hotfixes to come so I won't be able to update it for a while.
Thanks.
-TODO List-
Is there any possibility to solve the problem about this mod? ORZ
For me, AVF 1.4 seems better than 1.51. AVF 1.4 does not spam the landing animation with gravity when the actor is on the ground, and negative velocity to Z is available for sliding downhill. So both are more functional on the ground.
Sorry if it looks like I'm complaining, I'm just having trouble reporting the issue correctly. (That said, it would be nice if you could keep these as two different velocity functions in your framework.)
However, power armor is still angry and often triggers impact landing animations.
I tried to dig into the condition function related to velocity and would like to share it with you.
highlow value output to "VelocityZ" in AnimationVariable/GraphVariable, but I haven't come up with a workaround.In idle animation, "GetGraphVariableFloat VelocityZ < -900" is used for impact landing. I compared it to "GetVelocity Z" that jump fall had. It seems like GetGraphVariableFloat VelocityZ returns the last z and GetVelocity Z returns the current z.
The following tests were done with AVF function gravity = true, or velocity z -500. Tested with 1st/3rd person, with/without power armor.
Gravity: GetGraphVariableFloat VelocityZ returned about -5000. GetVelocityZ returned about -200. (This begins to trigger while moving.)
Z -500: GetGraphVariableFloat VelocityZ returned between -5000 and -30000. GetVelocityZ returned about -500.
Gravity in version 1.5 seemed to be over applied. As an example gravity can continue to be applied downhill and velocity can reach almost teleport. I think (at least in version 1.4) gravity is intended to be applied in the air, not on the ground, right? Could you please confirm if this is the intended behavior in version 1.5?
By the way, I also tested "ActorVelocityFramework.SetVelocity(PlayerRef, 0.0, 0.0, 0.0, 3.0, 0.0, 0.0, 0.0, true)", i.e. applying gravity for 3 seconds. Movement is severely restricted while gravity is applied, and it looks very incorrect when the player takes a step downhill.
EDIT: You're right. I forgot to convert Fallout 4 units to Havok units.
Movements should feel the same as before (I've tested with your mod) except the gravity but I feel like the current version is more similar to actual gravity in Fallout 4 so I'll just leave it as it is.
I changed the way AVF works slightly because of two reasons:
1. It was using the jetpack flag on Fallout 4's character controller, which caused the character to float a bit.
2. It was using character movement finish event, which didn't match up with the actual character position update.
The mod now uses the game engine's actor update event and modifies the character's Havok object directly. Those changes caused the mod to use Havok units and ignore player mid-air control inputs.
If you have time, could you please advise me about the function that returns your AVF version? It shows 1 or 1.000000 and I'm not sure if it's related to your AVF dll file version having 1.0.0.0. Perhaps I'm misunderstanding about F4SE's GetPluginVersion function?
Debug.Notification(sAVF + " version: " + F4SE.GetPluginVersion(sAVF))
So far, the buggy things I've experienced with AVF 1.51 are related to gravity and power armor. The script I posted the other day to test gravity for three seconds spams an impact landing animation with power armor. It can happen in either 3rd or 1st person, especially in 1st person, where it makes so much noise that it could make someone's heart explode. In FPS Dodge slide it happens sometimes but not often.
대쉬 모션을 지원하면, 캐릭터가 기동할때 도움이 될거 같은데
Acceleration and deacceleration, mainly for robots or which the 'drivable' car mods are built upon
Two issues these mods have they turn on the spot(when using A and D) and they instantly stop and start
The turning issue can be negated by blocking the use if A and D so you have to use the mouse to turn which would prevent the stupid turning
For the stop and start i was hoping for when you let go of W or S the actor(drivable/robot) takes some time to decrease/increase velocity, maybe accompanied with a sound effect for audio feedback so you know your coming to a stop when letting go of W
Is a velocity based acceleration/deceleration possible?
Another idea i had which i think would also be based on velocity to some degree is 'drifting' depending on the mouse turn arch and the current speed of the actor(drivable/robots) velocity it negates the movement direction of the crosshair for a small amount of time. As in you continue to travel in the direction you was traveling even though you have turned, AKA a drift
These two velocity adjustments in the absence of actually vehicle physics would make drivable feel way better and vanilla robots in general, wheeled robots atleast, and even the airboard ones like mr handys they should stop instantly either and seeing them drift around would also be cool and realistic.
Only other thing i can think of that again kinda rolls into velocity mechanics is upward velocity, for doing jumps with a fading acceleration effect and a bounce like effect when in a downward velocity when at a certain speed. Basically if you have a downward verlocity over a certain speed it cause several upward velocity movements in succession AKA a bounce, fall height and velocity speed taking in to a calculation of how high of and upward velocity you get and how many in succession you get. Small drop you get a low bounce and less of them, a higher drop a higher bounce with more of them in decreasing heights
As i say i envision these effects for the drivable mods but should defiantly apply to the vanilla wheeled and airbord robots making them way more dynamic in movement and less stiff and rigged
Edit: Figured it out but it would still be good to get an example or two.
I've made a dodging mod with this already tho unfortunately its causing a lot of crashes such as this one in some havok code:
https://pastebin.com/0rh7Ykdk
So in Creation Engine, Havok takes two parts: Animation and Physics.
The error you're having right now is related to the animation part. Could you try playidle console command to check the animation?
Here's my mod in action anyway:
If you can think of anything you'd like me to try to help you troubleshoot just let me know!
Player getting stuck in a fall state is a technical limit in the behavior graph. Bethesda didn't make any transition between jump start to land, only mid-land exists so the "land" event gets ignored during short hops.
Thanks again for the functions! I just made sliding. =D
If having any of this stuff could help with with testing and stuff I'm more then willing to send it to you, just putting that out there. :)
I thought you were playing around with the animations as well.
I just watched your videos and damn, that looks hella fun! Nice implementation and thanks a lot for testing out my stuff.
I've been using this framework for like 3 months and I finished a playthrough with DoomFist as well so I don't think it will have any serious issues, but if you find any, or need function improvements then please post here. I'll be checking regularly.
https://pastebin.com/XVBRVmvm
https://pastebin.com/NKFJXiZk
I've managed to get the dodging and sliding to feel amazing to play with but I can't release it in this state.
If you'd let me I'd love to send you my mod so you can try to replicate these crashes yourself, maybe I'm doing something wrong and just can't see it.
Edit : I've read your log again and it's pointing a vicious dog (60BFD) placed in Commonwealth. I could locate it through Creation Kit and it's placed around that area, so I have to ask. Do you have any file edits related to the dogs? I don't see anything directly related to them in your load order, but well it doesn't hurt to check I guess.
Edit: After playing with that mod for a day, I'm gonna give it a pass and uninstalled. Ran into some problems I couldn't ignore (most probably bc of my PC + load order). Perhaps I'll try it again when its out of beta.
for instance, the item wheel mod can take anywhere between three and six seconds to open when you use it in a crowded combat scenario where multiple npc's are hostile, and that issue compounds the more script-intensive mods you have, like tactical action extension and even kill tips and hit sounds. since that appears to all be done with f4se and script functions, there's multiple seconds between you pressing a button and your desired effect taking place, either from sliding in TAEP or something as simple as slowing down time or hearing a hit sound in KT/HS. how's that for responsive?
what would be ideal is an engine-level sliding mechanic akin to Simple Impact's engine-level hit registration. however, we've already heard from hitman47101 that trying to develop such a mechanic was proving to be difficult. hopefully he and the OP figure something out, as i'm a huge fan of these kinds of movement options. hell, the uneducated shooter mod pretty much earned a permanent place in my load order, because leaning and crouching underneath objects are invaluable abilities to have. i also enjoy the movement flow in the newer call of duty titles, so being able to turn the commonwealth into a giant slip-n-slide adventure would really complete the package.
but these are all merely ideas, and we all know what the opinion of an ideas guy with no programming expertise is worth.
I've updated the mod to feature three more functions : GetActorAngle, SetPositionQuick, and SetAngleQuick.
So for SetPositionQuick you can basically enter any number and it will send the actor to that position. I've tried sending the player to like 4000 units away and it works without any problem. However, if you try to send the player to unloaded cell then the game will freeze itself for a while and load it.
SetAngleQuick takes 3 floats: x, y, z. Thses are angles in each axis in radians, but y value doesn't do anything. x value should be a number between -1.396 and 1.396.
Please report if you have any issues with the functions.
; Have the statue face the player
float zOffset = Statue.GetHeadingAngle(Game.GetPlayer())
Statue.SetAngle(Statue.GetAngleX(), Statue.GetAngleY(), Statue.GetAngleZ() + zOffset)
I'm trying to make the PlayerRef face the akTarget
float zOffset = PlayerRef.GetHeadingAngle(akTarget)
ActorVelocityFramework.SetAngleQuick(PlayerRef, PlayerRef.GetAngleX(), PlayerRef.GetAngleY(), PlayerRef.GetAngleZ() + zOffset)
I encountered 2 problems in the result:
1.Sometimes the angle is wrong.
2.The camera is always moved above the character's head.
Float[] ang = GetActorAngle(Player)
Actor akTarget = Game.GetPlayerFollowers()[0]
if(akTarget)
float zOffset = Player.GetHeadingAngle(akTarget)
SetAngleQuick(Player, ang[0], ang[1], ang[2] + zOffset * 0.0174533)
endif
I've used this code for testing and it worked very well. It forced the player to look at her follower.
I also didn't seem to have any issues with the camera. Could you take a gif/vid for it, so I can use it as a reference?