feat: allow swapping item in slot #71
xury
noahg
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "noahg/allow-swapping-item-in-slot"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refactored interaction handling to be able to facilitate this three-way interaction coordination.
Refactored item slots so that their current item is automatically assigned from its child nodes.
Thank you for putting this together, this already feels so much better for solving the sculpture puzzle, quickly being able to swap is great!
I did notice that's possible to display the wrong hint when too far away:
With the globe on the pedestal, and standing far enough away, the hint says "Pick Up" but if you press E you actually put your current held item down.
I'll keep looking at the rest of this PR :)
Edit: turns out this issue is not new to this PR, might be worth fixing at the same time, but it's also okay to save that for another time.
I haven't fond the exact way to reproduce this yet, but while shuffling around the children in editor I got this error a couple of times:
This is looking really good, thank you for putting the work in on this it makes a big difference inside the editor and during game play!
Check my comments for a few minor areas of concern, I don't see any blocking issues though.
@ -8,0 +10,4 @@_item_placement_marker = valueif _current_item and _item_placement_marker:_current_item.transform = _item_placement_marker.transformThis is awesome! I wasn't expecting this feature, but it works really well!
It was more of a workaround than a feature. I ended up finding a simpler solution that let me stick with
@onreadyso I was able to eliminate this extra@exportand other supporting logic.@ -11,0 +30,4 @@assert(_item_placement_marker, "No Item Placement Marker assigned")var pickup_items := _find_pickup_items_in_children()assert(pickup_items.size() <= 1, "More than one PickupItem found in children")I'm not sure which part of the code is responsible for this, but there's a small user experience issue:
In the current version, if I drag multiple PickupItems onto the ItemSlot, the first one it finds is snapped into the placement marker, but the others are left alone and it issues the assert.
While it's not valid to run the game in this state, the expected behavior would be that all of the items slot in, even though it issues the warning.
In my quick experimentation from a level design standpoint; I can tell this would be super useful for drag-and-dropping in any order I like, and fixing things as I go to take care of the asserts. But right now, if I drag in three, then move the first two, the final one is left behind, not snapped into place.
There was definitely a logic gap before. The weird behavior you identified should be fixed now.
@ -11,0 +33,4 @@assert(pickup_items.size() <= 1, "More than one PickupItem found in children")if not pickup_items.is_empty():place_item(pickup_items[0])This line change seems like it was supposed to be part of the previous commit
It definitely was. As I was cleaning this up I realized it should have done it differently anyway.
@ -11,0 +40,4 @@str("Child PickupItem position is not equal to the Item Placement Marker position. ","This may have happened because the scene was edited outside the editor. ","Try unparenting and then reparenting the PickupItem to automatically place it back in the correct position.",Using the method I described above, I was able to get into this state, but I did not see this assert trigger.
Also, upon reloading the scene / playing the level object snapped into place anyway.
I also tried getting it into this state, then making a build of the game, the built game also did not throw the assert, it just snapped the item into the slot. Not really an issue, I'm just not seeing this assert.
This should be sorted out now. Also, FYI asserts do not trigger in release builds of the game.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#assert-keyword
@ -11,0 +50,4 @@returnif _current_item and _item_placement_marker and not _current_item.position.is_equal_approx(_item_placement_marker.position):_current_item.position = _item_placement_marker.positionThis is probably fine, but I did notice you can try to use the gizmo, and it just detaches from the object, which is an odd behavior if you don't know what's going on. I wonder if there's a feature for locking the gizmos as well.
I looked into how to go about solving this and there does not appear to be a simple way that doesn't come with new problems. The closest thing I could find was to lock the node by setting a special metadata flag, but that can still be defeated if you unlock it manually, so it's not a complete solution.
@ -11,0 +79,4 @@warnings.append(str("This node requires exactly zero or one PickupItem child node. ","Please remove all extra PickupItem child nodes.",Excellent!
c6f81a9adato643802ae09@xury wrote in #71 (comment):
Fixing this would require a more involved reworking of how the interaction areas work and might even need the PickupItem objects to be aware of whether they are currently in a slot. The globe is a special case anyway, so I'm going to leave this as-is for now.
@xury wrote in #71 (comment):
I haven't been able to reproduce this error. Maybe the project just needed to be reloaded first?
The new version has a couple of issues. I tried reloading Godot and deleting the .godot folder just to be sure.
I did encounter this:
This happened when I dragged three puzzle pieces from one pedestal to another at the same time.
It seems inconsistent though, not sure why it happens some times and not others.
Also, the assert to say there should be exactly zero or one item doesn't seem to be triggering anymore in this PR.
Edit: for posterity - both of these issues turned out to just be an issue where this class didn't reload correctly because it's a
@tool- I just had to reload the editor.Another thing I noticed: If you put all three correct puzzle pieces in place in the editor, I would expect the puzzle to register as solved when the game starts, but it doesn't you have to pick up one item and put it back down to get it to trigger.
643802ae09to5da154d07d@xury wrote in #71 (comment):
That error seems to be solved after reloading the project on my end.
The issue with setting the correct pieces not triggering the solution should now be resolved.