drakynfly / heartgraph Goto Github PK

There are some features from Plato worth pulling into Heart: better dynamic pin generation, editor features, etc
And there are some things in Heart that Plato could get.
I might just merge them at some point. At minimal, ill rewrite Heart's pin generation to more closely resemble Plato's.

Determine if any kind of network support should be handled internally in Heart.
a. Replication of node connections?
b. Replication of action runners?
Or just leave all this up to implementations . . .
Likely I'll wait until a good use-case arises with internal projects to decide this.

GraphNodeRegistrars must be added as a scanned type to the asset registry in order to be auto-discovered. A pop up should appear on engine start up if this isn't setup. (Game feature plugins do this, so copy that code!)

Support use of this plugin either as an extension to HeartCanvas in a new module, or as an internal implementation, once it is more developed, and I learn to use it.

1. All pin connections must be stored two-way, Eg, both nodes know about the connection,
2. Pin connections should not contain any pin guid not found in its pin descs, or link to any node guids not contained by the graph

Hey, first of all, thanks for your work on this project =)

I would like to ask you for an easier to understand and simpler demo project. I'm having a hard time to undestand how the calculator demo works.

Just for context, what I'm trying to achieve is:

• Define a bunch of nodes using JSON. For example, node A has three inputs (ai1:string, ai2:int, ai3:bool) and one output (ao1:Vector)
• Load the JSON containing the descriptions of theses nodes in runtime
• Allow the player to create a graph using these nodes
• Save the created graph as a JSON

Is it possible using this plugin?

Hey,
I really like your plugin from what I have seen so far. Is there a version for ue 5.0 or is it ue 5.0 supported? Im having quite some compile issues with 5.0.3 atm, a lot of syntax differences too.

Thanks a lot!

If the graph is not saved, the pins are restored upon reload. If the asset is saved, then the pins are permanently deleted, and the node has to be removed and re-added.

Why does compiling a node blueprint affect instances of it???

The CalcGraph from the Demo project has a blueprint implementation for a DAG-style graph compiler. This should be nativized for general use, probably as part of a larger system of base tools for graph compilation.

FHeartSpawnNodeCommands::GetActionByChord is a mostly stub class for creating nodes from keybinds. Right now it only can spawn comments. The editor registry subsystem should read keybinds from registries and add them here.

Potential issues

• Conflicts between registers vying to use the same chord

Use Algo's Levenstein distance for fuzzy search.

Node layout helpers that come in two flavors:

• Placement aids, e.g, snap to grid functionality, place between pins, etc
  • The behavior class determines which placement aid is used.
• An autoformatter, e.g, StraightenConnections, AlignNodes.
  • In the editor, these should be implemented the same way as normal, using UI_COMMAND
  • For runtime, everything will likely need to be rebuilt. Write these as a command function, taking in any graph/group of nodes, and dynamically re-layout'ing it/them.
    • In addition to straighten connection horizontal and vertical, make a radial layout for perk trees.

Line 1715: ensure(QueuedRequests.Num() == 0); is being tripped frequently, when dependencies are loaded for heart graphs.
Why? Aren't assets allowed to load other assets? What is different about this one.

Issue one: Visually they glitch out and become bright . . . . wtf
Issue two: Copying nodes from one graph to another is bugged. Something about external object being linked. Probably the node objects aren't being duplicated

Similar to widget blueprints there should be a toolbar button to switch to a umg preview for heart graphs that have a registered viewer setup.

This might need to be backed up be having registers that only auto-add themselves in-editor.

2D viewer should create a UMG panel in "preview" mode.
3D viewer should create a preview scene, modified from https://github.com/Sythenz/AssetEditorTemplate probably

Heart, HeartCanvas, and HeartCore should all get a stat category for tracking cpu time.
Prime targets to moniter are GetPin/GetNode-type functions, Canvas draw times, and input rerouting times.

This is to support nested categories. The current palette UHeartNodePalette only supports one level of categories.

Epic has a new experimental plugin for wave function collapse algorithms. I want to drive it with a Heart Graph if possible, for user editable generated worlds.

It'll work perfectly for serializing runtime created graphs

Basically the title.
Not fully tho, because I don't want to interfere with people using common ui's gamepad features, so more like just having features like "select on hover" flags, and such.

Probably just keep notes on how gamepad support is done for private projects and make a writeup/documentation on how it should be done. . .

Two things to consider
- generic node object type for runtime-created comments
- object may either be of the type UHeartComment_Text or UHeartComment_Image. Both would be stored in the same heart node, it's up to widgets to distinguish them.
- Copy editor authored comments into runtime as a UHeartComment_Text, and synchronize edits.