[niram games]

Okay, thanks for the help!

[niram games]

Hello.

I like those ideas! The super minimap sounds especially ambitious, but I agree that it might end up quite messy in the end.

Thanks and good luck with creating it!

[niram games]

Got it, thanks!

[niram games]

Hello.

I am also getting that same error. But I don’t think it is related to entering PlayMode(I might be wrong). I get it whenever I reload the domain(when the Reloading Script Assemblies window appears). I use Enter Play Mode Options and have domain reloading turned off and it doesn’t appear when entering Play Mode, only when reloading the domain. Could you try it and see if it’s the same for you?

Here are my repro steps:

1. Make a new FSM.

2. Create a custom ActionTask.

3. Assign that action to a node in that FSM.

4. Override the info property inside that ActionTask.

5. Write code that encounters a null reference exception(any kind of exception will probably work) before the return statement inside the getter of the info property.

6. Recompile. A bunch of errors will appear(as they should). The Node with that action assigned will look all weird.

7. Fix the code so that it always returns something.

8. Recompile. The errors in the screenshot will appear, even though your code is fixed. The errors will appear whenever you recompile(reload the domain) for the rest of that Unity session(if the Canvas window is visible).

Hope this helps!

Attachments:

You must be logged in to view attached files.

[niram games]

Hello.

I don’t think it’s necessary for the overview window to be a fully featured graph editor. The only necessary controls I can think of are zoom and pan. I’ve been thinking about this feature, and I imagined it working like this:

If you have an FSM owner with an asset FSM attached, and the FSM has sub-behaviour trees A and B, you could open one of them using breadcrumb navigation and then somehow create a new window to watch that sub-graph. Now, at runtime, that window would display the state of the nodes in that sub-graph for the currently selected graph owner, and if you change the selected graph owner, that window would display the same sub-graph, but for the new graph owner(who might have other nodes running). So you can debug any agent in the same way. Now, this raises an issue: what if you select a graph owner that doesn’t have the same FSM asset attached? Maybe display a message in the window that the currently selected graph isn’t appropriate? That seems a bit specific to that kind of workflow.

Another variant would be a window that displays the currently active sub-graph(if any) of the currently selected graph. So you could just select the FSM owner and see the BT that is currently relevant. But that is also quite specific to the workflow that the two of us are using. Also, what if multiple sub-graphs are currently active?

Let me know what you think about these ideas. How would you approach these problems?

When it comes to the GUI I would like it to look the same as in the main graph editor, for consistency’s sake and also because the graphs in the canvas window look absolutely beautiful. This is the most aesthetically pleasing tool in the Asset Store, even above Amplify shader editor. I just want to plaster my whole screen with different graphs. IMO, it looks better than a lot of the 2D and 3D assets in the store too. 🙂 I do understand your concern with performance though, and I can respect it. I would like it to present more information than the minimap(overriding the info property has been really handy for making the graphs more readable, so at least displaying that would be nice). Whatever design decision you make, I trust that it will be a good one, considering your work so far.

Also, If you don’t mind me asking a bonus question in the same thread:

Do you have any experiences in the industry that have inspired you to create such a practical and well-designed tool?

[Author]

Posts