V1 Feature Request: Allow sprite color overwriting

[alberttheprince]

Sprite color can't be overwritten, so you can't customize points to indicate different functions. For example, using this for garages, you can't mark red/green pull out/put in locations.

This was helpful for differentiating different points and acting in a way that markers worked.

[DemiAutomatic]

once again we somewhat come to the issue of there is no parent to the options anymore. each option defines its own set of rules and is just displayed with other options that fit the same context (this is the same way ox_target works). what if there are 5 different options for a context and each option defines a different sprite color?

[Manason]

That would be up to the caller to deal with the ambiguity, no? Since each option with offsets can be at its own coordinate. The caller would need to avoid setting sprites at the same coordinate to two different colors. sleepless_interact could handle that by picking the first or last one in the options list to be the dominant color.

[DemiAutomatic]

i guess one of the main issues i am thinking is if some escrowed garbage is setting colors/distances on things that effect other unrelated options that may appear in that same context/grouping

[Manason]

I'm a bit confused by the concern. Is that a scenario where an escrowed script is setting colors/distances at the same coordinate as a non escrowed script is? Or are you just saying that an escrowed script could not use the API as intended?

[DemiAutomatic]

well it wouldnt just be for coordinates. it could be for global entities/objects/peds/players

as well as it feels weird to have one option internally making decisions for other unrelated options in the group

[Manason]

Isn't the idea of an option first design that each option is independent from the others? How are option previews "combined" in today's world? Is there a minimum distance they need to be apart for each other to see them as two different options?

i.e. if I added two options to the same entity, each with its own offset, I'd expect to see two different sprites.

[DemiAutomatic]

yes but if 2 different scripts add an option to the same entity or same entity bone they now get grouped together (same way ox_target works) it is true that offsets get their own identifier for what should be grouped with it. one of the main complaints of v1 was the lack of grouping interacts for the same context. for example if you have a script that does something globally for vehicles and then you have another script that adds a specific option to a specific verhicle, in v1 you would have 2 separate overlapping interacts at the root of that vehicle (assuming no bones or offets were used) in v2 it would now just check through all options (global and specific) and group those together into a single interactable location. this is similar to how target groups all options for whats valid.

[DemiAutomatic]

interact.addGlobalVehicle({
    {
       label = 'global option',
       spriteColor = 'green'
    }
})


local netId = NetworkGetNetworkIdFromEntity(some_net_vehicle_entity)

interact.addEntity(netId, {
    {
       label = 'entity option',
       spriteColor = 'red'
    }
})

this is a rough quick example.

[Manason]

For our use case, we wouldn't run into conflicts, since it is a coords interact specific to our resource. In the case of a conflict, detecting that and printing a warning could suffice as a way to handle it.