Improved Error Feedback for 'secondary' errors in editor

I would love it if the red error box feedback could be differentiated between primary sources of an error (the location where there is an error in the actual patch) and secondary sources that just contain references to the primary object in error.

Because sometimes one small error on a common object can make your entire application turn red which does not help tracking that issue down.

In the scenario in the image it would be great if the ‘secondary’ objects had some differentiation like a red dashed outline?


Same / related:


Understood. We’ll tackle that. Sorry for the inconvenience!


We reviewed the topic.
The storytelling now goes like this:

VVVV is unmatched in its combination of

  • letting you express yourself in a language that detects typing errors early and thus is able to guide you with typing errors on links and data hubs, while
  • still letting you iterate fast by being able to test those parts of your program, that don’t have a problem

So that’s our insight: You want the errors in order to be able to track down potential bugs early, but you also want to be able to work and test refactored versions of your patches before solving each and every single issue.

But you are completely right, that red node applications and red node definitions all over the place are not helping when it’s about

  • finding the actual issue
  • estimating the real amount of problematic patches

We, therefore, now mark patches as red if they contain errors. They still partly run. But to find the error we figured you want those nodes to show up in red. All the others, that are further away from the initial issue - nodes that only use nodes that have errors inside - are now considered as worth having a look at. Thus we put a warning on them (making them orange).

From a definition perspective, we mark Categories in red that contain red definitions.

1 Like

Can you add what the quickest way to find the location error is? How to know where the definition with the error is? Especially if the definitions are placed deep in the runtime patches themselves.

1 Like

Yes, we will.

Edit: Wait I think I read that wrong. Yes, we will add the one or other UI idea that directly lets you jump t the source(s) of the problem.

What you actually asked for: We didn’t test that thoroughly, but the intuition was that finding the error already is much easier than before.

  • on definition side: only the definitions are red, which have an error. Or categories that have definition that has an error.
  • on application side: if you have one orange and one red node next to each other, you better go into the red one to find the actual problem.

Anyways: We are absolutely aware of an error view or a shortcut missing to easily jump between the actual issues. Please stay tuned for that.

1 Like

I just send Elias a project (concerning another issue). The patches there have a lot of cyclic dependencies. Try creating an error somewhere deep inside one of those patches and then hunt it down.
Should be a good test case.

1 Like

Unrelated to the tasks on our side:

I didn’t have that deep look at your project yet, but I am wondering if you ever tried to get rid of those cyclic dependencies?

I can only imagine that on a project of some larger scale rearchitecting the system is a very difficult task… But might still be an interesting exercise to at least try it on paper. What would be possible - in theory?
The thing with everything depending on everything is that it’s getting harder and harder to change bits.

If this is infeasible there is yet another thing that could lead to less cyclic dependencies:
Find one or a few types that you often use to hop from one system department to another. Try to do those hops via interface calls. Your patch now depends on the interface, but not the implementation. When done on a central type this abstraction could immediately give you

  • faster compilation time
  • less orange nodes

But these are just ideas for stuff you could try independently from us. We still tackle the topic from our end.

I appreciate the improvements so far in 2022.5.0. The ‘error is deeper’ functionality is already a big improvement. I also agree that best solution would let you jump to the error, possibly from a list like an ‘error explorer’. (Or from an error highlight on the solution explorer?)

In terms of the proposal to adjust architecture to remove cyclic dependencies, I think on most jobs that is going to be architecture priority 4 or 5 at best.
Realistically on a rapid prototyping job I will not have the time to achieve priority 4 or 5.
If my application is to process FOO and BAR then I’m simply going to reference those definitions a lot.
Adding an interface and casting abstractions iFOO and iBAR generally takes me further away from understanding how data is flowing through my application and what could be going wrong.

But I will give it a try next time I’m at that point and will add that experience to this discussion


I want to highlight that this is already so much better now. You immediately see what node/definition you need to check.

Yes, 100% agree, I’ve never worked on a real-world project that even reached priority 3… It is important to differentiate between developing a library for reuse by others and an “end-product” with an approaching deadline. The rules and what kind of consideration goes into the architecture are quite different. The final software is/should be allowed to break any rule and use whether works in the shortest amount of time (also considering the skill of the developer).


Love the new error reporting. So much better. Just found a case where it failed though. See here: Stride GPU Particle example broken

The error is not shown in the root patch, but only one level down.

This is in 2021.4.11-1338. Maybe it got fixed in the stable version?

Related: Latest 5.3-previews are shipping with a new Error View (Ctrl+E) window. It is still in the works but already available for testing.