-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong Channel order CVP in JSON #52
Comments
I guess I’ll have to check how Mumble orders them. By "wrong", you mean different from Mumble I see. |
Looks correct to me. I have all these channels position set 0. Oh, I guess you are using viewer, not viewer2? I guess the installation doc still pointed to viewer, not viewer2. The reason for the two in the first place is viewer uses SVG images, but renders rather slow for that reason. (Viewer also does not use the |
Oh I get why we didn't understand each other :) I'm using my own ChannelViewer (own php, js, etc). All I'm using is your JSON. So I'm not using either viewer or viewer2. This means that there's a big chance your mview.js is perfectly fine with the way ChannelViewerProtocolProducer.php now works and my javascript didn't like the changes. Here's the JSON I'm using: http://MYIP/MumPI/?view=json&serverId=1 |
The JSON contains the position field, which should be used by the viewer. But I guess the provided CVP could order it accordingly as well - I have not checked that (only about position and text, not capsulation order specifically). |
PHP is a pain in the arse. |
I thought my fix was pretty simple and effective. Any reason it could cause problems? |
It still doesn't order the channels the right way (http://i.imgur.com/2JJdZrO.png). As you can see at the bottom, STFU and "Small Talk" should be swapped.
Here's another screenshot with the mumble client on the right and the CV on the left: http://i.imgur.com/Std0Wfk.png
Both channels are set at Position=0.
If I put Position=1 for STFU, it will be at the good place.
If I change STFU to Stfu, it will be at the good place.
So I think that the compare also compares the case. The capital letters are before the non-capital letters in the ascii table which might be the problem.
The text was updated successfully, but these errors were encountered: