• 🏆 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!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Mpi | mui

Status
Not open for further replies.
Level 33
Joined
Mar 27, 2008
Messages
8,035
Okay, there 2 methods to make a spell MUI, namely: Hashtable OR Indexing

But, how to actually create a system, MPI ???
I've seen some triggers use the:
  • Set MPI = (Player number of (Owner of (Triggering unit)))
To make it MUI, or so I thought
Well, what is the difference between MUI and MPI in a trigger ???
Does, MPI usage is based ONLY on systems ???
While MUI, for spells ???

And, I just want to know...
What function/action that causes that trigger to become MPI
Like MUI, hashtable/indexing what causes that trigger to become MUI
 
Systems/spells/snippets; they are not by default what they are called, we define them with their uses.
My point is, a spell/system/snippet can be MPI too.

A spell can be MPI, so that, one unit per player can cast it simultaneously with other players' units, by avoiding conflictions.

A sample of MPI:
  • Trigger
  • Events
    • Unit - A unit uses an item
  • Conditions
    • (Item-type of (Item being manipulated)) Equal to Orb of Darkness
  • Actions
    • Set Hero1[Player number of (Owner of (Triggering unit))] = (Triggering unit)
  • Trigger2
  • Events
    • Unit - A unit dies
  • Conditions
    • (Triggering unit) Equal to Hero1[Player number of (Owner of (Triggering unit))]
  • Actions
    • Sound - Play Sound1
Same as MUI:
  • Trigger
  • Events
    • Unit - A unit uses an item
  • Conditions
    • (Item-type of (Item being manipulated)) Equal to Orb of Darkness
  • Actions
    • Hashtable - Save True as Key(useditem) of (Key(Triggering unit)) in Hashtable
  • Trigger2
  • Events
    • Unit - A unit dies
  • Conditions
    • (Key(useditem) of (Key(Triggering unit)) in Hashtable) Equal to True
  • Actions
    • Hashtable - Clear all child hashtables of (Key(Triggering unit)) in Hashtable
    • Sound - Play Sound1
 
Level 7
Joined
Dec 31, 2005
Messages
712
I think you know it, but MUI stands for Multi Unit Instanceable, and MPI for Multi Player Instanceable.

That is, MPI systems/spells/snippets can be used by every player simultaneously without malfunctioning, but generally not by every unit simultaneously. In Pharao's example, the sound would be played only if one specific unit had died for each player, not every player's units.

MUI systems/spells/snippets can be used by every unit simultaneously. In Pharao's example, again, the sound would be played if any unit who had picked an orb of darkness had died.
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
I'm opening this thread, because...
I was using a system (which I won't mention it here), and when the PLAYER UNIT activates that system, the player will get a direct disconnect message
Could this be that the system is NOT, MPI ?
I heard about Dr. Super Good saying if the system is not MPI, it will cause a "desync", that will cause that game to have multiple of split server, that's what causing the disconnects
Is it, true ?
 
Level 20
Joined
Jul 6, 2009
Messages
1,885
Won't work properly as it won't have the intended effect. If the system is supposed,for example,to periodically give you gold and it's not MPI,it won't give gold to all players.
If a system causes players to disconnect,it's not about system not being MPI,it means the system just...bugs,that's it.
 
Level 7
Joined
Dec 31, 2005
Messages
712
When we talk about MUI or MPI we're not talking about usefulness, exactly. We're talking about being able to be used simultaneously by more than one player (MPI) or unit (MUI). It's useful for some things, not for others.

For example, take a hero selection system such as double-clicking.
You'd like it to be MPI, since two players may be selecting hero at the same time.
MUI is not useful for this system, since units has nothing to do with this system at all (it would make sense if it were the units who selected a hero).

Now take a... Knockback spell.
If it was not MUI nor MPI, if two units had used this spell at the same time (only few seconds of difference, let's say), only the last one would really execute (it's an example of "malfunctioning", could happen other bad things).

MPI is partially useful. However, MUI is more useful as several units of the same player could cast the spell simultaneously (see how it's not MultiPlayerInstanceable, but MultiUnitInstanceable?)
 
Level 19
Joined
Feb 4, 2009
Messages
1,313
you won't get disconnects unless you spam actions or use (functions with) GetLocalPlayer

maybe you can tell us a bit more about what exactly you are trying to do so we can help you better

There should be,in my opinion,another category like SUMI (Same unit multi instanceable),which means that spell,for example,can be casted by same unit multiple times without malfunctioning.

had exactly the same idea
but I wanted to call it SMUI (super multi unit instanceablility)
your idea is ok, too
I demand everyone to use this expression now!:grin:
 
Level 22
Joined
Nov 14, 2008
Messages
3,256
you won't get disconnects unless you spam actions or use (functions with) GetLocalPlayer

maybe you can tell us a bit more about what exactly you are trying to do so we can help you better



had exactly the same idea
but I wanted to call it SMUI (super multi unit instanceablility)
your idea is ok, too
I demand everyone to use this expression now!:grin:

Not disconnects but desyncs and server splits.

Always if you use indexing it will be MUI or SMUI or whatever you want to call it. Hashtables can malfunction with the MUI part if not used correct.

Yet if something is MUI, then it's also MPI (duuh).

I thought MUI meant by the rules that a unit can cast the spell multiple times and every single unit can do it without malfunctioning... Seems that I'm wrong.
 
Level 22
Joined
Sep 24, 2005
Messages
4,821
SUMI
When a spell is cast, a spell object will be created, which is independent of the other spell objects of same and different spell parents, but knows who and what spell instanciated it.

Is that right?
 
SUMI does not really talk about a single unit casting a spell more than once at the same time... its more about ensuring that if a unit casts it successively while the effect is still active, it will not bug...

example of a MUI but not SUMI spell would be like this:

A spell which deals DoT, using the caster's handleID as a hashtable key... If the caster recasts, the old target will not be damaged anymore...

or a supportive self-target over-time spell which does not stack...
 
Level 15
Joined
Oct 16, 2010
Messages
941
There should be,in my opinion,another category like SUMI (Same unit multi instanceable),which means that spell,for example,can be casted by same unit multiple times without malfunctioning.

I've always though the same ^-^

SUMI does not really talk about a single unit casting a spell more than once at the same time... its more about ensuring that if a unit casts it successively while the effect is still active, it will not bug...

example of a MUI but not SUMI spell would be like this:

A spell which deals DoT, using the caster's handleID as a hashtable key... If the caster recasts, the old target will not be damaged anymore...

or a supportive self-target over-time spell which does not stack...

^ This is accurate

Essentially SUMI would create a spell object that contains all the data for that spell (instead of saving it to the casting unit using a hashtable or something). So the spell can be cast multiple times by any unit at any time and it will still work.
 
Level 15
Joined
Oct 16, 2010
Messages
941
What we mean is that, say you code a rejuvination effect that heals the caster for (100 * ability level) health per second for 10 seconds.

When the ability is cast you calculate the (100 * ability level) and save whatever that value is to a hashtable using the casters handle id right?

And you save a 'duration count' integer to the unit (via hashtable) and initialize it to 0. Then every second you add 1 to the duration count and heal the unit for whatever the initial saved value was. If the duration count is greater than 10, you remove the unit from the system.

The problem with this is that if a unit casts the spell, and then 5 seconds later casts the spell again, the second cast will overwrite the first one. It will re-calculate the heal amount and it will reset the duration count to 0 (effectively resetting the spell).

SUMI would be where the second cast DOES NOT overwrite the first cast and both work independently of eachother.
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
You mean like, SUMI can stack multiple of healing ?
Say, 5 seconds left until healing disappear and new one is casted to the same unit
Both fresh 10 seconds of healing AND 5 seconds of healing working together to heal the unit ?
Isn't that, imbalance ?
 
Level 22
Joined
Sep 24, 2005
Messages
4,821
SUMI again lol
So if a spell effect is non-stackable but is MUI, then it's classified as SUMI? What if the spell is MUI but the effects are stackable and does not bug out?
 
Level 29
Joined
Mar 10, 2009
Messages
5,016
When the ability is cast you calculate the (100 * ability level) and save whatever that value is to a hashtable using the casters handle id right?

That will definitely bug, but why using caster's ID?...like what I said above...

use a different one like 'last created unit' or put a condition 'handle Id exist'...

you can even use picked unit's ID when you cast the ability by using Unit Groups...
 
Level 15
Joined
Oct 16, 2010
Messages
941
Quote:
When the ability is cast you calculate the (100 * ability level) and save whatever that value is to a hashtable using the casters handle id right?

That will definitely bug, but why using caster's ID?...like what I said above...


Quote:
use a different one like 'last created unit' or put a condition 'handle Id exist'...

you can even use picked unit's ID when you cast the ability by using Unit Groups...

O.K....say you use some random units ID, then if you cast it again on that unit it will do the same thing. All a handle ID is is an integer value that is unique to every unit object. Therefore every unit on the map has a unique handle ID. If you saved it to "picked units handle ID" or whatever then your just saving it to whatever unit you just looped through.
 
Level 22
Joined
Nov 14, 2008
Messages
3,256
Stop this nonsens.

First. A spell cannot be casted at the same time as another spell due to trigger queue even instant spells without waits cannot be casted at the same time.

Second. The SUMI or SMUI thing seems weird. Isn't MUI for that purpose? Obviously using a unit's id that will be able to cast the same spell again when the first one isn't finished is bad triggering. It's easy in plain JASS as you can just use a timer's id (for the simpliest example).

Using the id of a dummy is fine I guess as long as you don't enum the locust units and bug (yeah there are a script somewhere that enums locust units too, I think EnumUnitsOwnedByPlayer or something).

Third. In a loop you use the "picked unit's" id. Not in the cast trigger. If that was what you meant.

Fourth. When did MUI became one spell instance per every unit on the map? I thought that it was unlimited instances for the same caster (and with caster I mean every single unit on the map). But I'll guess I'm wrong.
 
Level 29
Joined
Mar 10, 2009
Messages
5,016
First. A spell cannot be casted at the same time as another spell due to trigger queue even instant spells without waits cannot be casted at the same time.

This I Agree...

If you saved it to "picked units handle ID" or whatever then your just saving it to whatever unit you just looped through.

No, its not 'whatever', I said Unit groups
You can save an ID even if you use GetEnum...


  • test
    • Events
      • Unit - A unit Starts the effect of an ability
    • Conditions
      • (Ability being cast) Equal to Bloodlust (Neutral Hostile 1)
    • Actions
      • Set Index = 0
      • Set Pt[1] = (Position of (Target unit of ability being cast))
      • Set UGrp1 = (Units within 400.00 of Pt[1] matching (True Equal to True))
      • Unit Group - Pick every unit in UGrp1 and do (Actions)
        • Loop - Actions
          • Set Index = (Index + 2)
          • Set ID = (Key (Picked unit))
          • Hashtable - Save (5.00 + (Real(Index))) as (Key timer) of ID in Hash
          • Unit Group - Add (Picked unit) to UGrp2
      • Custom script: call RemoveLocation(udg_Pt[1])
      • Custom script: call DestroyGroup(udg_UGrp1)
      • Trigger - Turn on testloop <gen>
  • testloop
    • Events
      • Time - Every 1.00 seconds of game time
    • Conditions
    • Actions
      • Unit Group - Pick every unit in UGrp2 and do (Actions)
        • Loop - Actions
          • Set Pickedtest = (Picked unit)
          • Set ID = (Key (Picked unit))
          • Set timer = (Load (Key timer) of ID from Hash)
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • timer Greater than 0.00
            • Then - Actions
              • Hashtable - Save (timer - 1.00) as (Key timer) of ID in Hash
              • Game - Display to (All players) the text: (String(timer))
            • Else - Actions
              • Custom script: call KillUnit(udg_Pickedtest)
              • Unit Group - Remove Pickedtest from UGrp2
              • Hashtable - Clear all child hashtables of child ID in Hash
              • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                • If - Conditions
                  • (UGrp2 is empty) Equal to True
                • Then - Actions
                  • Trigger - Turn off (This trigger)
                • Else - Actions
 
Level 15
Joined
Oct 16, 2010
Messages
941
Quote:
First. A spell cannot be casted at the same time as another spell due to trigger queue even instant spells without waits cannot be casted at the same time.

This I Agree...

What we meant by "casting at the same time" is any situation where a unit casts a spell before the initial effect is over.

And if we enum those units after they're already been enumed? That will overwrite the previous or am I just wrong?

No, you're right
 
Level 22
Joined
Sep 24, 2005
Messages
4,821
Incorrect.

test script:
JASS:
globals
    constant group g=CreateGroup()
endglobals

function enumgroup takes nothing returns nothing
    call BJDebugMsg(I2S(GetUnitUserData(GetEnumUnit())))
endfunction

function doTest takes nothing returns nothing
    local integer i=0
    local unit c=null
    loop
        set c=CreateUnit(Player(0),'hfoo',0,0,0)
        call UnitAddAbility(c,'A000')
        call SetUnitUserData(c,i+1)
        call GroupAddUnit(g,c)
        call GroupAddUnit(g,c)
        call GroupAddUnit(g,c)
        call GroupAddUnit(g,c)
        exitwhen (i==5)
        set i=i+1
    endloop
    call ForGroup(g,function enumgroup)
    call BJDebugMsg("There are "+I2S(CountUnitsInGroup(g))+" units in the group.")
endfunction

function InitTrig_grouptest takes nothing returns nothing
    call TimerStart(bj_lastStartedTimer,1.0,false,function doTest)
endfunction

This test displayed:
1
2
3
4
5
6
There are 6 units in the group.

Conclusion: A unit is checked first if it already exists in a group before it adds the said unit.
 
Level 22
Joined
Sep 24, 2005
Messages
4,821
Oh, sorry, what Id were you referring to? HandleId's? could you explain a bit, I'm confused looking at GUI triggers. I shouldn't have butt in, I thought you were talking about adding units to groups. LOL
 
Status
Not open for further replies.
Top