Timeline for State Machine implementation issues
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 30, 2020 at 1:41 | vote | accept | Pheonix2105 | ||
| Apr 30, 2020 at 1:35 | answer | added | DMGregory♦ | timeline score: 1 | |
| Apr 30, 2020 at 1:16 | comment | added | Pheonix2105 | Is this where I would use something like an input queue? I was reading up on them last night I just didnt want to charge into doing something like that if I had incorrectly implemented the state machine. *small correction, I meant event queue but I assume the principle applies to input too. | |
| Apr 30, 2020 at 1:14 | comment | added | DMGregory♦ | It sounds then like you'll want to centralize the way you provide inputs to your states. Right now you have some of the input triggered through events in the Raycaster's update, and some triggered through direct input checks in the states' update. This gives an opportunity to double-handle input, since the two updates run sequentially with the same button down information. You want to have one and only one paradigm for providing input to your states, so you can guarantee it's handled exactly once. | |
| Apr 30, 2020 at 0:55 | history | edited | Pheonix2105 | CC BY-SA 4.0 |
added 4113 characters in body
|
| Apr 29, 2020 at 21:53 | history | asked | Pheonix2105 | CC BY-SA 4.0 |