Announcement

Collapse
No announcement yet.

Attaching Player to Landscape - Collision/Navigation Issues

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

  • replied
    Where/How did you place the camera?
    Are you actually using that camera?

    Use the different debug views - drop down from the "lit" section here
    https://gyazo.com/02feb36798f0d8d00948749f63815a9e
    to see what's going on. If you have simple collision, visibility collision view may help.

    If your camera is distant enough, something may not render - but with default settings, usually anything placed in level will always render

    Leave a comment:


  • replied
    Originally posted by MostHost LA View Post

    Instead of placing the player up high, play with switching cameras. You can have several cameras at the same time and you should be able to get the views to switch over nicely.
    For the character- change the camera to a child actor of type camera, so you can use the blend nodes.
    For the top-down view camera that is added - I'm not seeing any actors placed in the landscape. Understand the StaticMesh added for the Actor might be small to be visible at an elevation - so I've placed Z of the actor closer to this new Camera's Z and disabled Gravity/Physics on the actor (the Z of the Camera is 1million and rotation Pitch -90 to look-down on the landscape, and I've tried Z of Actor to be various values from 100k to 998k and still not visible).

    Is there something wrong here?

    Leave a comment:


  • replied
    Selecting the object and hitting the home key to snap it down seems like the only approach you should be using.
    just do it once, get the Z values, and use them within the script that generates it at runtime.

    Or you could, as suggested, create a simple routine to stop simulating physics on impact.

    Leave a comment:


  • replied
    Suggestions... 1. Add a HIT event to the dropped objects to disable physics once they land..... Or 2. Move the objects down without physics using only interp'd movement, such as Set Actor Location or Add Actor World Offset etc. Do this in a Loop on a Delay or use a looped Timer etc.

    For example, deduct z -100 (z = z-100) every second or so after starting with the object at the highest possible point on the landscape (working downwards). Ensure Sweep is enabled on the movement node so it stops the object from colliding with the landscape. Remember to disable the loop or timer once Z is at the lowest possible point. Using shaped Traces is another solution as well, but the other suggestions are definitely easier...
    Last edited by EntrpriseCustomr; 01-19-2020, 04:49 PM.

    Leave a comment:


  • replied
    Originally posted by MostHost LA View Post

    assuming you have no height fall damage, you can just place them very high up and simulate. They'll find the floor themselves.
    The actors are bouncing after they are landed on Landscape, and sometimes getting scattered. I need them to stay as -is (even if there is a slope / step on the landscape). In the picture given below, the Green Pyramid bounced and fell to ground. How to fix this (I played with the collisions settings but not able to figure-out)?

    Attached Files

    Leave a comment:


  • replied
    Originally posted by ClavosTech View Post

    Have you somehow parented 'Camera1' to 'Camera' in the BP components list.... So when you rotate Camera, Camera1 gets rotated too? Otherwise one shouldn't affect the other. I'd check that first as the code you've shown looks ok...
    It does - thanks for the help. It's working now.

    Leave a comment:


  • replied
    If the default Camera is looking down, the newly added Camera1 when activated is also looking down - instead, I want the Camera1 view to be always constant
    Have you somehow parented 'Camera1' to 'Camera' in the BP components list.... So when you rotate Camera, Camera1 gets rotated too? Otherwise one shouldn't affect the other. I'd check that first as the code you've shown looks ok...

    Leave a comment:


  • replied
    Thanks ClavosTech - it's working, but the Rotation seems to be from the other Camera instead of the static values set in the Event Graph (Ex: If the default Camera is looking down, the newly added Camera1 when activated is also looking down - instead, I want the Camera1 view to be always constant). Is there anything wrong with below?

    Attached Files

    Leave a comment:


  • replied
    only problem I'm having is the Mouse Events and other Action Inputs I've created are not good with the other view - is there any way to disable them in one Camera view (or should handle by setting some boolean variable to switch accordingly with Branch)?
    There is an IsActive (Camera) node IIRC, that you could add to your input handlers using a Branch.
    It would save on adding another Bool at least (its often worth having Gates to block inputs anyway).
    As the other obvious option: the Set Input series of nodes etc, come with their own quirks / gotchas...
    Last edited by EntrpriseCustomr; 01-18-2020, 06:32 PM.

    Leave a comment:


  • replied
    Thanks - Great Idea on switching cameras. I was about to go for some complex logic. Used a FlipFlop to Toggle - only problem I'm having is the Mouse Events and other Action Inputs I've created are not good with the other view - is there any way to disable them in one Camera view (or should handle by setting some boolean variable to switch accordingly with Branch)?


    Attached Files

    Leave a comment:


  • replied
    It would be very complicated to extract the correct Z for a random location.

    Here are a few options.

    1) Create a line trace at each location, make the lenght of the trace long enough to actually hit the terrain, and you can then use the hit result value as the amount t to subtract from the arbitrary Z you started the linetrace with.

    2) Take the inital Z, solve the height on the heightfield file associated with the landscape based on the position you have - very complicated really.

    3) place a box at the needed XY, set a high Z, hit home to make if fall to the landscape. Click it again and record the Z value.
    Shoudl the terrain change, you'll need to redo the values for the area where the change occurred.

    Moving on

    Instead of placing the player up high, play with switching cameras. You can have several cameras at the same time and you should be able to get the views to switch over nicely.
    For the character- change the camera to a child actor of type camera, so you can use the blend nodes.

    Leave a comment:


  • replied
    Also - Is there a way to activate Gravity for the Player based on action (like a key press)? I need to place the player at some height when the game is started, so that I've bird's eye view of the landscape - and then when I want player to walk / navigate on the landscape, would like press that button that enables gravity and the player can walk.

    Leave a comment:


  • replied
    Simulate Physics wasn't set - corrected that now.. It is working (they are back on landscape).

    As an alternative to do this right - Is there an option to "Get Landscape Location" of a particular point (and if we provide X and Y, that can give corresponding Z)?

    Leave a comment:


  • replied
    It's runtime (to set the location).

    I've tried placing them high - but they are not falling to the floor (landscape). The actor has Physics Gravity set to true.
    Attached Files

    Leave a comment:


  • replied
    Are you placing them once, or is this happening at runtime?

    If it's happening at runtime - assuming you have no height fall damage, you can just place them very high up and simulate. They'll find the floor themselves.

    If you are placing them ONCE via a construction script, choose a very high default Z, you can thn select all the actors and hit the HOME key, this will automatically push them all to the terrain similar as to how you would simulate.
    once placed, the actors will stay there until you move them.

    it may be best to drag them all up a unit or 2 after placement so that they can fall to the terrain on their own.
    avoid the possibility of anything getting "stuck" in the terrain or possible props.

    Leave a comment:

Working...
X