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
Conversation
src/content_cao.cpp
Outdated
@@ -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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments
@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 ;-) |
src/content_cao.cpp
Outdated
@@ -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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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().
There was a problem hiding this comment.
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.
src/object_properties.cpp
Outdated
@@ -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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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. |
e4b413c
to
d0a1471
Compare
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. |
Tested using |
@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. |
@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? |
@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. |
Thanks but I spotted a problem, the server-side properties are updated first therefore it's no use updating the |
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 |
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. |
8f47678
to
b199a64
Compare
src/object_properties.cpp
Outdated
@@ -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); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
317c6d6 can be omitted by the merging developer if backwards compatibility is not an issue.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 ;-)
There was a problem hiding this comment.
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.
c448822
to
5922ce3
Compare
5922ce3
to
730820e
Compare
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. |
…etest#6218) * Make entity selection and collision boxes independently settable
…etest#6218) * Make entity selection and collision boxes independently settable
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,apointable
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.