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

Problems with colored names #13

Open
EpicKnarvik97 opened this issue Jun 20, 2022 · 7 comments
Open

Problems with colored names #13

EpicKnarvik97 opened this issue Jun 20, 2022 · 7 comments
Labels
bug A problem that impedes core functionality
Milestone

Comments

@EpicKnarvik97
Copy link
Collaborator

The § character is illegal for some reason. Tab-completing a colored portal name causes a server disconnect. Color codes need to be temporarily switched to some other character between tab completion and user input to fix this problem.

@EpicKnarvik97 EpicKnarvik97 added the bug A problem that impedes core functionality label Jun 20, 2022
@Thorinwasher
Copy link

This might be a bug worth posting to spigot or paper.

Would it be stupid to just replace § with & in the tab completion, and expect the user to understand?

@EpicKnarvik97
Copy link
Collaborator Author

EpicKnarvik97 commented Aug 2, 2022

This might be a bug worth posting to spigot or paper.

Would it be stupid to just replace § with & in the tab completion, and expect the user to understand?

It seems it's the Minecraft client which kicks the player for tab-completion (or rather submitting the paragraph character which is given in the tab completion), so I'm not sure if it's possible to prevent it from the server-side.

Something like replacing the paragraph sign with & is probably the only thing we can do. We need to keep the color code in some fashion, as "&2Portal" and "&4Portal" can be two completely different portals.

@Thorinwasher
Copy link

Thorinwasher commented Aug 2, 2022

Something like replacing the paragraph sign with & is probably the only thing we can do. We need to keep the color code in some fashion, as "&2Portal" and "&4Portal" can be two completely different portals.

Yes, I agree. Would it be a good idea to use the api to check for the disableCustomColoredNames setting? This could invalidate the relevance of color codes

@EpicKnarvik97
Copy link
Collaborator Author

Yes, I agree. Would it be a good idea to use the api to check for the disableCustomColoredNames setting? This could invalidate the relevance of color codes

Assuming color codes can be encountered even though disableCustomColoredNames is disabled, and there is no possibility at all that two portals with the same names, but different color codes exist, we could potentially strip the color codes as part of the tab completion, as long as we can get the portal "&aPortal" using the string "Portal".

What happens if custom colors are disabled after portals and networks using them have been created? And what about the case where two portals have been created that have a name collision if the color codes are stripped?

@Thorinwasher
Copy link

Thorinwasher commented Aug 2, 2022

What happens if custom colors are disabled after portals and networks using them have been created?

Their names will have hashes following that setting, and all color codes will be ignored. They will still have stored color codes in the database.

And what about the case where two portals have been created that have a name collision if the color codes are stripped?

I think we thought it through, but I've honestly forgot. Probably just that there will be a name collision for one of the portals, thereby invalidating it. I don't see any other solution than that.

@EpicKnarvik97
Copy link
Collaborator Author

For local networks, it seems the color is stripped in the constructor, so we don't need to do anything special for those. For inter-server networks and all portals, we would still need to strip the color.
Alternatively, we could just display the id instead of the name for tab-completion, as that would already have the color stripped.

I'm actually kind of confused, looking at the code. For local networks, the name is stripped, if DISABLE_CUSTOM_COLORED_NAMES is enabled. No portal names or inter-server network names have this behavior. Is this inconsistency intended?
In all cases, the IDs are stripped of colors when DISABLE_CUSTOM_COLORED_NAMES is enabled, so in all cases, color codes are ignored when testing for duplicates (though, I've been wondering: does stripColor work on &1,&a,... as those are techincally not color codes until they've been converted? Or are we not treating those as color codes unless they're actually formatted to display a color?).

@Thorinwasher
Copy link

I'm actually kind of confused, looking at the code. For local networks, the name is stripped, if DISABLE_CUSTOM_COLORED_NAMES is enabled. No portal names or inter-server network names have this behavior.

Then that's another fail on my part, they should all follow the same behavior.

does stripColor work on &1,&a,... as those are techincally not color codes until they've been converted?

I don't think it will work, has to be done on real color codes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A problem that impedes core functionality
Projects
Development

No branches or pull requests

3 participants