[JASS] General JASS Questions

[Wietlol]

Time for me to act dumb

1. Which one is better?
call TriggerRegisterPlayerUnitEvent(t, Player(0), EVENT_PLAYER_UNIT_ATTACKED, null) call TriggerAddCondition(t, Filter(function f))
-----
call TriggerRegisterPlayerUnitEvent(t, Player(0), EVENT_PLAYER_UNIT_ATTACKED, Filter(function f))
(Assuming that there will be no manual calls.)


2. How do I play a sound multiple times?
For example, I have a missile that plays a sound each time it hits a target.
However, the sound is played one time, then it won't play any more until it is finished.
How do I make it play multiple times at once.


3. How do I create massive registries without breaking the Operation Limit?
(And how big is that limit?)
Lets say I have 100 operations for each unit type and register 200 units.
Then I have 100 operations for each item and register 300 of those as well.
Then I register 400 abilities that require 100 operations.
Then I set data of all pre-made objects which requires for example, 10k operations.
Now I have 100k operations.
Can I simply put a call TriggerSleepAction(0.01) between most of them or do I have an alternative option?


4. What is TimerUtils and what does it do?
I always wondered and on the main threads it is actually never clearly told.


5. How can I reduce loading time of the map?
My map is currently loading 1:20-1:30 on my laptop and will be increasing massively (at least that is what I expect).
Are there any basic things that I can do to improve it?


6. Does it help to remove dead units?
I heard that units cause leaks. Maybe removing units can help that.

 

[PurgeandFire]

1. Event responses (such as GetSpellAbilityId() or GetTriggerUnit()) normally don't work in event filters. Keep that in mind. I almost always use TriggerAddCondition() since it works well--the difference is negligible.

2. It has to be a 3D sound.

3. Usually you can run things on new threads to avoid the op limit. There are plenty of functions that allow you to call functions on a new thread (TriggerEvaluate(), ExecuteFunc(), TimerStart(...) to name a few). But note that if you are running 100k operations, you'll most likely experience a big lag spike from wc3 trying to run all the computations involved in your loop. If possible, you should spread out the calculations over time (timers are good for that), and have a failsafe in case you need the calculations done right away.

4. Rather than giving you a huge explanation, I'll just link you a tutorial:
http://www.thehelper.net/threads/how-to-use-timers-in-jass.145499/
It is a bit dated, but that tutorial should give you the information you need. Here is a quick tl;dr version of it: most mapmakers will eventually want to make a spell that does things over time (e.g. damage over time, add some buff for X seconds, knockback a unit, etc.). Using TriggerSleepAction() isn't always the best option--especially for things that need to be done periodically (such as knockbacks). For those cases, you need to use timers. Timers require a separate function called the "callback" function. TimerUtils, and hashtables etc., allow you to "attach" data to the timer so that you can use the data in your timer function (without MUI issues). For an explanation on MUI, read the MUI part of this:
http://www.hiveworkshop.com/forums/...orials-279/visualize-dynamic-indexing-241896/

5. Use Widgetizer. There are some manual steps too:
http://www.hiveworkshop.com/forums/...ow-reduce-loading-times-object-editor-234574/

 

[Wietlol]

Thanx.

3. Usually you can run things on new threads to avoid the op limit. There are plenty of functions that allow you to call functions on a new thread (TriggerEvaluate(), ExecuteFunc(), TimerStart(...) to name a few). But note that if you are running 100k operations, you'll most likely experience a big lag spike from wc3 trying to run all the computations involved in your loop. If possible, you should spread out the calculations over time (timers are good for that), and have a failsafe in case you need the calculations done right away.

With InitTrig... functions, does all of those have their own thread or do I have to make a few timers that start with 0 seconds at map initialization?

Also what about 6?

 

[DD_legionTN]

What he meant is separate the operations with different timing (example sec 0 do action 1~10, sec 1 do 11~20 etc). In your case the map will still having bit lag spike (since all the actions/thread are queued if they are ordered to execute at same time, basically just like in same thread without having to worry about operation limit).

6. dead units (well here i'm just guessing base on my logic) having time to decay (mostly 60 seconds), during this timing the game have to handle the unit's corpses and saved in war3 memory. War3 need to handle them 1 by 1, after 60 seconds the unit is completely removed and automatically cleared from war3 memory. If you have lots of units that decaying, your war3 basically will more lag. Overall i don't think its a leak.

 

[edo494]

dead units will be remove automatically from the game after certain time.
That time is dependant on object editor data for that unit type. If it can be raised or does decay, it will take the whole 180 seconds(default, can be changed in gameplay constants) for the unit to be removed from the game, and if the unit cant raise nor does it decay, it should be removed rather shortly after playing death animation.

Unit leak is unavoidable.

Your map loads for so long most likely because you have 400+ abilities and god knows how many more object editor data. Widgetizer is nice, but it causes some overall problems with warcraft 3(next map you load may fail to load with
fatal error for instance).

InitTrigs all run in the same thread, since they are injected into the Main function as calls. JassHelper takes care of some initializers(dont remember exactly which) which get ExecuteFunc-ed.

 

[Fingolfin]

There are two main benefits from using TimerUtils:

1. Timers are recycled. The reason you want to do this is because the timer stack can get corrupted if you create and destroy too many timers (this is a very rare problem, though). Also, it is possible that retrieving an existing trigger is less taxing than creating a new one (don't quote me on that though).

2. It includes intuitive functions for attaching integers to timers. So basically, if you want to pass over a struct instance to a function called from a timer expiration, you can do this:

function B takes nothing returns nothing
    local mystruct m = GetTimerData(GetExpiredTimer())
    call ReleaseTimer(GetExpiredTimer())
endfunction

function A takes nothing returns nothing
    local mystruct m = mystruct.create()
    call TimerStart(NewTimerEx(m), 2., false, function B)
    //NewTimerEx() returns a new timer with the input integer attached to it
endfunction

 

[BloodDrunk]

For reducing loading time drastically, you can use W3mapOptimizer by Vexorian. It does a really good job optimizing your map.

Download it here, Wietlol. =}

 

[Wietlol]

@DD_legionTN
As mentioned in here... it does leak... but is unavoidable.

@edo494
Thats a pity.

@Fingolfin
But am I still able to save data in a hashtable under the handle Id?
Or do I have an alternative option?

@BloodDrunk
thanks... but we already had that one

 

[Fingolfin]

Yes, the GetTimerData function is just a hashtable load in disguise. TimerUtils uses its own private hashtable, and you can save as much data as you want to the timer in your own hashtable aswell. It's just that with TimerUtils it looks a bit prettier.

 

[PurplePoot]

TUtils is nice because you can attach a struct to the timer and then not worry about hashtables at all. I'm not usually one to use vJass libraries, but TUtils solves an easy and tedious problem in an elegant way, which makes it pretty much a must.