How to make Player use PathToReference?

[dagobaking]

Do you mind if I ask what you've found to be atrocious about the package system? I've also had a LOT of trouble with them over the last few months and I was starting to think I was crazy! =)

 

Heh. Sure!

 

My main gripe is that I am forced to use a proprietary visual tool (creationkit) to access core game features. As a developer, I would much prefer to handle those things in code as the creationkit is basically a hand-holding tool created so that Bethesda can hire non or psuedo-developers to help build out content. It makes sense from their perspective. But, is just clunky and sometimes inflexible for code-heavy modding.

 

Package specific complaints:

 

There is no Papyrus command for setting a players package. So, you have to jump through several creationkit hoops (using aliases, some kind of quest or spell casting strategy, etc.) just to dynamically change a characters behavior with code. This just adds a lot of overhead and limitations to what can be done from code.

 

There is also the keyword system that I feel adds to the confusion. There are so many keywords flying around and scripts affecting them that its always a question. "Is this not working because of a keyword I didn't know about?"

 

What are the issues you have had with them?

Edited March 15, 2018 by dagobaking

[NikaCola]

 

Do you mind if I ask what you've found to be atrocious about the package system? I've also had a LOT of trouble with them over the last few months and I was starting to think I was crazy! =)

 

Heh. Sure!

 

My main gripe is that I am forced to use a proprietary visual tool (creationkit) to access core game features. As a developer, I would much prefer to handle those things in code as the creationkit is basically a hand-holding tool created so that Bethesda can hire non or psuedo-developers to help build out content. It makes sense from their perspective. But, is just clunky and sometimes inflexible for code-heavy modding.

 

 

 

That makes a lot of sense! I don't have any kind of development background at ALL, so I guess I never thought of it like that before. I did notice a few times that there appeared to be papyrus functions for doing things that packages also covered, but I was never able to get them to work quite as "well" as packages. (blech now it feels gross just to type that lol)

 

 

 

What are the issues you have had with them?

 

For me I feel like my main struggles with them have been that they just seem to break randomly! Like, I'll make a simple travel package for an NPC to walk over to an xmarker during some scene, and if I change ANYTHING about that scene at all, the package starts to run inconsistently or not at all. (and also like you were mentioning the NPC with that package never want to face the right way, even if you tell them to!) I find myself having to delete packages and create new ones just to fix a minor change like moving a scene phase around or adding a new actor to a dialogue scene. Plus I've found that I can't edit packages once they are created. Any edit to them seems to break them completely, which is really frustrating to have to create a new one every single time I want to change something as simple as walk/movement speed or add/remove a condition!

 

Anyway I hope that makes sense, and thank you for letting me vent. :happy: There's no documentation about this stuff anywhere which makes it more frustrating, or feels like I'm just going crazy or doing something wrong a lot of the times. :ohmy:

[SKKmods]

 

There is no Papyrus command for setting a players package. So, you have to jump through several creationkit hoops (using aliases, some kind of quest or spell casting strategy, etc.) just to dynamically change a characters behavior with code.

 

 

I have just been through this loop to get NPCs to transition from ambush, sneak, walk, jog, run depending on factors.

 

Ended up with a package for each on a Quest RefCollectionAlias with the conditions set to a GlobalVariable value. With the Global set in code and EvaluateAll() on an aggressive 2-5 second timer its an OK code solution. There's a stack of lag so not real-time smooth response, but best the platform can offer.

 

Aside - using Globals for state flags is probably not memory optimised, but gives less problems than :: script variables.

[dagobaking]

 

 

Anyway I hope that makes sense, and thank you for letting me vent. :happy: There's no documentation about this stuff anywhere which makes it more frustrating, or feels like I'm just going crazy or doing something wrong a lot of the times. :ohmy:

 

 

Word. I share your pain. On the other hand, we probably shouldn't lose sight of the fact that these tools are way more than most (if not all) other games offer for modders. So, something is better than nothing? :)

 

I just think that there is a huge market for modding. So, the tools should reflect that market and be more polished and complete. Some company is going to invest in going all out on their mod tools and it will pay off.

 

There should be some very common sense functions available. "RemoveAllPackages" or "PackageOverride". "WalkToPosition". "FaceDirection".

 

 

 

There is no Papyrus command for setting a players package. So, you have to jump through several creationkit hoops (using aliases, some kind of quest or spell casting strategy, etc.) just to dynamically change a characters behavior with code.

 

 

I have just been through this loop to get NPCs to transition from ambush, sneak, walk, jog, run depending on factors.

 

Ended up with a package for each on a Quest RefCollectionAlias with the conditions set to a GlobalVariable value. With the Global set in code and EvaluateAll() on an aggressive 2-5 second timer its an OK code solution. There's a stack of lag so not real-time smooth response, but best the platform can offer.

 

Aside - using Globals for state flags is probably not memory optimised, but gives less problems than :: script variables.

 

 

Thank you for the insight.

Can't this be done without polling code on a timer? That seems pretty drastic. I think I've seen solutions that did not require that.

 

To clarify, are you starting a new quest for each character that you are applying it to? Or, is it one quest and you fill in aliases with actors as you need to affect them?

[SKKmods]

I would love to not use timers, but if there is an event that will fire on distance deltas to trigger NPC speed up or slow down I have yet to find it.

 

If you have an event or trigger suggestion with a cycle time of around 3 seconds to trap a 1,000 game unit distance change for a team of 1 to 8 chars running at up to 350 units per second I would be grateful.

 

Its just one quest with one ReferenceCollection that has the travel packages attached and is reused for each hostile team spawn.

[dagobaking]

I would love to not use timers, but if there is an event that will fire on distance deltas to trigger NPC speed up or slow down I have yet to find it.

 

If you have an event or trigger suggestion with a cycle time of around 3 seconds to trap a 1,000 game unit distance change for a team of 1 to 8 chars running at up to 350 units per second I would be grateful.

 

Its just one quest with one ReferenceCollection that has the travel packages attached and is reused for each hostile team spawn.

 

Aha. I was thinking of the context of my mod where the value could be set at convenience. I thought you were saying that evaluatepackage must be run that often just to keep the characters doing what they are supposed to.

 

It sounds like you have unique circumstances requiring the timer.

 

So, instead of having a dozen separate referencealiases I can have the one referencecollection and add any actor to it that needs the special package behavior? How would I make each individual walk to a different marker? A second referencecollection of markers?

[JonathanOstrus]

 

I would love to not use timers, but if there is an event that will fire on distance deltas to trigger NPC speed up or slow down I have yet to find it.

 

If you have an event or trigger suggestion with a cycle time of around 3 seconds to trap a 1,000 game unit distance change for a team of 1 to 8 chars running at up to 350 units per second I would be grateful.

 

Its just one quest with one ReferenceCollection that has the travel packages attached and is reused for each hostile team spawn.

 

Aha. I was thinking of the context of my mod where the value could be set at convenience. I thought you were saying that evaluatepackage must be run that often just to keep the characters doing what they are supposed to.

 

It sounds like you have unique circumstances requiring the timer.

 

So, instead of having a dozen separate referencealiases I can have the one referencecollection and add any actor to it that needs the special package behavior? How would I make each individual walk to a different marker? A second referencecollection of markers?

 

 

No, for that you'd need different ref aliases and a diff package with the alternate marker on that alias. If you want them all to walk to the same marker you can use a collection. This is just how the game engine was designed to function. You're supposed to use a bunch of aliases, bunch of packages, and bunch of markers targeted by the packages.

 

A sort of hack that might be closer to what you want however is to use ApplyToRef(ObjectReference akRef) to apply the alias details to a reference without putting them in the alias. So you could do something like make 10 aliases which have one of 10 packages that point to one of 10 different markers. Then via script just RefAlias01.ApplyToRef(SomeActor01) then do a SomeActor01.EvaluatePackage() and they'll go on off based on whatever the packages of the refalias you used was. You still have to define an alias, package, and marker in CK but you can script who gets what when and have multiple that way if necessary. Though I don't know why you wouldn't just make them all collections and then add the actors to the collection.

[dagobaking]

 

No, for that you'd need different ref aliases and a diff package with the alternate marker on that alias. If you want them all to walk to the same marker you can use a collection. This is just how the game engine was designed to function. You're supposed to use a bunch of aliases, bunch of packages, and bunch of markers targeted by the packages.

 

A sort of hack that might be closer to what you want however is to use ApplyToRef(ObjectReference akRef) to apply the alias details to a reference without putting them in the alias. So you could do something like make 10 aliases which have one of 10 packages that point to one of 10 different markers. Then via script just RefAlias01.ApplyToRef(SomeActor01) then do a SomeActor01.EvaluatePackage() and they'll go on off based on whatever the packages of the refalias you used was. You still have to define an alias, package, and marker in CK but you can script who gets what when and have multiple that way if necessary. Though I don't know why you wouldn't just make them all collections and then add the actors to the collection.

 

 

Thank you. I'm not against using collections. That would certainly be better than serializing a bunch of aliases.

 

But, it's not clear to me how easy (or possible) it would be to use a collection and have each actor in the collection going to a different marker.

 

I know that I can serialize all of this and make "slots" to fill in. I'm just seeing that as a last resort. As a developer, it makes my brain want to explode. :D

 

What about spells? Would there be a way to apply packages via a spell? Then there wouldn't be a need to serialize.

[JonathanOstrus]

Thank you. I'm not against using collections. That would certainly be better than serializing a bunch of aliases.

 

But, it's not clear to me how easy (or possible) it would be to use a collection and have each actor in the collection going to a different marker.

 

I know that I can serialize all of this and make "slots" to fill in. I'm just seeing that as a last resort. As a developer, it makes my brain want to explode. :D

 

What about spells? Would there be a way to apply packages via a spell? Then there wouldn't be a need to serialize.

 

Unfortunately the only real way I see to do what I think you want to do is to serialize it. That's just the way the engine and tools were designed to work.

 

That's what I was trying to say, you don't. Everyone in the Ref Collection will have the same packages applied that the collection has. As well as any other parameters set by the collection. If you want to have each actor going to a different marker you have to use different collections or separate aliases. You could use the ApplyToRef() function to put the data of an alias/collection on an actor without putting them in the alias/collection but I don't think it would make much difference for the use case you have.

 

To be clear things would work out something like this if you wanted:

 

Collection01 has Package01 points to Marker01

Actor01

Actor02

Collection02 has Package02 points to Marker02

Actor05

Collection03 has Package03 points to Marker03

Actor04

Collection04 has Package04 points to Marker04

Actor03

Actor06

Actor07

 

Just keep in mind once you're done with the actors you either need to shutdown the quest or clear the collections so they don't remain persistent (unless something else is holding them).

Edited March 17, 2018 by BigAndFlabby

[SKKmods]

^ what he said, you must implement your own proactive (if spawning then super aggressive) scavenging of references out of aliases to release the resources to avoid pestilence and resource famine effects. Most of my spawning code is accounting watchdogs and scavenging rather than fun.

 

As I'm on a roll ... if you hook up resource monitors you will see that the memory/compute/thread resources allocated to and used by the Fallout game engine don't get anywhere near the OS/hardware available on a sensible system, and of that the Papyrus script processor budget allocation is tiny. OK not "8088 16K RAM manage your bit registers" tiny, but surprisingly small for the amount of stuff that runs to try and deliver near real time interactive entertainment experiences. Ah ! that's better ...