Debugger: add "FlxObjects-are-draggable"-mode

[Gama11]

Apparently you can do this in HaxePunk.

This would be extremely handy for UI-building and other things of that nature. MouseEventManager could be used for this - would need to iterate over FlxState and add a onClick callback to everything that is a FlxObject (MouseEventManager supporting FlxObject is useful after all, @impaler, @gamedevsam :P).

[Eiyeron]

Idea : make this as a toggable feature, that would make things easier (imagine this + NAPE)

[Gama11]

Yeah, the idea is to add a new toggle button for this to the debugger. :)

[Eiyeron]

Will this feature be debug-mode exclusive? (I assume no, IIRC I can toggle hitbox display without enabling debug mode.)

[Gama11]

(ignore earlier comment)

The debug drawing functionality is removed when FLX_NO_DEBUG is defined. You can still set FlxG.debugger.drawDebug to true, but it won't do anything.

[Gama11]

FlixelCommunity/flixel#217 might be a good reference for this.

[Dovyski]

I can work on this. I know HaxeFlixel has a way more advanced debugger than FlixelCommnity, but the plugin architecture is quite similar. I remember that everything of this feature was implemented as a plugin in Flixel Community, so maybe I could do a direct port and iterate from that.

How about it?

[Gama11]

That seems reasonable as a starting point.

Quickly glancing over that old flixel-community, I noticed you're using FlxG.mouse and keys in the plugin. Does this mean interaction doesn't work while the vcr is paused? Debugger components usually register their own Flash event listeners because of this.

[Dovyski]

I implemented everything on the engine side avoiding whenever possible anything that was connected to Flash directly, which should help us here.

The only way to stop the interaction is to prevent the update() method of the plugin from being invoked. It should nener happen because it was using the preUpdate signal to update itself, as well as the postDraw signal to render things. I never tested things together with VCR though.

As a side note, VCR was removed from the core and made a plugin in flixel-community.

[Dovyski]

I've done the initial port and at least one tool (the pointer used to select things on the screen) is rudimentary working. I have a problem with mouse visibility though.

I've tried setting FlxG.mouse.visible = true when the interactive debug is activated, but the mouse does not become visible at all. I am using Mode for development and in the PlayState the mouse visibility is set to false. If I comment that line out, the mouse is always visible.

Am I doing something wrong to make the mouse visible or is it a bug?

EDIT: my code is here.

[Gama11]

Sorry for the delay!

FlxDebugger has some special code to make the mouse appear while the user hovers over a debugger window and then make it return to the previous state after it leaves the window again. This is a bit tricky because there are at least 3 cases to consider:

• custom sprite cursor
• system cursor
• native system cursor

Anyway, this code is what's interfering with it - you click the pinpoint button while hovering over the toolbar of the debugger, and when you leave that, the previous mouse state is correctly restored. You need to add some special checks to the mouse handling code in case of tool debugging I guess.

---

I've managed to make it crash clicking on a FlxText in Mode's main menu:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
    at flixel::FlxSprite/isOnScreen()[C:\HaxeToolkit\haxe\lib\flixel\git\flixel\FlxSprite.hx:942]
    at flixel.system.debug.interaction.tools::Pointer/draw()[C:\HaxeToolkit\haxe\lib\flixel\git\flixel\system\debug\interaction\tools\Pointer.hx:75]
    at flixel.system.debug.interaction::Interaction/postDraw()[C:\HaxeToolkit\haxe\lib\flixel\git\flixel\system\debug\interaction\Interaction.hx:96]
    at flixel.util._FlxSignal::FlxSignal0/dispatch0()[C:\HaxeToolkit\haxe\lib\flixel\git\flixel\util\FlxSignal.hx:292]
    at flixel::FlxGame/draw()[C:\HaxeToolkit\haxe\lib\flixel\git\flixel\FlxGame.hx:877]
    at flixel::FlxGame/onEnterFrame()[C:\HaxeToolkit\haxe\lib\flixel\git\flixel\FlxGame.hx:543]

This was mid-state-transition. I suspect destroy() had already been called on this object, because scrollFactor was null.

---

Like I suspected earlier, your approach of using Flixel events for debugging isn't viable. There's a reason (almost) everything else in the debugger uses regular Flash event: you're supposed to be able to use the debugger while the game is paused and flixel events aren't firing.

[Dovyski]

Sorry for the delay!

No problem!

You need to add some special checks to the mouse handling code in case of tool debugging I guess.

It seems the mouse cursor problem is a bit tricky then. I don't think adding more code to the mouse cursor logic in the engine will improve things, so I will go with a custom cursor when the draggable mode is active. I can track mouse events there and position a sprite (cursor) on the screen accordingly. I can even change the cursor to indicate that one object can be manipulated, for instance. If you disagree with that, I can add the special checks you mentioned.

I've managed to make it crash clicking on a FlxText in Mode's main menu:

Yeah, I got that a lot during development. I also think it has to do with the state change. If you make PlayState instead of MenuState the starting point in the game, you can test the draggable mode properly. I'm still working on such corner cases.

Like I suspected earlier, your approach of using Flixel events for debugging isn't viable. There's a reason (almost) everything else in the debugger uses regular Flash event: you're supposed to be able to use the debugger while the game is paused and flixel events aren't firing.

Ok, I can easily change that.

[Dovyski]

I've finished the port and opened the pull request 🎉

It's possible to select (multiple) objects, move and delete them. I kept the idea of a "toolbar" (at the left of the screen when the interactive debug is activated), where the user can select the tool to use. It's not perfect, but I will not invest more time on that before checking what you guys think about it.

[Tiago-Ling]

Very nice!
Off-topic, but how hard would it be to also create an "inspector" panel, to show some properties of the selected object?

[Dovyski]

I think that is not hard at all. Everything required to implement that is already in place, it's a matter of creating the window to show the info.

[Gama11]

There are tracker windows already, you would just have to open one on click.

[Tiago-Ling]

Yeah, seems like a very nice option: when clicking on the object, some common variables could be added to the watch window. Ideally the user would be able to customize which variables appear in the window. The draggable objects together with this and other features of the debugger would be a very powerful tool!

[Gama11]

Shouldn't be added to the watch window, it should create a tracker window instead.

[DleanJeans]

Remind me of this

[Tiago-Ling]

This should definitely be integrated into the framework imho :)