Fix Issue #144 - Entity isSwimming function

[crkellen]

This is a fix for #144.
The issue was there wasn't a function to test whether or not a given Entity is swimming. There is 'isLevitating()' and 'isInvisible()' but until now, all swimming code had to be repeated everywhere.

This also goes along with pull request #142. It should be used as a replacement for #142, if it is accepted. It implements the swimming checks added/modified in #142 with the new method added in this PR.

Additionally, this also has the fix for #143.

[lheckemann]

I like this better, apart from all the redundant == true expressions. x == true is the same thing as x if it's a boolean! Likewise, !x is nicer than x == false.

[crkellen]

I disagree on two main reasons. 1. It helps prevent ambiguous code. I don't need to guess what type of variable it is. It helps distinguish it from all of the "ints used as bools" used throughout. 2. Despite it making the statement slightly longer, I strive for readability over all else. I can easily tell which value is expected, and what the normal case might be from a glance. I elected to do this after sifting through the code and constantly having to decipher these if statements. I can't remember off the top of my head where, but the turning point was a variable being used as `!(var)` but the usual, average case was the opposite from expected. All in all, I found the code very unreadable. I opted for this alternative. Of course, this is not my call to make. If addictgamer would prefer it the other way, I'll update the PR. null

[lheckemann]

This only really makes sense when the choice of variable names is poor — isSwimming should obviously be a boolean or a function returning a boolean (which are easy to distinguish) and I can't really see what else swimming / !swimming would be either.

[lheckemann]

IOW, if (swimming) ("if swimming") and if (!swimming) ("if not swimming") are a lot more readable than if (swimming == true) ("if swimming is true") and if (swimming == false) ("if swimming is false").

[crkellen]

I suppose another reason was to make everything explicit. Most of the warnings Barony has right now is due to implicit conversions and such, and in general, making everything explicit is how I prefer to program.

However, after further reading (I had previously done reading on this subject prior to implementing any conditional checks like this, and sided with explicit), I do believe that if the variables are well named, it should be fine. I'll update now.

[addictgamer]

I do believe that if the variables are well named, it should be fine.

Sadly, this is an issue. Well-named variables should be preferred over the alternatives.

[crkellen]

I believe I already updated everything. null

[crkellen]

Yes, the issues were already handled. If you have any additional concerns, please let me know.