Hello!
We're working a first person 3D game where the player can pick up and drop items.
To achieve the drop mechanism, we are running an actionlist asset that executes the following actions:
Inventory: remove
Object: add
Object: teleport (to marker)
Hotspot: enable
Object: visible
The marker is actually the player prefab with a marker script.
This seems to almost work, except that it appears that the marker used is the previous location of the player, not the current one. The video below can show it much better, please pay attention to the player's transform during the first drop interaction and then the pillow's transform during the second drop interaction, they are identical.
Does anyone know at which point the marker's transform is stored? It seems to save it after the action is performed instead of before.
Is there perhaps a feature I have missed which could resolve the issue?
Thanks for looking into it!
Comments
It would be worth discounting any colliders on the object that may be moving it away, but one thing you should look into is setting the Relative to field on the Action to Player, and then teleporting it to a scene-located Marker placed at the origin of the scene. This will cause the player's position to be added onto that of the Marker's, but due to the Marker being at the origin it will then use the Player's position completely - no need for a Marker on the player prefab itself.
It's a strange issue. I noticed mention of an "InitPlayer" error in your Console - just so I can discount anything non-AC, are you using any custom scripts that might be affecting the player?
What is the position of the player when you first pick it up inside the temple? Is there a similarity between that and where the object ends up outside?
The object does look so close to the player's old location that it probably isn't a coincidence. How is actionlistDrop being run, exactly? I would like to see a screenshot of the contents of dropPillow (both Actions and properties).
One more thing to test would be to create a "dummy" Cutscene that runs actionlistDrop (with an ActionList: Run Action) with the same parameters, which you could then run manually at any time. If the position is then correct, it'll likely be an issue with the transferral of parameters between the two ActionLists.
If the ActionList: Run Action in question is in an asset file, then only the GameObject (i.e. prefab) reference will be passed on. If it's a local Cutscene but sending to an ActionList asset file, then both the GameObject and ID number is passed on, because ID numbers are the way for assets vs scene objects to communicate.
I'll accept that it is a little fiddly, but I'm extremely hesitant to make changes to it as it's a core feature of Actions and even the tiniest change could affect (read: break) existing games and projects.
The "safe" solution, therefore, is to create a second GameObject parameter that is assigned via Constant ID number only. Since an ID number can only reference scene files, this will guarantee that its use will only affect the scene-based instance of the object, whereas the first GameObject parameter should only be used to spawn the object into the scene with Object: Add or remove.
Essentially it boils down to it literally using the same GameObject you pass as the parameter - so if that GameObject happens to be a prefab, it'll manipulate the prefab. Passing the CID number will instead force any Action that makes use of it to search for a scene object that shares that CID.