Dirty COMP flag adjustments

The Problem

I’ve built a few different varieties of TOX saving and externalizing tools over the past few years, and recently have revisited using the .dirty flag on COMPs. One sticking point here is that a COMP that contains another externalized COMP will be marked dirty if its external child contains changes.

Here’s an example work flow:

project hierarchy looks like:

/project1/base_some_component (external)
----/project1/base_some_component/base_some_child_comp1 (extneral)
----/project1/base_some_component/base_some_child_comp2 (extneral)

Changing the op:
/project1/base_some_component/base_some_child_comp1 marks this op as dirty, but also marks its external parent (/project1/base_some_component) as dirty.

When it comes to tracking changes / knowing when an operator needs to be re-saved this presents an ambiguous scenario. Ideally, I want one developer to be able to work in /project1/base_some_component/base_some_child_comp1 while another works in /project1/base_some_component/base_some_child_comp2. While each dev may have only made changes in their respective components, using .dirty to inspect components would lead them to believe that their component workspace and its parent are both dirty.

example file
dirty.zip (5.4 KB)

My current work-around is to build a hash table for all external ops at start, then rehash and compare when saving. This works reasonably well, but currently I only track operators and parameters… leaving op connections, position, color, etc as changes that aren’t currently supported.

That’s a passable band-aid, but not great in the long run.

The Ask

Change the .drity member (or add another) to reflect the status only of the contents of a COMP and it’s non-external children.

Bonus Ask :grimacing:

Include a dirty indicator when inside a component next to its external comp status:


This is particularly an issue in git when merging between branches. If I just save everything dirty all the way up I can hit a merge conflict when it isn’t actually an issue. Either I have to track each file that I touched or I have to accept merge conflicts as part of my workflow and do a side by side to confirm.


+1 for this or other similar solution for managing external tox changes. In our Tox Tools in The HQ PRO we used the dirty flag to mark in a UI which external components might need saving. We’ve had reports from macOS users that it can be finnicky on macOS specifically. Also sometimes it seems like sometimes on Windows it also doesn’t always feel rock solid. Improvements on the dirty flagging or another solution for better managing changed states of external toxes would be great. I think @dylanroscover would have some thoughts as well, as he’s built a few externalizer tools.

1 Like

Jup, thats a big ol +1 from me.

On the other hand, changing parameters does not mark them as dirty. This is, in general expected and good, but for example adding a custom-parameter should mark the component as dirty.

@raganmd really like the idea of hashing the component to check for a dirty-status.


ooh that visual dirty indicator sounds spiffy

1 Like

Another big plus 1 .

And a similar issue. A COMP is also flagged dirty when text DAT (that is synced to file and defines an extension) is externally edited .

1 Like

Same here. So far we need to manually manage a collection of all externalized COMPs and monitor their dirty flag (usually by checking every frame) .

Maybe this would also be a good time to simplify the creation of such tools? Opfind DAT to support flags ?

Some kind of indication is def a welcome addition. Esp inside the component. I put in a little widget into the default UI to get a good glimpse of if something is dirty or not:

If we are on the topic of that, anyone knows what kind of timestamp the externalTimestamp is refferring too?

externalTimeStampTime (Read Only):

Time stamp of the external tox file when it was last saved or loaded.

1 Like

Hey folks,

Just acknowledging reading all those comments.

We are aware that the dirty flag got some limitations at the moment.

I encountered some of the same issues listed here myself in the past, and also had designed a tool like some of you did.

I’ve listed all those good comments internally as an issue / RFE.

No ETA on when some work will get started, but we will try to overhaul this and confirm that the feedback here is taken care of.



Where did you find externalTimeStamp documented? I’m using it in my toxmanager but realized I have no idea where I found a reference to it. I can’t seem to find it anywhere on the wiki.