I have just updated the list to include the various Drawing.Color.<color> aspects for extra clarity.

 

12 hours ago, Stealth22 said:

just to clarify, are we using Color.Green for the "green" color, or Color.Lime?

I've updated the list to make it Lime. Please see the original post and let me know what you think of the color codes now.

Looks fine to me. 

All my plugins and callouts will be updated soon if they aren't conformant now. As far as I see they conform to most of this specification.

BTW great idea :)

Just a quick question- how do you get your text to be "lime green"?  I know of the ~color letter~ before the text, but is there a specific letter for that?  (Sorry for the stupid question!)

10 minutes ago, fiskey111 said:

Just a quick question- how do you get your text to be "lime green"?  I know of the ~color letter~ before the text, but is there a specific letter for that?  (Sorry for the stupid question!)

Lime green is for the blips. I believe ~g~ will be fine for text and should match lime green blips.

Yeah, it's not exact, but its close enough. Lime is a better match to ~g~ than Drawing.Color.Green anyway, lol.

If everybody ends up using this, could we use the natives SET_BLIP_COLOUR and SET_BLIP_ROUTE_COLOUR? Example:
NativeFunction.Natives.SET_BLIP_COLOUR(blip, 5);
NativeFunction.Natives.SET_BLIP_ROUTE_COLOUR(blip, 5);
It sets the blip to the proper color used in GTA V depending on the index, some indexes:
1 - red, used on enemies
2 - green
3 - light blue
5 - yellow, for routes
17 - orange
27 - purple

I prefer to use this instead of the System.Drawing.Colors because they look better than Color.Red, Color.Yellow,... at least until we find which RGB are those colors(Blip.Color returns R=0, G=0, B=0 when using this). 

There can be some exceptions, like when using it on a search area, I think that Color.Yellow looks better or the orange, I think that Color.OrangeRed looks better.

Edited February 18, 201610 yr by alexguirre

Using the System.Drawing colors makes it a lot simpler though, especially when it comes to custom ped objects and such. We can leave it up to each dev, I guess, if someone prefers to use natives instead.

Edited February 18, 201610 yr by Stealth22

18 minutes ago, alexguirre said:

If everybody ends up using this, could we use the natives SET_BLIP_COLOUR and SET_BLIP_ROUTE_COLOUR? Example:
<snip>

 

5 minutes ago, Stealth22 said:

Using the System.Drawing colors makes it a lot simpler though, especially when it comes to custom ped objects and such. We can leave it up to each dev, I guess, if someone prefers to use natives instead.

I would actually recommend developers avoid using natives where possible. The benefit of the natives only comes in the form of RPH updates wont break them (like when methods become deprecated, plugins have to be updated).

At the gain of that 1 benefit you lose compiler errors, your code becomes a spew out of hashes (that occasionally change) or large obtrusive looking strings. You also limit and somewhat hinder your error outputting should the plugin crash because natives are determined during runtime.

And as stealth said, it's much simpler to use for everyone.

If RPH has a replacement for it (eg. myBlip.Color in this case) I really would recommend using it. Someone pretty competent at coding added that functionality into RPH, there is no point in reinventing the wheel or going back to basics.

I agree with @LukeD. I only use native functions when I absolutely have to. They are nearly impossible to debug if an exception gets thrown. Not saying that will happen with this, but for example, take something as simple as the "GET_VEHICLE_COLORS" native, I think its called. I had a weird StackOverflowException whenever I called that native, and the game would crash completely. Even if I put it in a Try/Catch block, it would still crash to desktop. When I changed the code to call it via the Hash instead of the name, it mysteriously worked fine.

Remember that all mods for GTA V are, by definition, unauthorized.

Rockstar can change stuff around at any time, and they do not provide us with an API...whereas RPH does. Use it to your advantage whenever possible.

Edited February 18, 201610 yr by Stealth22

I'm a bit late, but I like this idea. I'll update my mods to follow those new rules then :)

12 hours ago, alexguirre said:

I prefer to use this instead of the System.Drawing.Colors because they look better than Color.Red, Color.Yellow,... at least until we find which RGB are those colors(Blip.Color returns R=0, G=0, B=0 when using this). 

I'm feeling pretty lazy right now but you can just spawn blips in each color, take a screenshot, and look at the color of the pixels in the screenshot

6 hours ago, goigle said:

I'm feeling pretty lazy right now but you can just spawn blips in each color, take a screenshot, and look at the color of the pixels in the screenshot

EDIT: I should probably tag @alexguirre in this :P

 

Or you could all stop being noobs and look at the System.Drawing.Color MSDN documentation, each colour has it's ARGB hash value which you can deduce the integer value 0-255 from quite easily if you're not a total noob :P

Also you can just use Color.B which will return the value of the blue channel as a byte (0-255)
and obviously there is .A, .R and .G

For the noobs or the seriously bored, here's how to manually convert ARGB hashes to individual integers along with a little explanation of what I'm on about (honestly it's easier to just use a converter website or the .B method above but hey. Who doesn't love a bit of maths?):

Spoiler

ARGB hashes are hexadecimal (base 16, also known as 0 - F)

Example: the colour black has an ARGB value of #FF000000 and the colour blue has an ARGB value of #FF0000FF
ARGB stands for Alpha, Red, Green, Blue.

So lets take the hash for blue above (#FF0000FF), each "channel" has 2 digits so it's actually [FF][00][00][FF].
This means FULL alpha channel (FF = 255), no red, no green and full blue. This the result is an opaque full blue colour.
Now in this case it's very easy to determine what the integer values are as we don't have any confusion with in between values.
A = 255, R = 0, G = 0, B = 255.

You can of course plug each of the 2 digit hash codes into a hexadecimal to decimal converter for simplicity sake. But I'll show you how to work it out anyway for fun and because I really don't want to read a scientific paper for university yet.

Let's take a slightly more complex colour so we can show how to work it out.
Ah here's a good one. LimeGreen = #FF32CD32

So once again we have a full alpha channel of FF. Leaving us with RGB = 32CD32.

So how do we work this out. Well remember this is in hexadecimal not decimal. So 32 in hex is not 32 in dec. I'll show you how to work it out using the letters below, but the same principle applies to all parts of the hash.

Well counting from 0 to 9, gives you decimal. after 9, each number is represented with a letter up to F So A = 10, B = 11, C = 12, D = 13 etc.

So CD is 1213 then right luke? Literally yes. But in decimal no, so we need to convert it. To do this we multiply the values by 16 to the power of its place value, then add them together.
So we only have CD that's 2 place values. C is 1, D is 0 (if it was E7AD for example that would have 4 place values so E = 3, 7 = 2, A = 1, D = 0)
CD = (12x16¹)+(13x16⁰) = 192 + 13 = 205.

And again remember the 32 is still in hexadecimal and needs converting too!
32 = (3x16¹)+(2x16⁰) = 48 + 2 = 50

So ARGB of LimeGreen #FF32CD32 is
A = 255
R = 50
G = 205
B = 50

Voila.

 

2 hours ago, LukeD said:

For the noobs or the seriously bored, here's how to manually convert ARGB hashes to individual integers along with a little explanation of what I'm on about (honestly it's easier to just use a converter website or the .B method above but hey. Who doesn't love a bit of maths?):

  Reveal hidden contents

ARGB hashes are hexadecimal (base 16, also known as 0 - F)

Example: the colour black has an ARGB value of #FF000000 and the colour blue has an ARGB value of #FF0000FF
ARGB stands for Alpha, Red, Green, Blue.

So lets take the hash for blue above (#FF0000FF), each "channel" has 2 digits so it's actually [FF][00][00][FF].
This means FULL alpha channel (FF = 255), no red, no green and full blue. This the result is an opaque full blue colour.
Now in this case it's very easy to determine what the integer values are as we don't have any confusion with in between values.
A = 255, R = 0, G = 0, B = 255.

You can of course plug each of the 2 digit hash codes into a hexadecimal to decimal converter for simplicity sake. But I'll show you how to work it out anyway for fun and because I really don't want to read a scientific paper for university yet.

Let's take a slightly more complex colour so we can show how to work it out.
Ah here's a good one. LimeGreen = #FF32CD32

So once again we have a full alpha channel of FF. Leaving us with RGB = 32CD32.

So how do we work this out. Well remember this is in hexadecimal not decimal. So 32 in hex is not 32 in dec. I'll show you how to work it out using the letters below, but the same principle applies to all parts of the hash.

Well counting from 0 to 9, gives you decimal. after 9, each number is represented with a letter up to F So A = 10, B = 11, C = 12, D = 13 etc.

So CD is 1213 then right luke? Literally yes. But in decimal no, so we need to convert it. To do this we multiply the values by 16 to the power of its place value, then add them together.
So we only have CD that's 2 place values. C is 1, D is 0 (if it was E7AD for example that would have 4 place values so E = 3, 7 = 2, A = 1, D = 0)
CD = (12x16¹)+(13x16⁰) = 192 + 13 = 205.

And again remember the 32 is still in hexadecimal and needs converting too!
32 = (3x16¹)+(2x16⁰) = 48 + 2 = 50

So ARGB of LimeGreen #FF32CD32 is
A = 255
R = 50
G = 205
B = 50

Voila.

 

My god you're like my data analysis professor. 

8 hours ago, goigle said:

I'm feeling pretty lazy right now but you can just spawn blips in each color, take a screenshot, and look at the color of the pixels in the screenshot

Yep, when I have some time I will take screenshots and then use photoshop to get the color of the blips.

2 hours ago, LukeD said:

<snip>

I know that each color has a hash value and that it's in hexadecimal, I didn't know how to convert hexadecimal to decimal so thanks for it.

4 hours ago, LukeD said:

or you could all stop being noobs and look at the System.Drawing.Color MSDN documentation, each colour has it's ARGB hash value which you can deduce the integer value 0-255 from quite easily if you're not a total noob :P

That's missing the entire point though :p

If we could use Drawing.Color to get the colors alex was talking about, we wouldn't need to know it's RGB info in the first place.

22 hours ago, alexguirre said:

It sets the blip to the proper color used in GTA V depending on the index, some indexes:
1 - red, used on enemies
2 - green
3 - light blue
5 - yellow, for routes
17 - orange
27 - purple

I prefer to use this instead of the System.Drawing.Colors

 

I have the RGB values of the colors I was talking about so we don't have to use the natives:

• Red:           R=224 G=50 B=50
• Green:        R=114 G=204 B=114
• Light Blue:  R=93 G=182 B=229
• Yellow:       R=240 G=200 B=80
• Orange:     R=234 G=142 B=80
• Purple:       R=171 G=60 B=230

This is the image I used to get the colors:

To compare with the colors you had set:

Edited February 19, 201610 yr by alexguirre
Added second image

It looks like they are darker shades of the colors that we picked...almost as if they took the "pure" colors, and turned down the opacity. The yellow and orange that R* selected look too close, IMO.

I don't know what you guys think, but I just released my stuff with the Drawing.Color values, so I wouldn't be able to change anything until the next release.

I think we're getting too granular with this, though. As long as we decide on a set of colors and stick to them, that's enough. They don't have to precisely match with whatever R* picked. Its not like we're integrating plugins with stock R* missions or anything.

Edited February 19, 201610 yr by Stealth22
Sorry...meant to say can't change anything UNTIL THE NEXT RELEASE :)

I think personally I prefer the R* colors and I'll probably use these, though I don't think we all need to agree to use one or the other. 

I will update my modifications soon to make blips adhere to most of the guidelines.

In some cases though, like on the ANPR callouts, I prefer to have my routes red to indicate the severity of the case - I'll be keeping that as it is.

For new stuff, though, I'll try to keep the colours in mind.

I like the initiative! The encouragement for authors to work together to make their stuff less confusing is a great one