https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    So, you could ditch the substate which is likely not a good plan
  • b
    Or, and this probably works but maybe is buggy, you set the HaxeUI/flixel container to your substate instead
  • b
    I don’t want to force you to create some kind of FlxHaxeUIState that auto does that, so there would have to be some manual effort
  • b
    And then you change the container (I’m guessing) using 
    Toolkit.screen.options.container = mySubState
  • b
    Mm no you set 
    options = { container : mySubState }
  • b
    I’ll think about if there’s an easier way to do that using signals, though that would be making a lot of assumptions
  • q
    @brave-kangaroo-30399 ... where 
    Playstate.uiGroup
    is an already initialized 
    FlxGroup
    ...
    Copy code
    haxe
Toolkit.init({ container : uiGroup });
this.add(this.uiGroup);
var _ui = ComponentMacros.buildComponent("assets/ui/playstate.xml");
uiGroup.add(_ui);
  • q
    I did conceive of a few wrokarounds.
  • q
    One of them was to just create a different playstate
  • q
    But this is for a player's inventory and simple dialogues so
  • q
    You can imagine that seems non-ideal.
  • q
    If your idea works - to change the container - I am curious, is there any reason that a simple subclass of FlxSubstate wouldn't suffice?
  • q
    On create, sets container to self; on destroy, sets container to parent?
  • b
    Container is a FlxGroup so any FlxGroup will work
  • b
    I do this when I swap states so I assume it’ll work here
  • q
    Under the hood, I assume init can only be called once per application.
  • q
    I hadn't had call to check.
  • b
    You’d have to play with it, but HaxeUI also can have multiple UIs that you hide and show as needed
  • b
    But yeah play with it and let me know what happens
  • q
    Hiding and showing is an option for an alternative to full substates.
  • q
    It seems... anathema.
  • q
    I guess I mean, it seems to run counter to the notion of flxsubstate, to instead show/hide ui as a substate implementation.
  • q
    Under what conditions does haxeui ignore input? Any that are easy to set?
  • b
    im not flixel expert, but i would have expected haxeui to be using something like this
  • b
    Main.hx: Toolkit.init() (once) State1.hx: Create ui whateverway, then just add to state (.add) State2.hx: Create ui whateverway, then just add to state (.add) ..
  • b
    is that not something that works? I mean, i guess you could call init over and over again, but i dont think you'd need to seems that you are only doing that to use a different, flixel specific, 
    { container : uiGroup }
    ?
  • q
    State1 can have substate1 which is a child; while substate1 is active, [the rest of] state1 is supposed to be inactive. Typically in Flixel substates are used for pause menus, inventories, etc.
  • q
    What you seem to be suggesting, on its face, should work. However, it doesn't fit the use case or one of the major, normal behaviors of flixel development.
  • q
    If HaxeUI can replace pause menus in Flixel - great! There still needs to be some model for pausing the rest of the state while that's in place. Some child of flxsubstate makes the most sense.
  • q
    The problem I had was that HaxeUI's state1 UI was still active while substate1 is present.
1...293031...1687Latest