The conditional check on line 216 to see if "#ent > 0" is not needed. The "for" loop won't error if "#ent"
is less than one; instead it simply won't do anything (which is what you want in that situation anyway).
Ditto for the check on line 218 to see if "ent[
i]" exists. "#ent" doesn't actually return the length of the "ent" table so much as it returns
the highest index found before encountering nil; meaning that the loop will always end before that value is reached anyways.
It looks like your use of table.remove() should ensure that this won't be a problem anyway (as that automatically moves subsequent indexes to take up the emptied positions in the table, rather then leaving indexes set to nil), but for those situations where you did need it, table.maxn(ent) would give you the highest index in "ent" regardless of any empty indexes. It's ever so slightly slower, however.
Defining an extra variable on line 219, "ents", has little benefit. You can simply refer to eg "ent[
i].x" and so on. Though I suppose it's possible that performing the table lookup over and over is slower than allocating the extra variable and referring to that. Dunno.
Let's look at the logic on line 220/221:
if (ents.x <= tankInfo.x + 2 and ents.x + 2 >= tankInfo.x) and (ents.x + 2 <= tankInfo.x + 2 and ents.x >= tankInfo.x)
and (ents.y >= tankInfo.y and ents.y + 3 <= tankInfo.y - 3) then
First consider that your use of "and" statements across the board means that the brackets effectively mean nothing; if
any of the conditionals resolve as false, the
whole thing resolves as false.
If ents.x >= tankInfo.x is true, then "ents.x" must be more or equal to "tankInfo.x". If ents.x + 2 <= tankInfo.x + 2 is true, then "ents.x" must be less or equal to "tankInfo.x". Hence in order for
both to be true, "ents.x" and "tankInfo.x" must be the same. That's rather limiting.
If ents.y >= tankInfo.y, then "ents.y" must be more or equal to "tankInfo.y". But if ents.y + 3 <= tankInfo.y - 3, then "ents.y" must be at least six less than "tankInfo.y". Those conditions are mutually exclusive: They cannot ever both be true, breaking the entire check.
A given tank looks like this:
|
*-*
| |
*-*
Let's call that a 3x4 shape. Hence to see if two collide, you'd use a check along these lines:
if not (ents.x > tankInfo.x + 2 or ents.x + 2 < tankInfo.x or ents.y > tankInfo.y + 3 or ents.y + 3 < tankInfo.y) then
If any of the four conditions in the brackets are true, then that means the tanks are not touching. If all four are false, then they ARE touching. The use of "not" in front of the brackets will flip whatever their contents resolve to.
Edit: Dayrider10's pointed out to me via PM that the enemy tank is actually rendered "up" the page, and the player's tank is rendered "down" it - if they both are set to the same co-ordinate, they won't appear at the same place on the screen.
Given this, the correct check for his script is:
if not (ents.x > tankInfo.x + 2 or ents.x + 2 < tankInfo.x or ents.y - 3 > tankInfo.y + 3 or ents.y < tankInfo.y) then
