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!
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 .
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
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.
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...
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.
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.
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?
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.
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 ^.^...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
.
T Setup
Events
Map initialization
Conditions
Actions
Set HERO = Paladin 0000 <gen>
Time - Every 0.03 seconds of game time
Custom script: call SetUnitX(udg_BAG, GetUnitX(udg_HERO))
For each (Integer A) from 1 to 3, do (Actions)
