3rd person - magic item - indicator prefab not showing on terrain as it should.

R

River

New member
My set-up is 3rd person top-down, with mouse disabled and vertical look direction (so I can shoot the ground at my feet).

The issue resides in the magic item script - magic - Direction - selected 'indicate' with the surface indicator prefab:
During play the indicator does not appear on the terrain, only when looking at a e.g. crate. On a cube it simply slides of the sides, when on it, it doesn't appear on the surface. - I'm stumped.

The indicator object gets essentially disabled whenever not on the crate or on the side of the cude. When I add the 'teleport' in the cast action the indicator does not show up at all. This is all quite frustrating, no leads on google either.

So it appears the indicate ray-cast is somehow filtering, but the detect layers are set to default and the crate, terrain and the cube are all on the default layer. Could be the look source, which I assume is on the camera, should be high up enough not to just raycast to the side of things.
Any suggestions?

Many thanks,
 
The Surface Indicate is positioned based on the Magic Item's cast parameters. The best way to figure out why it isn't hitting the terrain is to place a breakpoint within MagicItem.LateUpdate. The DetermineCastValues returns a position/rotation of the hit object and it sounds like something within that method isn't returning the position that you'd expect.
 
Hi Justin, as update I gave up on the item script - magic - Direction - selected 'indicate' with the surface indicator prefab.

I simply created a new enum for the castdirection which I specified to be a raycast from the main-camera to the mouse position. That works.

Cheers,
 
Dear Support,

See above, I have a way-around the teleport issue, but want to have this issue properly resolved since it may affect other systems/magic items in the future.

I have continued with my fresh install (only UCC, 3rd person top-down, camera 3rd person top-down) and added modified the TopDown.cs with the code... if (!m_Aiming && !m_PlayerInput.IsCursorVisible()) {

Next I followed the Teleport video to the letter. The indicator prefab does not show and the SurfaceIndicator (child to the Teleport with transform reset) is disabled when the Magic Item script is set to 'indicate'. The disabling I image is due to the fact it cannot get a raycasthit.

As suggested I checked the layers of the floor* - these are set to default, the Detect layers of the Magic, Indicate, Detect Layers is set to Mixed, which include the default as a layer.

The Nolan character is set-up with default values for 3rd person (top-down) only, with as mentioned only the following changes:
(Unity Input): Disable Cursor is unchecked.
(Camera Controller): View Type = Third Person Top Down - Vertical Look Direction is enabled.
The Teleport ability is set up only as 3rd person item.
Ofcourse The project is otherwise set-up correctly (i.e. include layers, input etc...).

*I tested both a plane and a terrain seperatley as default ground layer both with Navemesh baked in. Aside from the plane/terrain and the Nolan character the Game scene is just that.

Again if it is not just me doing something overly stupid, you should be easily able to reproduce this issue yourself in a few minutes.

Please let me have your valuable insights to resolve.

Thanks.
 
River said:
modified the TopDown.cs with the code... if (!m_Aiming && !m_PlayerInput.IsCursorVisible()) {
Click to expand...
Not sure what you mean by this - in the TopDown movement type or view type script? And where have you put this code and why?

As Justin suggested, MagicItem.LateUpdate is where the surface indicator raycast logic happens, so your best bet would be to put a breakpoint or Debug.Log in there to see where the issue is (e.g. if the cast is invalid).
 
What was your workaround?

When I am in a first/third person view the indicator properly shows on the terrain so I think that it's more related to the top down view rather than the terrain.

The indicator position is determined by the crosshairs so with a third person view the standard crosshairs is disabled. This fix will likely be tied to allowing the crosshairs to be visible at the pointer location. I am trying to get an update out this week and will try to get it in that version, otherwise if it turns out to be a bigger change it'll be in the next version.
 
Last edited:
Hi Andrew, thanks for your response

As to the First point: the script update was based on another issue - please have a look at the tread topic '3rd person top-down - look to mouse not working'. - Justin was actually the one suggesting the script change.

As to the current issue:

The cast is working but does not return a hit to the floor (the prefab indicator parented to the Teleport Item on the character is disabled). One of my earlier tests (in a different project, not the current clean UCC test one) was with a crate in the scene and observed that 'The indicator object gets essentially disabled whenever not on the crate or on the side of the crate.' So it apparently it can hit objects on the default layer, but only see the sides of objects in the scene (placed atop the ground floor).

So the cast works but it can't find the ground floor. This is due to, as I currently suspect, the cast direction is from the player's head going parallel to the ground surface (so yes it won't find the floor and yes it then would be able to see the side of things). Indeed I checked in code the direction of the raycast being send (I remember it being parallel, but this was a while ago - I can look again at this if you find this useful and provide the data).

This may be associated with another observance: when (Camera Controller): View Type = Third Person Top Down - Vertical Look Direction is enabled I can shoot down on the ground. However, it does not appear that the players heads looks down as well (as in e.g. the pseudo 3d setup). Would the Physics Sphere Raycast indeed be cast from the look-direction of the player (and not from the camera position), which seems a possibility, then of course if not looking down, the look direction from it as it won't touch the floor).

So what could causing the issue is possibly that the ray is not cast from the camera position in this set-up, but as mentioned from the player's head, which does not look to the ground but only straight ahead.

As also mentioned, when doing a custom cast (by building my own custom targeting script using a cast assuredly from the camera it could find the ground).

In summary - when the Magic Item script is set to 'indicate' it essentially successfully raycasts, but appears not to be directed properly. This issue occurs in a new and clean Project with default settings for top-down 3rd person only, (not including any 1st person set-ups), using the default Nolan model.

I think it would be highly beneficial if you can briefly repeat a clean-project set-up for 3rd person top-down only and test this out yourself. Either you find the issue yourself, which would be good for the Opsive team to be aware of. I merely speculate, but it appears the Opsive team relies quite a bit on checking if everything works for the Demo scene (and not necessarily from each specific project set-up). This makes sense but as with the 3rd person top-down - look to mouse not working' this may hide some interesting behaviors.

As to your suggestion: As Justin suggested, MagicItem.LateUpdate is where the surface indicator raycast logic happens, so your best bet would be to put a breakpoint or Debug.Log in there to see where the issue is (e.g. if the cast is invalid). - as you can understand from the above I did already made quite some debugging.logs to make some sense of it. Other then that, since my set-up is as barebones/default and simple as it gets (using only assets included in the UCC pack, the issue is interesting. For example I could image issues when using different camera's and/or character set-ups then the default ones - but this is not the case.

Thanks,


​

 
Edit - only now see the reply of Justin of about the cross-hairs. Somehow missed that. If the indicator position is determined by the cross-hairs than the issue makes a lot of sense since the crosshairs don't work in this set-up either. The solution would be rather simple: if the targeting relies on the position of the cross-hairs than they should move with the mouse (by inheriting its position from the mouse cast to ground). would be great if this could be included in the next update.
 
Edit: For completion as to my earlier workaround - I can look up the exact code I used, but I do have a full-time job and arrangements this evening - I could provide, but not before Wednesday evening. - Let me know if you still want to have (it was a while ago), will be my pleasure to help if I can.
 
River said:
Edit: For completion as to my earlier workaround - I can look up the exact code I used, but I do have a full-time job and arrangements this evening - I could provide, but not before Wednesday evening. - Let me know if you still want to have (it was a while ago), will be my pleasure to help if I can.
Click to expand...
No, it's no problem. I now I have an idea of the cause so will be able to do a proper fix :)
 
Many thanks for taking the time and effort of looking into this. I'll await the update with considerable interest.
 
You must log in or register to reply here.
Top