Hello,
I saw an issue request for supporting colored log messages and thought this sounded like a fun small project to work on, so I implemented this by adding a new public variable to store color data on the server object. This required changing from a
Why add a separate mapping from name->color? It seems easier just to say e.g. Log("Foo", Color.red) than to have to register every color you're going to use..
I agree with Dan's comment, leave the colors to whoever is calling Console.Log. If you want to subclass Server in your project and have editor-defined colors, then you can wrap Log in a method to which looks them up. Otherwise people can use the pre-defined colors (eg Color.red) or add constants to their code for different colors.
RE: The color mapping in Server - Yeah, I agree with you guys, the approach I was taking for that portion was a bit overengineered. I had hoped for it to be used as a message context, however yeah that's something that users of this asset can do for themselves easier than forcing it on the server end (such as just using constants like suggested). Easier for both maintainability and for users.
I reverted the changes to Server.cs, and updated Log in Console.cs to be string, Color32. Thanks for the feedback, I like this approach much better! Let me know if you have any other concerns with this.
Hello, I saw an issue request for supporting colored log messages and thought this sounded like a fun small project to work on, so I implemented this by adding a new public variable to store color data on the server object. This required changing from a
Why add a separate mapping from name->color? It seems easier just to say e.g. Log("Foo", Color.red) than to have to register every color you're going to use..
I agree with Dan's comment, leave the colors to whoever is calling Console.Log. If you want to subclass Server in your project and have editor-defined colors, then you can wrap Log in a method to which looks them up. Otherwise people can use the pre-defined colors (eg Color.red) or add constants to their code for different colors.
RE: The color mapping in Server - Yeah, I agree with you guys, the approach I was taking for that portion was a bit overengineered. I had hoped for it to be used as a message context, however yeah that's something that users of this asset can do for themselves easier than forcing it on the server end (such as just using constants like suggested). Easier for both maintainability and for users.
I reverted the changes to Server.cs, and updated Log in Console.cs to be string, Color32. Thanks for the feedback, I like this approach much better! Let me know if you have any other concerns with this.