dagobaking

Keyword before starting the quest is ok. I will try that. So, I just made an adjustment to what I was doing. And it looks like it fixed the problem I was having. But, now, that old bug with all the NPCs AI not working is back! So frustrating. I guess it means that the two issues are somehow related... [since I noticed the old bug right away, I was able to backtrack better. So, I think I understand a LITTLE better what is causing it. In my wait package, I had set the flags to basically ignore everything, combat, no aggro radius, etc. That IS what I want during the wait scene. But, apparently, something about those flags on that package somehow remain in effect not only the reference alias but every NPC... Once I turned those flags off, the AI bug doesn't happen... It really doesn't make sense though because if the Wait package was still running, the character released from the ref alias when the Quest stop would stay still right? They don't. They walk around... Anyway, it looks like both bugs are fixed. Knock on wood. PS: Thank you for the clarifying linked references. I get it now. If I discover that this latest build has a flaw I haven't noticed yet, I may try using those.]

I'd like to have it set up so that if I add a keyword to an actor dynamically in script, that will cause this quest alias to populate with that actor. I want to do this so that I can then run a scene on the quest that controls the actor. Possible? I'm still a bit lost about what linked references are exactly. It sounds like you link a keyword to a furniture or other object. Then you can give that keyword to an actor and connect them to the furniture so that they use it in a specific way (with a specific package). Right? That sounds like roughly the same functionality that I need. But, I'd like to apply it via a Quest to run a scene because the scene has two phases (travel to and wait). Whereas a package would just be one part of it and I would need more set-up to transition to a second package.

I see in the Reference Alias panel that there is an option for "Find Matching Reference". Would it work to populate that alias to check that option and then add a condition for "HasKeyword" and specify a unique keyword to give them at the moment I want to run the scene? I can try these strategies to test. But, they each take a lot of set-up. So, it would help to get some insight if you know what will/won't work?

I now suspect that he problem I am seeing is caused by calling ForceRefTo too many times in a short time. There is this note on the CK: https://www.creationkit.com/fallout4/index.php?title=ForceRefTo_-_ReferenceAlias While I don't think that I am calling it in the way this note describes exactly. The fact that doing so can break packages sounds eerily familiar. I am calling ForceRefTo many times on different Quests all timed almost at the exact same moment (from Flash). SO, I would like to try an alternative way of populating aliases or running packages to avoid ForceRefTo to see if that helps. Your above example uses furnitures. I am no longer using furnitures in any way for this. So, need something a bit different. Is there a way to use the method you describe here but cause it to populate a refalias on a quest through a keyword?

True. Easy to test.

It is tough to say because there are different levels of significance between errors. Some are probably harmless. Even just loading the vanilla Fallout.esm will result in a bunch of errors in that window. I'm not sure how much fixing the CK does just by loading an esp. It very well could break that plugin to re-save after loading it in CK. It could be that it's looking for certain files that you have different paths for and saving it in that state will blank some things out. In a case like this, you should probably ask the mod author if they are aware of the errors, if there is a fix, etc.

Ok. I will try that arrangement. Makes sense to me. My original strategy was to start with settings from another mod known to work. But, maybe they had other layers going on that affected things.

See anything that should be changed on the walk package?

Thank you. Will do.

Where are you seeing the errors?

Yes. Please do send the mod. What I am doing is essentially a dynamic version of that. So, in theory, instead of a modder having to code it all, they just make the animations and give my mod some instructions and it handles the rest of the process for them. Here is the alias screen: See anything there that should be set to allow populating with PC more consistently?

If you're up to looking, I can share screenshots of the scene panel, etc.? Thank you for the tip on SQV. I really need to learn more about console commands for this kind of thing. Is your hugging mod posted? Might be helpful for me to review the esp in CK. The fact that it works as expected in some cases leads me to believe that the ref alias part is already ok. It seems like the problem has to do with different game conditions that might prevent populating the alias (dialogue situation, combat alert, etc.). Going to have to pick this back up tomorrow. Out of synapse power tonight. Thanks again and good night!

Hello KakouZ. Just trying to understand the problem better. You aren't needing help rotating it on the z axis, right? Relative adjustments for that are pretty straight forward. You just add or subtract to its existing zangle number. It sounds like you want to tilt it rather than rotate (semantics I know). But, the x or y axis seems to change depending on the direction it is facing on z. If that is the case (I haven't tested this), you can probably set it to face 0 on z first. Then do your x or y rotation while it is in a zeroed out direction. Then rotate the z back to where you want it. BUT, all of that said, I'm not sure why it needs to be tilted via Papyrus like that? Why not just make the nif tilted already? Then, you just make sure x and y are 0.0 and it will always be the right tilt in game.

Added note as I'm testing: The problem of not being able to populate the ref alias with the PC seems to be context dependent. That's why it seemed to work before and not now. I was able to go to a different location and it then worked. Maybe I need to set a flag somewhere to ignore some kind of alert state?

I got ahead of myself. The problem is not that the phase doesn't change. The PC never actually starts into the scene at all. I trace the formID of the package during that wait loop. When it is an NPC it shows a number as expected. But, when I run this on the PC it shows as 0 and the log reports an error for running GetFormID on a None object. Here is the relevant snippet of code: AAF_WalkToAndWaitQuest[sceneKey].Stop() AAF_WalkToAndWaitQuest[sceneKey].Start() (AAF_WalkToAndWaitQuest[sceneKey].GetAlias(0) as ReferenceAlias).ForceREFTo(targetActor) (AAF_WalkToAndWaitQuest[sceneKey].GetAlias(1) as ReferenceAlias).ForceREFTo(walkMarker) AAF_WalkToAndWaitScene[sceneKey].Start() If(targetActor == PlayerRef) Game.SetPlayerAIDriven() inputLayer = InputEnableLayer.Create() inputLayer.DisablePlayerControls(\ abMovement = false, \ abFighting = true, \ abCamSwitch = true, \ abLooking = false, \ abSneaking = false, \ abMenu = false, \ abActivate = false, \ abJournalTabs = false, \ abVATS = false, \ abFavorites = false, \ abRunning = false \ ) EndIf While (targetActor.GetCurrentPackage() != AAF_WaitPackage) ;Debug.Notification("D: " + sceneKey + " : " + targetActor.GetDistance(walkMarker)) Debug.Notification("P: " + sceneKey + " : " + targetActor.GetCurrentPackage().GetFormID()) Utility.Wait(2) Endwhile Debug.Notification("WALK DONE: " + sceneKey)I do want the actor (NPC or PC) to wait at the marker for some time. They are waiting for a second actor to reach the same marker. Sometimes the marker is away from both actors. Sometimes it is at the location of one or the other. So, when they reach it, they need to wait for the other to also reach it before the code proceeds. The framework is more a generic toolset that can be used for multiple things rather than designed for one use. This walking and positioning part of it allows modders to group actors together for scenes where they might run different animations or poses.

Of course, now that I fixed one thing, a new problem has shown up that I had not seen before. My scene has two phases. Walk and then Wait. Previously, this worked reliably for NPC and PC actors. Now, the PC does not want to shift from the Walk to the Wait phase. I have a while loop that is waiting for them to complete the walk. It measures that by looking to see if the wait package exists or not on the actor. But, that is not happening. Any ideas on that one? Is there a way to force the shift via code? Because I can poll for the distance from the marker (which is less than 1) and force the switch if there is a way?

I appreciate your help walking through the different possibilities. That was a tough one!

Thank you for breaking that process down. I had not tried a set-up like that and I think that will be helpful to understand in the future. I actually had to eventually move away from the furniture method that I was using because, after getting it all working, I later discovered that it doesn't allow changing the idle a second time on NPC actors. So, it would animate the actor with a looping idle once. But, when I later went to add a switch animation functionality, only the PC would change. Using a different way to lock actors in place fixed it.

Well. Not sure whether to laugh or cry. I rebuilt my esp from the ground up, connected it to the exact same code and now it works. I ran the animation routine, exited, went and punched a nearby NPC and they had enough brains to punch me back. It was beautiful. Lesson: esp files can become corrupt without any apparent errors given in the CK. And the result of that can be bugs that seem connected to your code (and are thus very difficult to troubleshoot). Beware!

Originally, it was keeping actors in furniture that I was having trouble with. I used keywords and removed vanilla keywords and for some reason NPCs would still try to walk out of the furniture at random times. Using wait package in a scene was the only thing I found that completely locked them down. I'm sure that there is a way to do it in all contexts. But, the vanilla game has so many layers of influence going on it ends up being a matter of which strategy allows you to avoid having to dissect what keywords are being used in x,y,z case.

Thank you. That is nifty way to approach it. Though, it still doesn't seem to get us out of having to make multiple copies of the mechanic in order to have it running on a bunch of actors at the same time, dynamically chosen. Also not sure if will over-ride all of the vanilla packages the same way that scenes do. I tried a keyword scheme before and I couldn't eliminate all of the other vanilla keyword interferences.

Hm. In this case I did test the build that isn't working from a new game. So, not sure if it could be a bad save. Will double-check that. I have made various edits with FO4Edit at different times and there are odd remnants here and there that don't appear in the rebuilt version. Things like "unknown" flags set on packages.

I recreated this functionality from the ground up in a new esp. It is not a 100% copy at this point. But, with most of the code in, it seems to work. Is it possible to have a corrupt esp that would cause symptoms like I am seeing?

I removed all of the old forms. Didn't fix. Here are some screenshots of my scene settings. See anything wrong? Or, maybe there is something I can do to control/shut-them-down on top of stopping the quest?

Kind of a long shot. But, maybe it has something to do with the scenes I have in the main script quest from my old method. I'm not using them any more with the above code. But... I will clean all of that up and see if that helps. I agree that it must be some odd combination of things because I have seen this general pattern work... Maybe some package or scene settings? I will post screens of those later to see if anyone can see something there. In terms of the idle/furniture, it plays idles dynamically. So, no specific one. It is an animation framework. So, the purpose is to be able to play animations or poses from packs in a way that is easier than using the console.