[Trigger] an efficient way to damage a line

[Lestat(br)]

I wonder if there is a better and simpler way to damage a line as it it was a lightning effect damage. Yes, shockwave can damage a line, but it doesnt have a flexible distance changing, and creating multiple area damages isn't more efficient/easier. +rep.
Thanks in advance

 

[PoZoR]

if u want a variable distance, and also instant damage, then u must instantly create dummy units in the damage area for referencing for the 'unit within range' function. it wont be hard to do, it will just take a while to get it right.

basically say u create like 5 dummies in your line of damage, then pick every one of those dummy units and add all units within range to a unit group variable, and then damage those units. use some simple maths to place those dummies correctly, and remember to remove leaks, you should be fine

 

[Hoernchen]

Simply calculate the speed at which your missile will move and then create a loop:

• For Each Integer A from 1 to x do
  • Deal damage at position offset of last position to units within small area
  • Wait time taken to get to next point
  • Repeat

 

[Avator]

Can't you base it on Chain Lightning, and make it an ability targetting a point instead of a unit. You can check every x (e.g. 100) distance (let's call these checking distances 'DistanceCheck') between TempPoint1 (position of caster) and TempPoint2 (position of point the ability was casted) to see if there are any units in the same distance of the distance you check until they reach TempPoint2.
If you want units in a bigger or smaller range to be effected, you increase/decrease both the distance around the DistanceChecks as the radius around the DistanceChecks. This to avoid overlapping of 2 DistanceChecks, which can cause units to be damaged twice if they're in range of a DistanceCheck.

If you don't completely get me, I'll make a little drawing on paint when I get home. It'll give you a good view of what I mean, and how to increase/decrease the effective area.

 

[Hoernchen]

No you cannot, since chain lightning is an ability that targets units. Furthermore, it doesn't move in a straight line.

 

[Avator]

Then base it on something that target's a point. With the trigger concept I posted, you make a straight line.

 

[Crusad3r91]

Try creating an area ability (like Healing Ward with no summoned unit) and a dummy unit with the immolation ability, then make a trigger like this:

• Events
  • Unit - A unit starts the effect of an ability
• Conditions
  • (Ability being cast) Equal to (your ability)
• Actions
  • Set AbilityTempLoc=Target point of ability being cast
  • Set CasterTempLoc=Position of (casting unit)
  • Unit - Create 1 (ImmolationDummyUnit) for (Owner of (casting unit)) at (CasterTempLoc) facing (AbilityTempLoc)
  • Set DummyUnitVar=Last created unit
  • Unit - Add a ((Distance between (AbilityTempLoc) and (CasterTempLoc))/(Current movement speed of (Dummy Unit)) second (generic) expiration timer to DummyUnitVar
  • Unit - Order DummyUnitVar to Move to (AbilityTempLoc)
  • Custom script: Call RemoveLocation(udg_AbilityTempLoc)
  • Custom script: Call RemoveLocation(udg_CasterTempLoc)

That's it. I don't know if the expiration timer will function, but it should set the "life" of the projectile to end once it reaches its target... if you want a lighting effect then add it with the AbilityTempLoc and CasterTempLoc points .

[EDIT]
By the way, by doing a unit-based projectile you will not be able to set its speed over 560 or so... you may add a trigger that instantly moves it to the designated location every 0.3 seconds by... let's say 10. That would include points with polar offset and other variables though. You may also create another dummy unit on the other side and make it to move to the caster unit or periodically create dummy units with immolation each (number) for filling the distance between the caster and the target point.

 

[Hoernchen]

Not exactly the best way to handle the problem. I don't advise using dummies, they often screw up, looping triggers are usually the way to go, since you don't have to worry about stuff like sight, walk-ability or other triggers screwing up your dummy.

 

[Crusad3r91]

Actually you shouldn't have any problem with dummy units like the ones you pointed out. Adding the "locust" ability would prevent that, wouldn't it?

 

[spiwn]

Wtf?
Why do you need dummy units???
Just for fun?
That approach is good(not really, but works), but there is absolutely no need for dummy units.
Just pick up the units around the location where you would have placed the dummy ...
But heck, what do I know, may be easier to place the dummy on a known location and pick up the units within some range of the location of the dummy(the location where you placed it)

 

[Hoernchen]

simply, cause creating a unit creates lag, while using a function uses much less cpu, since with the unit, there is a lot more data to load. lotus units would still be effected by some triggers that detect when a unit is created.

 

[Squiggy]

• Actions
  • Set temppoint1 = (Position of (Triggering Unit))
  • For each integer A from 1 to 7 do:
    • Set temppoint2 = temppoint1 offset by x towards (Facing of (Triggering unit)) degrees
    • Set temprect = Region centered at temppoint 2 with size 200, 200
    • Custom script: set bj_wantDestroyGroup = true
    • Unit Group - Pick every unit in temprect matching (Matching Unit) belongs to an enemy of (Owner of (Triggering Unit)) equal to true and do:
      • Unit Group - Add (Picked Unit) to dmg_group
    • Set x = x + 100
    • Custom script: call RemoveLocation(udg_temppoint2)
    • Custom script: call RemoveRect(udg_temprect)
  • Unit Group - Pick every unit in dmg_group and do Unit - Cause (Triggering Unit) to damage (Picked Unit) for...
  • Custom script: call RemoveLocation(udg_temppoint1)

Lower or increase the maximum integer (7 here) as 1 goes for 100 range and 7 for 700 range and on and on..

//There might be slight differences as this trigger is handwritten

 

[PoZoR]

damn im stupid, i just thought of a better way.

first i must say that damaging in circles across the line will double damage some of the units, which is BAD

make several carrion swarm abilities with different ranges. The more you are willing to make the more accurate your range will be. Use a dummy ability for this spell u wanna make. In your trigger, reference the dummy ability, detect the range of the target point of ability being cast, and use maths to compute which carrion swarm (in other words, which range) to use

 

[Avator]

I just thought that you might solve double hitting by adding the hit targets to a unit group. So whenever the first part hits a unit, you add the unit to the unit group, when the second part hits a unit that is in the unit group, it'll do nothing, if it's not in the unit group, it simply does the effect it should. Very easy and efficient way to prevent double hits.
Do keep in mind that you'll have to clear the unit group when the spell has done it's full effect.

 

[Squiggy]

The question is: can a unit be added to a unit group more than once.
Because I don't think so - and putting all units in the rects into a untigroup and damaging them AFTER won't cause them getting damaged more than one time - correct me if I'm wrong

 

[Avator]

I've asked that in another topic a while ago before. The answer: No, only 1 of a unit can only be in a Unit Group. If you add the unit toi the unit group again, it'll won't have any effect.

I was saying that he can make if/then/else commands.

• If (All conditions are true) then do (Then actions), else do (Else actions)
  • If - Conditions
    • Unit in <REGION> is NOT in <UNIT GROUP>
  • Then - Actions
    • DO SPELL EFFECT
    • Add <UNIT> to <UNIT GROUP>
  • Else - Actions

That way the spell only takes effect if the unit is not in the group yet. After the spell is complete, you clear the unit group.

 

[GhostWolf]

Yes and that's exactly how you should do it since, sadly, we can use only vertical and horizontal rects.

Picking units with, say, a 100 radius and then a 100 radius after that can damage twice a unit that was exactly in the middle, so if you do that, pick 101 after the first one.
But still, it's a circle, not a square and thus you won't damage a line.

So, you have to pick at very small ranges (the smaller the accurate but more memory consuming) and check if they're in your damage group.

 

[spiwn]

Or you can use jass. Pick all units in an big circle that match a condition( they are in your very own custom rect(search for the programming method if you do not know how). Or you can simply go to wc3campaigns.net and find the system, code or whatever they classified it, that takes a set of coordinates and returns all units in the rect(like this one, but I recall others too).

 

[Avator]

Well, you can make new shapes by making like a hundred small square regions in the shape of the shape you want xD

That's just going to take too long, isn't very smoothly and probably also not worth the trouble.


About the distance between the center of the radius': I suggest you take about 1/4th-1/2th of the distance between the centers of 2 radius' if the ends of the radius' would touch. That means 1/4th-1/2nd of:

. . . |<------>|. . . . (<--- Distance between 2 radius' touching)
---==-------==-----
-=----=---=----=---
=--<>--==--<>--==
-=----=---=----=---
---==-------==-----

 

[Lord_BoNes]

To speed up unit picking around the current-point along the line, what you can do is:

When the spell initiates, find the distance/angle between start & end of line (this is obvious)... Then find the half-way point, do a "pick all units in range" using the total distance*0.55(extra 10% to be sure to catch all units) as the radius. Remember this group, by whatever means, and scan through it when looking for possible targets. 20x this way is much faster than 20x "pick all units in range".

As for the actual detection, Avator seems to have a good approach. But, I'd allow the circles to overlap, just filter out already effected units (add them to a group, and scan that group).

I've have used this sort of approach myself. I did it a while back using H2I, and it was still pretty quick, even though structs are a hell of alot faster.