[Suggestion/Proposal] Simple state machine on classes, old UnrealScript like

[JSandusky]

Simple state machine handling similar to old UnrealScript in classes, best feature of that language. When a state is active its' functions shadow those of the class.

class MyClass {
    void Function() {
        log.Print("default call");
    }

    void GoRed() { SetState(MyClass::RedLight); }

    void GoGreen() { SetState(MyClass::GreenLight); }

    void Reset() { SetState(-1); }

    state RedLight {
        void OnEnter() { // OnEnter / OnExit are optional special titles that will be searched for when the injected 'SetState' function is built
            log.Print("entered red light");
        }
        void Function() {
            log.Print("RED LIGHT!");
        }
    }

    state GreenLight {
        void OnExit() {
            log.Print("left green light");
        }

        void Function() {
            log.Print("GREEN LIGHT");
        }
    }
}

I've got a working implementation of the above with the limitations of no fields/properties in states. Still working out what the awkward cases are.

[codecat]

The SetState call feels a bit weird to me, like that function comes from nowhere. It would have to be registered externally I suppose, at which point does it make sense to also introduce a new keyword?

This could also be implemented in pure Angelscript with class inheritance, but I understand the syntactic benefit of this.

Not sure what the best approach would be tbh.

[JSandusky]

Yeah, there's a bunch of stuff being injected in the as_builder / as_compiler. SetState is auto-inserted as a generated function that looks at all the states to build the if/else blocks for the optional OnEnter/OnExit calls before setting the internal __currentState that indexes an added state-VFT. Compiler mangles variables names so: state MyState { int var; } is name mangled into state MyState { int __state_MyState_var; }. Function names get mangled similarly with the original root function being the only weirdness where it just gets moved to the added state-VFT without name mangling while the new "Do" generated function (that does the dispatch by __currentState) replaces it.

While it sounds like a lot of stuff, the SetState and dispatch function generation is like 80% of it, most of it is silly simple. The important stuff like debugger reported lines, default init behavior all stay intact as the name mangling doesn't change where things are, how they respond to object life-cycle, or were reported as being at.

I'm still working on getting inheritance working, it's all quite useless without it.

This could also be implemented in pure Angelscript with class inheritance, but I understand the syntactic benefit of this.

Possibly, but an additional object instance for each state on each object with a state machine isn't a cost I find acceptable especially once you start having to reflect and chance down object@s on the native side just to do basic serialization. Reading this stuff sucks.

While you could use static states now you've got to pass along a self object. Perhaps there's a "this" injection mechanism I'm unaware of? Native-side interrogation then depends on more plumbing because now you need to know about all the states, all the viable states for a specific class, etc so you need a bunch of registration code to be managed and kept up to date. Reading this stuff sucks.

You could possibly preprocessor/meta-compiler it as well, which is something I do to handle void Func() server { } stuff that transforms into void Func() { if (!server) return; } but I didn't consider that to be an option at scale and to cope with inheritance as well. But ehhh.

[JSandusky]

I've got this working but it's genuinely a bit a cursed problem once you hit inheritance.

class Base {
    int root = 5;
    void Do() { Print(root); } // prints 5, this function gets swapped out in the virtual table for a generated one in as_builder that handles the dispatch

    void Do2() { Print(root); } // prints 5 regardless what __currentState is

    state Alpha {
        int root = 3; // shadowed as: __state_Alpha_root, only the stuff in here knows about it
        void OnEnter() { Print("entered Alpha"); } // __state_Alpha_OnEnter
        void Do() { Print(root); } // prints 3, __state_Alpha_Do
    }

    state NotAlpha {
        void Do() { } // __state_NotAlpha_Do
    }

    // stuff out here will be using root = 5
    // that's kind of cursed, the notion of state shadowing would be ideal across the board and not as trivial as name mangling

   /* secret stuff injected directly into anything that has any states
   void SetState(int); // generated function that handles OnEnter/OnExit calls
   int __currentState; // state index
   bool __stateTransitioning; // sentinel that blocks state transitions during SetState, unsure if even needed in practice, preemptively there to stop infinite ping-pong
   int Alpha; // numbered in sequence, totally not going to stab someone refactoring stuff in the back
   int NotAlpha;
  */
}

class Subclass : Base {
    state Alpha { // legit, works, virtual table gets a new Do() override generated in as_builder and states from base are copied but then replaced with those in the derived
        int root = 1; // ERROR, tries to shadow __state_Alpha_root that is already in the base class - I can fix these easily (add class name to shadowpath, state shadowing is just a format string __state_%s_%s) but it's getting cursed and we start losing functions in the base state scope
        // Base::Alpha::OnEnter will be called - cursed issue
             // sometimes that's what you want, sometimes not, which way is the more "natural" default? A no-op is easy to write, just do void OnEnter() { }
        void Do() { Print(root); }
    }

    state Added {
        int root = 1; // this works because base doesn't have __state_Added_root, cursed
        void Do() {  Print(root); }
    }

    // injected
    int Added; // numbered accounting for baseclass # of states

}

I'm still on 2.32.0 so it'll take some time to look at differences and get it up as a commit/diff. I think it's useful, especially if you've got a hundreds of state machines to wrangle, but I don't think it's useful enough that it could actually make it in, or at least not my implementation.

I'll close the issue once I've got it up.

[anjo76]

I have something like this on the to-do list. I'm interested in seeing this as a PR that I can review more closely.

Entry in the to-do list: https://docs.google.com/document/d/1st0NAN_zQkiigxWCTEbLvpwNyYE1Q91LeGchFq8mWAw/edit?tab=t.x74qyx3dcf4o#heading=h.59u1hrx5f1cr