System Projectile

[Narks]

For example: A projectile is added to a group when it comes near a unit, then it is recycled and used again, once again it comes near the same unit, but it is already in the group this time, so it doesn't work properly.

How does anyone propose I fix that problem.

Well, maybe you should make your own "ProjectileGroup" struct? That way, projectiles can automatically be removed from the group when they collide with something (or maybe remove them from the group when you enumerate through the group, for efficiency), thus preventing lots of fun from happening.

 

[Zwiebelchen]

Just a quick question - I did not check everything yet:

Why do you use both [ljass]UnitEntersRange[/ljass] and [ljass]UnitEntersRect[/ljass] events, especially, when the first is nothing more than just periodic enumeration and slows down the system enourmously?
Isn't [ljass]UnitEntersRect[/ljass] sufficient?

 

[Tom_Kazansky]

What about preloading a number of projectile dummies at a variety of facing angles, so that one very near to the intended angle can be selected for use? Upon recycling, dummies can again be preset to a certain facing angle, with a delay before they are available for reuse to ensure that they have finished turning.

how many dummies do you think is enough ?

 

[Kenny]

Could you put some air units in the demo map? (I would, but I can't resave a map with non-//!imported vJASS.) I'm curious to see whether your projectiles can accurately track to the height of an air unit near the edge of a cliff or over a tree. (I'm betting not.)

Hmm, alright I'll see what I can do.

Who made the time slow dome model? Is it available for use? (It's pretty cool.)

A friend of mine found the mesh for it and I added the textures. Not sure if it would be right to release it to the public.

Well, maybe you should make your own "ProjectileGroup" struct? That way, projectiles can automatically be removed from the group when they collide with something (or maybe remove them from the group when you enumerate through the group, for efficiency), thus preventing lots of fun from happening.

Still doesn't really solve dynamic group usage in separate spells (look at my Slow Projectiles example).

Why do you use both UnitEntersRange and UnitEntersRect events, especially, when the first is nothing more than just periodic enumeration and slows down the system enourmously?
Isn't UnitEntersRect sufficient?

I found UnitEntersRect inaccurate for unit collision due to the different movement speeds of the units, making projectiles go straight through units quite a bit. I am still doing tests to see if I can remove one or the other.

how many dummies do you think is enough ?

Honestly... I don't even think 180 preloaded units would be enough. What if you want it to look good for ranged units (firing up to 2 projectiles a second in the same direction would completely fail).

Once again, this is still in its beta stage. So things still are in the works, but thank you all for the suggestions.

Edit:

As Weep foretold, flying units do indeed mess things up, in more ways than one. The height of a flying unit isn't just its flying height but also the height of the model itself. Take Gryphon Riders for example; their model seems to actually start a good 50 units below any visible part of the model.

That means that for it to work properly (for all air units, even custom ones), there would be a lot of work involved.

There is also the fact that flying over cliffs completely messes with height.

Not really sure what to do about this one.

 

[Viikuna]

If you want to have all 3 rotations, roll and pitch and yaw, you need to use either 2 dummies per projectile or SetUnitPosition.

My guess is that SetUnitPosition is much slower.
Then again 2 dummies method has some weird problems. ( Could be also caused by bad coding made by me. My math skills do suck. )


Anyways. Nice to see a projectile system. Projectile systems are cool.


edit. For only pitch and yaw, you can use animations for pitch and SetUnitFacing + SetUnitLookAt combo for yaw.

edit. Also you fail to reproduce proper wc3 attack projectiles.

Your projectiles deal the damage like would instantly hit the target, which is not the case. It takes time for projectile to reach the target, and during that time, for example, its armor might change.

edit. ...Which is not really important, though. This is a projectile system afterall, and its seems to be doing its job well. Its a good base for some proper ranged attack system.

 

[Jesus4Lyf]

Firstly, I like the effort you've put into this.

I'm not sure I understand why people keep doing projectiles in such a simulated way. What's wrong with using real WC3 projectiles, and a dummy spell with the model, making some kind of ProjectileStruct with object merger things, and then forgetting about projectile/projectile collisions and such (which I don't think are practical gameplay elements anyway)?

Then again, each to their own.

 

[Kenny]

@ Viikuna:

I actually added some of the features to this just to see what you would think of it. I know how all those other projectile systems without GroupProjectilesInRange() bugged you.

I'm not really sure what you mean about the ranged attack projectiles though... To me they replicate it pretty well. Also, it is just an example. If it were in a game I would do it a bit differently.

@ Jesus4Lyf:

I was wondering what you would say to this.

I do agree with you on your approach to a projectile system. However, I dont think I will ever understand vJASS and object merger + LUA enough to do that.

This is just a projectile system that should stop all the other 'normal' projectile systems being submitted. Kind of like a standard of sorts. Unless it is better, don't submit it kind of thing. Haha.

Also, there was a lot of effort put into this to make sure that it was easier for users while protecting them from their own stupidity.

Thanks for your comments, both of you.

 

[Jesus4Lyf]

This is just a projectile system that should stop all the other 'normal' projectile systems being submitted. Kind of like a standard of sorts. Unless it is better, don't submit it kind of thing.

I think I agree with you. It has all the fancy features. But it's also the kind of reason I'd encourage everyone to write their own stuff. Like someone already linked a map and you noted the system was written for the map, because it fits... but a system like I mentioned is nasty enough to fit everything, but have limited features. Best part? 0 periodic JASS stuff.

I don't know, if it makes sense to have a big phat projectile system for people to use, written by an experienced JASSer, with a nice interface, this seems like a good system. You've clearly tried to take efficiency and stuff into the equation, though I haven't read the code myself (and might not), and the feature list is extensive. People's comments will tell where this system is heading...

 

[Switch33]

TCX(toadcop's map) does correct facing instantly. It's been around before 1.23 patch. On XGM he released an open source version.

Anyways something that seems odd to me is the defend ability on the footmen. If you attack another unit it will re-direct projectiles around the footman passing by even though hes not the subject of the attacks. Guess that can somewhat be fixed if you made some sort of unit owner to projectiles and filter which projectiles are attacking what.

It seems like a lot of these attack systems leave out a bunch of functionality from regular physics engines that just design their own attacks. Like SEE it's pretty simple to do a bounce off of land if the projectile misses, a bounce limit, and able to have projectiles manipulative in pretty much every way needed. A lot of these things if wanted to be done would need to be re-coded entirely.

 

[Kenny]

Anyways something that seems odd to me is the defend ability on the footmen. If you attack another unit it will re-direct projectiles around the footman passing by even though hes not the subject of the attacks. Guess that can somewhat be fixed if you made some sort of unit owner to projectiles and filter which projectiles are attacking what.

The defend ability is just an example. There are no enemies on the map, so I made it re-direct any projectile. It is easily changable..

It seems like a lot of these attack systems leave out a bunch of functionality from regular physics engines that just design their own attacks. Like SEE it's pretty simple to do a bounce off of land if the projectile misses, a bounce limit, and able to have projectiles manipulative in pretty much every way needed. A lot of these things if wanted to be done would need to be re-coded entirely.

This isn't an attack system... It is a projectile system. I don't find bouncing and stuff part of a projectile system. There are advantages of this over a physics engine as well. This allows quite accurate arcing projectiles very easily, I have tried doing the same with a physics engine and it is either frustrating or incredibly difficult.

I think that this system provides everything a 'projectile' system should. If there is something that fits this system (and not a physics or attack engine) then I will more than likely try to add it.

A lot of people I know would rather simplicity in regards to user interfaces then extreme functionality that may or may not be used.

Edit:

@ Jesus4Lyf:

But it's also the kind of reason I'd encourage everyone to write their own stuff.

Once again, I think I agree with you. However, there are definately A LOT of people who do not understand how to do advanced projectile stuff. By all means, if you understand how to do this kind of thing, you should probably design your own for your own map, but then again this does most of the stuff for you, with an easy to understand interface.

So yeah, we'll see what people say.

 

[Switch33]

Yah, the learning curve is a huge problem with designing a physics system for a projectile system. And I do like how you do not need to modify ranged units at all to make them automatically work with the system besides just using a line of code for ranged units. But in the sense that you can create inter-actable doodads that will collide etc it's more of a physics system thing( I mean it would be weird to create an unmoving projectile as sort of a doodad object/barrier. Especially one that you can push over and stuff with projectiles. And walking on projectiles that have fallen for things like grenade explosions in halo.)

Sry if this is somewhat unrelated, guess what i'm trying to do is sort of seperate this in general from a physics system in explanation even if I am explaining it to myself.

Anyways a few related questions: This systems seems to match up with the attack rate of the units pretty well. Is there some sort of strange calculation required in doing that? Or is it just from detecting if an unit is attacked and blocking all damage except for custom attacks? Would it be accurate for something like giving an hero/unit an item that adds % attack speed?

 

[Kenny]

And I do like how you do not need to modify ranged units at all to make them automatically work with the system besides just using a line of code for ranged units.

Actually, you have to modify the unit's missile speed and missile model as well.

Anyways a few related questions: This systems seems to match up with the attack rate of the units pretty well. Is there some sort of strange calculation required in doing that? Or is it just from detecting if an unit is attacked and blocking all damage except for custom attacks? Would it be accurate for something like giving an hero/unit an item that adds % attack speed?

Basically how it works:

1) A unit's normal attack hits.
2) Block that damage.
3) Create a projectile, set all the members.
4) Deal the previous damage again as pure damage when the projectile hits.

Pretty simple (probably has some flaws, but they can be fixed). It should work with attack speed items and skills as well.

And then, you can set the damage type of custom ranged attacks to one not used in a map, so then you can do custom attack detection (just like normal attack detection).

 

[black.sheep]

How is it possible to detect when the missle hits a certain type of terrain?

 

[Viikuna]

1) A unit's normal attack hits.
2) Block that damage.
3) Create a projectile, set all the members.
4) Deal the previous damage again as pure damage when the projectile hits.

Pretty simple (probably has some flaws, but they can be fixed). It should work with attack speed items and skills as well.

This is exactly the problem. You cant use that old damage, because units armor might change during the flight of the projectile.

Example: Player casts a spell which gives +10000 armor to his hero, and hopes that it will save him from incoming archer arrows.

And it does not, because he receives some nasty pure damage that kills him.



This can of course be solved by using system like UnitProperties for finding out armor, damage and armor types, and then calculating the damage before resistances and then doing projectile damage with physical ( or whatever attack damage type that unit uses ) damage type.

 

[Weep]

What's wrong with using real WC3 projectiles, and a dummy spell with the model

Well, in this case, he wanted to implement modification of projectiles in-flight, as you can see in the demo map, which has a spell similar to Tides of Blood's Blueshift. You can't do that with native projectiles.

 

[Viikuna]

Or that Monk spell from Diablo 3, where he parries all the projectiles, or some other cool shit like that.

Possibilities become limitless, really.



Something Ive been wanting to do since my Birds -spell, is to make some Birdman Hero guys normal ranged attacks to be randomly coloured magic birds.

( Would be awesome )

 

[Narks]

Would there be any way to create more complex projectile arcs? (like, sideways)

 

[Kenny]

This can of course be solved by using system like UnitProperties for finding out armor, damage and armor types, and then calculating the damage before resistances and then doing projectile damage with physical ( or whatever attack damage type that unit uses ) damage type.

I would definately do it like that in an actual map. Using that new UnitProperty library with the GMSI script enables us to get the z impact point of units, which will make projectiles look so much better.

Something Ive been wanting to do since my Birds -spell, is to make some Birdman Hero guys normal ranged attacks to be randomly coloured magic birds.

I was actually thinking about adding that to the test map. Seems like such a fun idea.

Would there be any way to create more complex projectile arcs? (like, sideways)

If I can find a simple and efficient way of adding bezier curves to the periodic method without increasing the complexity by heaps, then I might add it.

I am currently cleaning up some updates to the script. Added some safety functionality to .projectArcing() so that users don't screw themselves up. Fixed the bug found by PurgeAndFire and looking for other possible updates.

Oh and I am still working on a recycler that works with unit indexing and stuff.

Edit:

Questions for anyone who cares:

Should I make it so that you can only determine whether or not a projectile is collideable when it is created, and not at any time over the lifespan of the projectile?

If the user sets .collideable to false, it would save one RegionClearRect() call, one SetRect() call and one RegionAddRect() call in the periodic method and just replace them with an if/then.

It would reduce the work needed for projectiles that shouldn't be or aren't collideable in the first place.

What do you (yes you!) think?

 

[BlackRose]

What about prioritizing collision?

Fire can only destroy grass missiles, grass can only destroy earth missiles, etc.

Unless that's already done and I'm stupid and didn't realize.

 

[Kenny]

That kind of stuff doesn't belong in a projectile system. It is something you build off of a damage/projectile system.

What if maps didn't to use priorities? Stuff like that would just lead to code bloating.