[Snippet] Dummy Caster

[Nestharus]

This resource has moved here.

--

gone

 

[PurgeandFire]

You forgot:

implement N

In your dummy caster struct.

Also, it should be call DummyCaster[orderId].cast() instead of call DummyCaster[spellId].cast(). (in the documentation) It is misleading. If you order a unit to perform an ability id, afaik it will just learn the spell if you have the skill points for it. (at least for issued orders with no-target)

Otherwise, nice job. I like the interface a lot.

 

[Nestharus]

Yea, I just tried to use this and realized I forgot to implement the module into a struct =P

 

[Bribe]

Private struct i is useless, just put the module in your active struct. It's private anyway.

 

[Magtheridon96]

Private struct i is useless, just put the module in your active struct. It's private anyway.

What he said... =p
Also, you forgot to mention that this requires LUA_FILE_HEADER =o

edit
Honestly, you don't need that global (Anyone can easily change it if they had to)

 

[Nestharus]

Updated to 1.0.0.3

If you have UnitIndexer in your map, the dummy unit will not be indexed now =).

 

[Magtheridon96]

Er, the link you posted next to "Unit Indexer" is for World Bounds

 

[Nestharus]

Fixed link

 

[Bribe]

Won't issuing orders from outside of world bounds (on smaller maps) cause the game to crash?

 

[Nestharus]

works just fine.

 

[Bribe]

If you upload a test-map so users can just copy+paste the dummy unit out of it from object editor (if they wish), this will be a much more portable library because of its soft learning curve. When I first got into unit indexing, the external blocks weren't even working so I was forced to c&p from the object editor.

 

[Nestharus]

If you upload a test-map so users can just copy+paste the dummy unit out of it from object editor (if they wish), this will be a much more portable library because of its soft learning curve. When I first got into unit indexing, the external blocks weren't even working so I was forced to c&p from the object editor.

no tx, too much work. I don't make demo maps anymore unless they are absolutely called for, like Encoder.

not going to make a demo map just for that. That's what the Lua script is for.


I've already written a full quickstart guide to Lua with an easy cnp step by step guide, so yea, there is absolutely no chance that I will ever write a demo map for this.

If you notice, I don't even include links to the basic requires Lua resources anymore =).

 

[Bribe]

According to long-standing site rules (http://www.hiveworkshop.com/forums/submissions-414/resource-rules-40760/) library requirements should always be included.

While I am quite liberal minded, I also have to walk the fence and respect the rules just a little.

I advise not being in such a hurry to submit resources that you don't even invest the time to properly document things. This has very little documentation and actually tells users nothing about the library unless they already know what a dummy caster is.

 

[BBQ]

Okay, in all seriousness, what's the point in submitting a resource that isn't even functioning properly.

1. It will cause smaller maps to crash because you are creating a unit at some huge-ass coordinates.
2. It won't work properly with abilities such as Thunder Clap and War Stomp because those affect units around the caster, and your caster sits at (32256, 32256) and cannot be moved.
3. It won't work with channeling spells or spells that have a casting time.
4. If you register, for example, two or more abilities based on Storm Bolt, then there is no way to cast them separately because they all share the same order. In other words, you are screwed.

 

[Nestharus]

It will cause smaller maps to crash because you are creating a unit at some huge-ass coordinates.

I tested on a small map.

It won't work properly with abilities such as Thunder Clap and War Stomp because those affect units around the caster, and your caster sits at (32256, 32256) and cannot be moved.

It will work with them... you're supposed to move the units to the caster, not the other way around. Furthermore, it should only be for applying effects like reviving a single unit or stunning a single unit.

It won't work with channeling spells or spells that have a casting time.

Why would you ever channel a dummy caster spell, you are giving totally unrealistic scenarios.

If you register, for example, two or more abilities based on Storm Bolt, then there is no way to cast them separately because they all share the same order. In other words, you are screwed.

Again, you are killing yourself with that >.>.

I advise not being in such a hurry to submit resources that you don't even invest the time to properly document things. This has very little documentation and actually tells users nothing about the library unless they already know what a dummy caster is.

API documentation is enough for me. I don't document more than that unless the resource is complex enough to merit documentation.

But I will link to the Lua tutorial.

 

[BBQ]

I tested on a small map.

So did I, and guess what? The map crashed. If maps didn't crash when units went far off bounds, then why was BoundSentinel (and stuff similar to it) made?

It will work with them... you're supposed to move the units to the caster, not the other way around.

I'm supposed to move the units that I want affected by Thunder Clap, War Stomp or Fan of Knives at (32256, 32256)? You're kidding, right?

---

If this is supposed to be used for reviving or stunning a single unit, then I see absolutely no point in it. The extra requirement is simply not worth it.

 

[Nestharus]

I'll make this use WorldBounds then and move dummy to edge of map.

If this is supposed to be used for reviving or stunning a single unit, then I see absolutely no point in it. The extra requirement is simply not worth it.

It makes it so that a unit isn't created/generated for every single library that does something like Revive or Stun or w/e.

But what I can do is add x/y properties to move the unit as well as an owner property to change owning player of unit =).

 

[BBQ]

That's okay, and consider renaming your castTarget and castPoint methods to castOnTarget and castOnPoint respectively. It makes more sense, at least to me.

You can also add an unregister method that removes the ability from the dummy, just like register adds it.

Also, write a note about channeling abilities, abilities with cast time and abilities that share the same order. Users should be aware of that.

 

[Nestharus]

That's okay, and consider renaming your castTarget and castPoint methods to castOnTarget and castOnPoint respectively. It makes more sense, at least to me.

Those can stay as is since I already have a lib using this ^)^, plus the castTarget and castPoint still make sense, even if they do make less sense than castOnTarget and castOnPoint =).

You can also add an unregister method that removes the ability from the dummy, just like register adds it.

I don't really see a need for unregister, but sure thing.

 

[BBQ]

Oh, and you don't have to use World Bounds.

Simply create the unit at (0, 0) and use SetUnitPosition(u, 32256.0, 32256.0) to move it to the highest coordinates.

SetUnitPosition() does not let the unit go off bounds, but SetUnitX() and SetUnitY() do.

I don't see a point for unregister either, but the user should be able to remove abilities from the dummy.

 

[Bribe]

The need for unregister is important due to order-id's being shared across
a lot of spells. Because of this, it would actually be good practice to simply
unregister instantly. But then there is the cost of recursion, because firing
the ability might trigger a spell event which then also tries to use the
dummy unit and then happens to share the same order id -_-

 

[BBQ]

The need for unregister is important due to order-id's being shared across
a lot of spells. Because of this, it would actually be good practice to simply
unregister instantly. But then there is the cost of recursion, because firing
the ability might trigger a spell event which then also tries to use the
dummy unit and then happens to share the same order id -_-

If this is supposed to be used solely within stun/revival/etc. systems, then the user shouldn't even be doing that.

Hell, I still don't see a point in this snippet, but nothing depends on me.

 

[Nestharus]

The need for unregister is important due to order-id's being shared across
a lot of spells. Because of this, it would actually be good practice to simply
unregister instantly. But then there is the cost of recursion, because firing
the ability might trigger a spell event which then also tries to use the
dummy unit and then happens to share the same order id -_-

You can't unregister instantly or the spell never fires. I already tried that in the first design.

edit
updated

 

[Nestharus]

Removed extra spaces and what not.

 

[jim7777]

suggestion

set
Art - Animation - Blend Time (seconds) to 0.00 (id: uble)
Art - Animation - Cast Backswing to 0.00 (id: ucbs)

to let war3 not play the unit's animation or wait before starting a spell's effect
so it will work with consecutive spell cast

perhaps add it to lua

 

[Nestharus]

i kno, haven't gotten back to this yet

 

[Nestharus]

Updated Lua code

Added non Lua version

Updated script to remove move ability



Should be able to chain cast with this now ; P

 

[Dirac]

If you order the dummy to cast the ability multiple times it will only cast it once, do the same thing i did in my own dummy caster system and add "order check" when the dummy is casting, if the dummy is busy doing something then create another dummy and have it cast it the spell

 

[Nestharus]

that's untrue.. it'll cast them one after another -.-


I've cast 3 spells in a row on this >.>, so don't give me that ;p


If it only casts 1, then ur spell is bad

 

[Dirac]

I'll have to test that, it was giving me issues in my map, also you forgot to add a method operator z for flying height

EDIT: also a level operator would be nice

 

[Nestharus]

It doesn't need a z for flying height, lol, but I will add a level operator : P

 

[Dirac]

Yes it does, if i want my spell to be cast from a certain height (and the spell is clearly visible) i need the Z operator.

Also, this causes lots of issues when combined with DamageEvent since the Dummy isn't actually indexed and it's index gets locked everytime it deals damage (Displays lots of debug msgs). Fix that.

 

[Nestharus]

sure thing ;o


spent all day doing AuraStruct, so I'll probably do the DamageEvent update and DummyCaster update tomorrow ; )

edit
just sneakily edited DamageEvent to not have the locks anymore for targets/sources that aren't indexed ; P

 

[Dirac]

Why wouldn't you just index the unit?
Plus wouldn't DamageEvent cause trouble with locked units? Since it locks and unlocks the index of an unit whether or not the index is locked. IMO it shouldn't mess with the indexes whatsoever

 

[Nestharus]

It should mess with the indexes or u'll run into serious problems...

also, indexing the dummy caster is really pointless, lol.


Think of the dummy caster as a null source ; P


Dummy casters are typically used for effects and buffs, not for damage =)

 

[Dirac]

This example is rather common:

Lightning Armor: each time this unit takes damage there's an 25% chance to cast chain of lightning upon the enemy.

I would have a dummy cast it and the spell itself deal damage rather than coding the whole chain lightning, dummys dealing damage through spells isn't a rare thing. Just index the damn dummy and leave DamageEvent the way it is, there's no need to tweak it and most likely make it slower for something that can be easily avoided

 

[Nestharus]

The dummy is a null source >.>. Think of it as not existing at all.


Giving it an index is bad practice >.>. It shouldn't have an index. It's like a CastSpell function.


CastSpellTarget(spellId, target).


Do you see a source unit anywhere in there? Nop. Same idea with the dummy. Yes, it does actually exist, but you should have 0 access to it >.>.


edit
updated to 2.0.0.0 >.>. Now you have 0 access to the dummy. It's like making a player cast a spell.

 

[Bribe]

Are you going to add support for channeling dummies? This looks good enough to be approved in its current state, I will add it to my list so I can give it some in-game testing first.

 

[Nestharus]

No support for channeling dummies. The ability must be an instant cast.


The reason for this is obvious ; P. It'd require multiple dummies ;D.

 

[Bribe]

Yeah I suppose that should be handled by a different system altogether.

 

[Dirac]

I really hate the way you completely changed this lib.
Remember that many w3 internal spells have special effects added to them and most of the time the user would like to see them. So casting a spell towards a target that is 6000 units away would cause bugs.
Also no way to change the dummy's Z or any way to access the dummy at all. I would never use this.

 

[Magtheridon96]

You don't need access to the dummy.
This library is for casting dummy spells.
Why would you need access to the dummy?

 

[Bribe]

Well a chain lightning for example would suck here.

 

[Nestharus]

Yea, access to the dummy makes absolutely no sense...

#1

Remember that many w3 internal spells have special effects added to them and most of the time the user would like to see them. So casting a spell towards a target that is 6000 units away would cause bugs.

How so? You are making absolutely no sense... it's impossible to have a unit 6000 away from the dummy... the dummy is always moved to the target...

Also no way to change the dummy's Z or any way to access the dummy at all. I would never use this.

Why the hell would you need to change the dummy model? That doesn't even make any sense. The user will never ever be able to see the dummy in the first place since it instantly moves back and forth. The dummy is not meant to show special effects. There is only one dummy and it has to do its stuff instantly. If you want any special effects, add them to the wc3 spell or create some particles when the spell is cast.



If you are trying to make the dummy cast an entire spell on its own and show special effects on the dummy etc with channeling, you have officially used this library completely incorrectly : P.


This is more meant to attach buffs to units. It can also be used for things like casting Revive for revival libs.

edit

Well a chain lightning for example would suck here.

Why would u cast Chain Lightning from the dummy?

edit
Oh I see what you guys are talking about now... it's not really meant to be used for what you guys are thinking, but... I can upgrade it to do all of that stuff if you like : ).

It'd require dummy creation (you'd create your own dummies) and it'd require use of the Particle lib.

local Dummy dummy = Dummy.create(etc)
call dummy.cast(spell) //etc

//etc

call dummy.destroy()

 

[Bribe]

The particle lib would suck with this because of all the CreateUnit overhead.

 

[Nestharus]

Well, I can run the Particle lib through your recycler ; ).


edit
nvm, your recycler isn't just a recycler... wtf at that -.-


Do I seriously have to write a simple dummy recycler??

 

[Magtheridon96]

Check out my recycler in the GY.
Writing a simple recycler in this library shouldn't be so hard

 

[Nestharus]

Check out my recycler in the GY.
Writing a simple recycler in this library shouldn't be so hard

Actually, I think I'll put the recycler inside of Particle. That's where it belongs : ).


It'll be really easy. I just won't remove the units and I'll only create new units on instantiation = ).

 

[Bribe]

The particle library needs a recycler that considers facing, not just any recycler. However, this resource (DummyCaster) just needs the basic recycling tools.

 

[Nestharus]

Ok, I'm keeping this library as it is right now. You guys are trying to abuse this library for stuff that it's not meant to be for. In the interest of promoting good and solid spell design, I am keeping this lib as is : ).