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

Make entity selection and collision boxes independently settable #6218

Merged
merged 2 commits into from Aug 24, 2017

Conversation

stujones11
Copy link
Contributor

@stujones11 stujones11 commented Aug 6, 2017

Addresses #6199

This PR adds an optional selectionbox property to entities that overrides the collision box dimensions, otherwise used as the default. This is particularly useful for vehicle mods where the collision box often needs to be a different size or shape to the vehicle itself.

Note that 'zeroing' the selection box table will cause the visible selection box to default to the collision box dimensions, however, a pointable property has also been included as a means to prevent selection.

This PR will also make entities more consistent with nodes in terms of available properties, IMO these ones in particular are even more important for entities.

@@ -1501,7 +1501,14 @@ void GenericCAO::processMessage(const std::string &data)
if (cmd == GENERIC_CMD_SET_PROPERTIES) {
m_prop = gob_read_set_properties(is);

m_selection_box = m_prop.collisionbox;
aabb3f no_selection = aabb3f(0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f);
Copy link
Member

@SmallJoker SmallJoker Aug 6, 2017

Choose a reason for hiding this comment

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

This is an ugly workaround. Rather extend ??????Environment::getSelectedActiveObject to skip the objects that aren't pointable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, I will look at that, however, the 'zeroed' aabb box also denotes that no selection box has been specified. I did say that it wasn't ideal but I see no other way of knowing whether a selection box was set in the entity def.

Copy link
Contributor Author

@stujones11 stujones11 Aug 6, 2017

Choose a reason for hiding this comment

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

Rather than make changes to ClientEnvironment::getSelectedActiveObject I think it would be better to include the pointable check in GenericCAO::getSelectionBox where it already returns false for invisible objects and is subsequently skipped by getSelectedActiveObject

doc/lua_api.txt Outdated
@@ -3956,6 +3956,8 @@ Definition tables
collide_with_objects = true, -- collide with other objects if physical = true
weight = 5,
collisionbox = {-0.5, 0.0, -0.5, 0.5, 1.0, 0.5},
selectionbox = {0, 0, 0, 0, 0, 0}, -- defaults to collision box dimensions
Copy link
Member

Choose a reason for hiding this comment

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

If it defaults to the collision box, then why is this table different from the other?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because this is the default setting and what you will see if you dump the property table.

@SmallJoker SmallJoker added @ Script API Feature ✨ PRs that add or enhance a feature labels Aug 6, 2017
Copy link
Member

@SmallJoker SmallJoker left a comment

Choose a reason for hiding this comment

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

See comments

@stujones11
Copy link
Contributor Author

@SmallJoker Cheers for the prompt review, I think I have now addressed the issues you raised. This PR is really quite trivial and it would be nice to see it merged before I start getting rebase conflicts ;-)

@@ -614,7 +614,7 @@ GenericCAO::~GenericCAO()
bool GenericCAO::getSelectionBox(aabb3f *toset) const
{
if (!m_prop.is_visible || !m_is_visible || m_is_local_player
|| getParent() != NULL){
|| !m_prop.pointable || getParent() != nullptr) {
Copy link
Member

Choose a reason for hiding this comment

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

getParent() does not return nullptr. Either revert this change to NULL or correct the function definitions and all lines where that function is checked against returning NULL. Never, ever mix these two.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's better to keep the nullptr and modify getParent().

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, I will revert that last commit asap, seems like the safest option.

@@ -71,6 +73,9 @@ void ObjectProperties::serialize(std::ostream &os) const
writeF1000(os, weight);
writeV3F1000(os, collisionbox.MinEdge);
writeV3F1000(os, collisionbox.MaxEdge);
writeV3F1000(os, selectionbox.MinEdge);
writeV3F1000(os, selectionbox.MaxEdge);
writeU8(os, pointable);
Copy link
Member

Choose a reason for hiding this comment

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

needs version bump for backwards compatibility.

Copy link
Contributor Author

@stujones11 stujones11 Aug 7, 2017

Choose a reason for hiding this comment

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

Should this be done as part of this PR? I have seen other new entity properties added without the need for that. I'm not too sure how to go about that, TBH.

Copy link
Member

Choose a reason for hiding this comment

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

This is only possible by adding the new values in this output-stream below the already existing ones. Otherwise, older clients will read garbage from the new "gap" you opened here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, that makes sense, are there any examples of how to bump the version, another PR perhaps? Or do you think it would be better just to move the new fields to the end?

Copy link
Member

Choose a reason for hiding this comment

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

KISS. Move the fields to the end.

@paramat
Copy link
Contributor

paramat commented Aug 8, 2017

This will be useful for my car mod, currently the selectionbox is set to the collisionbox which by necessity is buried inside the vehicle and barely visible.

@stujones11 stujones11 force-pushed the selection-box branch 3 times, most recently from e4b413c to d0a1471 Compare August 8, 2017 16:41
@stujones11
Copy link
Contributor Author

stujones11 commented Aug 8, 2017

I have made the requested changes and squashed the commits but am unable to actually test this right now. I will do this asap but given the changes, I think it should be fine.

@SmallJoker
Copy link
Member

SmallJoker commented Aug 9, 2017

Tested using pointable = false (and = true in minetest_game/mods/player_api/api.lua L49.
Works fine, but only when the server uses this commit. For some reason there's no SerializationError in this case when reading outside the actual packet. As a result of this, pointable is always set to false when playing on older servers. I.e. none of the entities is selectable.
EDIT: How about sending the inverted case and reading it with pointable = !readU8(is);, so a zero defaults to true?

@stujones11
Copy link
Contributor Author

stujones11 commented Aug 9, 2017

@SmallJoker Thanks for testing, I have done as you suggested and inverted the case. I have tested on an older server and everything seems to work as expected, however, I am wondering if backwards compatibility is really that important right now. I mean the current development builds are pretty much broken on older servers anyway.

@stujones11
Copy link
Contributor Author

stujones11 commented Aug 12, 2017

@SmallJoker I noticed a slight inconsistency with this on the server-side while looking at the ray-casting issue, I hope you are still okay with it?

@SmallJoker
Copy link
Member

@stujones11 I don't see any regression - If you didn't find any problems while testing either, I'm fine fine with the new change.

@stujones11
Copy link
Contributor Author

stujones11 commented Aug 13, 2017

Thanks but I spotted a problem, the server-side properties are updated first therefore it's no use updating the m_prop client-side, the server does not see this. I have now moved the selection box default to the script api, this is actually much better since it avoids the need to compare aabb3f boxes, which I never did like doing. Tested and working.

@stujones11
Copy link
Contributor Author

stujones11 commented Aug 13, 2017

Reworded documentation since now the selection box will be the same as the collision box if no selection box was specified in the entity definition. A 'zeroed' selection box will now behave just as expected but pointable = false should still be used to prevent selection.

@stujones11
Copy link
Contributor Author

stujones11 commented Aug 13, 2017

I have now extended these properties to also work with players, however, this requires some minor additions to the MTG player_api to make them actually useable for modders. I am not entirely sure there is any real use-case, it just seemed easier to include it over trying to document the inconsistency.

Note this commit also incorporates the ray-casting fix I made here #6241 so that would no longer be applicable if this were to be merged first.

@stujones11 stujones11 force-pushed the selection-box branch 2 times, most recently from 8f47678 to b199a64 Compare August 13, 2017 17:53
@@ -98,6 +100,9 @@ void ObjectProperties::serialize(std::ostream &os) const
writeF1000(os, automatic_face_movement_max_rotation_per_sec);
os << serializeString(infotext);
os << serializeString(wield_item);
writeV3F1000(os, selectionbox.MinEdge);
writeV3F1000(os, selectionbox.MaxEdge);
writeU8(os, !pointable);
Copy link
Member

Choose a reason for hiding this comment

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

why invert the boolean ? please keep the right value

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was suggested by @SmallJoker from the emote, it seems @sfan5 agrees.

#6218 (comment)

317c6d6 can be omitted by the merging developer if backwards compatibility is not an issue.

Copy link
Member

Choose a reason for hiding this comment

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

since readU8 defaults to false if out-of-bounds this needs to be inverted to get pointable to be true if omitted

Copy link
Member

Choose a reason for hiding this comment

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

@sfan5 it's crazy and not very dev friendly, we should fix this later... i dismiss my request

Copy link
Member

Choose a reason for hiding this comment

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

indeed this should be fixed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This can be fixed later without breaking anything so is there any chance one of you could give a second approval on this? It's fairly trivial stuff but useful for modders and also fixes a ray-casting bug ;-)

Copy link
Contributor

@paramat paramat Aug 17, 2017

Choose a reason for hiding this comment

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

Backwards compatibility is no concern at the moment as we have just merged 2 compatibility breaking commits, so just choose whatever is best without considering new-old server-client compatibility. I guess not inverting is best.
The 2nd commit could be left out on merge.

@stujones11
Copy link
Contributor Author

Rebased and squashed into 2 commits. I have reverted the backwards compatibility hack but left the revert commit so the merging developer can decide whether to include it or not.

@nerzhul nerzhul merged commit ac4884c into minetest:master Aug 24, 2017
@stujones11 stujones11 deleted the selection-box branch February 9, 2018 19:50
osjc pushed a commit to osjc/minetest that referenced this pull request Jan 11, 2019
…etest#6218)

* Make entity selection and collision boxes independently settable
osjc pushed a commit to osjc/minetest that referenced this pull request Jan 23, 2019
…etest#6218)

* Make entity selection and collision boxes independently settable
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants