Foreword: This tutorial is intended for use in maps where a limited number of heroes with arrangement-sensitive inventories are revived. If your map has 1000 reviving heroes, this is not a feasible method and I recommend searching for the arrangement-insensitive method or waiting for Blizzard to really fix it this time. To use the following method with a number of heroes with a known maximum limit (say, 1 hero per player with up to 12 players), simply make the arrays used into 2D arrays and change the triggers to track which hero is in question.
Setting Up and Understanding Your Item Containers
For the purpose of this tutorial, we'll assume that you already know how to make a hero (or regular unit) with one or two working inventories. The item containers applied to a hero are numbered in the order they are listed in the Inventory ability you gave your hero. Items queried by triggers in the first listed item container return a container value of (integer) 1. Items in the second return a container value of (integer) 2. Similarly, item slots begin at 1 and count upwards at an increment of 1. Both containers may have slots that are of the same number, so container 1 may have a slot 3 and container 2 may also have a slot 3. Here's a picture of an item container with 16 consecutive item slots:
Let's take a look at how these slots are numbered:
As you might see, it would be very simple to keep track of items in such an item container using a simple Unit Type array of the same size. The values of an size 16 array are at indexes 0-15 while the items in this size 16 container are at 1-16. You could simply store the type of item at slot X in array[X-1].
Let's see how you would declare a global variable array that would hold a simple size 16 container:
However, we have a dilemma! Some item containers look much fancier, and why shouldn't they? Let's take a look at the kind of fancy inventories we're used to:
There are 9 slots in this container. However, the numbering of slots in a container counts slots that do not exist. Let's take a look at how the previous container's visible and invisible slots are numbered:
As you can see, that creates a bit of a problem if you wanted to store the contents in an array while tracking the slot number the item came from by the array index used to store it. Index 0 can no longer necessarily correspond to Slot 1! But have no fear, we have a solution at our hands.
The Inventory Key
Let's declare two arrays. This first one will be the unit-type array that we'll save the contents of the container into, just like the array we declared for the simple size 16 container except this is for a size 9 container. This second array is what I refer to as the inventory key for that container:
At map initialization, you'll want to set its values (with a one-to-one correspondence) to the item slots of your complex container, like so (the order of the slots doesn't matter as long as each array index points to a unique item slot):
Now when you want to find what item slot is being stored in a specified array index value of your unit-type array, you can use this key!
In a simple container, you could find the item slot stored in an array index by calculating Index+1. For example, at (Index = 0) we are storing the Unit-Type found at Slot (0 + 1), or Slot 1.
In a complex container, you can do the same thing by using the key to find equipmentKey[Index]. In my inventory key initialized above, we find the slot at index 0 of equipmentKey is Slot 9.
We will want to be able to find the reverse as well. How do we find where the Unit-Type of Slot 49 is being stored? We create a function that takes an Integer (the Slot that we know, which is 49) and returns a different Integer (the Index value that we want, which is where Unit-Type at 49 is being stored):
If done right, Reverse Equipment Key(49) will return the Integer value 4. Now that we have the tools to read and write out of our simple and/or complex Unit-Type arrays, let's DO something with them!
Taking Snapshots of (Saving) Your Inventory
The following trigger will activate whenever our hero does just about anything with an item short of using a charge (storing charges is feasible but beyond the scope of this tutorial). It will first blank out everything it knows about the arrays to make sure there are no ghost items (items that have since been removed from the inventory). The minimal wait time delay between the previous action and the next action is vital, as it prevents the trigger from writing items that are being removed from the inventory as if they were still present. It will then pick every item, find which container it is in, and read its Unit Type into the appropriate place in the corresponding array.
We will see in the following section why the global boolean value reference is necessary. Make sure when you declare it the it is defaulted to "false". You may also place it under the conditions at the head of the trigger. It's in its own If-Then-Else here purely for debugging purposes.
Restoring the Inventory to Its Rightful Place
Run the following actions immediately after your hero has been revived. The boolean flag mentioned before is toggled here to prevent snapshots (saves) to be triggered while items are being placed into the hero's inventory, otherwise the snapshot trigger would blank out the arrays and all items after the first would be lost.
Whew, done. You've now got a hero whose gear is returned to him in correct order whenever it is revived.
An example map is not currently forthcoming as this was made while integrating it into my own privately developed map. If someone else successfully completes the tutorial in a small example map and is willing to share it, I will absolutely post it here.
I do not request any credit if you use this method in your map. I feel that it is merely a work-around to something Blizzard will eventually fix and not worthy of mention. If you absolutely cannot not give me credit, that's fine too.
This isn't a general item tutorial, it has a very specific purpose. If you use containers that each only hold 1 item that the other containers cannot hold, this tutorial won't have any useful info for you. Regardless, the tutorial does explain how the containers are ordered in the first paragraph:
Quote:
The item containers applied to a hero are numbered in the order they are listed in the Inventory ability you gave your hero.
You can tell the order of the containers in the Data Editor under the Abilities tab. Select Info+ from the inventory ability your hero is using and you should be looking at something like this:
The order in which these are listed is their order when dealing with triggers. The first one (numbered 0) is container 1, the second one (numbered 1) is container 2, and so on.
Have you tested with multiple containers in the setup I described? It has a significant effect on how items are laid out.
Items won't be created sequentially in slots, they'll be created all over the place.
In my map, I use triggers to create 5 items split between 3 containers with multiple slots, each item fitting into one and only one container. I don't create them in order of container 1,2,3, because I never know how the player will randomly acquire them in game. I then store each item in a variable. Later, I compare the items by using the Inventory Item Carried, and use the index that the item is in. Here's the trigger:
Unit - Order (Triggering unit) to (Order Use Item Targeting Point( Use Item Targeted, (Item carried by (Triggering unit) in (Inventory Slot of InvItem)), (Triggering ability target point))) (Replace Existing Orders)
The important part being (Item carried by (Triggering unit) in (Inventory Slot of InvItem) , InvItem being a variable where I saved my item.
This for some reason does not work. So, either Blizzard's triggers are wrong, or, Inventory Slots don't work as you described them when dealing with multiple containers. I'd appreciate if you could help me figure this out so we know exactly where the problem lies.
A52BcE, you are asking for help on a topic that is not a part of this tutorial (your question doesn't seem like it deals with hero death, revival, and item restoration even). This creates two problems:
1) Without adequate description or access to the map in question, I can't help you because it's not a topic I'm familiar with (i.e., my tutorial)
2) Other people who may be able to help you aren't finding you because you're asking in a tutorial thread that is unrelated to your question
From what I can gather, you are encountering the issue where not all of Blizzard's item triggers ask for containers. This is just a sad fact. If it weren't, my tutorial would be a lot simpler. However, item slots exist exactly as I describe them here no matter how many containers you use, I promise you. If you'd like help getting around the problem or if there's a different problem altogether, PM me with a link to a thread where you ask for help as the original poster and describe everything in complete detail, hopefully with an attached map.
That's not what I intended at all. I'm trying to point out there's a flaw in your simplistic approach.
Here's more what I meant: Send me the map you used with the tutorial (you probably should have included it in your post, or at least in library form so there's no need to redo it all by hand) because I think I can break it with little effort. If not, you're right, I'm in the wrong place. If so, its as I intended to show, that your formula doesn't work like you think it does.
That's not what I intended at all. I'm trying to point out there's a flaw in your simplistic approach.
Here's more what I meant: Send me the map you used with the tutorial (you probably should have included it in your post, or at least in library form so there's no need to redo it all by hand) because I think I can break it with little effort. If not, you're right, I'm in the wrong place. If so, its as I intended to show, that your formula doesn't work like you think it does.
As stated in the OP, the map I've implemented this on will not be released. The "formula", as you put it, does not lend itself to being added to a library since, as far as I know, Galaxy doesn't have any means for dynamically declaring arrays of varying sizes. What works for my map won't always work for yours. However, the entire method will work for any map and if you're having trouble implementing it you may confidentially share your map with me as I do not mind helping others.
If you simply cannot bring yourself to do any of the options I've provided, you can always add a simple Text Message action to your triggers that spits out the container and slot of a manipulated item and play with it yourself.
Please continue this in PMs if you feel it worthwhile, there's no reason to clutter a tutorial with this back and forth. If we learn anything meaningful, we can post THAT here.
Edit: I have sent you a preemptive PM fully describing why your trigger excerpt does not function correctly and why that isn't relevant to the method laid out in this tutorial. Feel free to PM me back for further discussion.
I stumbled across this thread wondering why the [insert appropriate wording] isn't this working correctly. For the past 3 hours i've been trying to get my inventory management working. But even following exactly what you've posted it does not work. After a huge amount of debugging i've determined theres absolutely nothing wrong with my numbering system.
In my map the ONLY thing I want to do is remove and re-add all items to the player hero after revive. The reason is if a hero dies, and is revived, then any stat modifiers (such as equipping an item that gives +2 damage) will not apply, until that item is moved/recreated/picked up again
The only important bits are
Variable - Set ItemType = (Unit type of (Picked unit))
Variable - Set ItemSlot = (Inventory Slot of (Picked unit))
Variable - Set ItemContainer = (Inventory Container of (Picked unit))
Unit - Remove (Picked unit) from the game
Unit - Create one ItemType item in the inventory of herodead
Unit - Move inventory item (Last created inventory item) to slot ItemSlot in container ItemContainer
I don't need any external variables. The slot numbers match up, so if I have for example a basic assault rifle in slot number 2, it should note it, destroy the existing item, give the hero a new one, and then move it to 2.
The last command 'move inventory item' DOES NOT WORK. I've tested it thoroughly, infact what seems to be even more strange is the only number that works with the command, is number 9. I've tried moving an item from slot 0 up to slot 100. The only number that moves the item, is number 9. Very very strange
I stumbled across this thread wondering why the [insert appropriate wording] isn't this working correctly. For the past 3 hours i've been trying to get my inventory management working. But even following exactly what you've posted it does not work. After a huge amount of debugging i've determined theres absolutely nothing wrong with my numbering system.
In my map the ONLY thing I want to do is remove and re-add all items to the player hero after revive. The reason is if a hero dies, and is revived, then any stat modifiers (such as equipping an item that gives +2 damage) will not apply, until that item is moved/recreated/picked up again The only important bits are
Variable - Set ItemType = (Unit type of (Picked unit))
Variable - Set ItemSlot = (Inventory Slot of (Picked unit))
Variable - Set ItemContainer = (Inventory Container of (Picked unit))
Unit - Remove (Picked unit) from the game
Unit - Create one ItemType item in the inventory of herodead
Unit - Move inventory item (Last created inventory item) to slot ItemSlot in container ItemContainer
I don't need any external variables. The slot numbers match up, so if I have for example a basic assault rifle in slot number 2, it should note it, destroy the existing item, give the hero a new one, and then move it to 2. The last command 'move inventory item' DOES NOT WORK. I've tested it thoroughly, infact what seems to be even more strange is the only number that works with the command, is number 9. I've tried moving an item from slot 0 up to slot 100. The only number that moves the item, is number 9. Very very strange
Any help here?
Hi Millenium,
It looks as though you've done some testing to see why the trick isn't working, since I don't use any variables for slot/container or remove the items from the game, and I applaud you for trying to crack down on this. If I understand you correctly, you are (without killing your hero) saving the position of the item in terms of slot/container and the type of the item, then throwing the item away, putting a new one in the inventory, and moving it. You are experiencing an issue where the item is not always being moved (but you are NOT receiving an error message about invalid slots/containers/items). Correct me if any of that is wrong!
I will start by saying that I too, have experienced a problem where the item will not obey the move action when it is being moved from a container to the SAME container. If you are experiencing this same issue, lemme know. If you are only using a single inventory, I have a solution for you: Do the trick in my tutorial, but instead of skipping over empty slots in the array while filling the inventory back up, fill the supposedly empty slots with a dummy item. After all the items have been placed, go back through and remove all dummy items. You'll have to ensure that whatever dummy item you are placing in any slot can fit there (might need a dummy item for each item class).
However, if you're using multiple inventories (like I do in my map), I have devised a different solution to the problem that I haven't tested yet. I will test it and get back to you on it ASAP. Please let me know if any of this is useful information or if you find out anything new so I may improve my tutorial.
Edit: There's definitely an issue with the Move Item action. It may freak out when trying to move an item to a location in a complex container or it may freak out when moving an item to a slot with a specified item class requirement. Since it sounded like you had a slot (9) in the same container as other slots, where 9 worked and the others didn't, it's probably the item class restriction. I'll put it through more rigorous testing later, but any more information you can offer would be awesome. Until then, filling empty slots with dummy items, then removing them, is the way to go.
After removing everything from a complex container, I'm almost certain it's a bug between the Move Item Action and containers. The container and slot numbers are 100% correct, so I'm just not clear on it. ANY info that you can produce on why you've got a single slot that works would be great.
After removing everything from a complex container, I'm almost certain it's a bug between the Move Item Action and containers. The container and slot numbers are 100% correct, so I'm just not clear on it. ANY info that you can produce on why you've got a single slot that works would be great.
All I can say is that my inventory consists of a total of 16 slots, 1 weapon slot, 1 armor slot, 4 accessory slot, 4 miscellaneous slots and 6 empty slots (no item class, anything goes)
It doesn't matter what item class I try to move the only slot that works is 9 which corresponds to the first accessory slot. Of course if I try to move a weapon to that slot, nothing happens. Only an accessory will successfully move
I wrote a basic trigger in that if I type -slot where is a number, it'll try to move the last created item to that slot number. So i've tried everything from 1-100 (my inventory only goes up to 72) and only that 9 slot works. No idea why
It's nothing logical, it's just a bugged editor. I'm not prepared to fill the inventory with dummy items, and i'm not sure if that even works? since if I 'create' an item it'll move to one of the empty slots. And since the 'move inventory item' command doesn't work I can't force anything to go to a dummy slot
Another thing that strikes me as odd is that logically if I remove an item, then create it again, it should go into the first available slot that it fits in. For instance if I have a health kit in slot 2 and a health kit in slot 4. Then my trigger would remove health kit in slot2 and create a new one which will be in slot1, fine. And then remove the second health kit and a new one would go in slot 2, since thats the next available.
But heres my findings that make me really just think WTF
It'll create a new health kit in slot 1 and slot 3. I've also tried putting them in slot 1 and 3, and they'll get created in slot 2 and 4. If I have 3 health kits in lets say slot 1, 2 and 3. By this twisted logic it should make one in slot 4 and the rest get bumped elsewhere, however it'll make one in slot 2 and the others get bumped. So i've said fk it they can be random until blizzard fixes it
It's enough to make one's monacle fall out I tell you!
Hi! Just wanted to check: The latest updates on the editor included a "Inventory Item Index" parameter. Is this function checking for the index of the item within a container slot?(meaning it has fixed the problem discussed in this thread)
EDIT: Nvm. Just found that it's a different thing.
I stumbled across this thread wondering why the [insert appropriate wording] isn't this working correctly. For the past 3 hours i've been trying to get my inventory management working. But even following exactly what you've posted it does not work. After a huge amount of debugging i've determined theres absolutely nothing wrong with my numbering system.
In my map the ONLY thing I want to do is remove and re-add all items to the player hero after revive. The reason is if a hero dies, and is revived, then any stat modifiers (such as equipping an item that gives +2 damage) will not apply, until that item is moved/recreated/picked up again The only important bits are
Variable - Set ItemType = (Unit type of (Picked unit))
Variable - Set ItemSlot = (Inventory Slot of (Picked unit))
Variable - Set ItemContainer = (Inventory Container of (Picked unit))
Unit - Remove (Picked unit) from the game
Unit - Create one ItemType item in the inventory of herodead
Unit - Move inventory item (Last created inventory item) to slot ItemSlot in container ItemContainer
I don't need any external variables. The slot numbers match up, so if I have for example a basic assault rifle in slot number 2, it should note it, destroy the existing item, give the hero a new one, and then move it to 2. The last command 'move inventory item' DOES NOT WORK. I've tested it thoroughly, infact what seems to be even more strange is the only number that works with the command, is number 9. I've tried moving an item from slot 0 up to slot 100. The only number that moves the item, is number 9. Very very strange
Any help here?
This problem is actually very simple. The following happens according to the game:
Trigger runs
Trigger stores variables
Trigger removes item
Inventory doesn't know that the item has been removed
Trigger creates item
Trigger tries to move item to slot where the removed item was in
Inventory thinks the removed item still exists thus results in move failure slot in use.
to solve this do the following:
Variable - Set ItemType = (Unit type of (Picked unit))
Variable - Set ItemSlot = (Inventory Slot of (Picked unit))
Variable - Set ItemContainer = (Inventory Container of (Picked unit))
Unit - Remove (Picked unit) from the game Wait 0.0 Game Time Seconds Inventory gets time to check the changes that the trigger applied
Unit - Create one ItemType item in the inventory of herodead
Unit - Move inventory item (Last created inventory item) to slot ItemSlot in container ItemContainer
nvm i was tired...
Ok so whats up with moving items into another container ? I do like move item i to slot 24(last) in container 2 and it freaks out.
I save items with data attached of their while-save inventory slot and yet it set's back quite badly (probably because of that second container)
Foreword: This tutorial is intended for use in maps where a limited number of heroes with arrangement-sensitive inventories are revived. If your map has 1000 reviving heroes, this is not a feasible method and I recommend searching for the arrangement-insensitive method or waiting for Blizzard to really fix it this time. To use the following method with a number of heroes with a known maximum limit (say, 1 hero per player with up to 12 players), simply make the arrays used into 2D arrays and change the triggers to track which hero is in question.
Setting Up and Understanding Your Item Containers
For the purpose of this tutorial, we'll assume that you already know how to make a hero (or regular unit) with one or two working inventories. The item containers applied to a hero are numbered in the order they are listed in the Inventory ability you gave your hero. Items queried by triggers in the first listed item container return a container value of (integer) 1. Items in the second return a container value of (integer) 2. Similarly, item slots begin at 1 and count upwards at an increment of 1. Both containers may have slots that are of the same number, so container 1 may have a slot 3 and container 2 may also have a slot 3. Here's a picture of an item container with 16 consecutive item slots:
Let's take a look at how these slots are numbered:
As you might see, it would be very simple to keep track of items in such an item container using a simple Unit Type array of the same size. The values of an size 16 array are at indexes 0-15 while the items in this size 16 container are at 1-16. You could simply store the type of item at slot X in array[X-1].
Let's see how you would declare a global variable array that would hold a simple size 16 container:
However, we have a dilemma! Some item containers look much fancier, and why shouldn't they? Let's take a look at the kind of fancy inventories we're used to:
There are 9 slots in this container. However, the numbering of slots in a container counts slots that do not exist. Let's take a look at how the previous container's visible and invisible slots are numbered:
As you can see, that creates a bit of a problem if you wanted to store the contents in an array while tracking the slot number the item came from by the array index used to store it. Index 0 can no longer necessarily correspond to Slot 1! But have no fear, we have a solution at our hands.
The Inventory Key
Let's declare two arrays. This first one will be the unit-type array that we'll save the contents of the container into, just like the array we declared for the simple size 16 container except this is for a size 9 container. This second array is what I refer to as the inventory key for that container:
At map initialization, you'll want to set its values (with a one-to-one correspondence) to the item slots of your complex container, like so (the order of the slots doesn't matter as long as each array index points to a unique item slot):
Now when you want to find what item slot is being stored in a specified array index value of your unit-type array, you can use this key!
We will want to be able to find the reverse as well. How do we find where the Unit-Type of Slot 49 is being stored? We create a function that takes an Integer (the Slot that we know, which is 49) and returns a different Integer (the Index value that we want, which is where Unit-Type at 49 is being stored):
If done right, Reverse Equipment Key(49) will return the Integer value 4. Now that we have the tools to read and write out of our simple and/or complex Unit-Type arrays, let's DO something with them!
Taking Snapshots of (Saving) Your Inventory
The following trigger will activate whenever our hero does just about anything with an item short of using a charge (storing charges is feasible but beyond the scope of this tutorial). It will first blank out everything it knows about the arrays to make sure there are no ghost items (items that have since been removed from the inventory). The minimal wait time delay between the previous action and the next action is vital, as it prevents the trigger from writing items that are being removed from the inventory as if they were still present. It will then pick every item, find which container it is in, and read its Unit Type into the appropriate place in the corresponding array.
We will see in the following section why the global boolean value reference is necessary. Make sure when you declare it the it is defaulted to "false". You may also place it under the conditions at the head of the trigger. It's in its own If-Then-Else here purely for debugging purposes.
Restoring the Inventory to Its Rightful Place
Run the following actions immediately after your hero has been revived. The boolean flag mentioned before is toggled here to prevent snapshots (saves) to be triggered while items are being placed into the hero's inventory, otherwise the snapshot trigger would blank out the arrays and all items after the first would be lost.
Whew, done. You've now got a hero whose gear is returned to him in correct order whenever it is revived.
An example map is not currently forthcoming as this was made while integrating it into my own privately developed map. If someone else successfully completes the tutorial in a small example map and is willing to share it, I will absolutely post it here.
I do not request any credit if you use this method in your map. I feel that it is merely a work-around to something Blizzard will eventually fix and not worthy of mention. If you absolutely cannot not give me credit, that's fine too.
I have a serious issue that your tutorial here doesn't cover.
I have three containers in my units inventory, each carrying a specific type of item so the player always knows where to look for it.
And now, I can't figure out which slot refers to which container and which item. How does the numbering go when you have multiple containers?
@A52BcE: Go
This isn't a general item tutorial, it has a very specific purpose. If you use containers that each only hold 1 item that the other containers cannot hold, this tutorial won't have any useful info for you. Regardless, the tutorial does explain how the containers are ordered in the first paragraph:
You can tell the order of the containers in the Data Editor under the Abilities tab. Select Info+ from the inventory ability your hero is using and you should be looking at something like this:
The order in which these are listed is their order when dealing with triggers. The first one (numbered 0) is container 1, the second one (numbered 1) is container 2, and so on.
Have you tested with multiple containers in the setup I described? It has a significant effect on how items are laid out. Items won't be created sequentially in slots, they'll be created all over the place.
In my map, I use triggers to create 5 items split between 3 containers with multiple slots, each item fitting into one and only one container. I don't create them in order of container 1,2,3, because I never know how the player will randomly acquire them in game. I then store each item in a variable. Later, I compare the items by using the Inventory Item Carried, and use the index that the item is in. Here's the trigger:
Unit - Order (Triggering unit) to (Order Use Item Targeting Point( Use Item Targeted, (Item carried by (Triggering unit) in (Inventory Slot of InvItem)), (Triggering ability target point))) (Replace Existing Orders)
The important part being (Item carried by (Triggering unit) in (Inventory Slot of InvItem) , InvItem being a variable where I saved my item. This for some reason does not work. So, either Blizzard's triggers are wrong, or, Inventory Slots don't work as you described them when dealing with multiple containers. I'd appreciate if you could help me figure this out so we know exactly where the problem lies.
@A52BcE: Go
A52BcE, you are asking for help on a topic that is not a part of this tutorial (your question doesn't seem like it deals with hero death, revival, and item restoration even). This creates two problems:
1) Without adequate description or access to the map in question, I can't help you because it's not a topic I'm familiar with (i.e., my tutorial)
2) Other people who may be able to help you aren't finding you because you're asking in a tutorial thread that is unrelated to your question
From what I can gather, you are encountering the issue where not all of Blizzard's item triggers ask for containers. This is just a sad fact. If it weren't, my tutorial would be a lot simpler. However, item slots exist exactly as I describe them here no matter how many containers you use, I promise you. If you'd like help getting around the problem or if there's a different problem altogether, PM me with a link to a thread where you ask for help as the original poster and describe everything in complete detail, hopefully with an attached map.
That's not what I intended at all. I'm trying to point out there's a flaw in your simplistic approach.
Here's more what I meant: Send me the map you used with the tutorial (you probably should have included it in your post, or at least in library form so there's no need to redo it all by hand) because I think I can break it with little effort. If not, you're right, I'm in the wrong place. If so, its as I intended to show, that your formula doesn't work like you think it does.
As stated in the OP, the map I've implemented this on will not be released. The "formula", as you put it, does not lend itself to being added to a library since, as far as I know, Galaxy doesn't have any means for dynamically declaring arrays of varying sizes. What works for my map won't always work for yours. However, the entire method will work for any map and if you're having trouble implementing it you may confidentially share your map with me as I do not mind helping others.
If you simply cannot bring yourself to do any of the options I've provided, you can always add a simple Text Message action to your triggers that spits out the container and slot of a manipulated item and play with it yourself.
Please continue this in PMs if you feel it worthwhile, there's no reason to clutter a tutorial with this back and forth. If we learn anything meaningful, we can post THAT here.
Edit: I have sent you a preemptive PM fully describing why your trigger excerpt does not function correctly and why that isn't relevant to the method laid out in this tutorial. Feel free to PM me back for further discussion.
This is good to see how they are numbered.
I am thinking of changing all of my heroes in my RPG to use the incapacitated thing that Blizzard uses instead of doing a revive system.
Whichever way gets the job done the way you want for the least amount of effort is the best way!
I stumbled across this thread wondering why the [insert appropriate wording] isn't this working correctly. For the past 3 hours i've been trying to get my inventory management working. But even following exactly what you've posted it does not work. After a huge amount of debugging i've determined theres absolutely nothing wrong with my numbering system.
In my map the ONLY thing I want to do is remove and re-add all items to the player hero after revive. The reason is if a hero dies, and is revived, then any stat modifiers (such as equipping an item that gives +2 damage) will not apply, until that item is moved/recreated/picked up again The only important bits are
Variable - Set ItemType = (Unit type of (Picked unit))
Variable - Set ItemSlot = (Inventory Slot of (Picked unit))
Variable - Set ItemContainer = (Inventory Container of (Picked unit))
Unit - Remove (Picked unit) from the game
Unit - Create one ItemType item in the inventory of herodead
Unit - Move inventory item (Last created inventory item) to slot ItemSlot in container ItemContainer
I don't need any external variables. The slot numbers match up, so if I have for example a basic assault rifle in slot number 2, it should note it, destroy the existing item, give the hero a new one, and then move it to 2. The last command 'move inventory item' DOES NOT WORK. I've tested it thoroughly, infact what seems to be even more strange is the only number that works with the command, is number 9. I've tried moving an item from slot 0 up to slot 100. The only number that moves the item, is number 9. Very very strange
Any help here?
Hi Millenium,
It looks as though you've done some testing to see why the trick isn't working, since I don't use any variables for slot/container or remove the items from the game, and I applaud you for trying to crack down on this. If I understand you correctly, you are (without killing your hero) saving the position of the item in terms of slot/container and the type of the item, then throwing the item away, putting a new one in the inventory, and moving it. You are experiencing an issue where the item is not always being moved (but you are NOT receiving an error message about invalid slots/containers/items). Correct me if any of that is wrong!
I will start by saying that I too, have experienced a problem where the item will not obey the move action when it is being moved from a container to the SAME container. If you are experiencing this same issue, lemme know. If you are only using a single inventory, I have a solution for you: Do the trick in my tutorial, but instead of skipping over empty slots in the array while filling the inventory back up, fill the supposedly empty slots with a dummy item. After all the items have been placed, go back through and remove all dummy items. You'll have to ensure that whatever dummy item you are placing in any slot can fit there (might need a dummy item for each item class).
However, if you're using multiple inventories (like I do in my map), I have devised a different solution to the problem that I haven't tested yet. I will test it and get back to you on it ASAP. Please let me know if any of this is useful information or if you find out anything new so I may improve my tutorial.
Edit: There's definitely an issue with the Move Item action. It may freak out when trying to move an item to a location in a complex container or it may freak out when moving an item to a slot with a specified item class requirement. Since it sounded like you had a slot (9) in the same container as other slots, where 9 worked and the others didn't, it's probably the item class restriction. I'll put it through more rigorous testing later, but any more information you can offer would be awesome. Until then, filling empty slots with dummy items, then removing them, is the way to go.
After removing everything from a complex container, I'm almost certain it's a bug between the Move Item Action and containers. The container and slot numbers are 100% correct, so I'm just not clear on it. ANY info that you can produce on why you've got a single slot that works would be great.
All I can say is that my inventory consists of a total of 16 slots, 1 weapon slot, 1 armor slot, 4 accessory slot, 4 miscellaneous slots and 6 empty slots (no item class, anything goes) It doesn't matter what item class I try to move the only slot that works is 9 which corresponds to the first accessory slot. Of course if I try to move a weapon to that slot, nothing happens. Only an accessory will successfully move I wrote a basic trigger in that if I type -slot
where
is a number, it'll try to move the last created item to that slot number. So i've tried everything from 1-100 (my inventory only goes up to 72) and only that 9 slot works. No idea whyIt's nothing logical, it's just a bugged editor. I'm not prepared to fill the inventory with dummy items, and i'm not sure if that even works? since if I 'create' an item it'll move to one of the empty slots. And since the 'move inventory item' command doesn't work I can't force anything to go to a dummy slot
Another thing that strikes me as odd is that logically if I remove an item, then create it again, it should go into the first available slot that it fits in. For instance if I have a health kit in slot 2 and a health kit in slot 4. Then my trigger would remove health kit in slot2 and create a new one which will be in slot1, fine. And then remove the second health kit and a new one would go in slot 2, since thats the next available. But heres my findings that make me really just think WTF It'll create a new health kit in slot 1 and slot 3. I've also tried putting them in slot 1 and 3, and they'll get created in slot 2 and 4. If I have 3 health kits in lets say slot 1, 2 and 3. By this twisted logic it should make one in slot 4 and the rest get bumped elsewhere, however it'll make one in slot 2 and the others get bumped. So i've said fk it they can be random until blizzard fixes it
It's enough to make one's monacle fall out I tell you!
Hi! Just wanted to check: The latest updates on the editor included a "Inventory Item Index" parameter. Is this function checking for the index of the item within a container slot?(meaning it has fixed the problem discussed in this thread)
EDIT: Nvm. Just found that it's a different thing.
This problem is actually very simple. The following happens according to the game:
to solve this do the following:
Variable - Set ItemType = (Unit type of (Picked unit))
Variable - Set ItemSlot = (Inventory Slot of (Picked unit))
Variable - Set ItemContainer = (Inventory Container of (Picked unit))
Unit - Remove (Picked unit) from the game
Wait 0.0 Game Time Seconds Inventory gets time to check the changes that the trigger applied
Unit - Create one ItemType item in the inventory of herodead
Unit - Move inventory item (Last created inventory item) to slot ItemSlot in container ItemContainer
nvm i was tired... Ok so whats up with moving items into another container ? I do like move item i to slot 24(last) in container 2 and it freaks out.
I save items with data attached of their while-save inventory slot and yet it set's back quite badly (probably because of that second container)