Announcement

Collapse
No announcement yet.

Trigger Firing Randomly?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Trigger Firing Randomly?

    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.Click image for larger version

Name:	t98.jpg
Views:	1
Size:	105.5 KB
ID:	1527296Click image for larger version

Name:	t99Cont.jpg
Views:	1
Size:	209.1 KB
ID:	1527297Click image for larger version

Name:	t99Cont2.jpg
Views:	1
Size:	150.5 KB
ID:	1527298



    Would appreciate some help.


    #2
    prior to the player making contact with it
    Log Other-Actor to the screen when it happens or use F9 breakpoint etc...
    It has a PC-0 check, but are you respawning or anything during this time?
    Last edited by franktech; 09-13-2018, 06:07 AM.

    Comment


      #3
      Originally posted by franktech View Post

      Log Other-Actor to the screen when it happens or use F9 breakpoint etc...
      It has a PC-0 check, but are you respawning or anything during this time?
      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.

      Last edited by Delta1; 09-13-2018, 12:50 PM.

      Comment


        #4
        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)...

        1. 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.

        2. Maybe the player has something attached to it, that's triggering the overlap event from far off.

        3. 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...

        Comment


          #5
          Originally posted by franktech View Post
          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)...

          1. 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.

          2. Maybe the player has something attached to it, that's triggering the overlap event from far off.

          3. 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

          Last edited by Delta1; 09-14-2018, 11:43 AM.

          Comment


            #6
            Click image for larger version

Name:	BeginOverlapT98A.jpg
Views:	1
Size:	144.1 KB
ID:	1527795Click image for larger version

Name:	BeginOverlapT98B.jpg
Views:	1
Size:	121.9 KB
ID:	1527796Click image for larger version

Name:	BeginOverlapT99.jpg
Views:	1
Size:	225.6 KB
ID:	1527797Click image for larger version

Name:	Trigger98In.jpg
Views:	1
Size:	131.0 KB
ID:	1527798

            Comment


              #7
              Delta1
              Originally posted by Delta1 View Post
              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
              Eh, I'm beginning to ask, is this the Blueprint equivalent of 'self-modifying-code' or something.
              Seriously.... This just doesn't seem like a wise or extendable solution you can build on dude.
              What was the original problem exactly. What's the actual goal here. Why take this approach?

              Trigger box collisions being moved relatively / Player being moved absolutely. Lots of hard-coding..
              Have you tried turning on ConsoleWindow -> Show Volumes to debug this. If so what does it show?
              This can't end well imo. How did you arrive at this point, did someone steer you down this road???

              Its not the code that's really at fault here, its the whole logic / design, in short there's nothing to find.
              Its impossible for me to Debug any of this, when I can't even picture what its really supposed to do...

              I'm wondering if the trigger boxes could have stayed fixed in place and had collision toggled on instead.
              Or gates used or something like that. A video would probably help to see what you're trying to achieve.
              Last edited by franktech; 09-15-2018, 02:05 AM.

              Comment


                #8
                Originally posted by franktech View Post
                Delta1


                Eh, I'm beginning to ask, is this the Blueprint equivalent of 'self-modifying-code' or something.
                Seriously.... This just doesn't seem like a wise or extendable solution you can build on dude.
                What was the original problem exactly. What's the actual goal here. Why take this approach?

                Trigger box collisions being moved relatively / Player being moved absolutely. Lots of hard-coding..
                Have you tried turning on ConsoleWindow -> Show Volumes to debug this. If so what does it show?
                This can't end well imo. How did you arrive at this point, did someone steer you down this road???

                Its not the code that's really at fault here, its the whole logic / design, in short there's nothing to find.
                Its impossible for me to Debug any of this, when I can't even picture what its really supposed to do...

                I'm wondering if the trigger boxes could have stayed fixed in place and had collision toggled on instead.
                Or gates used or something like that. A video would probably help to see what you're trying to achieve.
                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

                Comment


                  #9
                  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...

                  Comment


                    #10
                    Originally posted by franktech View Post
                    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.

                    Comment


                      #11
                      Delta1

                      Helps... No, no really but makes it more intriguing I guess... If the level was absolutely huge, moving triggers around might make more sense (think Epic's Kite demo etc). But for a small level, why wouldn't you just use lots of fixed triggers.... I guess you have to see the level to know. Either way, check the bounds of the Trigger Volumes at runtime (Show Volumes) as hinted above, which I think you plan on doing anyway.... You never know! Just in case where you picture the trigger in code, is not where it actually is in world space at that moment in time.

                      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...

                      Comment


                        #12
                        Originally posted by franktech View Post
                        Delta1

                        Helps... No, no really but makes it more intriguing I guess... If the level was absolutely huge, moving triggers around might make more sense (think Epic's Kite demo etc). But for a small level, why wouldn't you just use lots of fixed triggers.... I guess you have to see the level to know. Either way, check the bounds of the Trigger Volumes at runtime (Show Volumes) as hinted above, which I think you plan on doing anyway.... You never know! Just in case where you picture the trigger in code, is not where it actually is in world space at that moment in time.

                        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!

                        Comment


                          #13
                          Originally posted by franktech
                          Delta1

                          No worries 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 bounds of the Mesh etc...
                          Thanks again Frank!

                          Comment


                            #14
                            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...
                            Last edited by franktech; 09-17-2018, 06:27 PM.

                            Comment


                              #15
                              Originally posted by franktech View Post
                              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!

                              Comment

                              Working...
                              X