Jump to content

How to add Packages to AI Driven player?


Roggvir

Recommended Posts

I made a travel package (that does work on an NPC) and added it to a quest alias (quest priority set at 100, just in case).

Then i fill the alias with player, and then i SetPlayerAiDriven(true) ...and player just stands still.

 

Console command GetIsCurrentPackage shows that the player is NOT running my package.

I even added Trace messages to the package's OnStart/End fragments, but no traces in the log - So, clearly, the package wasn't even added to the player.

 

It worked in Skyrim (at least i vaguely remember doing it kind of like this), but clearly not in Fallout 4.

How is this supposed to be done???

Link to comment
3 minutes ago, CPU said:

After setting the AI driven and the alias, use the line: PlayerRef.EvaluatePackage()

This will force package recalculation for the player

Yes, using that too, even tried "evp" in console, just in case.

 

Are you 100% positive this should work? (isn't this yet anotehr thang that "used to work, but not anymore"?)

Could you summarize ALL the steps that needs to be done? I am clearly missing something.

Maybe i need specific package settings? (i tried all kinds of flag combinations, that i just dont know whats what anymore).

 

Currently the package is set as follows:
- Flags: Must Complete, Allow Swimming, Aggro Radius Behavior, IdleManager: Block Idles, Load Into Furniture (what is this? i noticed some vanilla travel packages use it, so i set it too)

- Conditions: nothing

- Schedule: nothing

- Begin/End/Change: fragments with simple Debug.Trace() messages

 

Package consists of single "Travel" procedure:

[-]..Sequence

            |_____Procedure: Travel

 

"Success Completes Package" is checked

Destination is set to RedRocket location (dont recall the exact name, but its valid and ok).

Prefered Path: False

Soft Radius: True

Ignore Heading: True

 

 

Quest is run and player alias gets filled when i activate the script (using "sqv" in console verifies all this).

 

The only effect i see is the player being unable to move as he is now AI Driven, but like i wrote in previous post - package doesnt seem to be run at all.

 

 

Link to comment

I just tried to use the package on Codsworth in Sanctuary - BEFORE player meets him for the frist time.

 

I started the game, used "coc SanctuaryExt" and then activated my quest/script, and...

and Codsworth didn't moved an inch.

- SQV verified that all quest aliases are filled.

- GetIsCurrentPackage shown that Codsworth is NOT running my package.

 

INTERESTINGLY, after i engaged in dialog with him and let him massacre all those Bloatflys,

right after he was done with it, my package kicked in and he started traveling.

So, SOMETHING was blocking him from running my package, which is strange, because my pacakge comes from alias on quest having priority of 100 - there is no Codsworth related quest that would have even the same priority to override my packages due to... i dont know.

 

Anyway, this got me thinking - maybe the same thing that was blocking codsworth, is blocking Player? ...must do more tests.

Link to comment
29 minutes ago, CPU said:

Try priority at 99 and not at 100.

No difference.

 

btw. I also added bunch of vanilla packages to that Alias - none of them is running.

It is like the game is completely ignoring the package stack on the alias (but only if i fill it with player, npcs work).

Link to comment
3 minutes ago, CPU said:

I am not sure.

Try also the command DisablePlayerControls() if you didn't use it.

 

Yep, had that. I was actually trying it wihout it just now.

 

travelAlias.ForceRefTo(PlayerRef)
ctrlLayer.DisablePlayerControls()
Game.SetPlayerAIDriven()
PlayerRef.EvaluatePackage()

 

...i also tried changing order of the first three lines - every combination (with and without disabling player ocntrols) - no change.

Link to comment

By default, the Alias is set in CK to point to Codsworth for testing.

Without changing ANYTHING except commenting out the line where i force Player into that Alias - it works, Codsworth travels to the static marker.

But if i put player into that Alias - he does not run ANY packages i try to give him via the Alias.

Link to comment
2 minutes ago, CPU said:

Just to try, change the order of things:

 

Game.SetPlayerAIDriven(true)
travelAlias.ForceRefTo(PlayerRef)
ctrlLayer.DisablePlayerControls()
PlayerRef.EvaluatePackage()

 

Yep, i mentioned i tried every combination of those first three lines (keeping the fourth line with EvaluatePackages() always last).

 

EDIT: i just noticed you wrote "Game.SetPlayerAIDriven(true)", where as i was using simply "Game.SetPlayerAIDriven()" - which should be the same as the true is supposed to be default, and indeed the player switches to ai driven in the game, BUT ...this is Bethesda's game, one cannot always rely on common sense :smile: - i'll trye with passign the "true".

Link to comment

I don't think it will make a difference.

"true" is the default option, and the actual compiled PSX will be the same in both cases.

 

I was doing, long time ago, before F4SE, a different approach to force the player to do stuff.

I was creating a Scene inside a quest, with a single actor (the alias of the player) and a single phase with just the package I wanted.

In this case, assigning the player to the alias, and then force-starting the scene, was making the player to do the tricky package.

 

But was about 2 years ago.

Link to comment

Well, as expected, having SetPlayerAIDriven(true) isntead of just SetPlayerAIDriven(), made no difference - both have the same result of the player becoming ai driven (although still not running packages).

 

Could it be osmething how the alias is set up?

I tried it having as "Unique Actor" and "Specific Reference".

Flags: Allow Reuse in Quest, Optional, Allow Reserved.

 

I even tried checking "Can Apply Data to non-aliased Refs", and then using ApplyToRef() instead of filling the alias with player - but still no packages run.

This is driving me CRAZY.

Link to comment

I made it into a scene, using the same unchanged package, and script with added myScene.Start(), and it instantly works.

THANK YOU VERY MUCH!


btw. so, does this mean that we have to make these damn scenes for everything where player is involved?

That is just horrible! It's like Beth is making things worse with each game iteration they release. I want to kick something :classic_angry:

Link to comment

One more thing for anyone who might find that usefull...

 

When using a SCENE, do not rely on IsPlaying() to check whether the scene is actually playing or not.

Unless i have the things set up very wrong, there seems to be a bug causing this function to keep returning true even after the scene ended.

 

I added a scene script with Trace messages inside OnBegin, OnEnd, OnPhaseBegin, and OnPhaseEnd events, so i can see what the scene is doing.

And the log shows:

 

[02/18/2018 - 11:48:00AM] [Rogg:SceneTest < (0B00175B)>] : OnBegin()
[02/18/2018 - 11:48:00AM] [Rogg:SceneTest < (0B00175B)>] : OnPhaseBegin()
[02/18/2018 - 11:50:04AM] [Rogg:SceneTest < (0B00175B)>] : OnPhaseEnd()
[02/18/2018 - 11:50:05AM] [Rogg:SceneTest < (0B00175B)>] : OnEnd()
[02/18/2018 - 11:50:05AM] [Rogg:TestQuest <RoggTestQUST (0B000F99)>] : testScene.IsPlaying() return value: 1

 

...now how the hell is the last message showing that Scene.IsPlaying() is True, if everything is clearly finished?

Unless someone can explain this to me, i'd say stay away from that function and find other means of checking for the scene playing or not (ie. scene script with On* event handlers where you set some "isRunning" property accordingly).

Link to comment

All code inside a scene will return isPlaying==true also the OnEnd code that is executed just before the scene ends.

IsPlaying should be used outside the scene code to get a valid result.

Link to comment
23 minutes ago, CPU said:

All code inside a scene will return isPlaying==true also the OnEnd code that is executed just before the scene ends.

IsPlaying should be used outside the scene code to get a valid result.

 

[02/18/2018 - 11:50:05AM] [Rogg:TestQuest <RoggTestQUST (0B000F99)>] : testScene.IsPlaying() return value: 1

 

...this last line is from a QUEST script, not the SCENE script - so, shouldn't that be considered "outside the scene code"?

but then again, the scene is on this quest, so i guess that makes the whole quest script "inside the scene code" then?

Link to comment

No. Quest code is not scene code.

Keep in mind that a scene may need a few seconds to fully end.

Add a debug.trace("ended") in the OnEnd fragment of the scene. And compare when it is printed with your checks with IsPlaying.

Link to comment
1 minute ago, CPU said:

No. Quest code is not scene code.

Keep in mind that a scene may need a few seconds to fully end.

Add a debug.trace("ended") in the OnEnd fragment of the scene. And compare when it is printed with your checks with IsPlaying.

You think the OnEnd EVENT is called while the Scene is still considered playing, but the "On End" fragment would be called when the Scene is actually fully stopped?

...i'll test this more later and report back once i do.

 

Link to comment

Ok, after a bit of testing, i can only confirm what you said about the Scene.IsPlaying()

 

If called too fast after receiving OnEnd EVENT, it will still return True - which makes sense if the event is sent just before the Scene ended (when it is about to end, and not after it actually ended), which clearly is the case here.

That leaves two options:

 

1.) use a timer to periodically check IsPlaying() until it finally returns False

2.) use "On End" Fragment to do what needs to be done (too clunky in my particular case), or to send a custom event from it.

 

Tough choice when one solution is crap, and the other one is shit :smile:

But since i passionately hate fragments, i'll just be bad and use the timer.

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use