Safest way to deal with the vanilla random encounter markers?

[DiodeLadder]

Hi guys,

 

I'm wondering what is the safest way to move the vanilla random encounter markers out of their original locations. The location I've picked for a settlement unfortunately contains a group of RE markers, and I'm hoping to move these to the adjacent cells. Keeping them in the original positions and disabling them is another option (the location reference will change for these markers in this case). Simply moving them to the new cells seems to cause warnings to pop up, saying that the references are not in the original cell. I don't have a good understanding of how these things work, and I am hoping somebody can explain the safest way to deal with them before I do something stupid, lol.

 

Thanks! :-)

[SKKmods]

If you want he RE system to keep working after moving the markers into other locations, you need to update and save the location data \Worlddata\Location, but changing base game data ... Grrrr.

 

More elegant would be to find the big red trigger box activator based on RETrigger* and disable that, which will prevent the story manger from using that location to kick events off.

 

;RETriggerObject

;RETriggerScene

;RETRiggerTravel

;RETriggerCamp

;RETriggerCheckpoint

;RETriggerChokePoint

;RETriggerAssult

;RETriggerSecondary

[DiodeLadder]

Ah, I was hoping that you'd show up! Thank you SKK.

 

So, if I did my homework correctly -

 

The Story Manager picks up on an event that the player is approaching the trigger, and the SM would pick and start a RE quest, which would then start filling the aliases and spawn them using the xmarker headings. So, disabling the trigger would prevent the SM from starting the whole thing. Is this right?

 

....I don't understand why the "Location" info is so important for the xmarkerheadings, though? I mean, aren't they identified using the linked reference from the trigger, instead of the location data? I don't think I have a good understanding of this whole "Location" thing. The "CommonwealthLocation" is marked as edited, because the cells these xmarkerheadings and the trigger are located in are now my custom location for a settlement. I guess I can safely ignore the warnings of "Special ref Xmarkerheading no longer in location" at startup since the trigger is disabled and SM won't start? Up to this point, I've always kept the <CURRENT> warnings to zero. :-/

[SKKmods]

Yes the trigger kicks the story manager which starts the quest.

 

Look at \Worlddata\Location\FortHagenLocation\LocationRefTypes

 

These are used by some quests to find locations to run from. If you break the integrity of that model by moving objects or markers that have a locationreftype, aliases wont fill and quests fail. Logic can look like "find me an xmarkerheading in an uncleared location that has a map marker between 10K and 50K units from the player."

[DiodeLadder]

Thank you, SKK! I understand better why you advice against moving these things around.

 

I think I am going to just create a test RE quest, so that I can get a better understanding of how all this works. It's a very important part of Bethesda game mechanics, and I gotta learn this.

[SKKmods]

Whilst your looking up RE sneak a peak at the EMSystemTurfScript directly attached to trigger volumes which looks like an early quest free instance of the RandomEncounter system.

 

Some interesting approaches in that.

[DiodeLadder]

Thank you for the pointer! I'll definitely look into it, as I really need to get up to speed on spawning varied enemies for repeatable gameplay. :smile:

Edited December 17, 2018 by DiodeLadder

[SKKmods]

EMSystemTurfScript uses statically placed actors and is one of the few base game scripts that uses EnableAI(), which was clearly an early attempt to reduce the compute load of active actors, probably before the game stopped managing them when they unload.

Two ways to dynamically spawn;

(1) Start a quest with quest alias to find a marker and another alias to Create RefToObject at the marker alias. Can find markers anywhere in the world, but low configuration option s on the actor.

(2) Run a script to FindAllReferencesOfType() and PlaceActorAtMe(). Will only find markers in the 10K uGridsToLoad active area around the player.

or a combo platter, where you start a quest to find the markers anywhere in the world and then script the PlaceActorAtMe() for granular configuration.

Many many hours of fun here. Oh and after some messing about you will understand all the spawning UX issues in Fallout 76 (if you care).

[DiodeLadder]

Thank you SKK for taking your time explaining this!

 

This SendToSleep/WakeUp treatment of AI in the EMSystemTurfScript is very interesting. Do you think this would be useful for building interior cells like Mass Fusion or Greenetech Genetics, where you have many floors vertically stacked in a small area? Err, I mean, say if I wanted to create an even taller building in such a fashion with more enemies as a quest location, I can lighten the system load by turning off their AI while the player is > 2 floors away, for example? If I make the building explorable without killing anyone by sneaking, this might potentially be very useful.

 

I was able to find a tutorial on the RE method #1 you listed, and I think I am going to start with that one, as I have a plenty of examples I can follow in the vanilla game.

 

Thanks again. :smile:

[SKKmods]

I would not worry about managing actor AI, which disables when 3d unloads between uGridsToLoad and fLODFadeOutMultActors.

I have observed the game system handling up to 128 actors in intense combat when no additional actor scripts are involved. Well, except my logging instrumentation scripts of course.

Adding scripted actor event registrations and logic, like mods which load on the AI processing to manage real time behaviours, will reduce that number.