Really weird behaviour when changing Start Node

[async0x42Participant]

I have an FSM I was creating for an example, but after creating a new start node, it bugs out on me, attached are the steps I can, and are reproducible.

Step 1: How the graph was
Step 2: Create a new node
Step 3: Set new node as Start -> Glitches, sets my last node as black
Step 4: Attempting to MOVE the new start node, results in the last node moving instead

The problem/solution: The transition states, if I delete one (either one), then I’m able to create a new node and set it as the start properly.

I’ve also attached the pre-glitch JSON export, and the post-glitch JSON export, as a note, the canvas changes after exporting the post-glitch, and I’ve attached a screenshot of what happens (the black node and the new start node kind of merge and are tied to each other)

[async0x42Participant]

Only allowed 4 attachments, so here’s the rest (Edit: Apparently if you edit the post, it merges the previous uploads if you add new ones! Next time I’ll just edit/add attachments to the original post)

[GavalakisKeymaster]

Oh 🙂
This is an old bug, that sliped away from me.
It basicaly has to do with IDing the nodes.

Thanks for the reminder and the detailed steps provided. I will have to fix this soon 🙂

[async0x42Participant]

No problem, glad to help!

[async0x42Participant]

Just to elaborate on this issue, I’m getting it in another situation too, attached are the two steps for reproducing it on my end.

Setting the start to a new node that isn’t attached to anything causes some to black out.

Edit: I’ve actually encountered this with a 2 state looping FSM that I added to the example shown above, and when CTRL-Z undoing and CTRL-Y redoing something, the two nodes got mashed and turned black, even without setting anything to Start. (Attached are Example 5 and 6)

[GavalakisKeymaster]

Hey,
I am still taking a look a this. Thanks for the info.

[Author]

Posts