I updated from v1.16.2 to v1.25.6 and sadly miss a button of type modal. Just one modal is not visible anymore When switching back to 16.2 the missing modal is there again. It must have something to do with the update: Also 25.6 shows German language which was not the case in 16.2 - can this be configured to be English, nevertheless what country I'm in? See screenshots:
I don't know how to debug it. Can you give some advice what could cause this or how to debug it?
I already compared modal_link JSON with some other modals but couldn't figure it out.
Maybe there is some API incompatibility between those versions that causes it.
If someone could help me, that would be awesome .. thank you
P.S.: I run the node version inside docker container.
As far as I can see there's no change that could cause this between these versions but it may be a bug, could you please upload the session file that works with v1.16.2 ?
To force the language to english, set the server's client-options field to lang=en.
Thank you for your response, using --client-options lang=en as cli argument solved the above mentioned language issue. Do you have an example how to put this into config.json. Up for now I didn't need config.json. But I'm planing to move cli arguments into that file. Is it new? Do you have a json schema, or where can I find information how to structure/layout this config.json?
I attached the complete session dmx-mobile-ctrls.json. To reproduce load it with 1.16.2 and with 1.25.6 to check for differences. It's a big project, also containing unfinished and incorrect parts, please excuse this. To highlight where the issue occurs, I also attached modal_failed_to_load.json, which is just the json part of dmx-mobile-ctrls.json containing the model_link button, that disappears from the SCNS tab when using 1.25.6.
All right, that sounds good, so I'll just wait for the next release > 1.25.6, then it should be fixed.
I also asked about config.json because since update from 1.16.2 to 1.25.6 the node app shows:
docker-compose logs -f open-stage-control
Attaching to open-stage-control
open-stage-control | (ERROR) Could not read config from file:/home/node/.config/open-stage-control/config.json
open-stage-control | Error: ENOENT: no such file or directory, open '/home/node/.config/open-stage-control/config.json'
open-stage-control | at Object.openSync (node:fs:586:3)
open-stage-control | at Object.readFileSync (node:fs:454:35)
open-stage-control | at Object.358.../../package.json (/tmp/open-stage-control/server/src/server/settings.js:117:1)
open-stage-control | at o (/tmp/open-stage-control/server/node_modules/browser-pack/_prelude.js:1:1)
open-stage-control | at /tmp/open-stage-control/server/node_modules/browser-pack/_prelude.js:1:1
open-stage-control | at Object.348../callbacks (/tmp/open-stage-control/server/src/server/index.js:4:1)
open-stage-control | at o (/tmp/open-stage-control/server/node_modules/browser-pack/_prelude.js:1:1)
open-stage-control | at r (/tmp/open-stage-control/server/node_modules/browser-pack/_prelude.js:1:1)
open-stage-control | at Object.<anonymous> (/tmp/open-stage-control/server/node_modules/browser-pack/_prelude.js:1:1)
open-stage-control | at Module._compile (node:internal/modules/cjs/loader:1099:14) {
open-stage-control | errno: -2,
open-stage-control | syscall: 'open',
open-stage-control | code: 'ENOENT',
open-stage-control | path: '/home/node/.config/open-stage-control/config.json'
open-stage-control | }
open-stage-control | (INFO) Server started, app available at
open-stage-control | http://127.0.0.1:8080
open-stage-control | http://172.18.0.4:8080
I looks like it doesn't harm and it is working, but 1.16.2 node app did not show that error.
Turns out it was a very subtle side effect of a change around v1.24 that made a container swallow its last child when other widgets in the same container had a specific value/property dependency pattern. It's now fixed in sources, to be released soon.
As for the config.json error, it was simply failing silently before, the message was added in v1.25.6. I guess it's something to do with docker / file permissions. It's harmless but you can still use --config-file to provide a file that o-s-c can read and write to if you want to remove the error.