Feature Request: Enable/Disable scene item by name as v4

[willyk0]

Feature Request Type

RPC Request

Feature Request Type (Other)

No response

Requested Feature

In v4, we could set the visibility using SetSceneItemRender, using just the name of the source and the scene name. This was specially useful for batch calls. One call and you can do everything you want.

In v5, we use SetSceneItemEnabled. It needs an "id". For getting an ID we need to use GetSceneItemId. This function doesn't search inside groups, so it does not do its function and we have to make a recursive search to list all items in a scene and repeat for its groups until you find the specific name to get its ID. It has no sense. Compared with the simplicity of v4, this is a huge step back and makes the implementation of basic things a headache and unnecesarily complex.

So it would be great if SetSceneItemEnabled works also with the source name as before.

Requested Feature Usage Scenario

Developing bots where you need to change visibility of things for showing up alerts, clips, texts...

[Eldoran]

I'm dealing with this problem too, now I cannot change the visibility of a source with just the name and the scene like in the previous version, I had to implement a search in the current scene, then in the groups inside until I find it, and then finally use the id to enable or disable it. I think it shouldn't be that hard just to enable or disable a source.

[tinodo]

+1 on this. Since the Source Names are unique anyway, having to specify an Id, which is obviously hard to get, makes things even more complicated. I think one should try to abstract these "identifiers" away from the user. I know it's the return value when creating the source, but otherwise it can be hard to find them. Anyway, it would require at least 1 roundtrip to OBS. When you create a Source using a unique name, one should be able to operate on that Source using that unique name as well. Consistency...

[bost-ty]

Is it possible this behavior is a safeguard to keep functionality after a scene or source name is changed by the user in the OBS frontend?

I'm not sure if that's good or not, but I suppose the ID is the "immutable" safety.

I have also noted from other issues/documentation that Groups are really not supported and can cause other issues. Does the same annoyance exist when using Nested Scenes?

Forgive any mistakes on my part, I'm trying to understand more about how obs-websocket works internally and make sense of it.

[willyk0]

I have also noted from other issues/documentation that Groups are really not supported and can cause other issues. Does the same annoyance exist when using Nested Scenes?

Yes it exist. Let me show you an example.

Let's say that you want to show an text alert on screen which name is "TextAlert" inside a group "Alerts" also insidet a scene called "My Scene". You don't know its ID (which may vary if elements in scene changes). In v4.9.1, you called "hey obs-socket, hide TextAlert from My Scene", and it worked. Simple and beautiful.

Now, you have to do "hey obs-websocke, give me the IDs for My Scene and their names". Oh, there is no TextAlert here. "Hey obs-websocket, list me the IDs for the group XXXX". Oh, not there. "Hey obs-websocket, list me the IDs for the group Alerts" Ok there it is! "Hey obs-websocket, hide the ID N from group Alerts". --> and it's the same with nested scenes. Believe me that this is a hard pain when you have to migrate a complex bot which manages thousands of elements in a massive scene collection (thanks for mantaining 4.9.1-compat). Also, IDs may vary if the element is present in various scenes. Names don't. So it's way, way, way easier to work directly with names as before in 4.x.

This applies to nearly all requests regarding SceneItems.

(BTW: Nested Scenes != Groups. A Scene will always have the canvas size, the group has the size of all its elements inside it, it's not the same when you need to do complex things. They are not interchangeable in most cases)

[tt2468]

The recommended behavior here is to use request batches and variables to perform the request:

{
  "op": 8,
  "d": {
    "requests": [
      {
        "requestType": "GetSceneItemId",
        "requestData": {
          "sceneName": "test scene",
          "sourceName": "test input"
        },
        "outputVariables": {
          "sceneItemIdVariable": "sceneItemId"
        }
      },
      {
        "requestType": "SetSceneItemEnabled",
        "requestData": {
          "sceneName": "test scene",
          "sceneItemEnabled": false
        },
        "inputVariables": {
          "sceneItemId": "sceneItemIdVariable"
        }
      }
    ]
  }
}

[willyk0]

That's exactly the unnecessary and pointless extra work that wasn't needed in v4 and why this issue was opened 🙄Ok never mind