[addon] Names ___

#1

https://github.com/ChrisRaven/FlyWire-Names/raw/main/Names.user.js

This functionality was previously implemented in its basic version in the Utilities addon.
But the code grew a little bit, so I’ve decided to move it to a separate addon.

The addon allows you to assign names to fragments (thanks @bl4ckscor3 for the idea!)
To add a name, Ctrl + right-click on a segment’s ID. A popup should appear. Enter there the new name and click “Save”.
The name will stay after refreshing the page.
When you split a named cell, both parts will have the same name.
When you merge cells:

  • when none of the cells were named, nothing changes,
  • when one of the cells was named, the merged cell will have the name of that cell,
  • when both cells have names, the new cell will be named “cell1name+cell2name”.

If you want to get rid of a name, edit segment’s name and delete everything in the name field (leave the field empty) then click “Save”.

Currently it doesn’t work for cases, when you remove and then readd a cell, but I might be able to make it work.

The names exist only locally. I’ve tried hard to make it work across the Internet, but to no avail. I’ve spent 3 days on this and was able to save the names to the json state server, was able to retrieve the information, but there was no way to tell, from which state I should read to get the correct information.

If there’s a need, I can make it that way, that you’ll be able to click a button, which will generate a string and copy it to the clipboard. You can then pass the string to another person and that person would be able to paste it to an input and apply the names. But for now, it doesn’t work like that.

You might also need to update the Links addon. The reason is that, I’ve decided to make this script (Names) also work using the IndexedDB mechanism. Because Links was already using a library for that, I’ve decided to move that library to the Dock, to make it available for all the scripts.

As usual, things may not work correctly or at all. Report any issues, if you find anything,

Enjoy :slight_smile:

6 Likes
#2

v. 0.1.1
Fixed the situation, that you could ctrl + right-click everywhere on the site and the Change name dialog was appearing. Now it works only for the segments in the right tab, as it should be.

1 Like
#3

This is really fantastic! I asked Sven if he can think of a workaround for local only storage. This would be useful to be able to share.

image
image1858×1128 152 KB

2 Likes
#4

If there was a place in code, where I could’ve read the initial shareable link, I could probably make it working. Currently it works that way, that when FW is opened from such link, the link is used for read in all the important data and then “forgotten”, and the scripts are loaded “long” after that. If I had that initial link, I could read it again via the script and read all the additional data (names).
I know, such links exist in the internal history of FW and I can read them, but I didn’t find a way, to tell, which one of the hundred or so links is the last one or, to be more precise, the one with all the data.
But still, that would only work for people using the script so all the other users, wouldn’t see the names (but nothing would be broken for them).
There’s also the problem, that the names would by available for others only by sharing the links. So, if somebody would change the name of a cell, and someone else would open the cell (e.g. by double-clicking it in 2D), the other person wouldn’t see the name. In other words - the names would be assosiated with states and not with the cells.
Yet, even in the current form I think, the script is useable. E.g. for local analyzing some circuits, or to make some private collections or to mark, if we’ve already check a cell from some batch or not.

1 Like
#5

I made a demo video of the connectivity app for some researchers this morning and I hope that you don’t mind that I plugged your addon :slight_smile:

3 Likes
#6

I don’t mind at all. That’s great! Thank you :slight_smile:

2 Likes
#7

v. 0.1.2

Now it works also in cases where you’ve removed and then readded a segment (no matter, what way you used to remove it). Still doesn’t work for outdated cells.

1 Like
#8

Thanks, helpful addon!

One bug I’ve found - I’m finding that splitting is not retaining the name of the previously split segment. Both new segments revert to cell ID numbers. I’ve updated to the latest version.

2 Likes
#9

Hmm, interesting. I’ve just tested it and it works correctly here. I will be looking for reasons, why it might work incorrectly in your case.

1 Like
#10

Ok, I was able to reproduce the problem. It was working when I was using the simple cut (C), because it was easier to do during testing. However, with multicut it doesn’t work. I’ll work on it.

#11

Thanks for doing the bug fix! However, when I was testing it I was using simple cut, not multicut. Do you think maybe another script could be interfering? I have a bunch activated atm

1 Like
#12

I usually have most if not all of them activated (but turn on and off some during testing).
It teoretically could be an interference, but I think, the problem is simpler - currently the Rendering tab in the right panel has to be active/visible to make it work. At least, that’s what I think is the reason for the error.

#13

v. 0.1.3

Now it should also work, when the Rendering tab isn’t currently active (it just waits, until the tab will be active and then show the changes).

Also, when merging two cells with the same names, the new name would be just the name of one of them, and not “name1+name2”.

3 Likes
#14

v. 0.1.4

When cutting/splitting was the first thing you did on the segments’ list after refreshing the page, the addon didn’t work correctly. This should be fixed now.

1 Like
#15

There’s a conflict between Names and Permanent Colors (possibly other features too). The problem is in the FW code. I’ve already reported it on GitHub, but until they correct it, the Permanent Colors might not stick.

The error is that the FW code used by Permanent Colors uses the displayed value of a segment ID and not a value existing in the background, so changing the displayed value to something else causes, that that code no longer sees a proper ID.

Maybe I’ll be able to find a workaround for it, but I can’t guarantee it.

3 Likes