[vJass] (system) Missile

This bundle is marked as approved. It works and satisfies the submission rules.
I have worked on this missle engine for 2 months now and start the first official beta today.

Please post feedback, critism, pros, cons, bugs, etc.
Thanks all for your patience!

And thanks for downloading.
Preview image by Furby. Thanks a lot!

Edit:
I've updated the testmap and added a second spell.
There is a lot of improvements in version 0.1.7 and I plan to make it even faster and even more modular. I also plan to create an easy to understand API.

Used librarys:


Changed all constants (TRUE, FALSE) to true/false
Changed interval to 0.03125
Fixed object leaks
Performance improvements on MissileMovement: Less object generation
Merged MissileLocHelpers to Missile<type>Target
Removed HomingMissile wrapper
Added second spell (Rain of Fire)
Removed Libraries from Modules



Changed name to Missile.
Completely remade in modules, supports now a lot of optional stuff.
Added SpellHelper, fixed a lot of problems, made the Miranas Arrow example WAY more powerful to show what this system is able to be capable of.


Keywords:
Missile, Projectile, xe, xemissile, xecollider, projectile, collider, awesome, anachron, collide, colliding, vJass
Contents

CustomMissile 0.1.7 (Map)

Reviews
BPower: 11:02, 25th Feb 2016 Reason for re-review: Nowadays the spell section is packed full of missile systems from different authors, therefore a more qualified moderator comment than "this is neat stuff" is required. There is keen...

Moderator

M

Moderator

BPower:
11:02, 25th Feb 2016

Reason for re-review:
Nowadays the spell section is packed full of missile systems from different authors, therefore a more qualified
moderator comment than "this is neat stuff" is required. There is keen competition, hence your new
review may not be as good as it was before.

Criticism:

  • A system released for public usage needs a proper documentation, at least about its API.
    You didn't write a single line of comments for other users. Compare it to the JassHelper
    without Jass Helper Manual or the WorldEditor with neither blizzard.j nor common.j.
    ---
  • It's very unusual to use a timer interval, which can't be multiplied with an integer to a result of 1.
    The most common timer interval in JASS is 1/32 which equals 0.03125.
    You use public static real period = 0.03175 which is ~1/31.49
    ---
  • TRUE and FALSE are constants for true and false.
    It's not required to use them. I guess you know that.
    ---
  • GetUnitState(theUnit, UNIT_STATE_LIFE) > 0.405 could be optimized to GetWidgetLife(theUnit) > 0.405
    ---
  • I guess it's your very own style of writting code, but your functions are arranged in a way, that the
    Jass Helper must generate a lot of pseudo-code to obtain a valid function order.
    Just look into MissileUnitHit. Functions are placed precise in the wrong order. Jass Helper fixes that, but for which price?
    ---
  • The unit enumeration radius is inaccurate, but that's the case in most missile systems.
    You must add the maximum collision size used in the map to get all units in collision range.
    ---
  • You hide units which are below terrain level, very neat, but where do you restore the full range
    of the locust effect after showing the unit
    ? Btw In that function you have a unit leak.
    ---
  • set .destHitGroup[GetHandleId(theDest)] = 1 is good, not perfect. Handle ids get recycled once there
    is not reference to their object and the object is removed from the map. Therefore it must be
    set .destHitGroup.destructable[GetHandleId(theDest)] = theDest.
    One of many reasons why Vexorians Table is compared to Bribes not perfect in API.
    ---
  • public method checkMissileHit takes nothing returns nothing does nothing, but takes space.
    ---
  • The math used in missile movement is cool. It's unfair to only criticise your work.
    ---
  • Array handle variables should be nulled once no longer needed.
    ---
  • Missile cast helper should be a seperate library named CastHelper. We have that better executed namely SpellEffectEvent.
    ---
  • Overall a bit unread-able code and even harder to use for someone who didn't code the system by him/her-self.

I don't know why a DC was taken into consideration in the past, obviously not out of objective reasons.
I depreciate the rating form 5/5 to 2,5/5. As we give out integer ratings you'll get a 3/5.
The entire system is good for own usage. For public submission
I would like to see a proper API documentation.

12:32, 8th Apr 2010


TriggerHappy:


I have not yet tested the system.

  • You might as well comment out ParabolaZ2 as it serves the same purpose as the first one. The only reason is should even be in the library is to give a better explanation as to how the first one works. so yeah.. just comment it out (/* */).
  • Your globals are private, don't give them prefixes (CM_NAME).
  • You could store (2. * bj_PI * CM_PERIOD) in a constant instead of doing the operation each time.
  • Is there really a need for the local in enumDestsInRange?
  • You are using a group per instance, either A) recycle them or B) use a global group.
  • Is there a reason why you're creating the timer in onInit instead of just initializing it?
  • It would be more efficient if you placed the contents of all your update functions directly in the move method. Yes it's going to be harder to read but just make some comments explaining them. Because currently you are doing a bunch of unnecessary function calls.
  • The system name is horrible. Just by using a system not made by blizzard already indicates that it's custom. You might was well call it Missile.


I have tested the system and the demo map is really lacking.
If you want to show people the power of your system include some really awesome eyecandy examples.

  • Still need to recycle groups.
  • Your comments explaining the interface use the wrong grammar. It's ran, not runned.
  • You still need to remove the prefixes on your globals.
  • Why don't you just make locRect static? As of now you are creating and destroying rects when you could just be re-using the same one.
  • You realize you are destroying enumGroup twice, right?

The_Reborn_Devil:
Due to Trigger's demotion I am now the only spell mod and thus I can finally review your system.

Hmm, it would seem my review is gone, but the system is great.


Status: Approved
Rating: Highly Recommended [Director's Cut]

hvo-busterkomo: After evaluating this system I do not think it meets the standards to be a Director's Cut. However, in respect to The_Reborn_Devil, I have left it as Highly Recommended.
 
Level 12
Joined
Feb 11, 2008
Messages
810
:D I made it that way, I think that is most realistic.
(That would be cheating instead)
However, you can still enable terrain hitting (but then missiles that hit terrain die, however, you can overwrite this behavior as well)

I don't think you understand what i said since missiles traveling underground aren't very realistic can they not just float along the surface until they hit there target?
 
In the latest test map, you forget to add a "." to pos.x twice as well as a "." to hazeNeg.
JASS:
        private method haze takes nothing returns nothing
            local Loc   new     = 0
            
            if .hasHaze then
                if hazeNeg then //here
                    set .hazeCur = .hazeCur - .hazeInc * CM_PERIOD
                    if .hazeCur <= .hazeMin then
                        set .hazeCur = .hazeMin
                        set .hazeNeg = false
                    endif
JASS:
       method operator z= takes real z returns nothing
            set .pos.z = z
            call SetUnitFlyHeight(.effUnit, .pos.z - GetLocZ(pos.x, .pos.y), 0.)
//here too
        endmethod
JASS:
        method operator loc= takes Loc l returns nothing
            call .pos.applyLoc(l)
            call SetUnitFacing(.effUnit, .pos.f * bj_RADTODEG)
            call SetUnitX(.effUnit, .pos.x)
            call SetUnitY(.effUnit, .pos.y)
            call SetUnitFlyHeight(.effUnit, .pos.z - GetLocZ(pos.x, .pos.y), 0.)
//and here =)
        endmethod

Also, don't you need to null "u" in:
JASS:
        private static method enumUnitsInRange takes nothing returns boolean
            local thistype this = thistype.curInstance
            local unit u = GetFilterUnit()
            local real z = GetLocZ(GetUnitX(u), GetUnitY(u)) + GetUnitFlyHeight(u)
            
            if IsUnitInGroup(u, .enumGroup) then
                //add set u =  null?
                return false
            endif
            
            if not .targetZ or (.targetZ and z >= .z - .h /2  and z <= .z + .h /2 ) then
                call GroupAddUnit(.enumGroup, u)
                call .onUnitTouch(u)
            endif
            //and here set u = null
            return false
        endmethod

Nice job on the system otherwise, I can't find any mistakes in the coding. =)

I tested it in game and it looks pretty good too. Although, perhaps you should create a more easy-to-test environment to see some of that collision action. =D
 
Level 14
Joined
Nov 18, 2007
Messages
1,084
But how realistic is it that a missile makes a curve on height just to be on top everytime? That looks awful.
I don't think it's very realistic at all for a missile to go through terrain.

For example, if a mage shot a fireball at a footman standing on a cliff, would he shoot the fireball directly at the cliff hoping that it will go through the ground to burn the footman's feet?

It's good that you want your system to be realistic in that most missiles would not curve all the time to stay on top of the ground. However, what about the missiles that don't like passing through the ground to reach their targets? (Like a heat-seeking or a magic missile.)

If you really want to be realistic, you would want the missile to curve when it is first thrown such that it would hit the target without passing through the ground unless the target moved to higher ground. (Unless the person that threw the missile wants his missile to pass through the ground instead of the air.)

In other words, you should at least have an option for a missile always being on top of the ground.


I didn't mean for this post to be offensive in any way; it's just how I view the situation about missiles passing through the ground.

About the test-map itself, I hope you implement better examples of the cool things that can be done with your system. =D
 
Level 14
Joined
Nov 18, 2007
Messages
1,084
I'm curious as to how to make the missile curve above the ground all the time.
If it's already implemented, then my above post should be pretty much disregarded.


Edit: Is changing the height of the missile not supposed to work or am I just being stupid? If I change the height of the missile in Arcane Missile to 1000, it seems to stay at the same height.
 
Last edited:
Level 18
Joined
Feb 4, 2009
Messages
1,315
How many projectiles can this roughly handle at once?

depends on your pc of cause

however the arcane chain spell does not deal any damage (I think it should deal dmg shouldn't it?)

and if it has terrain collision enabled it might jump to a unit and hit the ground even if there is a unit within range it could reach
but fixing this would require a pathing check before the missile is even fired
but you decided to code it that way so you can't fix it :grin:
 
PAF, thanks for your comment.

I will fix them in the next version.
You are free to add terrain collision detecting to any of the test spells.

Edit: Is changing the height of the missile not supposed to work or am I just being stupid? If I change the height of the missile in Arcane Missile to 1000, it seems to stay at the same height.
Its z, not height. Height is for collision detecting.

I'm curious as to how to make the missile curve above the ground all the time.
If it's already implemented, then my above post should be pretty much disregarded.
I won't implement it since it looks awful. (And is)

however the arcane chain spell does not deal any damage (I think it should deal dmg shouldn't it?)
If you check the spell script it can't. I was just to lazy to do it. Sorry.

and if it has terrain collision enabled it might jump to a unit and hit the ground even if there is a unit within range it could reach
but fixing this would require a pathing check before the missile is even fired
but you decided to code it that way so you can't fix it
I don't really get it.
 
Level 25
Joined
Jun 5, 2008
Messages
2,572
The test map gives this system no justice.

Throw in some xy/z arc movements and some colisions with the missiles themselves to show some of it's full potential.

It would also be nice if you would answer some of my questions:

When a missile hits another missile/obstacle how does it handle the colision?

Did you use vectors for determining the resulting angle/speed?

Is it possible to change the missile's look dynamically?
What if for example i want a missile to change to a fireball after 1.5 seconds?
Effect string comparison for example?

Does the system uses a dummy unit with Z facings?
And does it calculate it's Z facing automatically with height change?
If it doesn't it should(imo).

Some of the questions i have at this moment, will ask more later.
 
Throw in some xy/z arc movements and some colisions with the missiles themselves to show some of it's full potential.
Yes I sucked at the demo spells. Was kind of in hurry because I had to go to sleep.

When a missile hits another missile/obstacle how does it handle the colision?
Both missiles get the other missile as parameter, while the first created missile is parsed at first. I use a range check (math) to get a collision.

Did you use vectors for determining the resulting angle/speed?
No, not yet. I plan to do so but I don't know whether I should use it or not. It works fine without (Loc is kind of a Vector).

Is it possible to change the missile's look dynamically?
Of course. just use set cm(missle instance).eff = '' (String)

Does the system uses a dummy unit with Z facings?
And does it calculate it's Z facing automatically with height change?
If it doesn't it should(imo).
I was about adding this feature in the future, it can be changed by user until now, but I will add it by default too (which you can disable)

Thanks for the feedback.
 
Level 12
Joined
Jun 9, 2009
Messages
1,131
How much i see, this don't check terrain pathability, cause when you start from hole to attack someone on hill, missile, makes it self invisible, and when it reaches to target damages him, AND for now there is nothing to special with those missiles. Add somethings, setting flying height when getting to target, when starts, add <><><><><><> that moving of missile. Thats my suggestion.
 
Level 12
Joined
Feb 11, 2008
Messages
810
We gave quite a few on the last page you might not have gotten to see but other than that i say its looking pretty good.

1 thing though you should make an optional function that allows the missile to float along the surface since although its not realistic some people would probably use it.
 
# Update - 0.0.F

  • Your comments explaining the interface use the wrong grammar. It's ran, not runned. - Fixed
  • You still need to remove the prefixes on your globals. - Fixed
  • Why don't you just make locRect static? As of now you are creating and destroying rects when you could just be re-using the same one. - Fixed
  • You realize you are destroying enumGroup twice, right? - Fixed
 
Level 17
Joined
Jan 21, 2006
Messages
2,545
D4RK_G4ND4LF said:
depends on your pc of cause

I think it is quite crucial as to how many projectiles can be handled at once, since the more projectiles that can be used at any given time make the system a lot more wide-spread. A system that allows unlimited user interfacing but only handles 2-3 projectiles at a time without lagging horribly wouldn't be very useful. I'm going to stress test this and come back with a number. I have a relatively average PC.
 
Top