Implementation DamagingBlocks

[Filipa Ramos]

Hi!
We are one of the groups of students from Porto and we were thinking of implementing a new feature. As it was suggested by Team Leader Cervator on an issue (https://github.com/MovingBlocks/Terasology/issues/1697#issuecomment-158688397) we'll try to implement the burning characteristic for lava blocks.
The objective is to create blocks that damage objects/players applied to lava blocks at first (this feature may be needed in other blocks or objects such as cactus). When an object falls in a lava block it is destroyed. A player that falls into lava starts taking damage and if he doesn't step out of the lava before the lives counter reaches zero he dies.

 

[Cervator]

Great to see this get started!

The issue has a lot of my initial thoughts on the topic. Main thing is finding the event you can connect the functionality to. For something like stepping into a liquid maybe whatever Breathing currently does could help, but simply getting too close to a block (like a cactus) might be trickier. Maybe some sort of proximity event.

@msteiger and @Josharias might have some good ideas

 

[msteiger]

I thought that players get hurt when stepping on lava blocks already, but it doesn't work for me. To achieve this, the OnEnterBlock event needs to be caught and handled.

@ReceiveEvent
public void onEnterBlock(OnEnterBlockEvent event, EntityRef entity) {
...
}

 

[skit]

I think we'll try on a first approach to work on the lava damaging scope, but a good further improvement would be to be able to generalize for every block that has some "damaging" property set but at this point of our understanding of the project that could be a little more complex

 

[skit]

Hello!
We concluded the feature we proposed in this topic. It is implemented in this repository https://github.com/sergiomieic/Terasology .

 

[Cervator]

Awesome! Although I can't spot the code in there? You have a "DamagingBlocks" branch but there are no unique commits in it? Got the commits locally but not pushed to GitHub yet?

 

[skit]

The mod was developed in the develop branch, ignore the DamagingBlocks branch ( already deleted ).

 

[Cervator]

Alright

I still don't see it in develop though: "This branch is 1 commit ahead, 46 commits behind MovingBlocks:develop." - the one commit is https://github.com/sergiomieic/Terasology/commit/9bd70f164aa8447320a7e8221d7a08f0f710640c which only contains a single IntelliJ project file.

 

[skit]

So we had some troubles with git, that are now fixed, sorry for all the inconvenience it should be working now.
https://github.com/sergiomieic/Terasology/tree/DamagingBlock/modules/DamagingBlocks

 

[Cervator]

Awesome! I see it

You figured out Git and you made a new working module, well done! A few more steps and we can bundle this new module with the game, will be easy

Currently your DamagingBlocks module is embedded in the engine repository, but since it is a module we need to put it into its own independent module repository. I've created:

https://github.com/Terasology/DamagingBlocks + a build job for it at http://jenkins.terasology.org/view/ModulesPending/job/DamagingBlocks/

And granted your GitHub user write rights to it. Do this in your local workspace:

1. Move the existing DamagingBlocks directory out of /modules to somewhere safe (don't have IntelliJ open)
   
2. Run "gradlew createModuleDamagingBlocks" in a command prompt / terminal in the root of the project - this will recreate a new modules/DamagingBlocks
3. The new directory will have some files created including a module.txt. Take the module.txt from your safe copy of DamagingBlocks and overwrite the new one
4. Copy in just your two .java files from your safe copy - none of the XML files or build files. Look at the .gitignore file that generated in modules/DamagingBlocks - lots of stuff doesn't go into Git
   
5. Copy in anything else that might still be missing from GitHub (I see a "DamageBlockTeste.class" - do you have a src/test/java file that's missing?)
6. Run "gradlew idea" - this will regenerate IntelliJ project files
7. Run "git remote add origin https://github.com/Terasology/DamagingBlocks.git" inside modules/DamagingBlocks - that will connect your local module to the module repo on GitHub
8. Run IntelliJ and look around. You should have a new DamagingBlocks module now connected the right way with the ability to push code to the module repo online, which will cause our build job to run automatically

That might look like a lot but it isn't bad at all! If you have any questions or run into problems just ask here on come see us on IRC.

 

[skit]

So I've followed all the the mentioned steps, it should be all well setted up now

 

[Cervator]

Yep I see it! Nice job

One last tweak: the Java files at https://github.com/Terasology/DamagingBlocks/tree/master/src/main/java should then include the package path leaving them at https://github.com/Terasology/DamagingBlocks/tree/master/src/main/java/org/terasology/damagingblocks

You should be able to do a simple move locally then commit and push the update

No other files left? Did you test it locally with a new Lava block of some sort with this new component attached? Any unit tests?

 

[skit]

The path is now updated
I tested it locally and it worked (it only works when you enter the block and it's at foot level). I started designing some unit testing locally but didn't commited because I dind't manage to do a succesfull setup with mock objects.

 

[Cervator]

Yep works! Very cool

And this explains why I was puzzled how you got it to work without some sort of test block, I had forgotten we even had block.isLava() hehe

Understood on the unit test. Let me know if you'd like some examples, I can probably find something in a module somewhere with unit tests.

If you're up for it you could also run Checkstyle on the two classes, there are some style issues, mostly whitespace and some use of brackets. Could also take out the extra logging now that it is in place and works well

I'll add this module to the main lineup soon! Edit: And move this thread to the Module forum now that it is implemented.

 

[skit]

Ok, I'll work on that checkstyle and logging issues soon. In respect to unit testing, I'll try to see if I can find some examples.

 

[Cervator]

Thanks! Feel free to do it in two parts, one to just add final polish to the module and another for unit tests. Then sometime later hopefully we can enhance it further and the unit tests will guard us against bugs