What is the best way to disable or remove a trigger after it's played?

kici

When a new game starts I have certain triggers to walk the player through some Dialogues and Conversations with a few other camera movements,

Once these have played, what is the best way to ensure they are not played again, even if the player goes back to them?

I did an Object Add or Remove at the end of the Action and get this Warning (Unsure how harmful it is this way)

The ActionList 'WelcomeToLvl1' is being removed from the scene while running!  Killing it now to prevent hanging.

ChrisIceBox

The "safest" way would be to have the Trigger's Actions be located in an ActionList asset file, rather than the Trigger itself - so that when you remove it, you're not removing the ActionList.

However, you might be OK with what you have: the safeguard kicks in because you're removing an ActionList object, but if the ActionList is basically complete that point it shouldn't be a problem.

kici

Thanks Chris

kici

@ChrisIceBox just to make sure this is not doing something out of the ordinary,

I will have multiple triggers at the end that use the Add'Remove action 'remove' the trigger objects themselves so they can no longer be fiddled with within scene,

Essentially what I'm trying to get at is for the first time around within the 'level' to play the triggers, once played to not be played again,

What is the wisest most efficient way to do this? While keeping performance in mind,

Thank you

ChrisIceBox

I think I might have been caught out by your initial desire to use the Object: Add or remove Action.

If all you want to do is disable a Trigger, you merely need to send the "Turn Off" message via the Object: Send message Action.

Attaching a Remember Trigger component to the Trigger will cause it's on/off state to be recorded in save game files.  Avoiding the need to add/remove objects from a scene at runtime is best when keeping performance in mind.

kloot

While the "Object: Send message - Turn Off" solution works great while the player is in the same scene, the trigger will be enabled again the next time the player enters the scene..

What's the best way to disable a trigger permanently once it has been executed? Checking a variable in the action list itself isn't a good solution since it interrupts walking players to stop just to do nothing (if "when running" is set to "Pause Gameplay")?

It would be great if the trigger would stay turned off once the player re-entered the same scene (if the Remember Trigger component was added), or if there was an action that could enable/disable a trigger permanently.

kici

Now that I think about it, I will actually need the same thing...

@ChrisIceBox ; thoughts?

ChrisIceBox

The Remember Trigger should ensure it's enabled state is consistent when returning to the scene and save game files - that's essentially its purpose.

Are you relying on player-switching?  What are your Unity/AC versions?

kloot

I use the latest version of both Unity and AC.

And while my game utilizes player-switching, the trigger that is turned off is enabled again upon reentering the scene, even without switching players.

ChrisIceBox

Please be specific with Unity version numbers - with beta, patch releases etc, "latest" can take multiple meanings.

Is this occuring in the Editor, or in builds?  What platform are you targeting?

How about with save games?  Try saving while the trigger is on, disable it, and then load back within the same scene - does the same thing occur?

I can't recreate this in my own testing, so we'll need to see some Debug logs.  Open up RememberTrigger.cs, and paste the following on line 40:

Debug.Log ("START STATE: " + startState + " FOR: " + name, gameObject);

And then the following on what is then line 103:

Debug.Log ("LOADED DATA FOR " + name + ", IsOn: " + data.isOn, gameObject);

Leave the scene, and then clear the Console before entering it again.  When the issue occurs, what is the full output from the Console (including the stacktrace / line endings)?

kloot

Okidoke, 

Unity version: 2018.2.6
AC version: 1.64.5

The issue occurs both in the editor and in builds (PC, Mac  & Linux standalone on Windows 10).

Saving the game with the trigger set to off and then loading it worked fine - the trigger remains off. However, if the player then leaves the scene and reenters the same scene, the trigger is enabled again.

And here's the result of the trace (after having turned the trigger off,leaving the scene, clearing the console and reentering):

START STATE: On FOR: RefrigiratorTrigger

UnityEngine.Debug:Log(Object, Object)

AC.RememberTrigger:Awake() (at Assets/AdventureCreator/Scripts/Save system/RememberTrigger.cs:40)

So the load trace messaged doesn't seem to execute...

Update: Debugging the code I found the reason:

It turnes out thet RememberTrigger.LoadData() was called, but its call to Serializer.LoadScriptData() returned null. The reason is that the second scene activated FileFormatHandler_Xml as the active file format handler.

@ChrisIceBox - I'm sure you're wondering why the second scene switched file format handler?
Well it was an artifact that was mistakenly left over from an attempt of achieving this:
https://adventurecreator.org/forum/discussion/6894/optimizing-compile-time

I have tried many attempts to move AC into its own assembly in order to be able to compile my own code separately from that of AC, but none of my attempts has ended up working in any reliable way.

My absolute #1 ask for AC would be to be able to keep its code separate from my own, optimally through being able to keep it in a separate assembly. Feel free to inbox me if you would like to discuss the possible benefits of this and why all my attempts so far has failed

Thanks!

ChrisIceBox

First things first, is the original issue now resolved?

So far as separating AC's code, you can change AC's folder location so long as you also update the "mainFolderPath" string in the Resource.cs file.

kloot

Yes, the original issue is now resolved - it was I who mistakenly left the FileFormatHandler_Xml code in the second scene.

Thanks for the help!

Regarding moving AC to another folder. That doesn't solve the problem of compilation times (even when using separate assembly definition files from what I seen). Putting AC in its own separate assembly solved everything though, only it requires changes to the AC code.