search

glitchfur / NeosVR-Headless-API

Python wrapper for the NeosVR headless client
GNU General Public License v3.0
23 stars 4 forks source link

Support of color/text formatting in world names #1

Open brodokk opened 2 years ago

brodokk commented 2 years ago

Hello,

I already play a bit with handling the headless shell and i know how painful it is. But I was curious about something, is okay for you to have a feature like having a option to add the support of it? I talk about an option because the consequence it will add instability so it will basically be a choice between stability and a cool feature.

And of course i'm not saying that you should do it, just start the discussion in case someone wanted to do a pull request for that.

glitchfur commented 2 years ago

It's not that it would cause instability, it would just entirely break NeosVR-Headless-API in its current state. The library works by looking for the > character at the end of the prompt to determine when a command has finished executing. If a world name uses colors or other text formatting, it is likely to end with this character due to the XML-like syntax, tripping up the library. Particularly this happens with the status command, where the first line would end with that character:

Screenshot of the headless client showing the status command

Currently there is not a workaround for this that doesn't involve changing the world name. Honestly it has been a while since I developed this particular part of the project so I'd have to deep dive into it to see if a workaround is possible. I may have to add an exception specifically for the status command at the prompt detection "layer" of operation to ignore the first occurrence of a > or something if the name has text formatting.

I'm also not sure if the status command is the only command effected by this, or if other commands or even regular log output would also trip it up.

I will keep this open for now in case I discover something.

brodokk commented 2 years ago

Ok so... It was a bit what I was trying to explain, sorry if I was not clear.

The instability part is if you add something in the status command your can have something for handling this but the problem could come from the other commands who can maybe be affected by it, like you said. I should not have be too sure about it tho you right.

And yes the idea with this ticket was for "keep it here for later", I was not asking you to go deep dive in it again because I know it could take some time from you to do that.