SC2Mapster

Is there a way you can determine when there is an air pathing blocker directly in front of a unit? I know there is a 'location pathable validator that you can use, but that doesn't really solve my problem. There are certain obstacles (doodads) that when missiles reach, should be redirected. [The best I have been able to achieve is with a Unit Type compare validator with a periodic search effect. This, however, does not seem to work with doodads and is not the best solution.]

Basically, I have some doodads on the map and missiles should be redirected when it hits the pathing blocker(pathing footprint) of the doodad. I know I could probably achieve this by making those doodads units. But, is it possible to do this without making the doodads units?

Thanks.

Hmm, interesting idea. I can see how that could work but I am having trouble executing it. I cannot figure out how to determine the point to check for placement and where to move the unit back to ( the unit should move back to the point directly before the placement check fails ) if the validator returns false.

 Here are the relevant effects/validators:

----Launch Missile (Effect)----

Periodic Effect - Redirect Missile

----Redirect Missile (Effect)----
Effect: Validators: HERC - Cannot Place
Effect: Impact Location: (None):Caster Point:Unknown
Effect: Unit: (None):Caster:Unknown

----Cannot Place (Combine Validator)----
Negate - Can Place

----Can Place (Placement Location Validator)----
Target: Location: (None):Caster Unit:Unknown
Validator: Range
Validator: Unit HERC 

Okay, I am getting closer. I have a few problems though.

1. If the PlacementLocationValidator.Range= 0, then the validator always fails because you cannot place a unit on top of itself.

    For the missile ammo unit, I have: Movement: Pathing Footprint - Placement Footprint 1x1 (No Build)

2.  I am not sure how I set up the offset to be just behind the unit. Is the periodic offset the field you were referring to? Is this relative to the facing of the unit?

Here is what I tried(this seems to create the effect far away from the unit in some strange direction):

----Create Persistent Effect----

Target: Location + (None):Source Unit:Unknown

Target: Location Offset - End + (None):Source Point:Unknown

Target: Location Offset - Start + (None):Source Point:Unknown

Effect: Periodic Offsets^ + ((-1,0,0))

Thanks.

Okay, makes sense. 

Another issue that I have now run into is that I think some of the missiles move too fast for the periodic effect to handle. 0.0625s doesnt seem to be enough for the placement test. (Though it may be possible if I chained multiple validators together?)

I am assuming that the Range field on the placement location validator means that it CAN be placed within a radius of range from the unit/point? This is how it seems to behave in my tests so far.

A trigger solution is probably possible as well but is something I would like to avoid.

Really, what I need is a way to make missiles of any speed be able to collide with 1x1 pathing blocker doodads.

I apologize that was kind of long.

Alright, I was able to get the periodic offset working for the redirect missile effect, I had forgotten to change the location from caster unit to target point.

I am not sure I comprehend what you said about putting the validator in the effect after the create persistent. The validator should be in a periodic effect right? This changes when the periodic effect checks for placement, however, this should not change where it checks for placement location. I'm thinking that maybe I could create another persistent effect for checking placement in front of the unit? Perhaps I simply don't understand. Could you clarify what you mean?

Thanks.

Unfortunately, I wasn't able to get the calibration working quite right by moving the validator to another effect. However, I was able to get it mostly right by creating another persistent effect to check the front of my unit for placement ahead.

My question now is: Is there a way to determine what is causing the placement test to fail?  Perhaps an enumerate area validator from source unit to target point would work? I know this only detects units, but if the placement test failed and the enumerate area validator failed then it must be a doodad? Or maybe it would be easier to use different pathing flags for each kind of unit? Maybe I am overcomplicating this...

Gotcha. 

Shouldn't it also work to change the placement check layer of the placement location footprint to avoid something that I can set by doodads and not by units? (Ex: no burrow or near resources) The problem I have run into though is that units seem to not allow placement even with those custom footprints. Is there a way to change this? (there are no footprints set for the units; I am guessing that the ground pathing defaults all these to be applied to the cell the unit occupies?)

It appears that the placement location validator is not using the placement footprint of the missile ammo unit. It is using the radius for some reason. Is this normal?

I was able to get most of the slow-medium speed missiles working.  The enumerate area and function validators worked great.

I am having difficulty with HERC though. It just has insane speed. One would probably need to search for obstacles at cast time and redirect then if necessary... is this possible to do? (Ideally one would need to use a loop and incrementally increase the range to test for placement up until the distance from the caster to target)

Thanks.

Thanks for the help so far, I appreciate your willingness to assist. I almost have it working now. Just had to do one small part in the triggers for herc.

The problem I am having now is accurately determining if a unit is what causes placement to fail. I guess I do not understand how the placement test works.

I would assume that if distancebetweenpoints(placementpoint, unitpos) <= placementrad + unitrad then it did cause it. But, in my tests placement can fail and the unit is quite a bit further than that from the placementpoint. How exactly does placement work? Or, is there a way around this?

Ah, thank you so much DrSuperEvil. That explains a lot actually.

I still have the problem but now the distance is exactly the inner radius too big for the placement unit. Based on some tests I have run, it appears that the placement test is not centered upon the point. The center of the region for placement test is offset from the point by radius distance. So I believe I need to be offsetting where I scan for units by unitPlacementInnerRadius- y-axis relative. I do find this odd however that it checks placement forward instead. I think this is what is happening but I need to run some more tests.

Here is an illustration of what I have found so far.

-Edit: Yup that is exactly what is happening and accounting for it seems to be working  (within a 0.15 range discrepancy) - I wonder what could account for this.

https://pasteboard.co/H0RFrdv.png