• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • 🏆 Hive's 6th HD Modeling Contest: Mechanical is now open! Design and model a mechanical creature, mechanized animal, a futuristic robotic being, or anything else your imagination can tinker with! 📅 Submissions close on June 30, 2024. Don't miss this opportunity to let your creativity shine! Enter now and show us your mechanical masterpiece! 🔗 Click here to enter!

Backpack/bag system?

Status
Not open for further replies.
Level 3
Joined
Feb 19, 2009
Messages
24
Very sorry for all the questions forums, but i have one more (for now,). i was wondering, is there any Backpack system on here? i looked around a bit, couldn't seem to find one, but i would like one where you open the bag, you can have an extra page or 2 that you can place more items in, That'd be cool :).
 
Level 13
Joined
May 11, 2005
Messages
416
a simple way of doing that on GUI would be creating a dummy unit with an inventory and force selecting it for the player when he uses the bag item. make it a dummy hero for added accessibility, that way you can select it from the icon on the left side of the screen
 
Level 3
Joined
Feb 19, 2009
Messages
24
that seems ok, but how do i make it follow 24/7, even if someone clicks away? do i use trigger using region or what>?
 
Level 7
Joined
Sep 9, 2007
Messages
253
my first thought is to use a trigger which orders the dummy unit to move to your hero's location and make it fire every second.

Or, you could make it more efficient by moving the dummy unit to your hero's location only when it needs to be nearby. for example.... if you use a trigger such as the one suggested by Diosilva16 where you force select the dummy unit, you could simply add "Move" action to this trigger which moves the dummy unit to the position of the corresponding hero.
 
Level 14
Joined
Apr 20, 2009
Messages
1,543
While your at it, don't forget to remove the location where you want your dummy unit to be moved to. Else the location will stay inside the memory of the game until it finishes, which can cause lag if exceeding the amount of RAM memory of the player, Which is why it is being called a "leak". The more "leaks" you have inside your game, the more chance people will start lagging because it builds up RAM memory usage.

set my_location_variable = position of your hero
move dummy unit to my_location_variable
call RemoveLocation(udg_my_location_variable)

call RemoveLocation is the action Custom Script in GUI...
 
Level 13
Joined
May 11, 2005
Messages
416
i usually just store the location in a var named tempLoc and don't bother removing it, since every time the trigger runs it overwrites the variable it doesn't leak... unless i'm missing something, but according to my benchmark tests it's safe.
 
Level 4
Joined
Jun 25, 2010
Messages
94
i usually just store the location in a var named tempLoc and don't bother removing it, since every time the trigger runs it overwrites the variable it doesn't leak... unless i'm missing something, but according to my benchmark tests it's safe.

Then you're missing something. A leak is something that get's created but never get's removed (Like garbage), you store the data of the location(Or some other stuff that leaks) in a variable so you know where that garbage/location lies in the memory, but if you simply overwrite that variable with another garbage/location it "Forgets" where the other garbage/location lies. So you first have to remove the garbage/location you first created then afterwards add a new location of the new garbage/location in the variable.
 
Level 13
Joined
May 11, 2005
Messages
416
i've tested it before for a random map generator i was working on, i made a trigger that created a few thousand locations per second, when i left the trigger leaking the game usually became very laggy and crashed a couple minutes into it, after modifying the trigger to simply set tempLoc to a random point i've managed to keep the trigger running for a couple hours before i got bored. i've stopped removing variables ever since and haven't had any problem, so i guess it doesn't leak. is there something else i'm missing?
 
Level 14
Joined
Apr 20, 2009
Messages
1,543
i've tested it before for a random map generator i was working on, i made a trigger that created a few thousand locations per second, when i left the trigger leaking the game usually became very laggy and crashed a couple minutes into it, after modifying the trigger to simply set tempLoc to a random point i've managed to keep the trigger running for a couple hours before i got bored. i've stopped removing variables ever since and haven't had any problem, so i guess it doesn't leak. is there something else i'm missing?

It does leak, all your doing is overwriting the data stored inside the variable, however the location is not removed and therefore still in memory!
If you have recently bought a better computer with more RAM memory or have changed your RAM memory then it means that your computer can handle more memory leaks.
And b.t.w. your not removing the variable but your removing the location. Removing the variable would mean nullifying the variable as such: set udg_My_var = null
Which means the variable still exists but does not take any memory since it's completely empty.
The most optimized way of removing a location leak would be setting a variable to the location, using that variable,
removing the location and afterwards nullifying that variable.
Although I doubt that 1 more stored variable inside your memory won't make any difference...

A few tips on optimizing your map:

Add expiration timers to killed units to decrease the decaying timer of units to reduce the amount of units in your map.
Nullify variables if they are not used in your game anymore.
Note:
When using local handle variables in JASS, they cause a small leak. A handle is everything except real, string, integer, and boolean. If I'm not mistaken, this only occurs if the handle is ever destroyed or removed from the game. This means that if you are certain a handle will never cease to exist, it's safe not to null the variable. Althought players are handles, they should never need to be nulled.
JASS:
local unit u = GetTriggerUnit()
call SetUnitFacing(u, 270)
call SetUnitFlyHeight(u, 300, 50)
set u = null

Explanation of local variables: local variables are basically used to make triggers Multi User Instanceable.
Meaning that the trigger can be triggered simultaneously without causing the player who trigger it to de-synchronize with the data that is being send from the server to the client. Server in this case would be the game and client your computer.
When this happens the player does not receive the actual game data from the game causing the player to see stuff that is not actually there, or not see stuff that actually is there.
This usually causes the player to disconnect from the game.
So using local variables mean that multiple users can trigger the trigger at the same time since they are not using the same global variables at the same time, but local ones for each player.
Mostly of the time local variables are used in triggered spells and such.
However there are also ways of showing data to a player locally without causing a desync (however this depends on where you are using it for). For example:

JASS:
if (GetLocalPlayer() == player(0)) then
Do something here for player 1 locally
endif

GetLocalPlayer() is one of the most usefull natives out there...

Destroy Triggers when they are not being used anymore.
Note:
Only do this when you're sure you're not going to use them anymore: call DestroyTrigger(GetTriggeringTrigger())
Destroy Player Groups when they are not being used anymore.
Destroy Sounds when used.
Destroy Special Effects when used.
Destroy Unit Groups when they are not being used anymore.

Take reference here: http://www.hiveworkshop.com/forums/general-mapping-tutorials-278/complete-list-things-leak-126761/

Adding an expiration timer or removing killed units is not a leak but is considered to optimize your map since it decreases the amount of units in game.

With random point what exactly do you mean? Coordinates do not leak, for example: UnitX, UnitY

I hope this helps in improving the performance and speed of your map ;)!
I also hope this post has learned you something new ^.^...
 
Last edited:
For single unit.
  • T Setup
    • Events
      • Map initialization
    • Conditions
    • Actions
      • Set HERO = Paladin 0000 <gen>
      • Set BAG = Footman 0001 <gen>
  • T Loop
    • Events
      • Time - Every 0.03 seconds of game time
    • Conditions
    • Actions
      • Custom script: call SetUnitX(udg_BAG, GetUnitX(udg_HERO))
      • Custom script: call SetUnitY(udg_BAG, GetUnitY(udg_HERO))
For more units.
  • T Setup
    • Events
      • Map initialization
    • Conditions
    • Actions
      • Set HERO[1] = Paladin 0000 <gen>
      • Set HERO[2] = Archmage 0002 <gen>
      • Set HERO[3] = Mountain King 0003 <gen>
      • Set BAG[1] = Footman 0001 <gen>
      • Set BAG[2] = Footman 0004 <gen>
      • Set BAG[3] = Footman 0005 <gen>
  • T Loop
    • Events
      • Time - Every 0.03 seconds of game time
    • Conditions
    • Actions
      • For each (Integer A) from 1 to 3, do (Actions)
        • Loop - Actions
          • Custom script: call SetUnitX(udg_BAG[bj_forLoopAIndex], GetUnitX(udg_HERO[bj_forLoopAIndex]))
          • Custom script: call SetUnitY(udg_BAG[bj_forLoopAIndex], GetUnitY(udg_HERO[bj_forLoopAIndex]))
To make it full MUI I suggest hashtables and UnitHandles.
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
Kobas, I think your trigger now IS fully MUI, the thing is, you're doing it indexing, it is still MUI but needs to be fixed.

There should be an unlimited number of registration instead of 3 you put there, so, every register unit event occur, you should:
  • Set Hero[CurrentNumber] = (Current Number + 1)
At the loop trigger, just loop from 1 to CurrentNumber

So you can loop an unlimited amount of registration
CurrentNumber should start initial value as 0.
 
Status
Not open for further replies.
Top