SEE : Simple Entity Engine 2.4

[elfian]

How many entities does it support flying in the air at once? :O

 

[HINDYhat]

Mostly depends on your computer and on what kind of entities. There can be a lot in certain situations. For example if you put 200 tiny balls in a bowl, it will lag like crazy. If you make 200 bullets fly around the map, it pretty much won't lag at all.

 

[elfian]

Mostly depends on your computer and on what kind of entities. There can be a lot in certain situations. For example if you put 200 tiny balls in a bowl, it will lag like crazy. If you make 200 bullets fly around the map, it pretty much won't lag at all.

You just told me "you suck" in face. :O

EDIT: I see you are Looping through an array instead of using the ForGroup method, does that make it faster?

 

[HINDYhat]

I don't remember exactly all of the reasons because I haven't Jassed in over a year, but iirc the difference was minimal, and there were several advantages to looping through the array.

Also, wat @ "you suck"?

 

[elfian]

Um, in the map I am currently developing I'm using a a much simpler physics engine to simulate bullets, knockbacks, explosions and so on, and it supports only up to 50 at once laglessly, despite the fact that your code is much more complex and probably two times longer And you said 200

 

[HINDYhat]

The most lag comes from collision detection and resolution. Because of how bullets have small radii and are often fired in wide spaces, there isn't really much collision detection other than the native Enum call, and there is basically no collision resolution at all. But the collision detection/resolution was probably the most difficult part to write for this system, so I can understand your issues

 

[FrozenHellfire]

There's no chance you can simulate dust/sand using this right?

 

[elfian]

You can try, but if you get too much particles I bet it will lag

 

[HINDYhat]

What do you mean, dust and sand? Like... the actual sand in a desert, or just dust particles? If you just mean dust particles, this should work fine, because you won't need to worry about collisions. You can always run a shitton of anything that doesn't use collisions.

 

[Magtheridon96]

By means of readabiliy, this can be improved
All I see is spaghetti code xD
Otherwise nice job
Although, I fear this system can break movement oriented spells xD (Or make them look realistic ;D)

 

[HINDYhat]

This code is very old. When it was written, I was pretty terrible. If I ever feel really nostalgic and stupid, I might come back some day and rewrite it entirely, and add stuff like angular velocity, and maybe properly implement friction.

That said, if you need any help understanding part of the code, let me know. I'll try my best to explain.

What do you mean about movement oriented spells though?

 

[Noobsmoke]

This code is very old. When it was written, I was pretty terrible. If I ever feel really nostalgic and stupid, I might come back some day and rewrite it entirely, and add stuff like angular velocity, and maybe properly implement friction.

That said, if you need any help understanding part of the code, let me know. I'll try my best to explain.

What do you mean about movement oriented spells though?

He was talking about dinamic spells i think (like a shooting spell --> bullet moving ...)

 

[Magtheridon96]

This needs a huge update:

- Use Table instead of UnitUserData (Using UnitUserData would make ANYONE using AIDS, UnitIndexer or AutoIndex trash this D We can't let an amazing system like this get thrown away because of some lame Blizzard-thing D:

- GroupEnumUnitsInRange with a null boolexpr and a FoG loop would be way faster than your current setup.

- Don't use onDestroy D:

 

[RiotZ]

I wish I knew what this did, but I don't so now I will spend the rest of my days wondering why it uses 10,000 lines of code.

 

[Magtheridon96]

This is a physics engine ;P
Duh.

 

[RiotZ]

This is a physics engine ;P
Duh.

Okay? I guess I need to download it to really get what it does....

 

[alfalfa]

hi

is the geniouse OP still watching?
i am intrested in the collision resolution, i would like to know how it works
i made something like this myself, i just split the game area allways into 4 smaller quads and sorting all the units insite into seperate groups
on internet its called Quad Tree
but it is not very efficient

are you useing mb a better method? or shall i try optimizing my functions?

help much appriciated ((

 

[RiotZ]

Well, yeah I tested it, and I'm still, wtfing over here, what is the practical use for this?

Ah I got it, PINBALL!

 

[alfalfa]

ok i didnt try to completly understand ur code HINDY
but i think i copied the method u used now
before i was testing for each unit if the range between them is below a limit
really like everything mathematically, zooming in with a quadtree

but i saw in ur code that u used the GroupEnumUnitsInRange() function, so now i make this enum in range thing on every moveing unit, and if any other units are in that group i know its collision, its really nice, it is much more efficient then this quadtree stuff, though i dont understand how wc3 can know that a unit is in range without going through the same steps i did^^, maybe the jass is just not as efficient?

well i have 500 static objects and 120 moveing ones scatterd around the map, for my purpose the quadtree system was not as efficient

but im still intrested what the purpose of your "resolution system" is
i was thinking maybe to make a system which prevents the collision checks if the unit has been detected to not collide with any other object soon, like makeing a bigger collision first or something^^
is ur resolution system something like this?

 

[HINDYhat]

ok i didnt try to completly understand ur code HINDY
but i think i copied the method u used now
before i was testing for each unit if the range between them is below a limit
really like everything mathematically, zooming in with a quadtree

but i saw in ur code that u used the GroupEnumUnitsInRange() function, so now i make this enum in range thing on every moveing unit, and if any other units are in that group i know its collision, its really nice, it is much more efficient then this quadtree stuff, though i dont understand how wc3 can know that a unit is in range without going through the same steps i did^^, maybe the jass is just not as efficient?

well i have 500 static objects and 120 moveing ones scatterd around the map, for my purpose the quadtree system was not as efficient

but im still intrested what the purpose of your "resolution system" is
i was thinking maybe to make a system which prevents the collision checks if the unit has been detected to not collide with any other object soon, like makeing a bigger collision first or something^^
is ur resolution system something like this?

Hey, thanks for trying to understand the code! It's nice to see people who actually want to learn stuff.

I'm not sure how the GroupEnum functions are implemented, but yeah Jass is just pretty slow, so that's likely mostly why your code wasn't as fast.

There are a few things I do to speed up collision detection and resolution. As for detection:

• The GroupEnum radius is this.radius + MAXRADIUS + this.speed*2, where MAXRADIUS is the biggest radius of all entities currently active. The sum of the radii should be pretty clear. The this.speed*2 part is a bit trickier: imagine your entity is a bullet with a small radius moving very fast, and another entity is moving towards the bullet. Normally, a collision should happen. If you don't have the speed*2 term, the other entity will never be considered and the bullet will just fly through. Again, think about it, and if you don't get it at first, try drawing a diagram (it's hard to explain in words why this works).
• For each pair of colliding entities, I only compute a collision once per iteration, by keeping track of collided entities in collGroup.
• If the entity's speed is greater than some threshold, then I try and find the precise location where two entities will collide in the future, and fast forward to that position. If not, then I simply check for intersecting entities.

And for collision resolution, really I just try to minimize the calls to math functions (SquareRoot, Sin, Cos, etc.). Though they aren't very expensive, it's nice to know how few you actually need.

 

[alfalfa]

ah ty for the inspiration, my system does not care about very fast moveing objects, nice idea putting the this.speed*2 thingy there to fix it, i will update my system to do the same

to do less cos and stuff i do when checking if a distance is below a limit like this:

instead of
Sqrt( xvector*xvector + yvector*yvector ) < 100

u do
xvector*xvector + yvector*yvector < 10000
or
xvector*xvector + yvector*yvector < 100 * 100

saw it in some math tutorial

 

[emjlr3]

why is it that "remove health bars" doesn't seem to quite cut it?

hmm also - i am trying to make some sense of your math

// --
                    // The following gets the terrain normal <vx, vy, SAMPLE_RADIUS>
                    // and checks to see if the concerned entity sphere is colliding
                    // with the terrain plane.
                    call MoveLocation(entity.tloc, e.xP - SAMPLE_RADIUS, e.yP)
                    call MoveLocation(entity.tloc2, e.xP + SAMPLE_RADIUS, e.yP)
                    set vx = GetLocationZ(entity.tloc) - GetLocationZ(entity.tloc2)
                    call MoveLocation(entity.tloc, e.xP, e.yP - SAMPLE_RADIUS)
                    call MoveLocation(entity.tloc2, e.xP, e.yP + SAMPLE_RADIUS)
                    set vy = GetLocationZ(entity.tloc) - GetLocationZ(entity.tloc2)
                    set vz = vx*vx + vy*vy + SAMPLE_RADIUS*SAMPLE_RADIUS
                    call MoveLocation(entity.tloc, e.xP, e.yP)
                    set r = e.data.radius/SquareRoot(vz) - (e.zP - GetLocationZ(entity.tloc))*SAMPLE_RADIUS/vz

so this determines whether the entity has struck ground or not

if r>0 than it has

what I am interested in is if the entity has struck the side of a cliff - which I imagine would produce a radically different r value

thoughts?

**through some experimientation - it looks as though r is very close to 0 when striking a cliff - the largest value I have encountered is <.03 - when striking the ground the values are much larger, the smallest I have encountered being >.2

seems like a decent enough approach, and has worked full proof so far through my testing

 

[Tal'Rarity]

It's kind of sad this never sees any usage due to its complex difficulty, making something like this in gui would be pointless though being able to access it by custom script would have been nice. I am aware there are again multiple resources that offer what this system does while also providing custom script access, however anyone have an idea of which is superior in terms of speed? Only Mados and Quilnez's I know of being the alternatives with mados no longer being easily obtainable due to wc3c being down still.

I suppose I probably answered my own question since the more updated one would have better tested code with faster checks, only problem is missing the specific bounce as well linking units together. Kind of ironic with it being so difficult to decide which one to use when likely all current ones will be useless for my later plans of trying to set new floors for multiple levels in the same area since I don't see any kind of ground height fields to disable downwards movement.

Thinking about it, if there's a knockup system and a knockback system with friction that I like then I could probably imitate what this does with my desired features without all the extra cloggage. Edit: I really have to stop answering myself.