User:Yosh/Workflow and design

generally this is how I go about designing things in resonite & my workflow in doing so.

Workflow mods

generally used to save time & navigate a large/unfamiliar project

• YAP - fuzzy picker for components/nodes
  • note: I make this mod primarily for myself and consider it "feature complete" for my use case. if you want to use it, you have to compile it yourself. alternatively, nepushiro made a port for bepisloader with a few more features.
• ProtoFluxContextualActions - little "suggestions" when pressing secondary while dragging out impulse/value wires in flux
• DefaultToolOverride - override the desktop 1234567890- tool buttons with whatever you want. I use - for the snapping protoflux tool.
• ReferenceFinderWizard - adds a wizard to search for references to any particular element. mainly useful when exploring unfamiliar/large systems to see what points where. it has a neat shortcut of when you press secondary while having a reference held with a dev tool, a context menu option pops up for finding what points to it.
• ComponentSearchWizard - search for components under a specific slot. it has the same shortcut as ReferenceFinderWizard when dragging out a slot with a dev tool.
• EnumDropdown - adds a dropdown for picking enums in inspectors/nodes
• BetterGlobals - makes working with global values/references nicer. a bit niche if you don't retrofit your workflow around it, but there's no reason not to have it imo

Variables

An example of an "exposed" variable and architecture of variables. The GlobalReference<IValue<T>> bit is not recommended now, as I found it to be clunky to use as opposed to the normal handling of global references for source nodes.

• only use dynamic variables when wanting to expose something for others to interact with. they're quite clunky to manage for internal systems, and it makes usage inconsistent with locals/datamodel fields/etc.
  • when using dynamic variables, place the DynamicVariableSpace on the root of the item.
• Variables slot in the root of the project. Exposed and Internal slots as children of this.
• a variable is the Value/Reference field of a ValueMultiplexer/ReferenceMultiplexer respectively. this is to make it very easy to tell what that variable affects by looking at the drive list and finding references to the MultiDriver value field.
  • if it's a variable not meant to be used by the outside world, they are a child in in Internal. the slot name is the "name" of the variable.
  • if it's a variable intended for dynamic interaction with other things, they go in Exposed and a DynamicField/DynamicReference points at the MultiDriver value.
    • Dynamic variable names are always OnlyDirectBinding and follow username.Thing/variable_name (e.g. yosh.TileTool/vis_mat) to prevent accidental conflicts. copy this name with a ValueMultiDriver<string> to a GlobalValue<string> for usage in protoflux and the name of the slot for easy viewing.
    • interact with exposed variables directly only; never use the dynamic variable writing nodes for purely internal systems unless, well, you need to interact with something that works with your thing dynamically.
  • I experimented once in using a DynamicReference<IValue<T>> (or SyncRef<T>) so that all Source nodes could use the same global reference, but this is a bit of a hassle to manage. any situation where the global itself is deleted will need to be fixed on all source nodes regardless, it's very unergonomic to create new source nodes from said reference, and it means to see all places where a variable is used, you must find the references for two separate elements—the MultiDriver field and the global component—rather than just the MultiDriver field.
• create variables for things that you may need more than once and/or is expensive to compute. from then, all it is is a source node to get the variable.
• if a variable is "driven" by something else, put the drive code on the variable slot itself. this means you can disable calculation of that variable for users who don't need to calculate it, making everyone happy.

Dynamic impulses

• naming scheme: username.Thing.impulse_name
• prefer not to use dynamic impusles for one-shot code in favor of simply delegating more space. they should generally be used for code that's called from multiple places.
• put the code of the dynamic impulse on its own slot. on that slot, make the GlobalValue<string> of the receiver name as well as the slot of the receiver if so desired.
  • use these with GlobalToOutput when referring to the dynamic impulse
• generally should write back to the "centralized" variable register. the written-back variable should be self-valuecopied such that no networking is done.
  • thought while writing: 3rd variable slot of Internal returns specifically?

Globals

• whenever reasonable, separate out the usage of a global from where the global is defined
  • reasonable: dynamic impulse tag names, raw data tool reference, etc.
  • not reasonable: source nodes