HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps
Wc3C.net » Warcraft III Modding » Developer's Corner » Triggers & Scripts » MUI - truth and misconceptions

MUI - truth and misconceptions

08-14-2007, 11:38 AM#1
cohadar
Ok we all now what MUI is,
it means Multi Unit Instancable, a spell that can be used by any number of units.

We will examine this in a little bit detail now.

Meet Bob,
Bob is an experienced GUI mapper who decided it is about time to learn JASS.
Bob also knows there is one kind of spells that is easily made with GUI and that is almost MUI, the MPI.
(Multi Player Instancable)

Bob made a lot of MPI spells in his GUI career
using arrays[16] to keep spell data for each player separate,
and using player numbers as array index,
it was all he ever needed for his cool new AoS

But this MPI spells have a problem that they are connected to the players
and he learns that is bad and he learns about JESP and stuff like that.

Now in JASS Bob finds out that by attaching stuff to timers,
using handle-vars or any other system out there
he is able to make MUI spells that can 100% be used by any unit.
I finally made it thinks Bob, I am a pro Jasser now, who's da man.

Meet Joe,
a man who spends more than 8 hours a day on JASS forums,
has rep in three digits, and probably has a couple of systems,
or even tools of his own, he is generally acknowledged and respected.
He tried every possible system that was ever created and finally settled with structs. (he still used handle-vars because he needs it for some old spells he created like 3 years ago because he does not want to hussle and recode them again)

Now Joe knows something that Bob does not,
it is the great secret of MUI, a deep dark truth kept from innocent GUI mappers by centuries and guarded by secret societies like Illuminati, Freemasons or Blizzard.
It is a secret behind number 23.

Warning: Tell anyone and you will die by natural causes.
Hidden information:

Bobs spells that use handle attachments are not really MUI,
spells in JESP section are also not MUI,
actually the number of custom spells that actually are MUI is exactly 23.
Those spells are kept coded on the scrolls from the dead sea.
No man has ever seen all of these scroll,
Vexorian who is believed to be one of the higher Illuminati
has actually seen only 5 of them in his life time.

Wait 23? The Illuminati? What is going on here asks Bob?
What is the price you would pay for the truth Bob?

The catch is this:
The spells for witch is believed that are MUI are actually MUI69 (3*23)

What does this mean?
It means that spells that attach stuff to timers are
Multi User Instancable as long as the number of units is <= 69

Wait this cannot be true says Bob,
why 69 out of all numbers, why is it so special?

Have you ever tried using your MUI spells with more than 69 units at the same time?
No, but...

And Bob discovered the horrible truth...
When he uses his MUI spell with more than 69 units at the same time,
his game deadlocks and two serpents appear on his screen
biting each-others tail.

Now Bob never existed, and that dialog never happened
or maybe we don't know if Bob really existed, or Bob was smart enough to turn around and walk away the moment the things started to sound creepy.
As for you peoples that are not so smart...
...
It happens because when you attach stuff to timers to make the spell MUI
you must:
1. create local gamecache to store your spell data.
2. create a timer for each instance of spell.

When number of timers that run at the same time exceeds 69
the game lags to a serpent-lock

When number of spells that use gamecache exceeds 253 the game crashes.

Now Bob has never seen this because
in his AoS there is only 12 players and each player has one hero,
so even if they all pick same hero for some stupid reason
and all of them use all 5 spells at the same time,
and all that spells happen to just accidentally be with timers,
there would be only 12*5 = 60 < 69 timers running at the same time.
Bob map is safe, thanks God.

Now Bob does not know this truth,
and Joe knows that Bob does not need to know it in the first place.

Ok but what about that gamecache stuff? why was that mentioned?
Well the point there is that if there are more than 253 spells that use gamecaches even if they dont use timers,
the game will also serpent-lock.
253 = 2(2+3)3 = 11*23 - coincidence don't you think?

At some point of this tale one of the members of Illuminati decided
to turn against his brotherhood.

He designed an array system that could store 16 or 32 or even 64 structs
at the same time.
He named his arrays Collection16, Collection32, Collection64.

Now spells made with this system are MUI16, MUI32 and MUI64 respectfully,
MUI16 would be enough for any AoS map, MUI32 would be used in rare
cases where is more than one struct per spelldata,
and MUI64 would be used for really complex spells.

None of this spells would ever be truly MUI,
but we know there is no such thing as true MUI
there is only MUI69, and MUI64 is pretty close to 100% MUI
in the terms of Illuminati.

The author of these collections was first ordered to make
Collection23 and Collection69, but that never came to be.

Why hasn't he done so is unknown, so is the fate of this author,
But one thing remains open
Collection64 is only 5 steps away from Collection69
and 5 = (2+3)

Coincidence don't you think?
08-16-2007, 10:00 PM#2
Vexorian
...

what are you talking about? I have seen even 1000 timers works simultanouesly without deadlocks..

Quote:
When number of spells that use gamecache exceeds 253 the game crashes.
what are you talking about? Or does suddenly gamecache spell now requires its own gamecache?

--
I mean, sure no spell is actually MUI, unless of course it is one of those spells that don't require any wait or things like that, but I don't really agree with the numbers
08-16-2007, 10:08 PM#3
cohadar
That thread is a mix of fantasy and truth,
but there are some hard truths in there.

I was talking about high frequency timers.
On my pc when I play around 70 timers with 0.04 period it locks.

As for gamecaches 256 is the limit I think,
but you are right when you say not every spell has it's own gamecache,
on the other hand that mission key is overused,
I always wondered is there a limit to number of mission keys...
08-16-2007, 10:14 PM#4
Vexorian
We once looked for the mission key and other limits within a gamecache.

They are very high...

Right now I wouldn't trade using a single timer with no attaching involved with anything out there...
08-16-2007, 10:22 PM#5
cohadar
Quote:
Originally Posted by Vexorian
We once looked for the mission key and other limits within a gamecache.

They are very high...

Right now I wouldn't trade using a single timer with no attaching involved with anything out there...

How do you mean with NO attaching involved?
08-16-2007, 10:46 PM#6
grim001
god you keep going on and on without stopping to learn first cohadar
08-16-2007, 10:53 PM#7
cohadar
I like going ahead of myself
Now as far as I know there is no way to use gamecache
in combination with timers and make a spell MUI
without attaching to timer.

If there is please enlighten me.
(gasoline and some matches would do )
08-16-2007, 11:18 PM#8
Earth-Fury
http://wc3campaigns.net/pastebint.ph...3ffd04408ae7e1
Collapse JASS:
library TimedEvent initializer Init

globals
 //***   Configuration   ***
 private integer NumberOfTimers = 100
 //*** End Configuration ***

 private integer array TAGS
 private Callback array CALLBACKS
 private timer array TIMERS
 private integer N = 0
endglobals

function interface Callback takes integer tag returns boolean

private function H2I takes handle h returns integer
    return h
    return 0
endfunction

private function TimedEventExpires takes nothing returns nothing
 local timer t = GetExpiredTimer()
 local integer i = H2I(t)-0x100000
    if not CALLBACKS[i].evaluate(TAGS[i]) then
        call PauseTimer(t)
        set N = N + 1
        set TIMERS[N] = t
    endif
endfunction

function TimedEvent takes real delay, integer tag, Callback callback returns nothing
 local timer t
 local integer i
    if N == 0 then
        call BJDebugMsg("TimedEvent Error: Maximum numbers of timers ("+I2S(NumberOfTimers)+") exceeded")
        return
    else
        set t = TIMERS[N]
        set N = N-1
    endif
    set i = H2I(t)-0x100000
    set TAGS[i] = tag
    set CALLBACKS[i] = callback
    call TimerStart(t, delay, true, function TimedEventExpires)
endfunction

private function Init takes nothing returns nothing
 loop
     set TIMERS[N] = CreateTimer()
     exitwhen N == NumberOfTimers-1
     set N = N + 1
 endloop
endfunction

endlibrary
08-16-2007, 11:27 PM#9
Toadcop
Quote:
H2I(t)-0x100000
in playable maps it's unsave...
08-16-2007, 11:41 PM#10
MaD[Lion]
Make periodic trigger of 0.01 frequency, and make Struct called CustomTimer.
And update these custom timers in this periode trigger. And voila u have a beautiful custom timer tat works :D I use this method for my stuffs...
08-17-2007, 12:08 AM#11
cohadar
Collapse JASS:
 local integer i = H2I(t)-0x100000
    if not CALLBACKS[i].evaluate(TAGS[i]) then

But this IS attaching to a timer,
it is unsafe and system depedant and ugly.

This is by far the worst method I have seen so far.

Collections are superior to this in every way.

EDIT:
I must admit that general idea for this is interesting,
but implementation is just horrible.

This would work a lot better if ABC hash algorithm was used.
And not all timer events need to be periodic.

But on the other hand all that this does is that
instead of attaching an integer to a timer
you attach a callback to a timer,
so it is basically unnecessary indirection.

Even plain old handlevars is better than this.

This method truly sux

EDIT2:
I did NOT double post, I just edited my previous post,
forum bug?
08-17-2007, 08:32 AM#12
grim001
No one ever said EarthFury was correct, that system he posted is just another method of attachment. Furthermore it doesn't operate on the same basis as DataSystem, so your assumption that it has the same so-called limitation is incorrect. (I guess toadcop is clueless too) Not that DataSystem ever had a limitation to begin with, since the number of arrays it uses can be extended infinitely, or backup to GC can be used, and only leaking morons would run into a problem with the 3 default arrays.

So on top of being wrong about all that:

To handle a periodic thing with no attachment, a timer can loop through a given array of structs and handle all instances of a spell simultaneously. It's obviously the best method when it's available. "Attaching" to a timer is very rarely needed at all except for arbitrary length periods.
08-17-2007, 08:48 AM#13
cohadar
Quote:
Originally Posted by grim001
To handle a periodic thing with no attachment, a timer can loop through a given array of structs and handle all instances of a spell simultaneously. It's obviously the best method when it's available. "Attaching" to a timer is very rarely needed at all except for arbitrary length periods.

Funny thing is that is EXACTLY what collections do,
so you just said that I am wrong because my system is the best way to do it ^^
08-17-2007, 08:52 AM#14
grim001
Except with a bunch of useless wrapper functions slowing it down, after all the point of the low-level approach is speed.

Your system solves a non-existent problem.
08-17-2007, 09:01 AM#15
cohadar
How about a problem of ugly and hard to understand code?
Or the code that is so low level that you are not sure if you can change anything without fucking up something else?

Besides even with wrapper functions it is faster than direct attachments,
not to mention that it is easy to use, simple to understand,
provides good encapsulation and makes pretty code.
Wc3C.net archive — static reconstruction. No accounts, no posting.
Hosted by www.hiveworkshop.com