Delta1
September 13, 2018, 9:48am
1
Hi,
I’ve got a chain of triggers in my map, one of which (Tbox99) seems to fire randomly, I’ve tested the game a dozen or so times and it plays as expected for most of the time but everynow and again it seems to fire without any reason and prior to the player making contact with it?
First 2 images of the same beginoverlap event for trigger 98 and the 3rd image is the beginoverlap for trigger 99.
Would appreciate some help.
Delta1
September 13, 2018, 11:00am
3
Log Other-Actor to the screen when it happens or use F9 breakpoint etc…
Hi Franktech,
It’s absolutely driving me nuts as it seems to be intermittent and works fine 90% of the time.
Can you please explain your suggestion as I’m afraid I don’t really understand what you mean.
The player location is changed using a “set actor location and rotation” node but not respawned as such.
I really appreciate your help.
Delta1
September 14, 2018, 12:29pm
5
@Delta1
Is the code getting past the first Branch where you test for PC0 in the Trigger99 overlap event? Why not add some Print Strings…
Overall, its hard to tell what’s going on from your description… In general, try to be more specific about the problem and how and when it occurs… How do you know the problem has even happened, because the DoOnce trap is already triggered when the player arrives there deliberately later-on? - Use Print Strings to show when Trigger99 is being triggered (use Append to form a print-out or log the value of Other-Actor)…
Maybe you have a piece of rogue code that teleports the player into Trigger99 momentarily by accident? However, it happens so fast maybe you don’t notice it.
Maybe the player has something attached to it, that’s triggering the overlap event from far off.
Maybe you have more than one Pawn in the scene (gamemode auto-spawn plus manual spawned actor), and that’s triggering it.
Add either a bunch of Print Strings or place an F9 debugging breakpoint on Trigger99 to help… Then when the code pauses, let the mouse hover over the Other-Actor pin and look at what the value says…
Hi Franktech,
Its getting past the first branch I’ve got some print strings in there that flags up when its being fired but thats all I can make out.
how do I log the value of other actor?
The player has nothing attached to it, theres no other spawn events in the map.
For some reason (I’ve tried fault finding it using both PrintStr and Breaks, but made absolutely NO changes) and it seems to work, can I please ask if you’d kindly look at the code to see what might be causing this and if you can spot it I can avoid it in the future.
I’d really appreciate your help.
I’ve used a chain of triggers, so one trigger is moved into position after the last has been triggered and consequently removed.
Trigger98In.jpg the last image, is the code that calls the problem trigger (trigger 98) into position, BeginOverlapTrigger98A.jpg and BeginOverlapTrigger98B.jpg is the same chunk of code and is the beginoverlap for trigger98, whereas BeginOverlapTrigger99.jpg is the next trigger in the chain and thrown in for good measure
Delta1
September 16, 2018, 1:02pm
8
@Delta1
Eh, I’m beginning to ask, is this the Blueprint equivalent of ‘self-modifying-code’ or something. :eek:
Trigger box collisions being moved relatively / Player being moved absolutely. Lots of hard-coding…
Its not the code that’s really at fault here, its the whole logic / design, in short there’s nothing to find.
I’m wondering if the trigger boxes could have stayed fixed in place and had collision toggled on instead.
It’s been put together using my limited level of understanding and coding ability tbh!
I need to try the console window > show volumes though.
Logic is this put trigger in game >> on user activating trigger move it out >> put next trigger in
Delta1
September 16, 2018, 7:25pm
10
@Delta1
Put the next trigger in to do what exactly…??? You never actually say! Anyway, you know the expression, don’t move the goalposts… In game dev or practically any software dev, you try not to move the goalposts and also move the players, because it risks anomalies like you’re running into. With the notable exception of attached triggers as part of a vehicle or a deliberately moving platform etc. Normally the player moves but the triggers stay in place etc. So can you explain why you’re moving triggers in / out… Are they meant to move in front of the player or where the player is running to etc…
Or put another way… Can you explain why fixed triggers won’t cut it for your gameplay… Or why for example you can’t reuse the same trigger each time without moving it. In short, why all those triggers at all. Could you teleport a single trigger wherever you need it to be, laid out in the level using ‘Notes’ or similar actors to avoid hard-coding. If the goal is to use different triggers to house different gameplay, then why not keep track of how many times a trigger is activated or use a ‘Multigate’ or something like that… Who knows, maybe triggers are the only option for your gameplay… But I doubt it…
The triggers need to move as the game only has a single small physical environment (16M2)that must be kept the same, however the player must navigate to certain areas within it, each of these are goals that the player needs to complete continuously.
Thats why we need to move both player location and trigger position.
Hope that helps.
Delta1
September 17, 2018, 6:30pm
12
@Delta1
Helps… No, no really but makes it more intriguing I guess…
BTW: I’ve seen some strange problems sometimes with Volumes in transit being moved and generating events on the whole other side of maps (100km2 levels etc). Never tracked it down, just worked around it (UDK). The other thing I’d do in addition to Show-Volumes, is get the World-Location (Get-Actor-Location) of both the Trigger and Pawn when the Trigger is activated unexpected / erroneously, and compare it with the world location when the same event happens as wanted / as expected… As I said, just in case they’re not where they should be…
I appreciate the help thankyou!
Delta1
September 18, 2018, 5:04pm
16
@Delta1
No worries again dude…
Last thought while I think of it. Its probably a better idea to try and use Teleport or Set-Actor-Location nodes on Actors in general, instead of moving their Collision-Components. While you’d expect it to be the same thing for Volumes, because they’ve no visual / physics aspects unlike Skelmeshes / StaticMeshes etc… Its still probably a bad habit to repeat, as I suspect you’ll end with Root-Motion / Character-capsule type mismatch problems, where the collision is now far off or far away from the actual ‘visual’ bounds of the Mesh etc…
Edit - Debugging Tip:
Look at using Notes or other Actors in your level as markers as a debugging aid. Even if you just use regular meshes like simple cubes / capsules etc. You can disable them in Release and keep them hidden in Development using a Toggle button. They’re useful when you’re trying to track down tricky problems as opposed to hardcoding destination vector locations… Temporary level meshes give you instant visual clues or tell you where things are supposed to be or supposed to go like the ultimate destination of a Trigger Volume after a transition etc. Its especially helpful when actors you’re moving have rotations you haven’t properly accounted for, that may change the final location. Its also a useful approach too, for when LineTraces aren’t working and the 2D debug lines don’t really help…
I’ll be sure to look into all this, very much appreciated!
