SC2Mapster

To make the explosion you don't even need to make a unit. Just do Create Model At Point and pick whichever effect you want (some explosion effects need to be Killed right after they're created).

To look for a decent explosion effect what I usually do is search through the models in the data editor, searching for "impact" and right click on them and say "preview model".

To kill the units near the explosion, just say:
Pick Each Unit In Region Matching Condition
For the region, use your region: 1[I]
Then, inside the block say Kill Picked Unit.

This is a pretty good idea and I'd like to help.

Neat.

Why would you bookmark something that's eternally on the front page?

Try making a record for each node, with references to all of its neighbors.

I don't know, how do you get it on there?

So, you looked everywhere except the tutorials forum? Because it has exactly what you need.

http://forums.sc2mapster.com/resources/tutorials/22121-triggers-implementing-a-physics-engine/

See step 4. Though, it wouldn't really work on its own without step 3, I'm assuming that your units will be colliding simply by walking into each other. In that case, you'd just get their velocity vectors as ( cos(Direction)*Speed, sin(Direction)*Speed ) instead of ( custom value 0, custom value 1 ) as used in the tutorial.

Oh, and in the tutorial, custom value 4 represents the mass of the unit.

Yeah, the purpose of this tutorial is to keep it as simple as possible and provide you with the tools you need to modify it for your own purpose. It should be trivial to make another ApplyForce function that also affects the Z, and adding air resistance would just involve using the "else" part of the friction conditional. The formula I got for deciding the initial Z-velocity was a matter of guess and check for the constant; I'm sure there's a more generic way of doing it though. You could multiply it by the mass, which is 1.0 so perhaps if you did that it would become more modular (I say multiply because if the mass was greater, it'd be moving slower, so it'd need more air time to reach destination, haven't tested it though).

Adding wind would be as simple as repeatedly applying a small force in the direction of the wind to all objects. In fact that's how you'd do a constant force of any kind, by repeatedly calling ApplyForce every game loop. See Homing Missile. Although yeah, objects with larger surface areas would tend to receive more force from wind, so maybe just multiply by the unit's radius.

Gravity doesn't care about mass in this simplified case. I'm assuming the mass of the ground is significantly greater than each object and distance is insignificant, and the ground is flat. This isn't meant to simulate planet-star systems. It gives you a parabolic trajectory for throwing footballs.

Yeah I'm aware, no reason it should stop checking collision on the balls if they still exist. I didn't give them an expiration timer so that I could test how many I have to throw until it starts to lag. Then, when I finally get around to optimizing the map, I'll see how much it improves.

@SouLCarveRR: Go

Originally I was just making it for a friend who's kind of new. I don't think I know enough of the details of football to pull it off.

Thanks, fixed.

@Arkless: Go

Thanks for the post. But as I said I did make it to not do any redundant checks, so it's already doing n*n/2 checks.

And about the "evil functions" that gives me an idea, maybe instead of taking the square root for the distance I should just square the other side of the inequality. Not sure how much faster that would be.

And yes I'm aware of that method of collision but I might be more comfortable with the sweep and prune technique (http://en.wikipedia.org/wiki/Sweep_and_prune).

Quote from HellGateSc2: Go

for(int i=0;i<Count;i+ +)
{
    for(int j=i;j<Count;j+ +)//may int j=i+1 have to try it out
    {
        //actions
    }
}

That's actually close to what it does, but it does it by removing the unit from the unit group to prevent redundant checking. It's still O(n²) anyway. Maybe it's not as fast as I think it is because I'm not even sure what the data structure for unit groups is.

I don't think it would be a very useful test since I'm using a laptop. Or do you mean when hosted on B.net? I'm not clear on the details of how that works, does the server handle all the computation?

@REDlandry: Go

I posted this in the tutorial. Is it not what you want? http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies/

@HellGateSc2: Go

I haven't encountered those problems, are you sure you set all the units' custom values up correctly and put them in the necessary groups? Have you tried the attached map?

You're right that I've simplified a few things. I don't want it to be too advanced for the average user and that's why I used triggers instead of scripts; it's easier to read and not everyone uses galaxy script.

I didn't include continuous collision detection because it's only really necessary for very small, very fast moving objects whose correct collision detection is essential. That's a pretty limited use in your typical Starcraft 2 map, unless you want to do some kind of bullet system. In that case, it might be better to just do hitscan, since projectiles in most cases would be overkill. Not to mention, CCD takes a lot of additional computation.

If you're worried because not using CCD would screw up the angle of collision, take a closer look at my SeparateUnits procedure and what exactly it does. It rewinds time for those two objects in much smaller increments until they're just barely not colliding anymore. That way the angle is very accurate and we don't have to pay for the additional overhead of CCD when collisions aren't even happening.

Another simplification is that all objects are spheres. If this doesn't suit you, try building your unit out of multiple collision spheres.

And one oversight with efficiency is that each pair of objects is compared for their distance; not the cheapest method. It would be better to use sweep and prune and/or cubic hitboxes before checking the spherical collision, especially with lots of objects.

Can you be specific on what bugs you found? I wanted to keep it simple considering how long this tutorial is already. 3D collision should be easy to add by making a z-component vector using the difference in heights and operating on that the same as the other two. Bouncing off the terrain involves finding the normal of the terrain and treating it as an object with infinite mass (1/m = 0). But in that case, I'd have to make the unit ignore terrain height in its trajectory however you do that. Might be something to work on this summer.