xe0.9

[Vexorian]

XE Developed by Vexorian Maintained by Anitarf Current version: 0.9

The successor to the Caster System, xe is a collection of libraries primarily aimed at spell makers. The core of this system is the xebasic library and the all-purpose dummy unit that comes with it. The rest of the system are all optional modules, each one designed to provide a specific feature that is commonly needed in spell making such as dummy casters and various projectiles. xepreload prevents the lag that occurs ingame when any ability is first added to a unit. xedummy recycles dummy units to help optimize maps that rapidly create and remove such units. xecast handles dummy casters so you don't have to, making it easier to cast spells with triggers. xefx allows you to move, rotate, scale and recolor special effects by attaching them to dummy units. xedamage provides a standardized interface for dealing and identifying triggered damage. xecollider is a directional projectile that detects collisions with units in its path. xemissile is a targeted projectile with arced trajectory, like standard Warcraft missiles.

Changelog 0.9:

[darkwulfv]

So if that small snip of code is the entire system... then how does this work, and what makes it great?

[Vexorian]

Since when are systems supposed to be great? Anyway THE system is 20% code, 50% a dummy model and 30% an object editor 'unit'

[Here-b-Trollz]

YAY!!!!

I never did enjoy the caster system just because of how ungainly it was. Simplicity, modularity, efficiency wins.

Excited to see this, though I probably won't use it. I've always liked the idea of every spells' scope containing absolutely everything that the spell needs to function. It just makes things so much easier.

Either way, more power to ya

EDIT: I hate myself for making this post. Somebody kick me in the face.

[darkwulfv]

I just wanted to know what this did. I can hardly tell by the spell code, it just contains a little bit of constant data.

I do like that it is simple. CS was really big and hard to use.

[Vexorian]

Yes, I need better samples, I haven't made them yet since object editing is a little tiresome on WINE:

Most people may find it more complicated than the caster system, because of the rather alien way to use it, this is the xecast module:

JASS:

 local xecast mp = xecast.createA()
    set mp.abilityid='Ahpm' //let's say this is polymorph's rawcode, ok?
    set mp.orderstring="polymorph"
    set mp.owningplayer = GetOwningPlayer(GetTriggerUnit())
    call mp.castOnAOE(x,y,radius)

Now, what I wanted is more flexibility and things that look similar, this casts AOE polymorph on various points:

JASS:

 local xecast mp = xecast.create()
    set mp.abilityid='Ahpm' //let's say this is polymorph's rawcode, ok?
    set mp.orderstring="polymorph"
    set mp.owningplayer = GetOwningPlayer(GetTriggerUnit())
    call mp.castOnAOE(x,y+500.0,radius)
    call mp.castOnAOE(x-500.0,y,radius)
    call mp.castOnAOE(x,y,radius)
    call mp.castOnAOE(x-500.0,y-500.0,radius)
    call mp.destroy()

The real deal is that you don't need to keep creating stuff and worry about struct 'leaks'

JASS:

globals
    private xecast mp
endglobals

//.. on init
   set mp = xecast.create()
    set mp.abilityid='Ahpm' //let's say this is polymorph's rawcode, ok?
    set mp.orderstring="polymorph"


// later:
    set mp.owningplayer = GetOwningPlayer(GetTriggerUnit())
    call mp.castOnAOE(x,y+500.0,radius)
    call mp.castOnAOE(x-500.0,y,radius)
    call mp.castOnAOE(x,y,radius)
    call mp.castOnAOE(x-500.0,y-500.0,radius)

What if you want to target a unit group instead? you keep everything and just replace mp.castOnAOE(x,y,radius) with mp.castOnGroup(g) ,

And when all the modules are done, it will probably get larger than the caster system. Though very few people will have to implement them all.

And... spells with embedded systems are an abomination, not something 'good' it is terrible and no reason for pride.

I don't really like how xecast works right now, xefx on the other hand...

[Here-b-Trollz]

actually, that's not alien at all really. that's just making awesome use of methods. actually that looks really awesome. load up the module with everything it needs to know, and then tell it what actions to run - a very dynamic, open style to coding, and I like it.

[Switch33]

Why not change xecast to being a cast module to more or less a group module as in-- using group functions with being able to set the functions that effect picked units with? I think it would have a lot more uses.
(Also i never really got the idea of making a spell that casts more spells it just sounds odd and inefficient, as you could just do the effect of the spell and avoid having to use a caster to cast it at all. The only real reason you would use such a thing would be for having single target spells dealt to a group, and that could even be handled in a picked unit function also.)

Another thing, why would you ever do separate location and x/y functions(so you could use both)? It's only a few lines of code to transfer into just x and y. Isn't it better just to always use x and y than a location?
(Although i remember hearing locations transfer faster between functions; i also think i remember hearing that x/y is faster in functions. And i think the x/y won better in performance either way.)

Below is taken from exfx documentation;

________________________________________________________________________________
player owner
----
For some reason you might want to change ownership of the effect, for
example, if you use abilityid (see bellow) and the ability does damage.

Example: set myfx.owner = GetOwningPlayer(GetTriggerUnit() )

________________________________________________________________________________
player owningplayer
----
The player that owns the spell (Who gets credited for it)
Example: set somevar.owningplayer = Player(2)

These should be the same thing... (If not it's just too weird having one player deal the damage and another player get the rewards.)

________________________________________________________________________________
playercolor teamcolor
----
The recycle delay is the time to wait before recycling the dummy caster, if
it is 0.0 the ability will be considered instant.

A proper recycle delay is important since when a dummy caster is recycled
its owner becomes player passive. Every damage done by the casted spell will
not credit the correct player.

Some other spells need some time in order to cast correctly. Not to mention
the channeling ones that require the caster to last during that situation.

Example: set somevar.recycledelay=10.0

And.. This doesn't explain what the playercolor teamcolor setting is for...

[Themerion]

Since you always want to set an orderstring and an ability id (and since you are not very likely to do it multiple times for the same xecast), I think it would be justified to shape the create method like method create takes integer abi_id, string order returns xecast which would save 2 lines of code for each spell, making it look cleaner. Does only cost 1 extra function call/spell, and that's at map init.

[Vestras]

in the xepreload trigger, don't you need a PauseTimer(..) and a nulling when destroying?

[Vexorian]

It is not necessary to pause non-periodic timers, There is also nothing to null as I am not using a variable there.

Themerion:

JASS:

    //========================================================================================================
    // you are always allowed to use .create() but you can also use createBasic which sets some things that
    // are usually necessary up.
    //
    public static method createBasic takes integer abilityID, integer orderid, player owner returns xecast
     local xecast r=xecast.allocate()
        if(r==0) then
            debug call BJDebugMsg("Warning: unbelievable but you actually used all xecast instances in your map! Please make sure you are not forgetting to destroy those what you create intensively, if that's not the case, then you'll have to increase xecast MAXINSTANCES")
        endif
        set r.abilityid=abilityID
        set r.owningplayer=owner
     return r
    endmethod

Though I should probably add an orderstring version, people like orderstrings for some reason.

Switch: That's an error with xefx's documentation, I was using xecast's as a template and it looks I left some garbage there

fixed?:

xefx
----
  This module just allows you to have movable special effects, they are actually
 dummy units, you can do plenty of things like changing their position, their
 height, their rotation (in the xy and in the z axis as well), color, and things
 like that. It is all about assigning attributes, the only two important methods
 xefx objects have are create and destroy. There are other accessory methods.
 
implementation
--------------
  Just copy the xecast trigger to your map.
 
xecast object
-------------

__________________________________________________________________________________________________
  static method create    takes real x, real y, real facing returns xefx
--
  This is the create method, it will make a new xefx for you to use, there are 
 initial values you must specify, like the x,y coordinate and the facing angle.
 facing is in radians.

  Eg. set myfx = xefx.create()
__________________________________________________________________________________________________
  method destroy   takes nothing returns nothing
--
  This just destroys your xefx object. (call myfx.destroy() )

* List of attributes *

________________________________________________________________________________
    string fxpath
----
    Determines the model of the special effect, yes, you may  change it after
 assigning it if necessary to change the model path.
    
    Example: set myfx.path = "abilities\thisisamadeup\modelpath.mdl"

________________________________________________________________________________
    real x
    real y
    real z
----
    Determine the position of your special effect, you can keep moving the
  effect in a periodic loop, etc.
    
    Example: set myfx.x=myfx.x + 65.0
             set myfx.y=GetUnitY(u)
             set myfx.z=JumpParabola(t)
            
________________________________________________________________________________
    real xyangle
----
    The angle in the xy plane, also called 'facing' angle. (Note: uses radians)
    
    Example: set myfx.xyangle = AngleBetweenPoints(target, source)*bj_DEGTORAD
    
________________________________________________________________________________
    real zangle
----
    The angle in the z-axis (inclination?), (Note: uses radians)
    
    Example: set myfx.zangle = bj_PI/2 //Now the model will look towards the sky

   
________________________________________________________________________________
    integer r
    integer g
    integer b
    integer a
----
    Well, the model's vertex coloring in RGB , a is the opacity value (use
 values from 0 to 255 here)
    
    Example: set myfx.r=255
             set myfx.g=0
             set myfx.b=255
             set myfx.a=128
             
______________________________________________________________________________________
    method recolor takes integer r, integer g , integer b, integer a returns nothing
----
    This one assigns all the color values in one pass.

________________________________________________________________________________
    real scale (write-only)
----
    Allows you to resize the xefx object, the default scale is 1.
    
    Example:   set myfx.scale=2.0 //double size (in fact 8x)
               set myfx.scale=0.5 //half size   (in fact 1/8x)
________________________________________________________________________________
    player owner
----
    For some reason you might want to change ownership of the effect, for 
  example, if you use abilityid (see bellow) and the ability does damage.
  
    Example: set myfx.owner = GetOwningPlayer(GetTriggerUnit() )
________________________________________________________________________________
    integer abilityid
----
    Well, you may use a xefx object to grab a passive ability, perhaps you need
    it for ye candy reasons or you want to use it as a damage dealer.

        Example: set myfx.abilityid = 'Hphf'
________________________________________________________________________________
    playercolor teamcolor
----
    The recycle delay is the time to wait before recycling the dummy caster, if
    it is 0.0 the ability will be considered instant.
    
    A proper recycle delay is important since when a dummy caster is recycled
    its owner becomes player passive. Every damage done by the casted spell will
    not credit the correct player.
    
    Some other spells need some time in order to cast correctly. Not to mention
    the channeling ones that require the caster to last during that situation.

        Example: set somevar.recycledelay=10.0
   
________________________________________________________________________________
    method flash           takes string modelpath returns nothing
----
    It shows the dead animation of the model specified by modelpath. This is
    in case you need this sort of eye candy.
    
    
    

(Also i never really got the idea of making a spell that casts more spells it just sounds odd and inefficient, as you could just do the effect of the spell and avoid having to use a caster to cast it at all. The only real reason you would use such a thing would be for having single target spells dealt to a group, and that could even be handled in a picked unit function also.)

The truth is that blizz spells are always going to be more efficient than you coding the effects yourself, there are also many things where dummy casters is just nice. Also your suggestion about groups is not something I agree with, mostly because I think, we should stop using groups that much, I also think a planned vJass feature would make such system unnecessary.

[Here-b-Trollz]

The most we ever really need out of a group is:

JASS:

private function Enumer takes nothing returns boolean
    call DamageUnit(GetFilterUnit())

    return false
endfunction

//...

call GroupEnumUnitsInRange(DummyGroup,x,y,radius,Filter(function Enumer))

That, and if we want to tag units in perhaps a spell that deals damage in a line, so they aren't hit more than once.


Awww.... Table is just a more robust form of gamecache. Cute :> I have to agree that gamecache is awesome, and now, with tables, you've given us arrays that have any size. Kewl.

[Themerion]

Ah, createBasic is what I wanted, yes.

Shouldn't you add a debug keyword for the if-statement too?

[Vexorian]

I think it needs a return 0

[Flame_Phoenix]

Hey, isn't this one of the spells you used on your dragon hero on the hero contest ?
Looks great !
mmm, why call it xe ? xD