-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flixel Actions #1741
Flixel Actions #1741
Conversation
I'll fix travis when i can, 99% sure its missing |
Okay, Travis is finally satisfied, if @Gama11 or anybody else has any comments on the PR itself. |
Does this preclude the current input system(s), or is this purely an addition to make life easier/enable steam controller? Also, needs a crossinput demo. |
This looks nice even if you're not using steam controllers :) |
@MSGhero: This builds directly on top of existing input stuff, so all that still works. You can use this instead of, or in combination with, existing input methods. It's the only sensible way to enable the steam controller, but it's still useful for regular input styles. |
Awesome work - this will be a time saver and a allow a better organization Are the update function calls mandatory (e.g. action.update() ) ? Or are Tiago Ling Alexandre 2016-02-24 11:07 GMT-03:00 Lars Doucet [email protected]:
|
@Tiago-Ling: it will need a bit of testing to verify, but I'm 99% sure: update() needs to be called on an action (or the action set it belongs to if you're using an action set), when:
Otherwise you can just use a naked FlxAction and call check() on it whenever you want to check. Digital actions have their JUST_PRESSED / JUST_RELEASED updated properly by flixel itself, but analog & steam controllers need constant update() logic to do that properly. If I KNEW the user was always calling check() every frame, then I could make it behave like update and check, which would make those guarantees implicitly -- but it's hard to know if that's how they're using it. But yes, as designed you can use actions by themselves, actions as parts of sets, or the manager. And if you use the manager, and add it to FlxG.inputs, you don't have to call update on anything, it's automatic. |
Update -- I just looked at things, and it seems that calling check() also implicitly calls update(), and also fires callbacks if they are present! This means that if the user is using a "naked" FlxAction (not used as part of a FlxActionSet or a FlxActionmanager) and calls check() every flixel update, there's literally no reason to also call FlxAction.update() -- in fact doing so could cause multiple erroneous callbacks, given the current implementation. So a "safe" pattern could very well be to just call check() every frame. There's a few problems though:
Issue 1. might not be a real problem -- it's the "user's fault". But 2 seems like bad implementation. Is there a way in flixel to get a timestamp for the current frame or some other way to check that we're still at this point in time, so I can put some internal logic to make the internal updating logic short-circuit if it tries to run more than once on the same update frame? |
Okay, now I'm fairly confident two usage patterns should suffice:
|
Question: I could make FlxActions (and FlxActionSets) extend FlxBasic, which would let you add() them to the current state, automating update()'ing and ensuring they get destroy()'ed on state switch. Good idea or no? |
I mean everything else extends FlxBasic. Destroying key inputs is a bit awkward, but I guess it kinda makes sense given that your state should have differently named actions, even if they use the same keys. |
I would also like the demo to use the relative mouse stuff just to see how it works. |
I brought that |
@Gama11 : I get this is a huge PR, and it'll take the time it takes to review, so no rush, but is there anything I can do in the meantime? Also maybe we should bring in some other people to review to lighten the load? |
There are some code style issues I've noticed but not commented on since I wanted to have a look at the high-level structure of this whole thing first. I haven't gotten to that though. A few general things:
/**
*
*/
var example:Int; vs /**
*
*/
var example:Int; |
@Gama11: style fix in. |
Travis says neko is failing but I crawled all over the log and can't seem to find the failure? |
This happens at the end of the munit tests:
|
What does that mean? |
I have no idea, but I restarted that particular job and now it's green. |
Weird :) |
Heh, well I have to fix all the codeclimate checks now, thanks pointing that out @MSGhero :) |
Squashed, see here: |
This is a big commit, so for a broad-strokes overview, see this:
https://github.com/larsiusprime/haxeflixel/blob/actions_/flixel/input/actions/FlxActionManager.hx#L24
(That giant info dump probably needs to go somewhere other than the code itself, I just put it there for now, probably would eventually just go in the flixel docs).
This has been tested and works on my machine, but I don't currently have a demo for it. The syntax to use it is this:
1: Simple Digital Action
This will trigger "JUMP" on left mouse click, spacebar press, or pressing the bottom face button on the (first active) gamepad.
In your update loop:
2: Simple Analog Action
In your update loop:
3: Using the Action Manager
4: Using the Action Manager with Steam Controllers
First, install the steamwrap library, and follow all the steps in the SteamWorks documentation to get the basics set up.
Then: