Define MUI

[baassee]

Hey.

I just had to bring this crap up for discussion.

As most people are aware of, our spell section requires a spell to be "Fully MUI" to be accepted. However what is "MUI"? Let's break it down.

MUI follows:

Every single unit should be able to have one instance running without clashing with another's.

Now the fun part:

So each and every unit should be able to have ONE instance running. So what about having 2 instances running from the same unit?

Example.

By using an unitindexer we made our example. Basically it's a missile traveling 800 units and then exploads.

The index of our arrays is the "UnitID".

We cast the spell once and once only. Looking good so far, the missile travels 800 units and then exploads. Now we cast it once and before the first instance ends, we cast it AGAIN. Now the arrays are being overwritten by new values and we loose our first instance (leaks it). You see the brilliance here? The spell is MUI but it still bugs the shit out (pardon my use of words).

We can also use the same example and situation, using a hashtable with the unit's ID (using GetHandleID on the unit) as parentkey. Same leak will occour but it's still MUI by definition? This can however be easily prevented using the missiledummy's handle ID instead of the caster to make it fully able to run unlimited instances. But that's not the case anyway.

So can I upload a spell, doing this one-instance-per-unit shit and still get accepted (not that I would, indexing for life)? Ooooooooooooooooooooor will it get rejected when I followed the rules?

Regards,
~baassee

 

[Yixx]

Just use structs and allocate a new struct each time it is cast. Then destroy it after the appropriate time, within the struct. Problem solved. No need for any Handle ID's, Indexing or other stuff..

 

[baassee]

Just use structs and allocate a new struct each time it is cast. Then destroy it after the appropriate time, within the struct. Problem solved. No need for any Handle ID's, Indexing or other stuff..

Yeah man, I would never even get troubled by this issue but just wanted to bring the discussion up 'cause it's seriously ridiculous that it - in theory - should be accepted by THW rules.

 

[Anachron]

There are:
OSI = One Single Instance
MPI = Multi Player Instanceable
MUI = Multi Unit Instanceable
SUMI = Same Unit Multi Instanceable

however, most only talk about MPI and MUI.

What does this mean for programming:
OSI = No problems
MPI = Don't interfere with other players
MUI = Don't interfere with other units
SUMI = Don't interfere with other instances of the same cast.

Examples:
OSI = Weather System
MPI = Resource Share System
MUI = Most of the spells
SUMI = Spells that have no cooldown or stackable spells.

 

[baassee]

There are:
OSI = One Single Instance
MPI = Multi Player Instanceable
MUI = Multi Unit Instanceable
SUMI = Same Unit Multi Instanceable

I remember when we had this convo a few years ago.

 

[Anachron]

Oh, now that you say it, yes I remember. We were talking in a spell thread iirc.

 

[rulerofiron99]

I prefer to use the dummy's index as the spell's index. This is especially for projectiles, but the same principle can be applied to any spell I suppose.

 

[mckill2009]

So can I upload a spell, doing this one-instance-per-unit shit and still get accepted (not that I would, indexing for life)? Ooooooooooooooooooooor will it get rejected when I followed the rules?

No you cant, the rules says it should be MUI (multi), not one-instance, and people pls get real, there's no such
thing as execution at the same time, one spell should be first from the other, why? coz jass scripts has a single thread...

SUMI = Same Unit Multi Instanceable

I define it as more than 1 different spells but uses the same orderID's...

 

[baassee]

You know that MUI means Multi-Unit-Instance able? Means multiple units not multiple instances from the same unit.

 

[Anachron]

Either make it MUI or SUMI.
But if you make it MUI, make sure you check if it's already casted and throw an error or overwrite it so it won't cause a crash/bug.
If you make it SUMI, make sure you tested it enough so it won't cause nasty glitches or freeze.

 

[mckill2009]

True, but it doesnt mean it can be able to cast at the same time, no thread and no function in wc3 script runs at the same time,
it always has a delay, like loops...

 

[baassee]

Yes I know JASS runs in threads. But as you saw in my example, over time based spells will overwrite the first one doesn't really matter if WC3 runs on threads or not.

 

[Anachron]

Nothing could possibly be on the same time since computers are designed to not support it. What I was talking about is that you have such a small cooldown that the spell could be active 2 times (like healing wave or such) at the same second.

 

[HappyTauren]

SUMI is the only sane way to make spells, ever.

 

[mckill2009]

oh wait, I forgot, how can it be MUI if arrays are being overwritten?, Im talking about this:
target[1], first cast
target[1], cast again

but if you're talking about this kind of overwriting:
target[1]
target[2]
then my bad...

 

[baassee]

That's what I'm talking about...

Basically a caster casts a spell that will last of an unknown duration greater than 0.

The same caster casts the exact same spell (thus the same code will fire) BEFORE the previous spell has ended. Now if we are using the caster ID from either a unitindexer or as a parentkey, this will overwrite all previous storage of the other spell BUT it will not be destroyed thus it will still exist as a leak.

I cannot clarify this more.

 

[Anachron]

Base, please check my suggestion about MUI/SUMI.
Also take care of Happytaurens suggestion, as this is the only way to make useful spells for mappers. (if possible)

 

[baassee]

Which one?

It's HappyTauren XD

 

[Anachron]

This one. And yes, I mean HappyTauren.

 

[baassee]

Ah that one. Yeah completly true but why create a spell that is only cast-able once for every unit in the first place I mean it works for spells that affects the caster in someway that makes it impossible for it to cast the same spell again.

 

[Anachron]

Well, sometimes you don't want spells to stack. (If it makes no sense, like Vodoo, enemy unit's are already invulnerable, what sense does it make to have 2 instances at the same time?) It still can be cast endless, but only one instance at the same time.

 

[baassee]

True true.

 

[Troll-Brain]

True, but it doesnt mean it can be able to cast at the same time, no thread and no function in wc3 script runs at the same time,
it always has a delay, like loops...

What ?!

There is no delay at all, it's just that jass is not multi-threaded, one thread active only.
And i don't get what you mean with loops ...

 

[mckill2009]

thus the same code will fire

oh yes! but it doesnt run at the same time, that's why timers or intervals are there, uses different index or handleID's,so it's called MUI...

BUT it will not be destroyed thus it will still exist as a leak.

correct coz overwriting doesn't mean its being destroyed, btw all spells that uses indexers or handleID's will surely leak if
that unit (or a handle) never comes back...

EDIT:

There is no delay at all, it's just that jass is not multi-threaded, one thread active only.
And i don't get what you mean with loops ...

can you see the delay?, I can...

function test2 takes nothing returns nothing
    call BJDebugMsg("test2")
endfunction

function test1 takes nothing returns nothing
    call BJDebugMsg("test1")
endfunction

function test takes nothing returns nothing
    call test1()
    call test2()
endfunction

 

[rulerofiron99]

GUI SUMI is the only sane way to make spells, ever.

Fixed for you

 

[baassee]

You do not get the point here. We're not talking multiple timer usage, we're talking looping with the same timer. And as stated, I said that the index used will either be from an UnitIndexer OR the caster ID as PARENTkey and due to these factors, it will be "MUI" but still it will leak either way.

btw all spells that uses indexers or handleID's will surely leak if
that unit (or a handle) never comes back...

What? Easily prevented using either some ID that will not be used again like a dummy's ID or just index within hashtables.

EDIT:

And yes this thread mostly concerns GUI coded things as we in JASS and the other JASS preprocessors do not experience these issues.

 

[Troll-Brain]

@mckill2009 : What the hell are you talking about, here you don't even open a new thread ...

 

[rulerofiron99]

Well if we're on GUI SUMI, you index the spell by a dummy unit, like a projectile. Save the caster to that projectile's index. Add the dummy to a unit group. Every loop of the spell (using one timer), pick every dummy associated with that spell and do your thing.

 

[baassee]

If you index you will not experience this problem at all as each index will be unique thus a caster can be on all available indexes yet it will act differently (if you moved as an example).

 

[mckill2009]

@mckill2009 : What the hell are you talking about, here you don't even open a new thread ...

OMG! dude you still didnt get it?, Im talking about the delay of >>>test1()>>>DELAY>>>test2()
test1 will always runs first, you may not see or feel the delay coz it's instant!...

 

[Troll-Brain]

You're crazy.

 

[rulerofiron99]

I think the word he's looking for is order of functions.

Technically there is a "delay" between the switches in the processor doing their thing, but for all intents and purposes yes it's instant.

 

[baassee]

I still don't understand a single bit. JASS is single-threaded - the end. Or?

 

[mckill2009]

This!

i think the word he's looking for is order of functions.

Technically there is a "delay" between the switches in the processor doing their thing, but for all intents and purposes yes it's instant.

and thank you!

JASS is single-threaded - the end. Or?

yes and period ...

 

[Anachron]

TrollBrain and mckill2009:
You both actually mean the same thing, so please stop arguing.

I guess this question has been answered now.

 

[HappyTauren]

As far as I know, JASS should use faux multithreading, which means that it has many threads running, but only does operations on one at the time. That'd also make sense, considering people didn't really think processors like the ones we have today could exist for the consumer market, back at the time wc3 was released. I'd also like to note that this:

Well if we're on GUI SUMI, you index the spell by a dummy unit, like a projectile. Save the caster to that projectile's index. Add the dummy to a unit group. Every loop of the spell (using one timer), pick every dummy associated with that spell and do your thing.

pretty much corresponds to what is done in jass with structs like

public struct instance
    unit u
    real x
    real y
    real inc
endstruct

By making structs instance based instead of unit based (the same thing you're doing in GUI), it opens up a wider array of possibilities, so if you may intend for spell to have cooldown, spell shouldn't fail if the user wants to remove cooldown altogether.

 

[mckill2009]

JASS should use faux multithreading

I call it looping through instances...

 

[Troll-Brain]

Well obviously nothing is instant, it's like saying the sun is shinning or the world is not flat.
You first sentence didn't make sense, now it's ok.

 

[HappyTauren]

It cannot be instant, but that is far from being an issue, not to mention that wc3 interfaces with the user at 65 FPS max (unless set differently in the registry), which means that if you can have all the systems do their thing in 1/65 of the second, user will not notice any artifacts, most of the time. I try to clock all my systems to 1/40, and delay is still not really visible.

 

[Anachron]

You sure? I had 67-69fps already with default registry keys.
Too bad I can't prove it because I didn't make screenshot.

Basically, I agree with you. Even 1/33 is not really noticeable for the human eye (depends on system though, if you have missile system with high speed it's a lot easier to notice).

 

[Adiktuz]

if the overtime uses a dummy per cast, you should use the Id of the dummy

if not, then you better use structs

 

[baassee]

Structs in GUI, nice joke.

 

[Adiktuz]

well the topic is only to define MUI... you never said GUI only...

 

[Troll-Brain]

• GUI Struct
  • Events
  • Conditions
  • Actions
    • Custom script: What's
    • Custom script: the
    • Custom script: problem
    • Custom script: with
    • Custom script: custom
    • Custom script: scripts ?

 

[Dr Super Good]

The MUI meaning for the most part is...
An ability can be used at any time by any reasonable number of units without unexpected behaviour occurring.

Reasonable number of units is a number of units supported larger than every well made map could possibly use. No real quantity has been defined for this.
Unexpected behaviour is when the ability does something it should not. A failure of MUI could be that two units cast the same ability at the same time yet the effect is run twice for one of the units and no times for the other when it is expected that the effect runs once for both units.

A common misconception is that MUI means that an effect chain has to run in parallel for every unit casting an ability. It is perfectly possible to create an ability which only 1 effect chain can exist at a time as long as that is the specified behaviour of the ability. For example the restriction on effect chains could be part of game mechanics such as only 1 air strike being able to be called at any given time as there is only 1 airport with aircraft to perform the strikes with meaning that if two units tried to cast at once, the one unit will fail casting or be made to wait.

As long as the behaviour is intended when many units try and cast at the same time, there is no problem.

An effect chain is a SC2 term for what an ability runs. GUI people may think of it as the actions of an ability.