Quantcast
Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
    1. Welcome to GTAForums!   (84,879 visits to this link)

    2. News

    1. GTA Online

      1. Find Lobbies & Players
      2. Guides & Strategies
      3. Vehicles
      4. Content Creator
      5. Help & Support
    2. Crews

      1. Events
      2. Recruitment
    1. Grand Theft Auto Series

    2. GTA Next

    3. GTA V

      1. PC
      2. Guides & Strategies
      3. Help & Support
    4. GTA IV

      1. Episodes from Liberty City
      2. Multiplayer
      3. Guides & Strategies
      4. Help & Support
      5. GTA Mods
    5. GTA Chinatown Wars

    6. GTA Vice City Stories

    7. GTA Liberty City Stories

    8. GTA San Andreas

      1. Guides & Strategies
      2. Help & Support
      3. GTA Mods
    9. GTA Vice City

      1. Guides & Strategies
      2. Help & Support
      3. GTA Mods
    10. GTA III

      1. Guides & Strategies
      2. Help & Support
      3. GTA Mods
    11. Top Down Games

      1. GTA Advance
      2. GTA 2
      3. GTA
    12. Wiki

      1. Merchandising
    1. GTA Modding

      1. GTA V
      2. GTA IV
      3. GTA III, VC & SA
      4. Tutorials
    2. Mod Showroom

      1. Scripts & Plugins
      2. Maps
      3. Total Conversions
      4. Vehicles
      5. Textures
      6. Characters
      7. Tools
      8. Other
      9. Workshop
    3. Featured Mods

      1. DYOM
      2. OpenIV
      3. GTA: Underground
      4. GTA: Liberty City
      5. GTA: State of Liberty
    1. Red Dead Redemption 2

    2. Red Dead Redemption

    3. Rockstar Games

    1. Off-Topic

      1. General Chat
      2. Gaming
      3. Technology
      4. Programming
      5. Movies & TV
      6. Music
      7. Sports
      8. Vehicles
    2. Expression

      1. Graphics / Visual Arts
      2. GFX Requests & Tutorials
      3. Writers' Discussion
      4. Debates & Discussion
    1. Forum Support

    2. Site Suggestions

Sign in to follow this  
MKKJ

Blip/Marker struct

Recommended Posts

MKKJ

Blip/Marker Struct

 

Structure: RadarBlip
Item size: 0x28 (40 bytes)
Pool start: 0xBA86F0
Pool size: 175 items

 

[table]

OffsetDescription+0Color ID of blip[/td]0 = Red
1 = Green
2 = Blue
3 = White
4 = Yellow
5 = Purple
6 = Cyan
7 = Threat/Friendly (Default Red)
8 = Destination (Default Yellow)

RGBA = Custom Colors (0xRRGGBBAA)

+4Handle of entity the blip is assigned to (ped/car/object, etc...)+8X Position of blip (not working for entity blips)+12Y Position of blip (not working for entity blips)+16Z Position of blip (not working for entity blips)+20Blip Counter; How many blips have created in this blip index+24Unused float (leftover from GTAIII debug)+28Size of blip (set by opcode 0168)+32Pointer to streamed enex marker (assigned with opcode 08DC)
*In save file struct, it contains enex index+1 instead+36Radar Icon ID+37Bunch of bitflags about blip properties belowBit 0Makes use of bright colors. Always set.Bit 1Whether blip is exist or not (set by opcode 07BF)Bit 2Long Distance; If set, blips won't disappear if out of radar range.
(set by opcode 08A8)Bit 3Whether blip is marked as FRIENDLY and set blip color to blue.
(Only for ColorID:7, set by opcode 07E0)Bit 4If set, marker will still appear after the entity's deletionBit 5Unused flag, always unsetBit 6Marked as THREAT (Blip color is set to Red)Bit 7Marked as FRIEND (Blip color is set to Blue)+38More flags about blip propertiesBit 0Show marker above entity (set by opcode 018B as 2-bit value)Bit 1Show blip on radar (set by opcode 018B as 2-bit value)Bit 2Type of assigned entity (It's a 4-bit value, not a bitflag)Airstrip blip[/table]

 

Original post

 

 

So, the other day I found something about marker struct below

 

[table]

Structure: RadarMarker
Item size: 0x28 (40 bytes)
Pool start: 0xBA86F0
Pool size: 175 items

struct RadarMarker {
DWORD dwColourID; // 0
DWORD* pEntity; // 4
float fPosX; // 8
float fPosY; // 12
float fPosZ; // 16
short wFlag; // 20
short _wAlign; // 22
float fUnknown; // 24 (either 1.0 or 5.0)
DWORD dwIconSize; // 28
DWORD *pEnterExit; // 32
BYTE byteIcon; // 36
BYTE byteFlags; // 37
BYTE byteType; // 38
BYTE _bAlign; // 39
};[/table]

 

And i wonder, is there are detailed documentation of this struct?

 

So far I only found out about byteIcon, fPos, and colourID, pEntity and can't figure out the rest.

I'm especially curious about Flag, wFlag and Type, since seems like they determine something something about marker's color and behavior.

 

Thanks in advance.

 

 

Edited by MKKJ

Share this post


Link to post
Share on other sites
OrionSR

The info below comes from the save file documentation, but the only new information appears to be Sphere Radius for the float at 0x18. Thisstructure never got the love that other structures received, but I've been meaning to fill in some of the blanks when the opportunity arose. I'd be willing to join the investigation. I should have a little more info stashed away somewhere - I think I've got notes on an allocation flag buried somewhere in a PM, and in later updates of the mobile versions (1.06+?) they added something like 50 or 75 to the pool size for no apparent reason. People have a lot of problems with stray blips left over after missions, and are frequently plagued by crappy cleo scripts that add the same icon over and over until the pool is stuffed full. But there are few tools to help manage the problem blips, and the lack of documentation probably has a lot to do with that.

 

Please, can we keep the original decimal offsets in your quote out of respect for the author but provide all future offset references in hex?

 

FYI, the entire marker pool is dumped as a complete structure into the save block and appears to have an identical structure as it does in memory.

 

From the SA Save File Wiki - http://www.gtamodding.com/wiki/Saves_(GTA_SA)#Block_9:_Markers

Marker structure:  0x00  dword         color  0x04  dword         entity handle this marker is attached to (opcodes 0186, 0187, etc)  0x08  float[3]      position X,Y,Z  0x14  word          index?  0x16  byte[2]       (Align)  0x18  float         sphere radius  0x1C  word          icon size  0x1E  byte[2]       (Align)  0x20  dword         (unknown)  0x24  byte          icon ID  0x25  byte[2]       unknown flags  0x27  byte          (Align)  0x28  end

Marler/Radar/Blip Icon IDs: MTA Wiki, SAMP Wiki

 

Hmm...The opcode database doesn't make it easy to identify a complete list of marker opcodes, It looks like the relevant opcodes are spread between blip, sphere and marker commands. I'll look into this more later. Opcode documentation should help out with the type field. Keep an eye out for a function to rebuild the radar pool. Sometimes it easier to work on a map without all the clutter.

Edited by OrionSR

Share this post


Link to post
Share on other sites
MKKJ

Very nice, it took me a while to understand but it's great when it finally makes sense.
More or less here's how the struct goes

Thanks to DK22Pac for the reference and Wesser which is credited in it.

Structure: RadarMarkerItem size: 0x28 (40 bytes)Pool start: 0xBA86F0Pool size: 175 itemsstruct RadarMarker {    +0        = Colour ID of blip                0 = Red                1 = Green                2 = Blue                3 = White                4 = Yellow                5 = Purple                6 = Cyan                7 = Threat/Friendly                8 = Destination    +4        = Pointer to Entity the marker is assigned to (ped/car/object, etc...)    +8        = X Position of marker (only for destination blips, not working for entity marker)    +12       = Y Position of marker (only for destination blips, not working for entity marker)    +16       = Z Position of marker (only for destination blips, not working for entity marker)    +20       = Unknown value (labeled as Index/TimesUsed)    +24       = Unknown float (labeled as SphereRadius)    +28       = Size of blip (opcode 0168)    +32       = Related to enex marker when the blip is in interior (probably pointer...)    +36       = Radar icon ID        +37       = Bunch of bitflags about blip properties below.        Bit 0 = Makes use of bright colors. Always set.        Bit 1 = Whether blip is exist or not        Bit 2 = If set, blips won't disappear if out of radar range        Bit 3 = Whether blip is marked as FRIENDLY and seems like only works for ColorID:7 (opcode 07E0)        Bit 4 = If set, marker will still appear after the entity's deletion        Bit 5 = Unused flag, always unset        Bit 6 = Marked as THREAT (Blip color is set to Red)        Bit 7 = Marked as FRIENDLY (Blip color is set to Blue)        +38       = More flags about blip properties        Bit 0 = Blip's radar display type (opcode 018B)                (It's a 2-bit value, not a bitflag)                0 = Don't show marker/blip                1 = Don't show marker                2 = Don't show blip                3 = Show both marker and blip                        Bit 2 = Type of assigned entity                (It's a 4-bit value, not a bitflag)                0 = None                1 = Car blip                2 = Ped/Actor blip                3 = Object blip                4 = Coordinate/Destination blip                5 = Contact Point (Marker+Sphere)                6 = Spotlight blip (Probably used in Amphibious assault and Black project)                7 = Pickup blip}

There's some left to figure out but probably already covered most of important bits.



And also


The file's here EDIT: Updated, now it reads and use RGB of game's colorID
Still far from perfect, like letter 0 for blip but at least works properly as coordinate marker for most missions like 2d era.

 

Another edit: The mod's already done

Edited by MKKJ

Share this post


Link to post
Share on other sites
OrionSR

I'm pretty sure I was able to manipulate the sphere radius by editing this field in a save and loading the save. I'm not sure what would happen if the radius of an active sphere was adjusted in memory. Maybe you'll have better luck altering the radius of a sphere that is farther away.

Share this post


Link to post
Share on other sites
MKKJ

I'm not sure, nothing seems changed when i alter its value.

In one of Wesser's reference it's also labeled as m_fUneffective0, so i thought this float is also a leftover.

Share this post


Link to post
Share on other sites
OrionSR
   +38       = More flags about blip properties        Bit 0 = Blip's radar display type (opcode 018B)        (...)                        Bit 2 = Type of assigned entity                (It's a 4-bit value, not a bitflag)  

Oooooh. I get it now. What a screwy way to encode these values. If they had swapped the order of entity type and radar mode then at least I could make sense of the nibbles. As it is I still need to display them as bits and tease out the values manually.

 

And, you and the references are correct. The radius float appears to do nothing. Changes persist but have no effect. I can only find one size of blip sphere. Anything larger or smaller are not associated with the marker structure -- usually controlled by a mission trigger script.

Edited by OrionSR

Share this post


Link to post
Share on other sites
Seemann

Regarding the +24 = Unused float value (labeled as SphereRadius).

It's a leftover from GTA III where it had a practical meaning. It was used for debugging purposes in conjunction with the CTheScripts::DbgFlag (00C3). When this flag is on, the game renders mission spheres in a special way as shown in the picture:
gta3_debug_lines1.jpg

A red arrow points to the purple cross which center is placed at the center of the blue cube. The cross lines are constantly moving and their offsets change from 1.0 to 5.0. I used CLEO to set the second value to 10.0 to see the difference. So on the left picture the purple lines are 10.0 units far from the center of the cube, and on the right picture they are 1.0 unit far. This offset is kept in the Blip+24 field and has the initial value of 1.0

Another example:
gta3_debug_lines2.jpg

I used the following CLEO script to test it:

{$CLEO}05df: write_memory 0x4393F0 size 1 value 1 virtual_protect 1  // set DbgFlag to 105df: write_memory 0x04A4B3B size 4 value 10.0 virtual_protect 1  // set hadrcoded maximum for debug cross to 10.005DC: end_custom_thread

The bottom line is that in Vice City/San Andreas this field is actually unused and does not relate to a marker sphere itself.

Share this post


Link to post
Share on other sites
MKKJ

Ooh yes that fancy III sphere, so thats what it was for.
Thanks for clarify, Wesser. That means it is confirmed a leftover.

 

 

Oooooh. I get it now. What a screwy way to encode these values.

lol, i know right?

Edited by MKKJ

Share this post


Link to post
Share on other sites
OrionSR

How do airport runway blips align with the direction of the runway?

 

How do I use the entity handle at +4? This doesn't look at all like a pointer. 1026 for that BMX at game start.

 

"Index" to describe the unknown word at +20 is likely a legacy of the early save file documentation -- where it's still labeled as "index?" with the question mark denoting a guess. Indexes are common in save file structures so all the pieces get put back into the right slot in the pool, But the marker structure is a complete dump so an index is unnecessary. These don't look at all like indexes; that description should be replaced. Times used? On a brand new save, empty records have a value of 1, new icons have a value of 2, and CJ's mission marker in Grove Street has a value of 3 -- not sure if it gets fiddled with or not yet. The blue marker on the BMX is deleted but has a few lingering values in the record.

 

Got any hints regarding the enex related field at +32?

Share this post


Link to post
Share on other sites
MKKJ

Looks like airport runways blip is handled elsewhere. It's iconID always 0 and only have XY Position defined.

I don't know how its assigned since i don't found anything in main.scm.

 

Entity handle is simply a value that is stored in variable and used to manipulate peds/cars/objects/pickups with opcodes. ex. $PLAYER_ACTOR

You can just get the CMarker +4 value to variable and manipulate it with usual opcodes (store pos, destroy, remove reference, etc...)

Just make sure to know what entity it is with +38 Bit 2 = Type of assigned entity

(EDIT: I got handle/pointer mixed up. Sorry if you actually try to point this out)

 

I just checked it, CMarker +20 is really how many times that blip index has been used.

It's starts at 1 and goes up for every new blips assigned to the index. The easiest way to see it is to buy a safehouse or restarting vehicle sidemissions. I don't know what's the point, though.

 

CMarker +32 most likely a pointer (or handle) to enex marker since its assigned with opcode 08DC, though i can't prove further.

 

Here's the updated summary of the struct

 

 

Structure: RadarMarkerItem size: 0x28 (40 bytes)Pool start: 0xBA86F0Pool size: 175 itemsstruct RadarMarker {    +0        = Colour ID of blip                0 = Red                1 = Green                2 = Blue                3 = White                4 = Yellow                5 = Purple                6 = Cyan                7 = Threat/Friendly                8 = Destination    +4        = Handle of entity the marker is assigned to (ped/car/object, etc...)    +8        = X Position of marker (only for destination blips, not working for entity marker)    +12       = Y Position of marker (only for destination blips, not working for entity marker)    +16       = Z Position of marker (only for destination blips, not working for entity marker)    +20       = How many blips created in this blip index    +24       = Unused float (leftover from GTAIII debug, related to sphere radius)    +28       = Size of blip (opcode 0168)    +32       = Pointer to enex marker (assigned with opcode 08DC)    +36       = Radar icon ID        +37       = Bunch of bitflags about blip properties below.        Bit 0 = Makes use of bright colors. Always set.        Bit 1 = Whether blip is exist or not        Bit 2 = If set, blips won't disappear if out of radar range        Bit 3 = Whether blip is marked as FRIENDLY and seems like only works for ColorID:7 (opcode 07E0)        Bit 4 = If set, marker will still appear after the entity's deletion        Bit 5 = Unused flag, always unset        Bit 6 = Marked as THREAT (Blip color is set to Red)        Bit 7 = Marked as FRIENDLY (Blip color is set to Blue)        +38       = More flags about blip properties        Bit 0 = Blip's radar display type (opcode 018B)                (It's a 2-bit value, not a bitflag)                0 = Don't show blips                1 = Don't show blip on radar                2 = Don't show blip above entity                3 = Show both blips                        Bit 2 = Type of assigned entity                (It's a 4-bit value, not a bitflag)                0 = None                1 = Car blip                2 = Ped/Actor blip                3 = Object blip                4 = Coordinate/Destination blip                5 = Contact Point (Marker+Sphere)                6 = Spotlight blip (Probably used in Amphibious assault and Black project)                7 = Pickup blip}

 

 

Edited by MKKJ

Share this post


Link to post
Share on other sites
DK22Pac

Blip handles (those which are commonly used in scripts) consist of 2 values - blip index and blip 'counter'.

 

 

struct tBlipHandle {    unsigned int arrayIndex : 16; // lower 16 bits, starts from 0    unsigned int counter : 16; // higher 16 bits, starts from 1}

A 'counter' is stored in blip's structure at offset +0x14.

 

 

tRadarBlip *GetBlipByHandle(tBlipHandle handle) {    tRadarBlip *blip = &CRadar::ms_RadarTrace[handle.arrayIndex];    if (blip->m_nCounter == handle.counter)        return blip;    return nullptr; // incorrect handle or blip doesn't exist anymore};
A value at tRadarTrace +0x4 is an entity handle, not a pointer.

 

And about airport runway blips, these blips have special type ID (8) and there's a special code to handle them.

 

Also, info about airports can be found at 0x8D06E0.

 

0x8D06E0 ; airstrip_info airstrip_table[4]    airstrip_info <1750.0, -2494.0, 180.0, 1000.0>; 0    airstrip_info <-1373.0, 120.0, 315.0, 1500.0>; 1    airstrip_info <1478.0, 1461.0, 90.0, 1200.0>; 2    airstrip_info <175.0, 2502.0, 180.0, 1000.0>; 3
First 3 values are x,y,angle(direction), not sure about 4th.

Share this post


Link to post
Share on other sites
Silent

First 3 values are x,y,angle(direction), not sure about 4th.

Radius? You need to be within X units for those blips to appear maybe?

Edited by Silent

Share this post


Link to post
Share on other sites
MKKJ

Sorry about whole pointer/entity thing, i got them mixed up when typing.

Yes, +4 is supposed to be entity handle, not pointer.

 

 

A 'counter' is stored in blip's structure at offset +0x14.

tRadarBlip *GetBlipByHandle(tBlipHandle handle) {    tRadarBlip *blip = &CRadar::ms_RadarTrace[handle.arrayIndex];    if (blip->m_nCounter == handle.counter)        return blip;    return nullptr; // incorrect handle or blip doesn't exist anymore};

So its for additional check to make sure it's the same blip and not another blip in same index.

I wonder if other handle use it too.

 

 

 

First 3 values are x,y,angle(direction), not sure about 4th.


Radius? You need to be within X units for those blips to appear maybe?

 

Doesn't seem like it. Airstrip blip always visible as long as player in a plane and only show nearest airstrip to player.

Edited by MKKJ

Share this post


Link to post
Share on other sites
DK22Pac

It's an airstrip length (or maybe animation time).

It affects airstrip icon animation (when you fly around airstrip).

 

Here what happens when changing 1500 to 50, for example:

jR2uI9E.gif

Edited by DK22Pac

Share this post


Link to post
Share on other sites
OrionSR

From the Intro mission at new game start:

00A5: $60 = create_car #BMX at 2246.508 -1263.087 22.9531 0186: $61 = create_marker_above_car $60 

As predicted, $60 matches the value of the handle field at blip offset +4. I think I've got a handle on this now. Thanks.

 

And the mystery of the runway blips sounds resolved. That's a question I've been pondering for quite a while. Thanks again.

 

So... Not sure what to do with this one yet.

+32       = Pointer to enex marker (assigned with opcode 08DC)

Not a pointer in the save file. For a single example ($582; Triads at 4 Dragons), it looks like it's the enex index +1 -- so the blip records 148 for 148th enex at index 147.

Yeah, works for the mafia icon in Caligula's as well; enex index 145 is recorded as 146 in the blip record.

 

Enex indexes are used to record the links between enexes in the save file, so find it strange that a different numbering system is used here. I guess they needed to avoid index 0. Enex documentation that includes indexes can be found in the SA Enex Documentation topic.

Edited by OrionSR

Share this post


Link to post
Share on other sites
MKKJ

Yeah thanks, i think i just figured it too. +32 is indeed pointer to address of streamed enex in index.

Going to this address reveals the enex struct as you posted, 60 bytes long for each marker.

Share this post


Link to post
Share on other sites
OrionSR

Oh wait. You probably are getting a direct pointer to the enex when examining the blip in memory. The enex index +1 values I'm reading are from the save file. That makes sense. A pointer to a dynamic memory location wouldn't help the save file at all. I guess the marker block isn't the exact copy of the memory pool I thought it was.

Edited by OrionSR

Share this post


Link to post
Share on other sites
Seemann

Oh wait. You probably are getting a direct pointer to the enex when examining the blip in memory. The enex index +1 values I'm reading are from the save file. That makes sense. A pointer to a dynamic memory location wouldn't help the save file at all. I guess the marker block isn't the exact copy of the memory pool I thought it was.

They replace an enex pointer at 0x20 with index+1 before dumping the whole blip struct into a save file, then restore back the pointer value.

An index value of 0 means no enex is associated with the current blip.

Share this post


Link to post
Share on other sites
OrionSR

Nit picking the language used to describe bits 0 and 1 at +0x26 of the marker structure:

 

In the updated description of the marker structure the word "blip" is used to describe the radar icon and the in-game marker "above the entity." The in-game marker can also be the sphere for destination marker types. I always associate a blip with a radar ping; something displayed on the radar or game map. Marker seems like a good description of either a target arrow above the entity, or a sphere for destinations.

    +38       = More flags about blip properties        Bit 0 = Blip's radar display type (opcode 018B)                (It's a 2-bit value, not a bitflag)                0 = Don't show blips                1 = Don't show blip on radar                2 = Don't show blip above entity                3 = Show both blips

I appreciate the positive nature of these descriptions.

enum eBlipDisplay {    BLIP_DISPLAY_NEITHER,    // 0    BLIP_DISPLAY_MARKERONLY, // 1    BLIP_DISPLAY_BLIPONLY,   // 2    BLIP_DISPLAY_BOTH        // 3

How is this different than bit flags? These settings could easily be read or set using bit operations.

  bit 0 = display marker  bit 1 = display blip

From a coding perspective, it makes more sense to enumerate this value as that's how the radar mode opcode has been defined for so long, but given the true if 1 nature of bit flags, I'd like to argue in favor of positive descriptions.

 

Added: If these were disable flags then 0 would be disable nothing and 3 would disable both, the opposite of the observable effect.

Edited by OrionSR

Share this post


Link to post
Share on other sites
MKKJ

Many thanks to DK22Pac, Wesser and OrionSR for helping in this topic. :colgate:

We have document almost everything about blip struct.

 

Here's the updated summary so far.

 

 

Feel free to document this elsewhere, if there's more to add or correct, keep them coming.

Structure: RadarBlipItem size: 0x28 (40 bytes)Pool start: 0xBA86F0Pool size: 175 itemsstruct RadarBlip {    +0        = Color ID of blip                0 = Red                1 = Green                2 = Blue                3 = White                4 = Yellow                5 = Purple                6 = Cyan                7 = Threat/Friendly (Default Red)                8 = Destination  (Default Yellow)    +4        = Handle of entity the blip is assigned to (ped/car/object, etc...)    +8        = X Position of blip (not working for entity blips)    +12       = Y Position of blip (not working for entity blips)    +16       = Z Position of blip (not working for entity blips)    +20       = How many blips created in this blip index    +24       = Unused float (leftover from GTAIII debug, related to sphere radius)    +28       = Size of blip (opcode 0168)    +32       = Pointer to streamed enex marker (assigned with opcode 08DC)                *In save file struct, it contains enex index+1 instead    +36       = Radar icon ID        +37       = Bunch of bitflags about blip properties below.        Bit 0 = Makes use of bright colors. Always set.        Bit 1 = Whether blip is exist or not        Bit 2 = If set, blips won't disappear if out of radar range        Bit 3 = Whether blip is marked as FRIENDLY and set blip color to blue (for ColorID:7, set by opcode 07E0)        Bit 4 = If set, marker will still appear after the entity's deletion        Bit 5 = Unused flag, always unset        Bit 6 = Marked as THREAT (Blip color is set to Red)        Bit 7 = Marked as FRIENDLY (Blip color is set to Blue)        +38       = More flags about blip properties        Bit 0 = Blip's radar display type (It's a 2-bit value, but can be read as bitflag)                As 2-bit value (value assigned by opcode 018B)                0 = Don't show blip and marker                1 = Show marker above entity only                2 = Show blip on radar only                3 = Show both blip and marker                As bitflag                Bit 0 = Show marker above entity                Bit 1 = Show blip on radar                 Bit 2 = Type of assigned entity (It's a 4-bit value, not a bitflag)                0 = None                1 = Vehicle blip                2 = Ped/Actor blip                3 = Object blip                4 = Coordinate/Destination blip                5 = Contact Point (Marker+entity)                6 = Spotlight blip (Only used in Amphibious assault)                7 = Pickup blip                8 = Airstrip blip}

 

 

 

EDIT: Since this topic moved to Documentation section, first post has updated.

 

Also, apparently +0 (ColorID) doesn't have to be ID. It can also contains RGBA value for custom colors.

 

Gang member blips use this in gang war.

Example: Grove St. blip Color is 0x46C800FF while Ballas is 0xC800C8FF

Edited by MKKJ

Share this post


Link to post
Share on other sites
Hollow Anderson

Hello, I want to share an adress than I found, is about the green color of radar when you enter in a plane, I found this adress long time ago using Cheat engine 5.5 but I decided publish it until now :p
In the imagen below we can se than the green section is below the texture named "radarRingplane" from hud.txd. And it moves according to the plane position.

Prueba2.jpg




The adress of the green color is: 0x586A7E (175 Default Value)
The alpha for this green is: 0x586A72 (200 Default Value)
I don't know too much about coding but I think the value of these two are 4 bytes.

When I found these adresses I wanted change the green for another color like orange or purple, but I didn't found an adress for red or blue, just green.
I kept changing adresses one by one around these two looking for changes but nothing happened.
Here are the last adresses than I changed: 00586C3A (+) and 00586A05 (-)

Here are pictures of some experiments than I made:

150_green_100_aplha.jpg

150 Green 100 Alpha


0_green_255_aplha.jpg

0 Green 255 Alpha
In this last pic you can notice than is not totally black the color, Is like a very dark purple but as I mentioned before, I dind't found addresses of Red or blue...(X files music)

I hope than you can find a way to change this ugly green color :) (Sorry for my bad english, I keep learning)

Share this post


Link to post
Share on other sites
DK22Pac

When we want to find 'an address' in GTA executable, we don't use CheatEngine.

We use IDA only.

 

0x586AB9 is an address where CRGBA constructor for 'green plane' color is called.

 

uNlodgu.png

 

You can use these addresses to change R,G,B,A values:

 

0x586A88 Red   ; 20  (1 byte)0x586A7E Green ; 175 (4 bytes)0x586A7A Blue  ; 20  (1 byte)0x586A72 Alpha ; 200 (4 bytes)
Edited by DK22Pac

Share this post


Link to post
Share on other sites
Hollow Anderson

When we want to find 'an address' in GTA executable, we don't use CheatEngine.

We use IDA only.

 

0x586AB9 is an address where CRGBA constructor for 'green plane' color is called.

 

uNlodgu.png

 

You can use these addresses to change R,G,B,A values:

0x586A88 Red   ; 20  (1 byte)0x586A7E Green ; 175 (4 bytes)0x586A7A Blue  ; 20  (1 byte)0x586A72 Alpha ; 200 (4 bytes)

 

 

OH, that was fast... thanks man. Finally I can change that ugly color!

I already made some experimets...

 

 

prueba3.png

 

 

 

 

PRUEBA4.png

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using GTAForums.com, you agree to our Terms of Use and Privacy Policy.