In pre H22 it was possible to create a copnet directly in "/obj"

If I try that now in 22.0.429 it auto creates a geo node wrapper, so you get "/obj/geo1/copnet"

that kind of breaking for me.. is that a bug or intentional?

This is intentional. A "copnet" at /obj causes confusion as it isn't a proper object, so can't be displayed. Also, lacking an enclosing SOP network, a lot of workflows that work in 3D get tripped up, necessitating moving it to /obj/geo1/copnet later anyways.

If you want a copnet that isn't living in a 3d space, you can create one in /img.

If, however, you really need the copnet in /obj, it is still there, just hidden. In a textport,
cd /obj
opadd copnet
will create one. You can create a tool macro to make it as well if this is a common workflow.

But I would like to hear more about why /obj/copnet is required for your workflow, vs /img/copnet or /obj/geo1/copnet.

jlait
This is intentional. A "copnet" at /obj causes confusion as it isn't a proper object, so can't be displayed. Also, lacking an enclosing SOP network, a lot of workflows that work in 3D get tripped up, necessitating moving it to /obj/geo1/copnet later anyways.

If you want a copnet that isn't living in a 3d space, you can create one in /img.

If, however, you really need the copnet in /obj, it is still there, just hidden. In a textport,
cd /obj
opadd copnet
will create one. You can create a tool macro to make it as well if this is a common workflow.

But I would like to hear more about why /obj/copnet is required for your workflow, vs /img/copnet or /obj/geo1/copnet.

Ok makes sense! Strictly it isnt required for my purpose, it was more that I have to change some automation tooling made in H21 which expects things to be at /obj but it's not a big problem to adjust. If it was a bug I wouldn't have bothered but now it makes sense to put the work in. Thanks!