Home › Forums › Bug Reports and Feature Requests › First person camera controls + when clicked puzzle problems
- This topic has 7 replies, 2 voices, and was last updated 4 months, 2 weeks ago by
kdv.
-
AuthorPosts
-
2024-08-05 at 9:30 pm #76402
adamabr
CustomerHi there!
In a larger project I’ve come across a weird problem when I introduce the “when clicked” puzzle.
I’ve tried to isolate the problem in a very simple scene to showcase how it works (or does not work). Basically I can’t walk around with WASD when the “when clicked” puzzle is enabled.
The project has an HTML UI that embeds the app as an iframe.
It has two cameras, one orbit camera, and one first-person camera.
Clicking the button at the bottom of the screen switches from the orbit camera to the first person camera. Usually this would work just fine and you’d be able to walk around but since there is a “when clicked” puzzle in the puzzle editor this does not work.For some reason, creating a button inside puzzles and using that to toggle between the cameras solves the problem. However, this is not a solution in my case, and the original bug still exists. I have some disabled puzzles in the file for doing this. Just enable them and switch to not referencing the “parent doc” when identifying the button.
Also you can remove the “when clicked” puzzle and it all works again for both button alternatives.
This looks like a bug to me, and I wonder if this is just on my end or something deeper.
Please try it and let me know!
Here is the project file: https://www.dropbox.com/t/3rPKEzUm1V6Rw150
Thanks,
Adam2024-08-05 at 9:36 pm #76403kdv
ParticipantThe project has an HTML UI that embeds the app as an iframe.
That’s the reason of this issues.
Clicking the button at the bottom of the screen switches from the orbit camera to the first person camera.
The app’s document is not in focus and doesn’t react to key events.
For some reason, creating a button inside puzzles and using that to toggle between the cameras solves the problem
The app’s document is in focus and reacts to key events.
Puzzles and JS coding. Fast and expensive.
If you don’t see the meaning in something it primarily means that you just don’t see it but not the absence of the meaning at all.
2024-08-05 at 10:02 pm #76404CustomerThanks for the rapid response kdv.
However, I’m not sure I agree. Try removing the “when clicked” puzzle and it will work both ways. I think there is something else going on here.
2024-08-05 at 10:10 pm #76405ParticipantTry to click the fullscreen button and you will see…
Puzzles and JS coding. Fast and expensive.
If you don’t see the meaning in something it primarily means that you just don’t see it but not the absence of the meaning at all.
2024-08-05 at 10:12 pm #76406CustomerAll I see when clicking the fullscreen button is that the HTML layer is no longer visible. What are you getting at?
2024-08-05 at 10:15 pm #76407ParticipantI mean that after clicking the fullscreen button (you can just press the mouse button, hold it and then move it away to prevent toggling the fullscreen mode) the FPS controls will work even with the “when clicked” puzzle. Untill you you click the toggle button in the parent document.
Puzzles and JS coding. Fast and expensive.
If you don’t see the meaning in something it primarily means that you just don’t see it but not the absence of the meaning at all.
2024-08-05 at 10:20 pm #76408CustomerInteresting find!
But why does it work using the HTML overlay without clicking the fullscreen button when there is no “when clicked” puzzle?
I find this to be very odd. Does the “when clicked” puzzle affect the focus somehow?
And what workaround could I use?
2024-08-05 at 10:30 pm #76409ParticipantDoes the “when clicked” puzzle affect the focus somehow?
Obviously it does…
Puzzles and JS coding. Fast and expensive.
If you don’t see the meaning in something it primarily means that you just don’t see it but not the absence of the meaning at all.
-
AuthorPosts
- You must be logged in to reply to this topic.