AAF HARDSHIP - beggar- whore -

[Tentacus]

21 minutes ago, requiredname65 said:

When scene get stuck in unjoining, AAF (for obvious reasons) won't (or doesn't seem to) fire OnSceneEnd -event. For example high heels system doesn't restore actor root node offset after animations when this happens. HHS listens on OnSceneEnd event for that. If papyrus vm stops excecution of a script instance on error then raider robberies wouldn't happen at all, nor any cleanup or globalvalue resets. Haven't tested that.

As for this problem, affects all mods using StopScene function IF they were compiled against version older than 151 such as Crackle and Hardship. It stems from addition of new parameter, abruptStop, to StopScene function which changed function signature from StopScene(Actor, Int[Optional]) to StopScene(Actor, Int[Optional], Boolean[Optional]). This is hinted towards in papyrus log
 

error: Incorrect number of arguments passed. Expected 3, got 2.
stack:
    [_T_CrackleQuest (7E001ECC)].Tentacus:Crackle:_T_QuestScript.SitOrSleep() - "D:\Games\Fallout 4\mods\Crackle\Scripts\Source\User\Tentacus\Crackle\_T_QuestScript.psc" Line 539 

 

I worked around this on my own setup by modifiying AAF_API and this resolved endless scenes in my current save which has encountered this issue and saved with it.

Modification for reference is

; Function StopScene(Actor targetActor, int levels = -1, bool abruptStop = False)
Function StopScene(Actor targetActor, int levels = -1)
	Var[] sendData = new Var[3]
	sendData[0] = targetActor.GetFormID()
	sendData[1] = levels
	sendData[2] = False ;abruptStop
	
	AAF_MainQuestScript.sendEvent("STOP_SCENE", sendData)
EndFunction

You should be able to correct this for Hardship and Crackle by bumping your dev version to 154, recompiling scripts using StopScene and adding that as new requirement.

LOL... Boy did I jump to the wrong conclusion. It was simply recompiling that fixed it and it would have worked with PlayerRef as well... Motherf---

 

This explains why the test mod worked cause I just recompiled it to change the parameters.

 

THANK YOU SO MUCH!

 

This seems really bad though There are dead/Orphaned AAF mods that are gonna just be useless now.

 

Obviously this is gonna delay the update into next week especially since I need to Update Crackle too.

[requiredname65]

1 minute ago, Tentacus said:

This seems really bad though There are dead/Orphaned AAF mods that are gonna just be useless now.

 

 

Obviously this is gonna delay the update into next week especially since I need to ypodate Crackle too.

Yeah, too bad papyrus doesn't support function overloading unique function names only in each scripts.

dakobaking would have to keep StopScene as it was pre 151 like in snippet above and add new function StopScene2 or something. Can't say if it is worth it tho..

[JHUNT]

There seems to be an issue when my character is being assaulted, by a guard for example. My character's clothes are stripped, and the dialogue fires as expected, but no animations. Any ideas?

[goosetrip]

Love the mod so I hope you get it fixed soon.  Maybe the Master= EgoBallistic could help.

[Bazinga]

20 minutes ago, goosetrip said:

Love the mod so I hope you get it fixed soon.  Maybe the Master= EgoBallistic could help.

Tentacus wrote:

Quote

Obviously this is gonna delay the update into next week especially since I need to Update Crackle too.

 

This will get fixed, they figured out the issue. The script just needs to be recompiled for the updated AAF version.

 

And I don't have problems with AAF 1.54 and any of the animation packs. Shit works.

It's just this stopscene script call that doesn't.

[dagobaking]

http://gamesas.com/papyrus-functions-with-optional-arguments-t334901.html

[Tentacus]

23 minutes ago, dagobaking said:

http://gamesas.com/papyrus-functions-with-optional-arguments-t334901.html

I'm not sure what the intent of this post is or who it's aimed at?

[Tentacus]

1 hour ago, Bazinga said:

Tentacus wrote:

 

This will get fixed, they figured out the issue. The script just needs to be recompiled for the updated AAF version.

 

And I don't have problems with AAF 1.54 and any of the animation packs. Shit works.

It's just this stopscene script call that doesn't.

Yeah the old animation packs are pretty safe, and anybody can make new XMLs for something that gets too outdated... It's actually more dangerous when they get fancy adding new stuff ? 

 

As frustrated as I am that this happened, it kind of comes with the territory. You'd rather @dagobaking keep trying to improve AAF than not , and I'm personally grateful for his efforts. He fixed the Strapon bug pretty quick when that cropped up. 

[dagobaking]

23 hours ago, Tentacus said:

What variables? I only use 3 simple AAF functions!

The simplicity of usage doesn't really change the situation. I have no idea what else may/may not be installed that could change how it works in a specific game. Modding can produce a lot of complex and unexpected problems. And I do not have enough time to try to re-create everyone's circumstances only to find out a lot of the time that the issue isn't actually a problem in AAF.

 

If/when an alleged bug comes up, someone other than me needs to do the due-diligence to demonstrate that it really is an AAF bug. This requires eliminating all outside factors in a simple package of files that can be installed and tested (without instructions like "install these other 34 mods too").

 

I don't think this is unreasonable to ask given how much time I put in. And I'm pretty sure that most AAF users would prefer that I spend most of my time working on actual AAF code rather than 90% of my modding time going to installing random users mod-lists to test.

23 hours ago, Tentacus said:

and every time you ask for this QA thingy I am left perplexed how I am supposed to recreate something specific to my mod that is SAFE FOR WORK?

Safe for work is not really what is needed. I just need you to do the testing to figure out specifically what code is broken and put a demo of that together that doesn't require me to install 30 dragons-with-dicks mods to test it.

 

In this case, you were telling me it was broken without having tested it yourself. If you don't have time to do that why do you think I do?

23 hours ago, Tentacus said:

Anyway sorry for venting a little. As of now I have not first hand experienced this issue because I haven't updated from 147, so when I am able, I will have a better idea what's going on. The first thing I intend to do is see if that old test mod works  

Looks like the issue is that mods that use AAF need to be recompiled with no other changes needed to them. (Thanks to the user above that figured that out.)

 

Given that some mod authors have disappeared and maybe won't recompile I will consider removing the abruptStop parameter in a future build. Though, at some point, these types of changes need to happen to progress the mod.

[Tentacus]

 

Quote

Safe for work is not really what is needed. I just need you to do the testing to figure out specifically what code is broken and put a demo of that together that doesn't require me to install 30 dragons-with-dicks mods to test it.

LOL I feel ya.

 

Quote

In this case, you were telling me it was broken without having tested it yourself. If you don't have time to do that why do you think I do?

Looks like the issue is that mods that use AAF need to be recompiled with no other changes needed to them. (Thanks to the user above that figured that out.)

 

Yes I did jump the gun a little last night. I really shouldn't have commented on the situation until I had time to test it myself so, sorry. As you can see in this thread though I spent the entire day testing and showing my work as it where, and the end my observation was justified, It was a change to AAF that broke it.

Quote

Given that some mod authors have disappeared and maybe won't recompile I will consider removing the abruptStop parameter in a future build. Though, at some point, these types of changes need to happen to progress the mod.

Honestly I don't think you should remove it. I haven't looked into it but something called "abrupt stop" sounds very useful, and for guys like Flashy who pretty much declared their mods dead and literally told people not to play them anymore I don't think it's a terrible thing to let them go. Just maybe put some kind of notification in the main AAF thread that modders need to recompile and make 154 a requirement if they use Stopscene. AFAIK I'm kinda the only guy who's anal about controlling his scene length by hand, so this may not affect much more than my 3 mods.

[dagobaking]

12 minutes ago, Tentacus said:

LOL I feel ya.

12 minutes ago, Tentacus said:

Yes I did jump the gun a little last night. I really shouldn't have commented on the situation until I had time to test it myself so, sorry.

All good. Water under the bridge.

12 minutes ago, Tentacus said:

As you can see in this thread though I spent the entire day testing and showing my work as it where, and the end my observation was justified, It was a change to AAF that broke it.

Kind of. It requires no change from AAF to fix it.

12 minutes ago, Tentacus said:

Honestly I don't think you should remove it. I haven't looked into it but something called "abrupt stop" sounds very useful, and for guys like Flashy who pretty much declared their mods dead and literally told people not to play them anymore I don't think it's a terrible thing to let them go. Just maybe put some kind of notification in the main AAF thread that modders need to recompile and make 154 a requirement if they use Stopscene. AFAIK I'm kinda the only guy who's anal about controlling his scene length by hand, so this may not affect much more than my 3 mods.

Yeah. Im not sure how many people have actually used that function since there are many other ways that the scenes get ended without it.

 

I will give it some time to see what happens. If people need to fix it the solution is to simply recompile their mod with the latest AAF installed. So, will make sure that is known.

[Tentacus]

28 minutes ago, dagobaking said:

All good. Water under the bridge.

Kind of. It requires no change from AAF to fix it.

Yeah. Im not sure how many people have actually used that function since there are many other ways that the scenes get ended without it.

 

I will give it some time to see what happens. If people need to fix it the solution is to simply recompile their mod with the latest AAF installed. So, will make sure that is known.

Well if it does what it sounds like it does (stops a scene suddenly and ignores ending transitions) I could remove a lot of workaround code that I have in 1.6 that makes it switch to a 1 frame animation before stopping the scene... so yeah I'd use the hell out of that.

[Tentacus]

Just FYI guys...

 

Crackle is updated on the Nexus and will be here Momentarily. I'll do Hospitality in the morning. Porno music doesn't mess with animations so it's already fine.

[dagobaking]

5 hours ago, Tentacus said:

Well if it does what it sounds like it does (stops a scene suddenly and ignores ending transitions) I could remove a lot of workaround code that I have in 1.6 that makes it switch to a 1 frame animation before stopping the scene... so yeah I'd use the hell out of that.

Ok. Good to know that there is already a demand for that feature. Thank you.

 

[PS: The feature may actually need some additional work as I switched to using the also-new feature of auto-ending scenes with characters that get combat alerted. So, it wasn't tested as thoroughly as I would have liked. But, let me know if it doesn't work as expected.]

[Tentacus]

3 hours ago, dagobaking said:

Ok. Good to know that there is already a demand for that feature. Thank you.

 

[PS: The feature may actually need some additional work as I switched to using the also-new feature of auto-ending scenes with characters that get combat alerted. So, it wasn't tested as thoroughly as I would have liked. But, let me know if it doesn't work as expected.]

That's fine as long as you tell us we need to recompile   I dunno if this is a new thing but I've noticed that a havok object in the scene area can end a scene explosively. actors ragdolling away etc... It's something I never observed before 147 when I made my test cell full of havok objects

 

Question... is there a sudden position change function also? The bane of my fucking existance is Ulfbearth and SC changing their XMLs to demand that every animation finish it's transitions, even when changing position using the tree system. This basically breaks Hardship completely so I've spent the last 2 weeks creating curated seperate XMLs for savage Cabbage and others (Future proof in case they jump on the bandwagon) with hidden positions and my own tags only Hardship will call so people can still use UAP with other mods but also have a working Hardship... Something like that would mean I didn't need to massively waste all that memory with duplicate XMLs.

 

Though truth told the XMLs are worth it for other reasons (Inconsistencies in alignment, updating morphs using Ulfbearth's method, etc...) so I'll be keeping them... but such a thing might help a future modder.

[Tentacus]

There is nothing more tedious than doing XML offsets.

[dagobaking]

19 hours ago, Tentacus said:

That's fine as long as you tell us we need to recompile  

Any time it says in the changelog that a new parameter is added to a function it would be needed. But, I will try to add a note about it in addition to that.

19 hours ago, Tentacus said:

I dunno if this is a new thing but I've noticed that a havok object in the scene area can end a scene explosively. actors ragdolling away etc... It's something I never observed before 147 when I made my test cell full of havok objects

 

AAF has always caused that to happen when the actors are attacked during a scene. There is a new feature that causes it to happen when the actors go into combat state. But, that is off by default.

19 hours ago, Tentacus said:

Question... is there a sudden position change function also? The bane of my fucking existance is Ulfbearth and SC changing their XMLs to demand that every animation finish it's transitions, even when changing position using the tree system. This basically breaks Hardship completely so I've spent the last 2 weeks creating curated seperate XMLs for savage Cabbage and others (Future proof in case they jump on the bandwagon) with hidden positions and my own tags only Hardship will call so people can still use UAP with other mods but also have a working Hardship... Something like that would mean I didn't need to massively waste all that memory with duplicate XMLs.

Hm. I think this is coming from setting "forceComplete" to true in position tree? That is basically an over-ride. So, there is not an over-ride to over-ride the over-ride.

 

Is there a given reason why they include that setting?

 

[Tentacus]

9 hours ago, dagobaking said:

Hm. I think this is coming from setting "forceComplete" to true in position tree? That is basically an over-ride. So, there is not an over-ride to over-ride the over-ride.

That's just as well. I put a lot of work into the workaround so at least that time wasn't wasted... lol.

9 hours ago, dagobaking said:

 

Is there a given reason why they include that setting?

 

Because they think it's "neat tech" apparently. I tried to talk him out of it but Ulfbearth can be pretty headstrong. He's gotta do what he's gotta do I guess. My mods are the only ones I'm aware of that have a lot of interactive position changing so it pretty much only affects Hardship and Hospitality. It's okay I am kinda making my own little sub-framework here in the near future with TSEX  that all my mods will use that will all draw on the same XML set that I can control. At the end of the day it's better to not have to rely on which way the wind blows.

[Tentacus]

Update:

 

The XMLs are done and I've begun work on retagging and recompiling the sex scripts. I'll be busy most of today though so I won't be able to devote much time to it till tomorrow, still we are on a solid path to a monday release if nothing goes wrong.

 

And I am still finding bugs. LOL

[Ulfberto]

10 hours ago, dagobaking said:

Any time it says in the changelog that a new parameter is added to a function it would be needed. But, I will try to add a note about it in addition to that.

AAF has always caused that to happen when the actors are attacked during a scene. There is a new feature that causes it to happen when the actors go into combat state. But, that is off by default.

Hm. I think this is coming from setting "forceComplete" to true in position tree? That is basically an over-ride. So, there is not an over-ride to over-ride the over-ride.

 

Is there a given reason why they include that setting?

 

the reason is because i want animations to finish looping before they can proceed. So the transition betwen one stage and another is uninterrupted and all stages can loop at least once before the sequence can proceed, making the scene more seamless. Plus it works better when the trees are NPC controlled and there are conditions involved.

 

My patch is being built around conditions. The user will have the chance to choose how long each sequence will last before AAF ends based on how fast the conditions will get to 100%. So, to ensure that each stage will play entirely at least once, i just realized using forceComplete will acomplish that. Its specially useful in sequences with a lot of stages like the ones from SC (with up to 8 stages)

 

1 hour ago, Tentacus said:

Because they think it's "neat tech" apparently. I tried to talk him out of it but Ulfbearth can be pretty headstrong. He's gotta do what he's gotta do I guess.

Well, i could say the same about you. The difference is that im in AAF discord and always trying to contact other authors
And its not my fault if i want to use most AAF features and you want to give half support to AAF. But dont get me wrong, each on their own, just saying...

[dagobaking]

19 hours ago, Tentacus said:

That's just as well. I put a lot of work into the workaround so at least that time wasn't wasted... lol.

There may be new opportunities to waste that time yet! ;)

19 hours ago, Tentacus said:

At the end of the day it's better to not have to rely on which way the wind blows.

This is understandable from the coders side. But, for users, I think it is helpful if things can play nice together in multiple combinations of mods.

 

There might be a middle ground solution here. I think I just need to understand all sides of the problem first.

 

You basically want to be able to use the API to switch animations on demand at any point, right? But, when forceComplete is set to true, those commands are blocked? So, you are making copies of the XML with forceComplete-true removed? Or, is there more to it than this?

18 hours ago, Ulfbearth said:

the reason is because i want animations to finish looping before they can proceed. So the transition betwen one stage and another is uninterrupted and all stages can loop at least once before the sequence can proceed, making the scene more seamless. Plus it works better when the trees are NPC controlled and there are conditions involved.

Makes sense. That is why that option was added. It is a nicer feel when using the tree widget.

 

Tentacus, there are a series of built-in AAF features that are somewhat in conflict with the use-flow you are using. So, authors shouldn't really be blamed for exploring/using those further. A lot of the system is designed to have beginning/ends of scenes controlled by conditions that are met (ie. the exit animation doesn't play until x stat is reached during the scene). Ideally, you could consider adjusting to accommodate that approach since it opens up a lot of possibility with the animation types/experiences. But, if you don't like or want to do that there may be mutual solutions as mentioned above.

 

[Tentacus]

3 hours ago, dagobaking said:

You basically want to be able to use the API to switch animations on demand at any point, right? But, when forceComplete is set to true, those commands are blocked? So, you are making copies of the XML with forceComplete-true removed? Or, is there more to it than this?

Makes sense. That is why that option was added. It is a nicer feel when using the tree widget.

More or less. I don't want the tree widget or the auto complete.

 

the problem as I see it, is that Ulf is a patch maker. Except for my Leito XMLs and a few native BP70 he's the only one providing gay XMLs for people to use. On top of that he's gotten into adding the straight ones which make his pack conflict with others. Personally I don't think infrastructure patches should impose gameplay mechanics like this when AAF has worked a certain way from the beginning. It should IMO be for the end modders to make those kind of calls situationally. 

Quote

 

Tentacus, there are a series of built-in AAF features that are somewhat in conflict with the use-flow you are using. So, authors shouldn't really be blamed for exploring/using those further. A lot of the system is designed to have beginning/ends of scenes controlled by conditions that are met (ie. the exit animation doesn't play until x stat is reached during the scene). Ideally, you could consider adjusting to accommodate that approach since it opens up a lot of possibility with the animation types/experiences. But, if you don't like or want to do that there may be mutual solutions as mentioned above.

I acknowledge the way I do things is a special case. That's why I bitched and moaned a little and then went and made my own solution which tries to be as compatible with what Ulfbearth is doing as possible aside from requiring people use My Leito XML pack: SLP instead of his. (To be fair he did step on my toes first by adding the M-F to his pack and making it conflict) I don't want to deprive users from the ability to use UAP with other mods, so I will always try my best to maintain maximum compatibility within reason. (I supported Indarello way longer than I should have)

 

BTW These XMLs I made for Hardship only affect my mods. I call unique tags and have them hidden so from an end user POV they shouldn't even be noticed. I already had a decent amount of these with custom aspects in Hardship before this even started.

 

It's the best solution I was capable of coming up with to maintain my gameplay. If somebody of sufficient Papyrus/AAF skill and commitment wants to come in and help me redo all my sex scripts (There are 9 of them and they are hella long) I'd entertain that as long as the existing gameplay mechanics can be closely approximated. It's a good time to explore this possibility since 1.6 will already be a major departure in terms of the internal functionality of Hardship and is still a way off. So if anybody is interested let me know. (Don't worry the 1.6 scripts are A LOT easier to read... lol.)

[Bazinga]

58 minutes ago, Tentacus said:

Personally I don't think infrastructure patches should impose gameplay mechanics like this when AAF has worked a certain way from the beginning.

It should IMO be for the end modders to make those kind of calls situationally. 

The vast majority will never do this. For them Ulf and others that provide AAF patches are the end modders and they are just mod users.

...

Wait, you mean calls like if they want to be able to change animations through the UI? I agree.

I also reactivated the AAF interface in AAF Violate. Kinda annoyed me that it was locked so I appreciated it when EgoBallistic introduced the option to activate it.

Unless it's something technical that can break stuff if you don't lock it away I suggest always following one rule:

Never ever take away control from the end user.

 

That forcecomplete feature seems to be something similar. From the AAF wiki:

Quote

forceComplete is true or false (false by default if omitted). If true, the position tree widget becomes locked while this branch animation completes. The purpose of this is to prevent the user from interrupting animations with navigation before the animation reaches its end.

Yeah so it only seems to prevent the user from interrupting an animation stage before it's finished.

And it sort of breaks mods that also want to change animations, like Hardship.

Not a feature that I particularly appreciate tbh. If I want to change animations manually then I have a reason for it.

[maddadicusrex]

There are so few mods out there that allow one to roleplay in the FO4 universe, which can be predictable and tedious after so many years out there. Hardship is the complete package and probably the only one that does not encourage mass killing of everyone around them in order to advance in the game. It is well made, well thought out, and a labor of love and sweat. Seems there ought be a way to meld the constant AAF mechanic tweaks with extensive mod immersiveness in order to play well with each other and not require the blowing up of such mods or the extraordinary effort to rewrite these type mods to bypass or support the latest and greatest AAF stuff. Folks seem to be forgetting that skilled modders are leaving the game and not new ones replacing them. That leaves the gamer vulnerable in staying with a mod too long or having no real options to improve the gameplay because fewer and fewer mods are being fixed to work with any new AAF offering..

[Bazinga]

40 minutes ago, maddadicusrex said:

There are so few mods out there that allow one to roleplay in the FO4 universe, which can be predictable and tedious after so many years out there. Hardship is the complete package and probably the only one that does not encourage mass killing of everyone around them in order to advance in the game. It is well made, well thought out, and a labor of love and sweat. Seems there ought be a way to meld the constant AAF mechanic tweaks with extensive mod immersiveness in order to play well with each other and not require the blowing up of such mods or the extraordinary effort to rewrite these type mods to bypass or support the latest and greatest AAF stuff. Folks seem to be forgetting that skilled modders are leaving the game and not new ones replacing them. That leaves the gamer vulnerable in staying with a mod too long or having no real options to improve the gameplay because fewer and fewer mods are being fixed to work with any new AAF offering..

That's true.

It's also true that there still is no perfect AAF patch or combination of patches, something always needs fixing or isn't implemented as thoroughly as it should be.

Examples from my setup:

I had to make my own little patch for gagged animations (50 Shades) because I didn't want to install DD.

The One Patch is outdated as fuck so I ignored it this time around.

Ulf does a great job for MM animations but everything else is better covered in other patches, so I uninstalled it again.

The Simple Patch, while promising, only covers 3 animation packs.

Indarello doesn't really communicate with other modders so his patch often has compatibility issues. The latest one I'm aware of is that he changed the morphs for vagina penetration to VaginaPenetrate2 on many animations and also changed his own edited Fusion Girl body to reflect that. He intends to use the old VaginaPenetrate morph for CBBE instead. And since CBBE doesn't have vagina bones he added VaginaPenetrate to animations that feature penetration via bones in the animation files themselves.

Would be great if he wouldn't link to my edited body or if he would have told me about his plan. Now I get weirdly stretched vaginas when using his AAF patch together with my FG edit.

 

So yeah, this is still all patchwork. Which is sad, AAF has been the standard framework for animations for a while now.

But I guess it reflects the lower popularity of Fallout 4 sex mods compared to Skyrim.

 

So while I don't care for the use of forceComplete in his xmls I still very much appreciate what Ulfbearth and the other AAF patch modders are doing. Hopefully it will one day lead to a selection of patches that really makes the best out of the available AAF features while not having conflicts with other widely used mods.