Minor Bug

Unity Courses Ask
#1

This one is not a major bug, but figured I’d ask for help anyway (pinky promise no more questions today so I can focus on my other problems, and see how I want to develop them moving on). In-game, I noticed the RandomDropper does not check for nearby static objects when determining the radius to spread the equipment to, so if there’s a house nearby for example, it would just drop the loot under the house, and it doesn’t even care that we can’t get a hold of it because it’s under… well… a house (i.e: a static object in our navMesh we can’t click on)

My question is, how do we ensure the radius the item being spread towards excludes the Static objects (i.e: how do we make sure loot doesn’t go under a house again?)

#2

Static objects should not be on the navmesh. The random dropper only selects spots that are on the navmesh, so under a building should not be possible. Make sure the buildings are marked as static.

#3

Hi again edc. Yes, it was marked as static (this rarely ever happens, but it did happen)

#4

Look at the building while the navmesh is displayed. Does it have a band that is not blue around the building? Maybe check the settings and re-bake the navmesh?

#5

This is the solution to the issue. The NavMesh should only return locations that are accessible. Setting an object to static should mark it inaccessible to the NavMesh unless it has a NavMesh Modifier that makes it walkable.

#6

Hey man, sorry for the late response. I had a coding rush session with Brian last night to solve some aggressive bugs (well, to some extent, we’re still fixing them), since we are implementing systems that don’t exist in the courses for my personal project.

To both of you, the building has the entire world around it in blue (unless there’s other static objects), but somehow items still might fall at the green (static) areas from time to time (and since my camera isn’t a freeLook camera yet (I’ll open a topic for this down the line, but right now it’s not my top priority yet), if one falls beside a house 180 degrees to my house, the IRaycastable doesn’t handle it too well, so that item is as good as gone)

#7

Can you post a screen shot with the navmesh showing and a pickup under the building?

#8

Navmesh (in red)
Navmesh (in red)889×494 89.5 KB

Sure, here you go. The red area I highlighted is where the items fell (i.e: under the house). Unfortunately I can’t get a pickup to fall there easily again though

#9

This looks correct. Can you post your RandomDropper.cs? I have to go to work now, but I will check back when I get home.

#10

Sure, here you go (P.S: I left out the part that drops my stuff when I die, since it’s not mentioned in the course anyway):

using GameDevTV.Inventories;
using UnityEngine;
using RPG.Stats;
using UnityEngine.AI;
using System.Linq;


namespace RPG.Inventories {

    // The class for this script is inheriting from 'ItemDropper.cs'
    public class RandomDropper : ItemDropper
    {

        // CONFIGURATION DATA:
        [Tooltip("How far can the pickups be scattered from the dropper.")]
        [SerializeField] float scatterDistance = 1; // distance from the enemy's death, to drop the loot
        [SerializeField] DropLibrary dropLibrary;   // a library of potential drops (and their quantities) generated by our enemies
        [SerializeField] int numberToKeep;

        // CONSTANTS:
        const int Attempts = 30;    // attempts to drop our Enemy drops on the ground (instead of somewhere inaccessible by the player) - higher = better

        protected override Vector3 GetDropLocation()
        {

            // generate 'attempts' number of random points for our loot to drop on (everytime loot hits the ground):
            for (int i = 0; i < Attempts; i++) {
            
            // The random Point should be within the Unit Sphere of the killed Enemy/Player
            Vector3 randomPoint = transform.position + (Random.insideUnitSphere * scatterDistance);

            // Ensuring our loot does not fall in the air, off the cliff or somewhere inaccessible by the player:
            NavMeshHit hit;

            if (NavMesh.SamplePosition(randomPoint, out hit, 0.1f, NavMesh.AllAreas)) {

                return hit.position;

            }
            
            }

            // if we can't drop it on the ground, just drop it at the players' location:
            return transform.position;

        }

        public void RandomDrop() {

            var baseStats = GetComponent<BaseStats>();

                // This function is responsible for how our enemies drop loot when they die
                var drops = dropLibrary.GetRandomDrops(baseStats.GetLevel());
                
                foreach (var drop in drops) {

                DropItem(drop.item, drop.number);  // drops 'numberOfDrops' number of items for our player to drop it

            }

        }

   }
#11

This looks essentially like the script in my project from the course. The only thing I can think of is that something is interfering with GetDropLocation when it is called in ItemDropper.cs. If you want, post your ItemDropper.cs and I will give it a once over.

#12

I remember a student had issues a few years back that were caused by an offset of the model file within the Pickup…
The pickup is placed on the NavMesh, as that’s pretty much all that can be returned by this method. The pickup itself, however, was offset a few units (not at 0,0,0) and therefore wound up being off of the NavMesh.

#13

My ItemDropper hasn’t changed in anyway compared to the course, never touched that script (well… reading it now :stuck_out_tongue_winking_eye: ). The only thing I did was comment out the CaptureState() and RestoreState() functions

#14

Yup… most of my pickups have that issue, where they are offset by a bit (but my guess is that’s natural because I am randomly dropping them in a virtual circle we created). Do we check for the offset in the prefab itself or in the scene? This bug probably won’t happen again anytime soon though, it’s kinda very rare for it to happen, if ever

#15

You fix the offsets in the prefabs themselves when you edit/create them. Any offset the model has in it’s position (ideally should be 0,0,0 but sometimes it is helpful to have the item up in the Y, so the model isn’t h 1/2 buried in the ground). The X and Z should almost always be zero.

#16
#17

Privacy & Terms