Telepathy's copy paste odd behavior

Grasshopper
1

Hi @andheum and @marcsyp, sorry for bothering, I’m experiencing a weird behavior on your awesome plugin Telepathy with the current Rhino release Version 8 SR11 (8.11.24254.15001, 2024-09-10) on Windows

whenever I Ctrl+C Ctrl+V a Telepaty Sender, the newborns do not automatically connect to their own receiver
the only way to have those connections to appear is to somehow rename either one of the same senders or the receiver into itself, like deleting a character from the Parameter name and re-typing it back (enable/disabling any sender/receiver will produce no results)

brief video of the odd behavior:

I am not completely sure when that started happening, but my best guess is that it started on the very last Service Release

Until 10 minutes ago I had the Food4Rhino Telepathy version 1.0.0.0 dated 2017

I just updated Telepathy to the latest available version on PackageManager, V 1.0.1, but it did not solve the issue

at this point I’m also very curious if anyone else is having the same behavior, or if it’s just me :upside_down_face:

[edit] I’m adding more info as I’m doing some tests, still Windows + Rhino 8 SR11 (8.11.24254.15001, 2024-09-10) + Telepathy 1.0.1

when a file is saved, closed and reopened, all the Telepathy wires are working correctly even if they were not before (this is actually an awesome workaround at the moment :+1: )

same machine, Windows + Rhino 7 SR37 (7.37.24107.15001, 2024-04-16) + Telepathy 1.0.1
all works as expected

System info

Rhino 8 SR11 2024-9-10 (Rhino 8, 8.11.24254.15001, Git hash:master @ d3c11108eae09fadc146928ba51b9b182a05303f)
License type: Commercial, build 2024-09-10
License details: Cloud Zoo

Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 32GB)
.NET 7.0.0

Computer platform: LAPTOP - Plugged in [100% battery remaining]

Non-hybrid graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 2080 (NVidia) Memory: 8GB, Driver date: 4-2-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 552.12
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
Primary OpenGL: NVIDIA GeForce RTX 2080 (NVidia) Memory: 8GB, Driver date: 4-2-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 552.12
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port

Secondary graphics devices.
Intel(R) UHD Graphics 630 (Intel) Memory: 1GB, Driver date: 6-1-2021 (M-D-Y).
> Integrated graphics device with 3 adapter port(s)
- There are no monitors attached to this device. Laptop lid is probably closed

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 4-2-2024
Driver Version: 31.0.15.5212
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8 GB

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.11.24254.15001
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.11.24254.15001
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.11.24254.15001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.11.24254.15001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 8.11.24254.15001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.11.24254.15001
C:\Program Files\Rhino 8\Plug-ins\Grasshopper\GrasshopperPlugin.rhp “Grasshopper” 8.11.24254.15001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.11.24254.15001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”
C:\Users\innoi\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\PanelingTools\2024.8.20.677\PanelingTools.rhp “PanelingTools”

2

copy/pasting within a definition works fine here (8.11.24254.15001, 2024-09-10 + telepathy 1.0.1) as well it does on R7. It’s only when I paste a receiver with same name from another document it doesn’t link up

3

oh wow, ok, thank you for trying that!
are you on windows 10 or 11? I’m on windows 10

I think it’s time to turn off all my plugins one by one then and see if there’s something that interferes with Telepathy then?

I really have no idea :slight_smile:

[edit] by using GrasshopperLoadOneByOne I said NO to all the Plugins but Telepathy, I said no also to the basic Curve and Surface ones which I believe are vanilla, Telepathy was the only plugin that was loaded, and the problem still persists

image
image750×1000 39.8 KB

also tried GrasshopperDeveloperSettings, both checked and unchecked (I keep it unchecked) it doesn’t solve the problem either

image

Installed the latest Candidate Service release Version 8 SR12 (8.12.24268.13001, 2024-09-24), did not make any difference

4

windows 11
Edit, sorry, i misread and can confirm i have the same behavior as you describe in R8, works in R7

I initialy copy/pasted the receiver, not the sender

5

ohh, nice and bad at the same time :smiley: at least I’m not alone :upside_down_face:

6

@AndyPayne do you know if something has changed that might cause this issue?

I can repeat the issue, but also found another workaround: double clicking the sender. It does involve deleting the generated extra receiver though.

7

oh this is awesome!

I don’t know if this will help circumscribe the issue, but when you actually double-click on one sender, a receiver gets created (and that has to be deleted by hand, I’m fine with that…) but the great thing is that it actually triggers the connection of ALL the other Senders on the canvas at once, not just the ones that was double-clicked!

quick visual demonstration:

8

in Version 8 SR14 (8.14.24325.13001, 2024-11-20) -which I believe is a release candidate- the problem returned back :upside_down_face:

the problem was not there in the last stable release, but it re-appeared with this very release candidate

the old solution -to just drop a new sender on the canvas and manually trigger it- still works fine tho, it’s just not automagical as it should be :+1:

9

@Gijs problem still present also in Version 8 SR14 (8.14.24332.15001, 2024-11-27) that I installed a few minutes ago

10

sorry @Gijs @AndyPayne, this is still present in last release Version 8 SR15 (8.15.25007.13001, 2025-01-07)

the workaround of double clicking the sender to trigger genereating an extra receiver (to be deleted) still works

13

@Gijs @AndyPayne in R8 Windows Version 8.30.26103.11001, 2026-04-13 telepathy does not work anymore

until maybe 2-3 weeks ago, double-clicking one copypasted random sender was updating the whole definition and rewiring all the new copypasted senders to their respective receivers (see video in my above reply)

with this version doubleclicking a sender does nothing at all, which is a big problem, at least for me :slight_smile:

omg, this solved the problem completely for me <3 Telepathy S thank you so much @dfytz1 !!!

14

Hi

Why are you trying to define the same sender multiple times?

One sender to multiple receiver is ok, but the same sender being copied seems weird.

Is like when in coding you define a variable.. if you repeat the definition it’s like if you are updating it (but not actually updating), but the variable is still one

I don’t think telepathy is meant to be used in this particular way, so maybe it is why the behaviour looks bugged/inconsistent

15

it worked fine until a few weeks ago :slight_smile: see this video:

as brief explanation imagine I have a part of the definition that creates some data, and that block of components can be copypasted multiple times in the canvas in such a way you can tweak some sliders and the sender of each block keep sending data to the same outputs

in reality, that parts that is copypasted around has both multiple receivers and a dozen of senders

the general issue solved by Telepathy is that, when you copypaste stuff, the main input-wires gets duplicated but the output-wires don’t (of course)

with Telepathy, the senders keep sending data to their connected receivers even when they are duplicated

16

I get it but i still think it’s weird or not the way it is supposed to be used, but if it works is fine :slight_smile:
It is like the receiver automatically merges all the data coming from senders with same name: as long as you are sure the order of merge is always the same for every receiver after the blocks, it works. Could it be that if you refresh the script, or modify something in just an instance of a sender in just one block, the order of the merge is not consistent anymore within all your blocks and you break the logic (you mismatch the parallel data and you may even not realize it)?

17

yes, what you described might eventually happen, but in my case is avoided by wrapping data (Metahopper’s Wrap List) with a sort of unique header/identifier before it goes through the various senders

that way we make sure each block of data is unpacked and recognized correctly regardless of the actual order in which it’s trasmitted/received

18

from a quick test it looks like it keeps track of WHEN a component is created and the automatic merge in the receiver is in this order, so the order can break if u delete and recreate a sender in one of the blocks after copy/pasting