& Color codes in config help!

Im trying to make it so you can use the & symbols and a number to make color codes. How would I do that?

Code:

            p.sendMessage("§b§lCrates: " + getConfig().getString("cratenames"));

I tired putting the § symbol but it converted to some other language of color coding.

 

Actually, your code is correct. Not sure what you mean by other language of color coding. But in strings you can always type \u00a7 and in yml you can always type #x00a7 instead of typing §. As for parsing &, it's simple:

Code:

.replaceAll("([^\\])&([0-9a-f])","\1§\2");

 

Eh, too much work. http://jd.bukkit.org/rb/apidocs/org...teAlternateColorCodes(char, java.lang.String)

 

@JarFile Use this found it on some thread:

Add this to your Class:
This replaces & to §

Code:

public String colorize(String msg)
    {
        String coloredMsg = "";
        for(int i = 0; i < msg.length(); i++)
        {
            if(msg.charAt(i) == '&')
                coloredMsg += '§';
            else
                coloredMsg += msg.charAt(i);
        }
        return coloredMsg;
    }

And just change it to this:

Code:

p.sendMessage("§b§lCrates: " + colorize(getConfig().getString("cratenames")));

And in the config itll look like this:
cratenames: '&bSUPER Crate'

That should work

 

@gal0511Dev

So you literally just rewrote the behavoiur of that method for.....what reason? @teej107 managed to accomplish what you posted in one line of code....

 

@gal0511Dev Not only that, your method is inferior - what if I want to say "Fish & chips"? Then I guess I'm plain out of luck with your code

 

At least I wrote "[0-9a-f]" although really it should be [0-9a-fk-or]

 

@pie_flavor

....no. It really should ColorCode.translateAlternateColorCodes()

 

Yeahhh...

dont click here (open) dont click here (close)

hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

Which takes up more characters?
ChatColor.translateAlternateColorCodes('&',string)
string.replaceAll("([^\\])&([0-9a-f])","\1§\2")

 

@pie_flavor

Which one is very clearly and unambiguously taking in ampersands and turning them into Minecraft color codes without relying on a specific implementation? Which one is easier to debug? Which one is not reinventing the wheel?

This isn't a competition to see how few characters you can do something in. Clarity, OOP, and reuse are of much higher value than a difference of 5 or so characters.

 

Code:

s.replaceAll("([^\\])&([0-9a-f])","\1§\2")

Here we go, I saved more characters! Or if you use this method a lot, you can do this!

Code:

public String r(String s){return s.replaceAll("([^\\])&([0-9a-f])","\1§\2");}

So yeah, characters used shouldn't be your aim - this isn't 30 years ago, you know. Hard drives have plenty of room now

 

@mythbusterma

Code:java

public static String translateAlternateColorCodes(char altColorChar, String textToTranslate)
  {
    char[] b = textToTranslate.toCharArray();
    for (int i = 0; i < b.length - 1; i++) {
      if ((b == altColorChar) && ("0123456789AaBbCcDdEeFfKkLlMmNnOoRr".indexOf(b[(i + 1)]) > -1))
      {
        b = '§';
        b[(i + 1)] = Character.toLowerCase(b[(i + 1)]);
      }
    }
    return new String(b);
  }

Reinventing the wheel, huh.

 

@pie_flavor

....yes, reinventing the wheel. I don't see the point you're trying to make. Very clearly, all you have done is provide an inferior implementation of the code you posted, what's your point? That the Bukkit developers did it better than you? That your code ties it to a specific implementation of the client?

 

You misunderstand me. My previous post was the actual code inside of translateAlternateColorCodes, which is totally reinventing the wheel. My code is simpler.

Also, as George Carlin once said, anyone who uses the phrase "reinventing the wheel" first in a conversation deserves to be shot.

I have no idea what you are talking about when you say specific implementation. The code I posted works for color codes, in everything, as easily as possible, and is part of standard Java.

 

@pie_flavor

Their code is used by hundreds of different plugins, and is part of an extensive API, instead of using the Java methods that are already provided, they opted for the faster solution. They have a legitimate reason to change the implementation, and their method is faster, easier to read, and respects the concept of separation of interface and implementation, whereas yours does not.

The only justification you've provided is "less characters," see @AdamQpzm's post for why that's the worst excuse since "static is faster."

 

I highly doubt that this is the code that Bukkit actually use... I mean, the Bukkit Dev team know how to use arrays...

 

@TGRHavoc I literally just decompiled it with jd-gui. If you don't believe me, here's the complete source.

@mythbusterma
"changing the implementation" "faster method" "separation of interface and implementation" i doubt those mean anything.
This isn't a fancy doohickey specifically tailored to Minecraft. I am simply replacing a sequence of characters in a string with another sequence of characters.
And anyone who would be reading it anyway would be able to understand regular expression.

 

I was referring to the bit that says "b == altColorChar" it should have been "b[ i ]== altColorChar".

Edit: @1Rogue Turned out that the BB code was messing with it Fixed now.

 

@pie_flavor

Separation of interface from implementation is kind of a big deal, assuming you know how to program. Also, pretty sure "faster method" has a very specific meaning. It takes a lot longer to decipher a regex than it does to read the plain English "translateAlternateColorCode."

@TGRHavoc

It's decompiled source, it looks like something the compiler did.

 

I always love this argument because I get to point out the fact that if your method actually worked correctly it'd still be longer:

ChatColor.translateAlternateColorCodes('&',string)
string.replaceAll("([^\\])&([0-9a-fk-or])","\1§\2")

Furthermore, Bukkit's implementation of the method would be faster because it converts the string into a char array, manually assigns the new char values and returns a single string object. Regex is slow, and using .charAt() and god forbid the string appending you did in your first method, neither is faster.

So I don't see the point. You have neither provided a faster nor more convieniant method. Methods exist to simplify code and make it easier to do a step while typing less complicated and less detailed things (the method declaration). Bukkit's implementation requires you to only know a method name, the string to convert, and the character to convert as a color code. Your methods either require knowing a regex pattern from memory every time you want to use it, or creating a façade method to simply your own when it already exists in ChatColor. Your façade method could also hilariously be simplified to:

Code:java

public String colorize(String msg) {
    return ChatColor.translateAlternateColorCodes('&', msg);
}

(Now which one is shorter?)

I will say that indexOf checks with an interned string is probably about as fast as you're going to get in java. You need to read each letter in the string and then compare it to a dataset of characters. Perhaps with something such as hashing you could achieve something faster but the micro-improvement would be completely unnoticeable anyhow.

So, in short, if you want to write a longer method just to avoid using the API that already wrote stuff for you, feel free. But don't recommend to other people to circumvent the API to make things "easier" when it isn't at all.

"b == altColorChar"
"b == altColorChar"

Unless you mean italics I don't see the difference.
https://github.com/Bukkit/Bukkit/blob/master/src/main/java/org/bukkit/ChatColor.java#L205

 

@mythbusterma @AdamQpzm

Code:

Nikolai@CALIGARI-7 ~/Documents/NetBeansProjects/BuildTools/Bukkit (master)
$ git log --reverse
commit 4e8311a6551e8d7794cff73c57a481251b47459c
Author: Dinnerbone <[email protected]>
Date:   Tue Dec 21 15:32:27 2010 +0000

    Let's get this project started
   
Nikolai@CALIGARI-7 ~/Documents/NetBeansProjects/BuildTools/Bukkit (master)
$ git log --grep="translate"
commit 606f33903c245615fe9906778741ccfcf6677ac7
Author: rmichela <[email protected]>
Date:   Fri Mar 16 00:40:47 2012 -0400

    [Bleeding] Added ChatColor.translateAlternateColorCodes(). Addresses BUKKIT-

Actually, as you can see the commit history: The project started on Dec 21st, 2010 and ChatColor.translateAlternateColorCodes() wasn't added until Mar 16th 2012... Which is WHY you'll see these methods existing in projects: They didn't re-invent the wheel: The added their own implementation before one existed in Bukkit.

It's legacy code... So if they want to support very old Minecraft versions, then they will NOT be able to use the Bukkit implementation... because it won't exist at runtime.

But yes, you are right... most of the time people should just use the Bukkit implementation because there will be no need for them to make their own or use a legacy implentation.

 

@Europia79 In my experience, people don't tend to be building on Bukkit builds that are 2 years old

 

@AdamQpzm Ain't your decision what they use.

 

Yep. You are right. I am probably the only one.

 

@pie_flavor Never said it was, all I said that people don't tend to. I've been here quite a while now, seen many threads, and never once have I seen someone complaining that ChatColor.translateAlternateColorCodes() doesn't exist.

 

That's right; instead of complaining, they use replaceAll("([^\\])&([0-9a-fk-or])","\1§\2") which has the bonus feature of working with backslashes.

 

@pie_flavor

Just stop. Your argument has been completely and thoroughly obliterated. Your lack of understanding of simple programming principles is quite evident, and it obvious to everyone here you're just scrounging for something to substantiate your ignorance.