Skip to content
This repository has been archived by the owner on Aug 21, 2024. It is now read-only.

Add network spawning for dynamic gltf-model objects. Make equippables work for network spawned objects. #4071

Merged
merged 29 commits into from
Nov 29, 2021

Conversation

HexaField
Copy link
Member

Summary

A summary of changes being made in this PR

Checklist

  • Pre-push checks pass npm run check
    • Linter passing via npm run lint
    • Unit & Integration tests passing via npm run test:packages
    • Docker build process passing via npm run build-client
  • Changes have been manually QA'd
  • Changes reviewed by at least 2 approved reviewers

References

References to pertaining issue(s)

Reviewers

@HexaField @speigg @NateTheGreatt

@HexaField HexaField changed the title try to get equip object working again Fix Grabbables Nov 13, 2021
@hamzzam hamzzam changed the title Fix Grabbables Add network spawning for dynamic gltf-model objects. Nov 23, 2021
@hamzzam hamzzam changed the title Add network spawning for dynamic gltf-model objects. Add network spawning for dynamic gltf-model objects. Make equippables work for network spawned objects. Nov 23, 2021
@hamzzam hamzzam marked this pull request as ready for review November 24, 2021 11:07
Copy link

@NateTheGreatt NateTheGreatt left a comment

Choose a reason for hiding this comment

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

looks good, @hamzzam ! just a few questions/comments. the only changes i'd like to see before merging is to have those hasComponent calls moved into removeComponent. we might also want some of those console.log calls removed, too.

!hasComponent(equippedEntity, EquippedComponent)
) {
addComponent(equipperEntity, EquipperComponent, { equippedEntity, data: {} })
if (!hasComponent(equipperEntity, EquipperComponent) && !hasComponent(equippedEntity, EquippedComponent)) {

Choose a reason for hiding this comment

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

for my own understanding, is this if statement here to prevent the existing component data from being overwritten?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes.

// } else {
const world = useWorld()

matches(action).when(NetworkWorldAction.setEquippedObject.matchesFromAny, (a) => {

Choose a reason for hiding this comment

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

what's the difference between .matches and .matchesFromAny? i always forget ><

Copy link
Member

@speigg speigg Nov 25, 2021

Choose a reason for hiding this comment

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

.matches will match an action only when it comes from a trusted source (e.g., the host, or itself)
.matchesFromAny will match an action no matter who sent it

In general .matchesFromAny is unsafe, and .matches should be preferred

Copy link
Member

Choose a reason for hiding this comment

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

@NateTheGreatt happy to rename these for clarity if you can think of better names

Comment on lines 60 to 69
if (hasComponent(entity, BoundingBoxComponent)) {
// TODO: Does the Box3 object need to be destroyed before this?
removeComponent(entity, BoundingBoxComponent)
}
if (hasComponent(entity, InteractiveFocusedComponent)) {
removeComponent(entity, InteractiveFocusedComponent)
}
if (hasComponent(entity, SubFocusedComponent)) {
removeComponent(entity, SubFocusedComponent)
}

Choose a reason for hiding this comment

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

are these hasComponent checks necessary if it's removing the component anyways? if it's needed, perhaps we should add the hadComponent check to the removeComponent function instead

Copy link
Member

Choose a reason for hiding this comment

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

@NateTheGreatt Does bitecs allow removeComponent if the entity does not have the component?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I was of the assumption that bitECS does not allow removeComponent if the component does not exist. But I just ran a test it does not throw any errors. So I will update the code and remove the extra hasComponent checks.

Copy link
Contributor

Choose a reason for hiding this comment

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

Done

hamzzam and others added 7 commits November 26, 2021 00:14
Co-authored-by: Nate Martin <mrtn.nathaniel@gmail.com>
Co-authored-by: Nate Martin <mrtn.nathaniel@gmail.com>
Co-authored-by: Nate Martin <mrtn.nathaniel@gmail.com>
…or.ts

Co-authored-by: Nate Martin <mrtn.nathaniel@gmail.com>
…or.ts

Co-authored-by: Nate Martin <mrtn.nathaniel@gmail.com>
…or.ts

Co-authored-by: Nate Martin <mrtn.nathaniel@gmail.com>
…or.ts

Co-authored-by: Nate Martin <mrtn.nathaniel@gmail.com>
@hamzzam
Copy link
Contributor

hamzzam commented Nov 25, 2021

looks good, @hamzzam ! just a few questions/comments. the only changes i'd like to see before merging is to have those hasComponent calls moved into removeComponent. we might also want some of those console.log calls removed, too.

Removed the console.logs and hasComponent checks. Let me know if anything else needs to be updated. Thanks

@HexaField
Copy link
Member Author

Are you able to provide a guide to show the functionality for this? I tried using the collision cube to create an equippable and there is an issue with the new interactable UI and i cant seem to equip anything.

@hamzzam
Copy link
Contributor

hamzzam commented Nov 26, 2021

Are you able to provide a guide to show the functionality for this? I tried using the collision cube to create an equippable and there is an issue with the new interactable UI and i cant seem to equip anything.

It was working fine before the latest dev merge. Let me try to debug

Copy link

@NateTheGreatt NateTheGreatt left a comment

Choose a reason for hiding this comment

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

QA steps would be great. i forgot to add that to the PR template

@hamzzam
Copy link
Contributor

hamzzam commented Nov 26, 2021

@HexaField @NateTheGreatt I tested it out, the equippables functionality is working fine. There are some errors in the interactables logic due to which the text and highlighting are not working. I tried adding some sanity checks but that didn't help. Probably the dev who worked on it will need to fix those.

To test the interactables you should do the following:

  1. In the editor, add a model node and set its interaction type to Equippable. Save.
  2. Then in the scene, take the avatar near the equippable model and press E. The object will attach to the avatar hand.

@NateTheGreatt
Copy link

NateTheGreatt commented Nov 26, 2021

thanks for the repro steps @hamzzam! I tested it out and there seems to be an issue with the item following the hand bone after pickup.

@hamzzam
Copy link
Contributor

hamzzam commented Nov 27, 2021

thanks for the repro steps @hamzzam! I tested it out and there seems to be an issue with the item following the hand bone after pickup.

Hey @NateTheGreatt that's because the getHandTransform function is returning a fixed hand position currently. There is a TODO present to use the actual hand position when the animation rig is in. And I think that is in the system now, should I try fixing this? will need to look into the animation rig system. @HexaField

@HexaField
Copy link
Member Author

Hey @NateTheGreatt that's because the getHandTransform function is returning a fixed hand position currently. There is a TODO present to use the actual hand position when the animation rig is in. And I think that is in the system now, should I try fixing this? will need to look into the animation rig system. @HexaField

Yes I think we are now in a place where this should work.

@hamzzam
Copy link
Contributor

hamzzam commented Nov 29, 2021

Hey @NateTheGreatt that's because the getHandTransform function is returning a fixed hand position currently. There is a TODO present to use the actual hand position when the animation rig is in. And I think that is in the system now, should I try fixing this? will need to look into the animation rig system. @HexaField

Yes I think we are now in a place where this should work.

Ok. I will make a separate PR for that, we can get this PR approved if that is the only thing left.
Or let me know if you think this change must be included in this PR.

Copy link

@NateTheGreatt NateTheGreatt left a comment

Choose a reason for hiding this comment

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

Ok. I will make a separate PR for that, we can get this PR approved if that is the only thing left.
Or let me know if you think this change must be included in this PR.

sounds good to me 👍

@speigg speigg merged commit 8c8f90b into dev Nov 29, 2021
@speigg speigg deleted the fix-grabbables branch November 29, 2021 19:22
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants