Arrow Quiver

Unity Courses Ask
#83

See the change above

#84

These changes are all done in ‘CheckForProjectileAndSufficientAmmo()’ right?

#85

Not the last one I posted, that one is in Hit()

#86

NRE:

NullReferenceException: Object reference not set to an instance of an object
RPG.Combat.Fighter.CanAttack (UnityEngine.GameObject combatTarget) (at Assets/Project Backup/Scripts/Combat/Fighter.cs:446)
RPG.Control.AIController.Update () (at Assets/Project Backup/Scripts/Control/AIController.cs:121)

Code:

public bool CanAttack(GameObject combatTarget) 
    {
        
        // if your quiver doesn't have enough ammunition of arrows for the appropriate bow, then you can't attack the enemy:
        if (!GetComponent<Quiver>().HasSufficientAmmunition(currentWeaponConfig.GetAmmunitionItem())) return false;

// Rest of my code...

It’s one of these codes where you can’t attack him, and the NRE goes wild, just from the thought of hovering on the guy (deleting that line solves the problem entirely, but isn’t that line necessary…?)

#87

‘GetAmmunitionItem()’ was a function we coded in ‘Quiver.cs’, and then referenced through a ‘Quiver’ call… Did you code that?

#88

I covered that above… You should be using the if(!CheckForProjectileAndSufficientAmmo()) instead of checking the Quiver. I’m surprised you weren’t getting an NRE before.

#89

This line just flat out removes the bow from the players’ hand if he even thinks of hovering on the enemy without any sort of ammo on him… I’ll keep this line out of it :stuck_out_tongue_winking_eye: (for now I think we can call the Arrow and Quiver system a day, we have achieved WAY more than what I initially wanted, apart from the tooltip thingy (which I might just walk it off by re-writing the description manually for every item))

#90

Are you starting to see why Blizzard did away with ammo yet?

#91

I’m starting to see a weak spot we took from blizzard xD, but RuneScape just wasn’t budging lel… This whole thing is really making me appreciate the fact that some people once did ALL THIS HARD WORK without guidance (WOW… Just WOW, all the simple stuff that we take for granted). Anyway, time for the next topic for another day :smiley: (for tonight let’s just celebrate the fact that we got the quiver system out of the way. You gotta admit though, I’m giving you amazing ideas as well xD)

#92

[JUST SKIP STRAIGHT TO EDIT 3]

Uhh Brian, before we lock this down, I just noticed a glitch with the arrows in the Quiver:

Here’s the thing, I tried storing my arrows in the bank, and I went crafted some more (I have a crafting system), and then I put the new ones on. When I went and pulled my arrows out of the bank and tried equipping them, my old arrows (which are EXACTLY THE SAME) were taken off the quiver and replaced with the new ones… WHICH ARE THE EXACT SAME ARROWS AS THE OLD ONES (I tried fixing that in the ‘QuiverSlotUI.TryHandleRightClick()’ and ‘InventorySlotUI.TransferToQuiver()’ method, but both were a nightmare). I want the exact same arrows to add up, not be replaced, please :slight_smile:

At first I thought this was a mistake, but apparently not. What changes do I need to do to fix this? Once we fix this we can start the ‘XP-Based system’, I’ll tag you there

The same problem does NOT exist for unequipping ammo (they add up perfectly fine), but it exists for transferring arrows to the quiver slot (they do not add up, they replace one another, although they are the same thing). Dragging and dropping works perfectly fine, but clicking to automatically send it to the quiver does not

Edit 1: 8 hours later, still can’t figure this silly thing out… I know for a fact it has something to do with ‘InventorySlotUI.TransferToQuiver()’

Edit 2: Now it also happens in the ‘Drag and Drop’ system too… this thing gets worse the more I try… Earlier it used to add the numbers up when we drag and drop, now it just replaces the entire old quiver content entirely, if they were of the same item type (I’m still trying to edit ‘TransferToQuiver()’)

[DRAG AND DROP ISSUE NOW]
Edit 3: ahh nevermind, I figured it out… at least for the clicking system (the drag and drop now just flat out replaces the arrows completely for some reason, how do we fix that…?). Surprisingly all it took was just an extra 2-3 lines of code.

My problem now is the drag and drop system. Whilst it works perfectly fine when transferring THE SAME TYPE OF ARROWS from the quiver to the inventory, transferring THE SAME TYPE OF ARROWS from the inventory to the quiver sends absolutely nothing back to the inventory (THIS CASE ONLY APPLIES IF THEY ARE THE SAME TYPES OF ARROWS. If they’re different, it returns them completely fine). It just completely takes over the old arrows (IF THEY ARE THE SAME ARROWS) and permanently deletes them… It doesn’t stack them up or anything, it just permanently deletes them

Skills based system
#93

I haven’t followed all of this, but there is one thing I noticed (and it may be completely irrelevant);
When you add items to the quiver, the method expects the full amount of items that will be in the quiver. If there are 5 and you want to add 5 more, you have to add 10. The drag-drop system is only going to pass how many items to add (in the example above, 5). If I have 3 arrows in the quiver and want to add 10 more, the click mechanic passes 13, so the arrows become 13, but the drag-drop system is going to pass 10, so the value in the quiver becomes 10, and 3 is just going to disappear. Should the quiver not perhaps add the value instead of completely replacing it?

public void AddAmmunition(AmmunitionItem item, int number)
{
    currentAmmunition = item;
    amount += number; // <- add it here instead of replacing
    quiverUpdated?.Invoke();
}

If you change it (and @Brian_Trotter will have to verify/validate/confirm) you would have to change the click to only pass number instead of number + amount

Edit
Actually, I suspect you’d need more checks, because if you are changing the ammo with different ammo, you’d want the number to be replaced instead of accumulated. Perhaps you should just update QuiverSlotUI to accumulate the items

public void AddItems(InventoryItem item, int number)
{
    if(item is AmmunitionItem ammunitionItem)
    {
        var currentAmount = quiver.GetAmount();
        quiver.AddAmmunition(ammunitionItem, currentAmount + number);
    }
}
#95

Ahh… this one made things worse. I had a bug where it adds stuff up in the quiver, but not remove it from the inventory, so now the math keeps going on forever…

For now I’ll revert to the solution I found, until Brian returns (I wonder where is he today… hope he’s well)

I’LL READ THE EDIT NOW

Edit 2: It makes things significantly worse… it brings back the bug I was trying so hard to avoid :sweat_smile:

#96

Yeah, there’s no checks in the QuiverSlotUI if the items are the same. It will just continue to add, regardless of what type of ammo is in the slot. You probably need to check the types and if they’re the same, accumulate. If not, replace

#97

I’ll go through this comment again in a bit, off somewhere brb

#98

ahh… didn’t work. Let’s wait for @Brian_Trotter

#99

You know, skipping to Edit 3, I’m still not entirely sure… is the click to equip properly adding or not?

In any event, here’s my fix for the click handler, checking to see if they are the same before swapping:

        private void TransferToQuiver(AmmunitionItem ammunitionItem, Quiver quiver, int number)
        {
            AmmunitionItem item = quiver.GetItem();
            int amount = quiver.GetAmount();
            inventory.RemoveFromSlot(index, number);
            quiver.AddAmmunition(ammunitionItem, ammunitionItem==item? number+amount : number);
            if (item != null && ammunitionItem!=item)
            {
                inventory.AddItemToSlot(index, item, amount);
            }
        }

Then for the dragging, in QuiverSlotUI, we needed to be checking to see if the item was the same as the equipped item before adding:

        public void AddItems(InventoryItem item, int number)
        {
            if(item is AmmunitionItem ammunitionItem)
            {
                if (object.ReferenceEquals(ammunitionItem, quiver.GetItem()))
                {
                    quiver.AddAmmunition(ammunitionItem, number + quiver.GetAmount());
                } else
                {
                    quiver.AddAmmunition(ammunitionItem, number);
                }
            }
        }

I was well, but had an unexpectedly long day and was unable to access a computer. Life happens, on occassion.

#100

Yay, welcome back Brian (gives you a long virtual hug like the one my 8 year old students give me nowadays :stuck_out_tongue_winking_eye: )

Anyway, the code works well now, thanks again Brian :slight_smile:

Eventually it did… there’s more than one way we got this to work apparently, I simply didn’t share the code in that edit :sweat_smile:

#101

Hello again Brian. I found a minor glitch in my Arrow unequipping system in my game, where my player inventory will instantiate the ‘unequipped’ (default weapon setup of my player, if he doesn’t have a weapon on him) into my inventory. To delete this, I was thinking of adding a Coroutine that waits for some time, and then checks for whether we have an ‘unarmed’ InventoryItem in my bag or not (P.S: he does, 100% of the time). If there is, delete it. If not, don’t do anything

But this doesn’t sound too practical. Do you have any alternative suggestions I can try out?

#102

Is your default weapon a projectile weapon?? Generally, we recommend the default weapon just be the Unarmed (effectively fists) which do not require ammo…

#103

Hello Brian. For my player, my default weapon, set under ‘Fighter.cs’ is ‘Unarmed’

Privacy & Terms