Your comments

yup. Google whatever you want to do, note down the Methods they're using, make sure you have the right Class/Type (you may have to add them in Type Options if its not one of the default ones) and throw them all in to Bolt. And at that point its just logically connecting dots. 

Personally I also prefer checking out the Unity API because it provides a lot more context, and is an easy way to discover potentially better suited methods. But some people would rather just use the Fuzzy Finder in Bolt, plop down a bunch of similar enough sounding methods, and common-sensing it out. Which is a legit way of doing things, especially in the beginning when your coding-fu is still weak.

The Discord is used more as the de facto repository of knowledge for Bolt (there's a search!), but here goes:

1) One point of Bolt is that for a lot of non-programmers, coding is very difficult to parse. Bolt provides a visual backdrop that makes it much easier to visualize the code, breaking it down in to simpler bits to parse in the process. (also, even if Bolt is not for you, you'd have to learn how to use a different tool regardless) Human Naming is also there as an extra step to make parsing even easier.

As for recommendations on how to progress, break a mechanic down in to a step-by-step list of what you want to happen. Be as detailed as possible. If you want something to, when you click it, expand, then after 2 seconds change colour and be replaced by an explosion sprite for instance? You can start searching for, and throwing in all the nodes you'd need for that: pointerDown, scale, waitForSeconds, Tint, setSprite are what those bring to mind. Once those are just lying in your graph, you connect a Flow of what should happen before/after. Then you just fill in all the needed inputs. In this way, you don't actually need a full understanding of what all that code does, you're just throwing in stuff you need and filling in all the inputs it requires. etc etc. Until everything works! (or you realize you actually wanted it to work in a completely different way ofc) And over time (with help from the Discord) you'll gain expertise on how Bolt itself works.

1b) I still say that that's one of the strongest pros of Bolt. That if you can break it down, you can build it. In a sense, the only difference between an easy mechanic and a hard mechanic, is if you can break it down (just in conversational terms) enough in a systematic way where everything still works.

2) Bolt works fine side-by-side with C#. Due to reflected units, you could get someone to code something for you, and you can just plop it in to Bolt, deciding on when it should happen / what parameters it should be taking etc. Same with most plugins and assets. (with some limitations such as Delegates, generics, which you'd need to write a wrapper function for, or wait for Bolt2) The Variables and Events systems are also exposed so a hired coder could take advantage of that as well.

3) Bolt is basically C#. Anything that can be done with C# can be done with Bolt. Except for Delegates, Inheritance, etc. But you can find workarounds for all that. Speed might be a concern for computationally heavy stuff though, recreating A* Pathfinding or mesh deformations in Bolt might not be a good idea for instance. In both cases, just finding an asset (or coding it) and triggering them in Bolt gets around those issues entirely.

4) My understanding is that it is literally the same as C#. No performance hit at all as it turns itself in to C# code before you run it.

That would explain the inconsistency of it only _sometimes_ working..

Is there no way to create a work-around? Even during the game jam I was using upwards of 5 tabs and kept forgetting some of them due to Unity restarts. Some way to save the state of each Graph tab, then on restart iterate through all Editor Windows of type <Graph tab>s? Even if it might be in the wrong order? No idea how it works under the hood, but though its a relatively minor issue, its so annoying to have to face it again (almost) every day..

Not sure if I understood correctly, but the Community addon has a Manual Event that you can trigger in Editor with a button on the Graph. Not sure if that fits your use-case or not though.

I think its fine to assume you've stopped creating a connection if you start messing with the graph inspector settings. Seems like unnecessary work to preserve such a niche "feature" after all.

So long as you the Bolt graph doesn't suddenly go blank from a seemingly innocuous action I think its a definite win :P

Hmm. Today's the first time this has worked for me (graph tabs remembering on Unity startup) in the past 2 weeks (at the very least). Haven't updated anything. So I guess this feature was already implemented but just isn't working all the time due to Unity reload shenanigans..

That's really cool in terms of finding where all your super units are! especially the distinction between graph/macro. A dedicated toolbox is also pretty cool, currently using a separate Graph tab to organize all my useful custom units.

That said, I guess I'm just fixated on the idea of a hub for organizing and linking to all our graphs and points of interest.

I'm just imagining something with your Find functionality, with all those options, but as a Unit with a button on it (similar to the manual trigger community unit). Then just putting them all in a separate Graph tab (or shelf) to be organized as you will. With in this case empty super units acting as reference points instead of Comment units. Which is the functionality I'm kinda getting at in the initial post. (if you ignore the problems of the graph not opening in a new/different Graph tab, and the problem of multiple results of course :T )

But that might be a better suggestion, reusing the tools already present in Bolt rather than making yet another window to house them.. It'd have to be done manually, but that's a small price to pay for organization honestly.

That's.. weird..

I know I've used that a bunch in Bolt 1.4 and I find no reason why they might have removed it in 2.0...?

Wouldn't [Transform: Child Count] be easier/more-effective? (I'm assuming anyways)

While slightly different, I think mine is a related issue, but in 2018.3.7f (1.4.2 net4) creating a variant prefab would have the variant lose Object Variables and the State Machine reference, no matter how many time you apply/revert changes.

Updating to 2018.3.12f1 seems to have fixed it, putting down repro steps in case it helps.

1. Make Cube Gameobject. Attach Flow/State Machine. Set an Object variable test = 10
2. Drag in to Project to make Prefab
3. Change value of test to 200 or something
4. Drag in to Project and make it a Variant Prefab.
5. (I forget if you need to instantiate a new Variant or if it affects the current one in the scene)
6. Check Variant. All object variables are missing. Flow Macro reference may be missing, or the component may be empty altogether.