Skip to content
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

review every command and possibility of user input #135

Open
marado opened this issue Oct 10, 2021 · 5 comments
Open

review every command and possibility of user input #135

marado opened this issue Oct 10, 2021 · 5 comments
Labels
Milestone

Comments

@marado
Copy link
Owner

marado commented Oct 10, 2021

...including MOTD and files, or other stuff that might not have been entered with commands, but certainly review every command too.

While we fixed #87 , allowing users to input color means we no longer control it - and, in particular, where it bleeds, or how to save it in the databases, or how to count the length of strings that might or might not have color... and so on.

It was quite easy to identify a few of this issues, and in eef1a39 I took care of those (and you can take a peek to understand the sort of issues I am talking about), but I'm pretty sure that if we do not review every little functionality from top to bottom with "color inputs and how they can mess things" in mind, we will most probably have still quite a few of those cases on our hands.

I'm tagging this as a "bug" because while I don't know any specific case where one actually exists... I bet there is more than one out there, related to this.

@marado marado added the bug label Oct 10, 2021
@marado marado added this to the 0.7.0 milestone Oct 10, 2021
marado referenced this issue Oct 17, 2021
Now that users can ~BGinput color~RS, we should have a different care
about everything that is user input. For now, this patch makes it so
that:

* descs with color do not ruin .who anymore
* rank names with color do not ruin .who anymore
* texts with color don't bleed out elsewhere

There is probably plenty more where user-input color codes can mess up
with current talker functionality: a thorough investigation of the use
of color with each command should be done.
@marado
Copy link
Owner Author

marado commented Oct 24, 2021

.dig is one of the commands that is bleeding color.
dig-bleed

Not only that, but it allows color in every character but the first, because the alphabetic validation to the name isn't taking into account the possibility of color codes.

@marado
Copy link
Owner Author

marado commented Oct 24, 2021

With us now saving places with colored names in them (~FGforest, for eg.), .map isn't picking the right "first character" do display in it. This can be seen either as a bug on TalkerNode (in dealing with colored places) or a feature request in Nodiverse (supporting colored names), but I'd rather we just went to the route that ends with us supporting color on place names :)

marado added a commit that referenced this issue Oct 24, 2021
* We're now able to dig with places that have color right on the start
  of their names;
* We no longer bleed color when trying to dig into a direction that
  already has something in there;
* We're saving on the database the actual name with its ANSI colours,
  instead of the NUTS-style color codes.

This is part of the efforts in #135 , even if it stays far from being
solved.
marado added a commit that referenced this issue Oct 24, 2021
marado added a commit that referenced this issue Oct 24, 2021
This helps us with #135 - Nodiverse 0.4.0 letting us have a working
.map even when the places shown in it start with a color.
@marado
Copy link
Owner Author

marado commented Feb 6, 2022

  • MOTD
  • command's help, description, etc.
  • check every command, one by one

marado added a commit that referenced this issue Feb 6, 2022
@marado
Copy link
Owner Author

marado commented Feb 6, 2022

issues detected on commands so far:

  • if user a emotes :~FYjumps they will see it correctly (colored) but others in the room will actually see the User ~FYjumps, with the color code
  • same thing is happening for .say !
  • if you try to .exa T~RSest it's OK if we don't find the user named Test but in the message There's no one called test. we should not be printing the color code (~RS or any other)
  • if user First does .go tes in order to go to the room Teste, another user will see :: Test starts walking to southeast towards tes... instead of the full room name
  • .go and .map might still have some problems with colored room names

commands still not tested:

  • .last
  • .look
  • .map
  • .password
  • .quit
  • .ranks
  • .say
  • .sayto (-)
  • .suicide
  • .tell
  • .version
  • .who (@)
  • .wizlist
  • .color
  • .desc
  • .semote (&!)
  • .shout ([)
  • .shoutto (])
  • .spod
  • .demote
  • .promote
  • .dig
  • .close
  • .destroy
  • .save
  • .setcmdlev
  • .entrypoint
  • .addrank
  • .entrylevel
  • .rmrank
  • .rnrank
  • .rcmds
  • .rntalker

@marado
Copy link
Owner Author

marado commented Feb 6, 2022

There might still be a problem with colored places - but this might also be because this map was made before the previous fixes (and I should make sure the nodiverse version being used here is also uptodate). Still, there's both a problem managing to go to the teste amarelo room, and the .map displaying it:

:: You look around...
:: You notice you are at center.
:: You see Marado.
:: You see 6 passages:
   northlands  Teste Amarelo  novo teste  canto  Sul  Teste Normal  
.map
                    
                    
                    
                    
          n   ~     
          |  /       
          | /        
          c - n     
        / | \        
       /  |  \       
      c   S   T     
                    
                    
                    
                    
.go t    
:: You start walking to southeast towards Teste Normal...
:: You arrive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant