Add creepers

[ccuser44]

Fixes #69

This adds creepers to the game. They function the same as in game expect they dont have the puff up animation.

Proof:

[ccuser44]

Ok here is a functional implementation of creepers. I still haven't tested this though.

[thatsprettygood]

I still haven't tested this though.

Why??

[ccuser44]

Done @p2r3

[AnimalRacional]

some things I think are missing: creepers shouldn't take damage from sunlight, they should disappear when they explode, and they should drop gunpowder
for the puff up animation, you should only need to send a Set Entity Metadata packet to update the fuse and ignited state of the creeper's data whenever it starts puffing up and whenever it stops (like when all players get away from it); maybe adding it to broadcastMobMetadata in procedures.c or sending sc_setEntityMetadata in the code for attacking

also, maybe I just have something wrong in my environment, but I had to change line 1379 of procedures.c to be able to compile because fast_rand is used with a parameter while it doesn't take any

[p2r3]

This is a review of just the code, I haven't tested this in-game. It seems the commenter before me has, so take that feedback into consideration as well.

[ccuser44]

Sorry, this pull request was a bit rushed as I had to hurry doing it. It's still in an acceptable state (if discounting the debug print) but yes it could be polished a bit.

I'm not currently available to do development until next friday due to being away from my home, unless I can get this working on my phone.

Yes the float conversion is there for a reason. I found distance checking with randomized decay a lot easier with it. I may convert it ints later

[p2r3]

Don't pull request sloppy code if you know it's sloppy, I'm not going to accept it. It's a bit disrespectful to the reviewer's time.

It's not up to you to determine what's an "acceptable" state, that's what reviewers are for. If changes were requested, then those changes have to be made before it's merged. I'll be blunt, the code quality here is not acceptable when compared to the rest of the codebase.

Finding float casting to be "easier" is not an excuse. The whole point of this project is doing things efficiently with the bare-metal hardware in mind. If I did things the easy way, this wouldn't run on a microcontroller. Again, the change was requested, so it has to be made before merging. Not a "maybe".

[ccuser44]

@p2r3 Ok. I've fixed all the aforementioned issues in the pull request.

I also took the puff up animation implementation from #161 as well as the idea for a mob griefing toggle so thanks and credit to @Blagish for both

[Blagish]

While kudos for trailblazing, I don't really see how this implementation is substantially better than mine...? Especially since there's literally chunks of code from my own pull request. The only defining point is randomness in explosions, but even that doesn't even work. It would be more productive to discuss changes and opinions of implementing instead of trying to win a race. I only took this issue because there were no more updates after initial review, and it was fair to assume it was dead for good.

Okay, actual issues:

• The code compiles with a warning on line 1390 in procedures.c.
• There are still a lot of edits of lines which are not part of the initial issue, including the removal of one particular check of MAX_BLOCK_CHANGES.
• As I said before, despite the defining of MOB_GRIEFING, creeper doesn't destroy any terrain at all, only the damage is dealt.
• Creeper behaviour is kinda sluggish, It only explodes itself when in 1-block radius near player, and continues moving even if the player is still in its area of attack.
• Creeper fusing animation is fixed on client-side at a length of 1.5 seconds. Bareiron operates at default at 1 tick per second, which means that the animation is either cut short, or is stopped at the last frame and it looks like a lag spike. Latter happens in this fork.
• Having a mob griefing check right in the beginning of explosion function is kinda strange, especially since there could potentially be explosions that are not originated from mobs. There aren't now, of course, but even then, there's a death message for dying to one.

There are also some style issues, but I'll leave that to the reviewer.

[ccuser44]

@Blagish

While kudos for trailblazing, I don't really see how this implementation is substantially better than mine...? Especially since there's literally chunks of code from my own pull request. The only defining point is randomness in explosions, but even that doesn't even work. It would be more productive to discuss changes and opinions of implementing instead of trying to win a race. I only took this issue because there were no more updates after initial review, and it was fair to assume it was dead for good.

Sorry. I didn't mean this to be a hostile action in any way. My point was not to win a race but finish my unfinished PR. And ported the creeper fuze implementation from your PR, if you'd like it to be removed feel free to let me know,

---

There are still a lot of edits of lines which are not part of the initial issue, including the removal of one particular check of MAX_BLOCK_CHANGES.

Fixed.

---

The only defining point is randomness in explosions, but even that doesn't even work.
As I said before, despite the defining of MOB_GRIEFING, creeper doesn't destroy any terrain at all, only the damage is dealt.

Ahh good catch. I accidentally swapped the preprocessor condition for MOB_GRIEFING so when its enabled no terrain is destroyed and vice versa. Fixed.

---

Having a mob griefing check right in the beginning of explosion function is kinda strange, especially since there could potentially be explosions that are not originated from mobs. There aren't now, of course, but even then, there's a death message for dying to one.

It checks if the explosion originates from a mob. And in the case where mob griefing is disabled and the explosion originates from a mob then no terrain is destroyed, otherwise the explosion passes as usual.

[Blagish]

My point was not to win a race but finish my unfinished PR.

Ah, I see. Sorry for assuming.

if you'd like it to be removed feel free to let me know

Nah, I don't mind :)