LÖVE

Hey LÖVErs, I'm having a stupid problem with ipairs, or maybe the problem is tables.
Im testing a super minimalistic algorithm for collisions to go with a top down simplistic game.
I can add and display walls in a table, but the collision function is only working on the last wall added to the table.
As you can see from the love file, the wall on the left is collision free, yet the wall on the right it works perfectly for.

I've included the .love file for any and all to ponder. (Including comments on what I believe to be the problem area)
Thanks for anyone who will help in advance, I've been scratching my head over this for 2 days.

PS: The collision code will probably make you cringe, bare with me.[

The problem is how you have structured your program. In update, it checks whether or not you collide with wall1, and sets you cameras "canmove"s as such, but afterwards it does this for wall2 and overwrites the previous results.

Instead of setting results true, just set canMoves true once at the beginnin of update.

Oh you wonderful, wonderful person!
Thank you Trebgarta, that was exactly what was wrong with it.

If you wouldn't mind, can you explain why this works the way it does?
I didn't try this originally because I was convinced that setting the results to true once in the update would mean that all collisions would be false and it would ignore the collision algorithm.

Thanks again for the help, that was the only thing I was stuck on.
-Riley

The answer is where the question is What does ipairs in your case?
It iterates your walls table and let you test collisions with every other wall there is.

So, when you check 1 wall your canMove.* fields have the result for your 1 wall.
Should you stop checking right now - your code will work perfectly with the first wall.

Alas, right after that, and before you even have a chance to do anything else (the current update cycle didn't finished up yet!), ipairs let you go and check the second wall.
The coordinates and size of the second wall may differ from those of the first wall. You're getting *correct* results but for the second wall.

Now, the problem is that the second check overwrites canMove.* fields, enabling you to pass through the first wall as if first collision check has failed upon you.




Now, what Trebgarta suggested works because the collision check can *not* overwrite a canMove.* field previously set to false and make it *true* once again.

When you set canMove.* fields to true at the beginning of the cycle (prior to iterating) you suggest that you can move in any direction.
When you iterate over walls, however, every other collision check with a wall will add restrictions to your movements.
Player can be in just one place at a time, so a distant wall won't add any restrictions (i.e. won't set any of canMove.* fields) to its movements.

Thank you very much 4aiman.
I think the crux of my misunderstanding was in the way that the update function executes.
I was under the impression that there was no heirarchy in the function, as in every bit of code is constantly running completely independent of any other code.
I see now that this is not the case. In fact heirarchy most certainly matters, and that the update function is running every bit in a linear way.

This information will be extremely helpful in being able to create better functioning code, thanks for all your help!