Hi, I'm developing a callout pack for lspdfr and I'm looking a way to turn on a vehicle's hazard lights or indicators. I don't care if I have to use another API that is not rageplugin or lspdfr api. Thank you.

Edited January 13, 20197 yr by mmods
I forgot to write a word.

I imagine you would call this native:

 

6 hours ago, willpv23 said:

I imagine you would call this native:

 

Thanks but how can I implement this on my script?

RAGEPluginHook also exposes this native directly within the Vehicle class. You can use:

 

https://docs.ragepluginhook.net/html/P_Rage_Vehicle_IndicatorLightsStatus.htm

 

To set both lights as visible, use VehicleIndicatorLightsStatus.Both. As far as I know, GTA V does not have a native hazard light function, so you'd have to process this between VehicleIndicatorLightsStatus.None and VehicleIndicatorLightsStatus.Both to create the effect that the lights are flashing.

Edited January 13, 20197 yr by liverlande

1 hour ago, liverlande said:

RAGEPluginHook also exposes this native directly within the Vehicle class. You can use:

 

https://docs.ragepluginhook.net/html/P_Rage_Vehicle_IndicatorLightsStatus.htm

 

To set both lights as visible, use VehicleIndicatorLightsStatus.Both. As far as I know, GTA V does not have a native hazard light function, so you'd have to process this between VehicleIndicatorLightsStatus.None and VehicleIndicatorLightsStatus.Both to create the effect that the lights are flashing.

Thanks for the support. I have tried this and it worked for me.

NativeFunction.CallByName<uint>("SET_VEHICLE_INDICATOR_LIGHTS", vehicle1, 0, true);
NativeFunction.CallByName<uint>("SET_VEHICLE_INDICATOR_LIGHTS", vehicle1, 1, true);

 

please stop using NativeFunction.CallByXYZ as it causes performance issues, use NativeFunction.Natives.NATIVE_NATIVE instead.

27 minutes ago, NoNameSet said:

please stop using NativeFunction.CallByXYZ as it causes performance issues, use NativeFunction.Natives.NATIVE_NATIVE instead.

 

I'm not sure where you got that information, but it is not true. The fastest way to call a native is calling it by hash, as that removes the overhead from converting from a string to a hash first. CallByName will also still be faster than using Natives as there is no runtime binding. I am not saying that the differences are big (they are in fact almost non-existent), but dynamic invocation will always be the slowest just due to the nature of how it works. It's the same as having a static call or a VTable call, of course there is no big difference, but ultimately the indirection will cost you a few cycles.

1 hour ago, NoNameSet said:

please stop using NativeFunction.CallByXYZ as it causes performance issues, use NativeFunction.Natives.NATIVE_NATIVE instead.

 

38 minutes ago, LMS said:

 

I'm not sure where you got that information, but it is not true. The fastest way to call a native is calling it by hash, as that removes the overhead from converting from a string to a hash first. CallByName will also still be faster than using Natives as there is no runtime binding. I am not saying that the differences are big (they are in fact almost non-existent), but dynamic invocation will always be the slowest just due to the nature of how it works. It's the same as having a static call or a VTable call, of course there is no big difference, but ultimately the indirection will cost you a few cycles.

 

I agree with LMS.

 

I believe when we call "NativeFunction.Natives.NATIVE_NATIVE", it will call "NativeFunction.CallByHash" at the end, because all those native functions are represented by HASHES in the lower level.

 

And I also believe that RPH has a map that convert a native names into hashes.

 

If we talk about the best performance, I think ""NativeFunction.CallByHash" is the best one.

 

 

Edited January 14, 20197 yr by Pazzi

36 minutes ago, LMS said:

 

I'm not sure where you got that information, but it is not true. The fastest way to call a native is calling it by hash, as that removes the overhead from converting from a string to a hash first. CallByName will also still be faster than using Natives as there is no runtime binding. I am not saying that the differences are big (they are in fact almost non-existent), but dynamic invocation will always be the slowest just due to the nature of how it works. It's the same as having a static call or a VTable call, of course there is no big difference, but ultimately the indirection will cost you a few cycles.

weird, I remember something being said that it was causing fps issues a while ago. 

Anyway glad it's fine and thanks for the info, truly thought there was an issue with it though.

12 minutes ago, Pazzi said:

I believe when we call "NativeFunction.Natives.NATIVE_NATIVE", it will call "NativeFunction.CallByHash" at the end, because all those native functions are represented by HASHES in the lower level.

 

And I also believe that RPH has a map that convert a native names into hashes.

 

That is correct. It works like this Dynamic -> Name -> Hash -> Address. Ultimately you want to call the address. So if you call with a hash already you can skip the first two lookup stages.

 

11 minutes ago, NoNameSet said:

weird, I remember something being said that it was causing fps issues a while ago. 

Anyway glad it's fine and thanks for the info, truly thought there was an issue with it though.

 

No problem, most of the time FPS issues come from calling an expensive native way too often.