• Check out the results of the Techtree Contest #19!
  • Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.
  • Create a void inspired texture for Warcraft 3 and enter Hive's 34th Texturing Contest: Void! Click here to enter!
  • The Hive's 22nd Icon Contest: Creep Abilities is now concluded, time to vote for your favourite set of icons! Click here to vote!

PackIt - Multi-bag system [GUI] V2.1

This bundle is marked as pending. It has not been reviewed by a staff member yet.

PackIt v2.1 - GUI Inventory Extension System


OVERVIEW​

PackIt is a lightweight, beginner-friendly inventory extension system for single-player RPGs and campaigns.
It lets players summon and manage additional storage bags, each with their own 6-slot inventory, using a clean trigger setup built entirely in GUI — no JASS or Lua required.

Items inside bags persist between play sessions via Game Cache, saved locally on the player's machine.

WHAT'S NEW IN v2.0​

The system has been completely streamlined.
Adding a new bag now requires only two steps:
1. Increase the bag count in "Init Bag".
2. Assign the new spell to the next array slot.
The system automatically handles all storage, restoration, and ID assignment.

HOW IT WORKS​

Each bag is an invulnerable unit with a 6-slot inventory.
When summoned, the system tries to restore it from the Game Cache (preserving its items). If no saved data exists, it creates a fresh bag. When saved or dismissed, the bag's contents are stored back into the cache and the unit is removed.

INSTALLATION​

Copy from the demo map:
- The "Bag" trigger
- The "Save" trigger
- The "Init Bag" trigger
- The bag unit type
- The bag summon ability (duplicate for each bag)
- The "Save Bag" ability used by the bag unit
- (Optional) The Spellbook ability

Then in "Init Bag":
- Set PACKIT_NumberBags to how many bags you want.
- Assign each bag's spell to PACKIT_BagSpell[1], [2], etc.

CUSTOMIZATION​

Since bags are triggered by regular abilities, you can add any condition to restrict access:
- Unlock by hero level (already included as an example)
- Unlock by item in inventory
- Unlock by quest completion
- Custom UI instead of the Spellbook
The system doesn't care how the ability is cast — it just reacts when it fires.

MULTIPLAYER​

Not recommended out of the box. For multiplayer:
- Replace Game Cache with Hashtable.
- Index variables by player number with GetPlayerId().

NOTES​

- Cap of 11 bags when using the Spellbook (66 slots total).
- Designed for low item-density RPGs, not loot-heavy games.
- Fully made in GUI. No scripts required.

UPDATES​

Thanks to @Rheiko for the suggestions for improvements.



[UPDATE 1.2.1]​


The system has been modularized to make it easier to add new bags. Here's what's new:


  1. Simplified Process:
    • To add a new bag, you only need to:
      • Copy the existing "if else" block for the bag system.
      • Change the PACKIT_ID to the next number in the sequence (e.g., 5, 6, 7...).
      • Modify the condition to match the new bag's casting ability.
      • Declare the total number of bags at the start.
      • Create a new ability for summoning the new bag.
  2. Automated Bag Handling:
    • The system now uses IDs to automatically handle bags.
    • Storing and restoring bags in the Game Cache is done automatically when you update the ID.
  3. No Need for Complex Changes:
    • After creating the new ability, the process is simple: copy the relevant "if else" action, update the ability condition, and you're done!

[UPDATE 1.2.2]​

The system no longer requires checking whether an ability has been cast for the first time.

Instead of checking whether or not to create a bag based on booleans, it attempts to load a bag from the cache from the start. If it fails, it creates a new one and stores it in the cache. (This was changed primarily because if you test the system and move it to another map with a different cache, it can generally break.) It now directly creates a new bag if it can't find one in the cache.

[UPDATE 2.0]​

The indexing system has been simplified. Now you only need to declare the new skill if you want to add a new bag and increase the total number of backpacks. The system handles the rest of the information automatically. It's now much easier to use.

UPDATE 2.1​

Bug Fixes & Memory Management

Visual Effect Fix
The summon and dismiss effects were not displaying correctly when calling a previously created bag or dismissing an active one. This happened because the effect was being attached to the unit before it finished loading or after it had already been queued for removal. The effect now spawns at a stored point instead of attaching directly to the unit, ensuring it always renders correctly regardless of the unit's state.

Memory Leak Fix A new variable stores the bag's position when summoned. This point is now properly removed via RemoveLocation() across all execution paths in the trigger. Previously, some branches cleaned up the point and others did not, causing a gradual memory leak over extended play sessions.

Level Bag Fix In the "level bag" trigger, the last action incorrectly referenced Last Created Unit when setting the custom value — no unit is created in that trigger, making the action meaningless. This has been corrected to reference Leveling Hero, which properly captures the unit that fired the level-up event.
Previews
Contents

PackIt v2.1 (Map)

Reviews
Rheiko
Hello, thank you for the submission! Here's my review so far: This system is cool and could be really useful — but right now, it lacks proper configuration options. Adding a new bag seems unnecessarily tedious. I have to duplicate triggers and...
Hello, thank you for the submission! Here's my review so far:

This system is cool and could be really useful — but right now, it lacks proper configuration options. Adding a new bag seems unnecessarily tedious. I have to duplicate triggers and manually change variables? That introduces a high risk of user error, and the system might break if something is set incorrectly.

A system should be easy to configure, especially for beginners. I assume that’s one of the goals of this system: ease of use. In general, users shouldn’t need to understand or touch the internal logic of the system. Instead, they should be able to change configurations via a dedicated configuration trigger.

So instead of having multiple triggers for each bag, consider using a smaller set of core triggers that handle all bags dynamically, and expose configuration settings through a separate trigger.

Duplicate triggers, while sometimes harmless, should generally be avoided — they can cause unnecessary performance overhead and make debugging harder.

Here are a few configuration values that should be exposed via a config trigger:
  • Number of bags (no trigger duplication should be needed).
  • Model used for the special effect and its attachment point (string variables work great here).
  • Sound effect used.
  • Unit type used as the bag.
  • The ability associated with the bag.
Also, I recommend using a 2 to 4 digit prefix for all your variables. This helps avoid conflicts with other systems or triggers that might be used in the same map. See: GPAG - GUI Proper Application Guide

You mentioned the system could be made multiplayer-compatible by switching from Game Cache to Hashtable. So why not use Hashtable from the start? That way, users don’t have to worry about compatibility depending on the map type — it’ll just work.

In its current form, the system isn’t quite lightweight or beginner-friendly enough. That said, it’s a great idea and a promising start. I really hope you keep improving it — looking forward to the next version!

Cheers!

Awaiting Update
 
Last edited:
Hello, thank you for the submission! Here's my review so far:

This system is cool and could be really useful — but right now, it lacks proper configuration options. Adding a new bag seems unnecessarily tedious. I have to duplicate triggers and manually change variables? That introduces a high risk of user error, and the system might break if something is set incorrectly.

A system should be easy to configure, especially for beginners. I assume that’s one of the goals of this system: ease of use. In general, users shouldn’t need to understand or touch the internal logic of the system. Instead, they should be able to change configurations via a dedicated configuration trigger.

So instead of having multiple triggers for each bag, consider using a smaller set of core triggers that handle all bags dynamically, and expose configuration settings through a separate trigger.

Duplicate triggers, while sometimes harmless, should generally be avoided — they can cause unnecessary performance overhead and make debugging harder.

Here are a few configuration values that should be exposed via a config trigger:
  • Number of bags (no trigger duplication should be needed).
  • Model used for the special effect and its attachment point (string variables work great here).
  • Sound effect used.
  • Unit type used as the bag.
  • The ability associated with the bag.
Also, I recommend using a 2 to 4 digit prefix for all your variables. This helps avoid conflicts with other systems or triggers that might be used in the same map. See: GPAG - GUI Proper Application Guide

You mentioned the system could be made multiplayer-compatible by switching from Game Cache to Hashtable. So why not use Hashtable from the start? That way, users don’t have to worry about compatibility depending on the map type — it’ll just work.

In its current form, the system isn’t quite lightweight or beginner-friendly enough. That said, it’s a great idea and a promising start. I really hope you keep improving it — looking forward to the next version!

Cheers!

Awaiting Update
Hi! Thanks for your suggestions. I'll work on a more convenient mode that uses fewer duplicates of the same trigger. When I have some free time, I'll work on refocusing the system better.

The reason I'm using GameCache is because the system, as it is, is focused on single-player, campaigns in general, or similar maps. Not multiplayer. That's why GameCache is necessary, since as far as I know, the hash tables only record and load data for the same map. :peasant-work-work:
 
The reason I'm using GameCache is because the system, as it is, is focused on single-player, campaigns in general, or similar maps. Not multiplayer. That's why GameCache is necessary, since as far as I know, the hash tables only record and load data for the same map. :peasant-work-work:
I see! If you ever want to make a multiplayer support for this that utilizes hashtable, you could make a separate system, so user can simply choose between the two. Just update the instruction, so they don't get confused.


Hi! Thanks for your suggestions. I'll work on a more convenient mode that uses fewer duplicates of the same trigger. When I have some free time, I'll work on refocusing the system better.
Awesome! glad to hear that. Looking forward to it. :)
 
I see! If you ever want to make a multiplayer support for this that utilizes hashtable, you could make a separate system, so user can simply choose between the two. Just update the instruction, so they don't get confused.
I'll work on that once I have the system more polished as it is.

Awesome! glad to hear that. Looking forward to it. :)
Update completed. I still need a way to further minimize user intervention. For now, I think the system is even clearer than before, and more automatic.
 
Back
Top