12 minutes ago, LtFlash said:

@alexguirre You are a legend. Thanks!

Not really, who added all the new stuff was Guad for NativeUI, I just changed few things to make it work with RAGENativeUI  

LSPDFR crash while going on duty since I updated RAGENativeUI, I found this in the log: 

Spoiler

LSPD First Response: Exception message: No se puede cargar el tipo 'RAGENativeUI.Elements.MenuListItem' del ensamblado'RAGENativeUI, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null'.

I will attach the entire log :)

RagePluginHook.log

6 hours ago, Mercuri said:

LSPDFR crash while going on duty since I updated RAGENativeUI, I found this in the log: 

  Hide contents

LSPD First Response: Exception message: No se puede cargar el tipo 'RAGENativeUI.Elements.MenuListItem' del ensamblado'RAGENativeUI, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null'.

I will attach the entire log :)

RagePluginHook.log

Update Traffic Policer.

For any devs using RageNative UI, are you guys checking the DLL version on startup? I know that Alex changed some of the class names recently, so it would break a few plugins if they aren't updated.

As a rule, you should be checking file versions on EVERY dependency of your plugin. This includes RPH, LSPDFR, RageNative UI, and any other DLL referenced by your project that needs to be present in the GTA V directory.

Now that being said, some of them will still crash on startup if .NET goes to use/reference them when your plugin is loaded. But in most cases, it should at least let you exit the plugin gracefully without crashing.

EDIT: And please, don't follow examples on the internet that use the Assembly class to check the version number. By doing that, you're loading the DLL into memory a second time, and wasting system resources. See my post in the Tips for Developers thread in the API forum on how to check a file version efficiently.

Edited February 8, 201610 yr by Stealth22

I have a user who's testing my Custom Backup mod reporting that the RageNativeUI menu is hyper-sensitive to key/controller input. Apparently, pressing enter causes the action to register multiple times, and switching between list options with right/left arrows scrolls too quickly to easily select an option. I haven't been able to replicate this behavior myself, although I had seen this happen in PoliceToolbox before (which may not have even been using RageNativeUI). The user isn't having this issue with other RageNativeUI plugins. 

Has anybody seen this happen? Any ideas on what might be causing it, why it only happens for some users, and what I can do to prevent it from happening? 

I haven't looked at the code in a while, nor have I used it in my plugins yet. But is the menu perhaps getting registered twice? 

On 11/2/2016 at 1:20 AM, PNWParksFan said:

I have a user who's testing my Custom Backup mod reporting that the RageNativeUI menu is hyper-sensitive to key/controller input. Apparently, pressing enter causes the action to register multiple times, and switching between list options with right/left arrows scrolls too quickly to easily select an option. I haven't been able to replicate this behavior myself, although I had seen this happen in PoliceToolbox before (which may not have even been using RageNativeUI). The user isn't having this issue with other RageNativeUI plugins. 

Has anybody seen this happen? Any ideas on what might be causing it, why it only happens for some users, and what I can do to prevent it from happening? 

Yes, the input is a bit more sensitive that what it should be, especially while going right/left in the list items, I don't know what is causing this or if it also happens in the Scripthook.Net NativeUI. 
And pressing enter never registered multiple times for me, your tester maybe went on-duty, off-duty and again on-duty and your menu might has been registered twice as Stealth22 said.

Edited February 12, 201610 yr by alexguirre

13 hours ago, Stealth22 said:

I haven't looked at the code in a while, nor have I used it in my plugins yet. But is the menu perhaps getting registered twice? 

 

11 minutes ago, alexguirre said:

Yes, the input is a bit more sensitive that what it should be, especially while going right/left in the list items, I don't know what is causing this or if it also happens in the Scripthook.Net NativeUI. 
And pressing enter never registered multiple times for me, your tester maybe went on-duty, off-duty and again on-duty and your menu might has been registered twice as Stealth22 said.

Good suggestion to look into the issue of going on/off duty possibly creating multiple menus. I'll check into that. Thanks for the feedback guys. 

RAGENativeUI has been updated to version 1.3.1

Small update for some bugfixing.

 Changelog

• Fixed UIMenu.SetMenuWidthOffset() throwing NullReferenceException.
• Fixed UIMenu.IsUsingController using wrong syntax.

On 3/29/2016 at 8:37 AM, alexguirre said:

RAGENativeUI has been updated to version 1.3.1

Small update for some bugfixing.

 Changelog

• Fixed UIMenu.SetMenuWidthOffset() throwing NullReferenceException.
• Fixed UIMenu.IsUsingController using wrong syntax.

Is this backwards compatible to 1.3.0? I.e. will it break plugins compiled against 1.3?

1 hour ago, PNWParksFan said:

Is this backwards compatible to 1.3.0? I.e. will it break plugins compiled against 1.3?

It is, but maybe it isn't compatible if you were using UIMenu.IsUsingController in your code because of the changed syntax, I haven't tested this

5 hours ago, alexguirre said:

It is, but maybe it isn't compatible if you were using UIMenu.IsUsingController in your code because of the changed syntax, I haven't tested this

Gotcha. I was not using IsUsingController. Can you give an example of a practical use for that method? I don't play with a controller myself. 

I do check the version on startup and warn the user if it doesn't match the expected version, but I don't force-quit the plugin since most small updates don't break backwards compatibility. I'll include the latest version in my next release. 

Thanks for your ongoing work on this useful tool!

22 minutes ago, PNWParksFan said:

Gotcha. I was not using IsUsingController. Can you give an example of a practical use for that method? I don't play with a controller myself. 

I do check the version on startup and warn the user if it doesn't match the expected version, but I don't force-quit the plugin since most small updates don't break backwards compatibility. I'll include the latest version in my next release. 

Thanks for your ongoing work on this useful tool!

IsUsingController returns true if the last input was from a controller or false if it was from the mouse or keyboard. In RAGENativeUI it's used to correctly handle the input, for example, don't draw or detect the mouse cursor if the player is using the controller.

hi, i do use a controller for LSPDFR, is RagenativeUI still gonna work for traffic control or should i stay with 1.3 ??

9 minutes ago, joe25 said:

hi, i do use a controller for LSPDFR, is RagenativeUI still gonna work for traffic control or should i stay with 1.3 ??

It should be compatible with every plugin unless the author added a version check that prevents you from using different versions of RAGENativeUI. You can stay one or two days with 1.3 to be sure that the author knows of this update and he will be the one to say if it's compatible or not.

Edited April 2, 201610 yr by alexguirre

38 minutes ago, alexguirre said:

IsUsingController returns true if the last input was from a controller or false if it was from the mouse or keyboard. In RAGENativeUI it's used to correctly handle the input, for example, don't draw or detect the mouse cursor if the player is using the controller.

Personally I don't like the cursor showing up because it resets your view to behind the player and you can't aim with a menu open. Can you add a method to disable displaying the cursor? Then plugin authors could put cursor on/off in their INI file or just disable it when they think it's appropriate. 

30 minutes ago, PNWParksFan said:

Personally I don't like the cursor showing up because it resets your view to behind the player and you can't aim with a menu open. Can you add a method to disable displaying the cursor? Then plugin authors could put cursor on/off in their INI file or just disable it when they think it's appropriate. 

You can already do that, if I recall correctly you set the properties UIMenu.AllowCameraMovement to true and UIMenu.MouseControlsEnabled to false. This will allow you to move the camera and won't draw the cursor but I don't think this allows you to shoot, you will have to set UIMenu.ControlDisablingEnabled to false.

EDIT: I did a quick check at the source code and setting MouseControlsEnabled to false should allow you to aim and shoot.

Edited April 2, 201610 yr by alexguirre

4 minutes ago, alexguirre said:

You can already do that, if I recall correctly you set the properties UIMenu.AllowCameraMovement to true and UIMenu.MouseControlsEnabled to false. This will allow you to move the camera and won't draw the cursor but I don't think this allows you to shoot, you will have to set UIMenu.ControlDisablingEnabled to false.

so the only way to shoot and remove cursor is to disable controller completely on the Menu?

Edited April 2, 201610 yr by joe25

1 minute ago, joe25 said:

so the only way to shoot and remove cursor is to disable controller completely on the Menu?

No, that depends on the way the devs set up their menus, there I'm explaining how the devs can disable the cursor.

oh, this is how they configure it ?

im hoping that LSPDFR can be modified to use the controller for the End callout menu