Phazorknight / Cogito

Immersive Sim Template Project for GODOT 4
MIT License
717 stars 81 forks source link

Make interactions be blocked by Environment safely #114

Closed FailSpy closed 4 months ago

FailSpy commented 4 months ago

This one's pretty self-explanatory. Resolves #110

FailSpy commented 4 months ago

I was going to add an exported check to the Player controller to adjust this, but I realized it's probably better to let devs adjust the layering system themselves to suit their needs. I think this is good for a default, and if devs want something else then it's very simple to change back or make work in other ways without being too prescriptive.

Phazorknight commented 4 months ago

Not sure if this is needed?

Issue #110 is caused by the walls not set on collision layer 2. Setting them to layer 2 fixes it, so I'd personally not change any existing layer structures on the player interaction component, especially since it would force users to update the collision layers on all their interactive objects.

But I'd be happy to hear of any other advantages that I might not be aware of.

FailSpy commented 4 months ago

As it is right now, in the Project Settings of the Cogito Godot project is Layer 1 is defined as "Environment", and Layer 2 is defined as "Interactables". To me it seems conflicting to have to make all your environment pieces "Interactables" to be physically blocking interactions.

So I don't see that it would be a good idea to have users be moving all of their environment that is not literally Interactable onto the Interactables layer just to get this feature out of the environment.

All I've done in the PR is move the player on to its own layer so that way the interaction raycast can't hit it, and include Environment as a collision layer for the raycast to have environment block interactions.

Unless this layer setup is no longer of interest, at which point the layer names should probably be changed. Though personally, I would prefer environmental pieces on the default layer 1 to be blocking interactions.

Also by not encouraging the separation of these layers, then you would have no way to discern Interactables vs Environment purely via Raycast if you did want interactions to work through walls, you have to do the raycast, then check if what it hit is in the group.

Phazorknight commented 4 months ago

That makes sense! Having the environment block by default would definitely be great. Let me take a closer look at the PR.

Phazorknight commented 4 months ago

Hey @FailSpy , when I open this on my end, playtesting the project makes my resolution all pixely, no matte which one I select from the options + the temp UI scaling slider is gone.

Could you take a look to undo any changes to those in this PR?

I'd try to cherrypick, but with the update layersettings I'd like to keep the project.godot file from this PR.

FailSpy commented 4 months ago

Oh those changes weren't included cause that PR wasn't merged when I started the interactions-fix branch. Will update the branch and that should fix it!

FailSpy commented 4 months ago

@Phazorknight give it a try now?

FailSpy commented 4 months ago

Oh wait, hold off. Found a major issue with the layering setup: bunch of stuff now doesn't collide with the player. Attempting a workaround that minimizes breakage of other people's existing work...

FailSpy commented 4 months ago

@Phazorknight Okay, so I've gotten rid of the player layer to be minimally conflicting with existing projects as it'd be a nightmare. Encountered all sorts of interesting bugs. As nice as it would be to have a separate player layer, I feel it's a bit much to do right now, so this is the absolute minimum set of changes to accomplish this PR's goal

EDIT: Force-pushes cleans up commits into one commit, considering the original commit for this branch was basically completely undone.

FailSpy commented 4 months ago

@Phazorknight Okay, properly ready now to be pulled in. Give it a shot, see how it goes for you.