[BUG] interactableVariables don't work 100% properly if the variable is on a vehicle, and the part is on a part of a vehicle.
boot2big opened this issue ยท 9 comments
interactableVariables work correctly under normal circumstances, however if a part is trying to reference a interactableVariable when it's on a part that's on a vehicle, it only registers hiding a placement hitbox. The part will still be interactable in terms of wrenching and seating (if its a seat.)
Okay, soooo.
You've got seats on an ihscout.json, interactable variables work there.
But suppose you had a part, that, for example, extended the scout's bed. So that would be ihscoutbed.json or something.
If ihscoutbed.json tries to reference an interactable variable on ihscout.json, it only references whether a part can currently be placed in this seat slot.
Regardless of whether the referenced variable is true or false, it will always behave as if the variable is true and will allow you to sit in a seat on ihscoutbed.json at any time.
I would think if it didn't work outright that you'd just never be able to place a seat into ihscoutbed.json, since it couldn't properly reference the variable at all. But clearly it is, since you can only place a seat into ihscoutbed.json if ihscout.json's door_bed is open.
Ahh, so what you're saying is that interactable variables only block intereaction on the part in that slot only, and not any of the child parts of that part? Including placing the part and actual intereaction? Or is it the former, and you can't place it, but still can intereact with it?
Neeeither. It doesn't matter whether the part slot that takes ihscoutbed.json has an interactableVariable or not. It's that the seats on ihscout.json will actively refuse to acknowledge any interactableVariables on ihscout.json as disabled and will infact behave as if they're constantly enabled. For everything except placing seats on them.
(And for clarification this does apply to parts beyond seats, but Imma just using seats as an example. Could apply to crates, engines, etc.)
Ehhh, somewhat. Though I'm still confused. Is door_bed a variable on the scout vehicle, or the scout bed? From what I can tell you're wanting to make a bed that has a door on it, and only when that door is open you can get into the seats. Does that mean that the door is defined on the bed, or the vehicle itself? Cause from that it sounds like, you defined the door variable on the vehicle, but to me that doesn't make sense. How would the vehicle have a bed-door variable if the door is on the not-yet-placed bed? I think a use-case would be easier for me to understand than pictures. But I am starting to get an idea and inkling of what might be going on here.
door_bed is a variable on the scout vehicle, not the scout bed. The issue is that, when door_bed is false, you can't put a crate into the scout's normal bed nor interact with any existing crates. However, if you installed this hypothetical bed extension part which reference's the scout vehicle's door_bed for interactableVariables, it allows you to interact with crates that exist in the bed extension even when the bed should be closed.
To clarify, I've got a part that takes an extra seat that's supposed to follow a door's variable. If that door isn't open, you shouldn't be able to sit in it. And likewise once sitting in it, it's supposed to close the vehicle's door like normal. But it does not.
So what you're saying, is that interactableVariables don't check the part-parent for their presence for intereaction. The only thing that checks part-parent is the holo-box visibility?