Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add HealthComponent #1

Merged
merged 8 commits into from May 22, 2019
Merged

Add HealthComponent #1

merged 8 commits into from May 22, 2019

Conversation

e-aakash
Copy link
Member

For now, just moved the HealthComponent of Logic/Health to the new module.

Copy link
Member

@Cervator Cervator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Throwing in some general comments hoping bits of it might be useful :-)

Another suggestion: Make a paired draft PR for the engine that removes anything this PR adds to the Health module, then update it over time. No intent to merge the engine PR for some time, but it might be good for visibility and being prepared. Then finally when Health is ready switch the engine PR out of draft mode (and/or recreate it fresh depending on how stale that branch went)

import org.terasology.network.Replicate;
import org.terasology.rendering.nui.properties.TextField;

public class HealthComponent implements Component {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well-written class level javadoc can be useful in very central components like this. Think long term: what might somebody like to see when they're fishing around for relevant components and run into Health?

@TextField
public int currentHealth = 20;

// Regen info
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer one-liner javadoc comments IMHO and document each field you think can be meaningfully enhanced. Example:

`/** Next tick time that will trigger regeneration */


public boolean destroyEntityOnNoHealth;

public HealthComponent() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a practice it may be wise to leave a comment on the no-arg constructor to highlight the reason it is here: if it isn't and there is an arg-constructor then the "invisible" no-arg constructor disappears. That then breaks stuff as some of the magic relies on there always being a no-arg constructor :-)

public HealthComponent() {
}

public HealthComponent(int maxHealth, float regenRate, float waitBeforeRegen) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figure this constructor is here because it already existed - I wonder how frequently it is used and if it is really justified for it to exist? It might be a good practice for us to always encourage the pattern of setting whichever exact fields you need rather than use a custom constructor

HealthComponent health;
health.maxHealth = 123;
health.regenRate = 42;
//apply the component to something

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After searching in the mega workspace, I couldn't find any usage of this constructor. I am hence removing this constructor.
And, since the unique constructor is removed, the default constructor is not needed explicitly.

@@ -0,0 +1,70 @@
/*

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if this test should be here or in the MTE module.

Copy link
Member

@Cervator Cervator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some more comments but mostly trivial / future thoughts so not going to block merging from it. Will push to merge without a merge commit so you can continue in your next branch without any updates needed. Can address any actionable review comments in a new commit during that effort :-)

Nice tests! They actually work for me for some reason, without hacking my workspace. I don't understand, but ... ¯_(ツ)_/¯

Haven't tested in-game as I don't know if that's ready yet.

private EntityManager entityManager;

@In
private org.terasology.engine.Time time;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for having this fully qualified?

@@ -4,6 +4,6 @@
"author" : "",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to toss an author name in there :-)


}

/** Handles DoHeal event to increase health of entity */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One-liner javadoc is good for simple fields, but methods should always use the expanded version including doc for parameters etc :-)

import org.terasology.entitySystem.event.Event;

/**
* Send this event to an entity to heal it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"to heal it ..." - fully? Or could a negative number be hurtful instead? Maybe that's covered in the System

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A negative value is supposed to cause damage, but not working at present. Will update the Javadoc when the issue is solved.

* Event sent upon an entity reaching full health if previously on less than full health.
*
*/
public class FullHealthEvent implements Event {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might this be more descriptive as OnFullHealthEvent ?

Would also put it more in line with OnHealedEvent - although then I'd wonder if this would work better as OnFullyHealedEvent plus wonder what the implications of both triggering would be

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renaming it as OnFullyHealedEvent, seems more apt for full health event.

}

/**
* @return The amount by which health changed. This is capped, so if the entity received 9999 damage and only had 10 health, it will be -10.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it though? This method just seems to blindly return the change - I don't see any capping here? It could happen elsewhere but then that'd make this javadoc somewhat presumptuous :-)

It also helps to still write out both statements separately - the method description and the return value. Sometimes that can be tricky to write in a meaningful way split into two fields but since they each go to a different place in displayed javadoc it is ideal to have both (IMHO anyway)

An alternative might be to throw a boolean into a single event that indicates whether or not it resulted in a full (or partial) heal

Copy link
Member Author

@e-aakash e-aakash May 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it does show the changed amount because the capping is done not in the event but in the method calling the event.
https://github.com/Terasology/Health/pull/1/files#diff-e0c50392da47b79c5d45c9c66a5ec5feR112

So, i think the javadoc should be modified to say so.

event.subtract(5);
event.multiply(2);
});
// expected = ( initial:10 + 10 - 5 ) * 2 = 30
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rewrite this ever so slightly for clarity. Like:

Suggested change
// expected = ( initial:10 + 10 - 5 ) * 2 = 30
// Expected value is ( initial:10 + 10 - 5 ) * 2 == 30

@Cervator Cervator merged commit a4d033f into Terasology:master May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants