Stealth22

Ped.GiveNewWeapon was deprecated in RPH 34, I think. myPed.Inventory.GiveNewWeapon(new WeaponDescriptor("WEAPON_PISTOL"), 56, false); 56 = the ammo count, and false means they don't have the weapon in their hand. (Change to true to make them hold it in their hand)

Yeah, that's alright too, as long as its a class in your project, not just a referenced DLL. I have more experience with VB.NET, but I think that should be fine. If there is any doubt, you can just fall back to GetExecutingAssembly(). It might work for referenced DLL's too, but if a user has a weird version installed, or that dependency is just plain missing, then it might throw an exception. That's why I prefer to check the file version directly. It allows you to display a message like, "RageNative UI not found!" if the File.Exists check fails, and then you can check the version number and display a warning if its too old. Also, just to clarify, use the CompareTo function of the Version class; that way, you can just check for a minimum version, and not have the version check fail if the user has a newer version installed than what you're looking for. (i.e. requiredVersion.CompareTo(installedVersion) returns 1 if the installed version is too old...I believe it returns 0 if they are the same, and -1 if the installed version is newer)

Sorry, I should have clarified. Assembly.GetName() is okay, as long as its done properly. For example: Assembly assembly = Assembly.LoadFrom("MyAssembly.dll"); Version ver = assembly.GetName().Version; is WRONG. The reason is, the LoadFrom function loads MyAssembly.dll into the AppDomain, which is a bad idea. It could cause an issue, and wastes memory. What you want to do is this: // Get the file version for the notepad. FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo("RagePluginHook.exe"); // Or..... FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo("Plugins\LSPD First Response.dll"); // Print the file name and version number. Console.WriteLine("File: " + myFileVersionInfo.FileDescription + '\n' + "Version number: " + myFileVersionInfo.FileVersion); And if you want to get your OWN assembly's version... System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly(); FileVersionInfo fvi = FileVersionInfo.GetVersionInfo(assembly.Location); string version = fvi.FileVersion; // You can also do assembly.GetName().Version -- This gets you the assembly version, whereas the above code gets you the file version // For our purposes, they are going to be the same, as long as you make them the same in your Application Properties. I personally code in VB.NET for my plugins, so I just use My.Application.Info.Version. There is no such property in C#, but the research I have done says that GetExecutingAssembly is the correct way of doing it. You can use either Assembly.GetName().Version (as long as you don't use Assembly.LoadFrom!) or FileVersionInfo for your own DLL version, as they will be the same value 99% of the time. But if you're checking a different DLL/EXE (i.e. anything but the executing plugin), its better to use FileVersionInfo.GetVersionInfo(), and then use the FileVersion property. Its way less overhead than System.Reflection. See the following Stack Overflow posts for more details (Disclaimer: The code snippets above are from the following two links) http://stackoverflow.com/questions/1755504/programatically-get-the-version-number-of-a-dll http://stackoverflow.com/questions/909555/how-can-i-get-the-assembly-file-version EDIT: Make sure you call File.Exists(pathToAssembly), which returns true/false, first. If you try to check the version of a file that does not exist, you're going to get an exception, lol. And the File class is under the System.IO namespace, FYI, so you'll need to add "using System.IO;" at the top of your code file.

Nice looking truck! Can't wait to see that in a police version! Do you know if that model allows peds to sit in the back seat? I can imagine that going in my SHERIFF2 slot (I have yet to find a decent Tahoe out there), haha. But if not, a standalone slot will do just fine!

Here's another one. Check your DLL references on startup!! It's good practice, it reduces crashes, and it makes your users smarter!! Not to mention it reduces the number of support requests that make you pull your hair out. And PLEASE, for the love of God, do NOT use the Assembly class to load a DLL into memory JUST to check it's version number. You're loading a DLL twice by doing that, and wasting valuable memory. Use the GetVersionInfo function of the FileVersionInfo class instead.

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.

LSPDFR does not use RageNative UI. You probably need to update Traffic Policer or another mod you've got that uses RageNative UI.

Unrelated question...I haven't updated to GTA V version 617 yet. Holding onto 573 as long as I can, lol. But each update, they change something in update.rpf...in the past, if I don't replace update.rpf in my mods folder with the new one (and as a result, reinstall every mod that was in there!), I get a CTD on startup. I'm assuming that each GTA V update, I'll have to remember to re-add the EUP line in the dlclist.xml, correct?

I wonder if its something else conflicting with it. I'll try to get you a log file tonight, but this week is going to be pretty busy for me. EDIT: Do you have me on Skype?

I know...I'm being a user today lol. The laptop is at home (and I'm not), so that's why I don't have access to them right now. I just wanted to post here so I don't forget about it, cause otherwise I will. I was hoping it might at least give you a test case to try until then, or maybe you'd get a "eureka!" moment when looking at the source code. I'll have to test some more, but I remember while playing yesterday, if I got into the cruiser, and then hit any sort of button (police computer, driving forward, etc) too quickly, I'd get warped out of the car. I thought I remember you saying that you couldn't duplicate that bug, but maybe give that a try in your testing.

I still get crashes when switching between vehicles. I keep forgetting to grab the log file though, so I'll try to remember to grab a snapshot of it for you. I also get warped out of the vehicle if I press a key too fast after entering it. I've found that if I sit in the car and wait a few seconds before driving or pressing any keys, it works fine. Again, I'll get you a log file ASAP.

There's a list of anims in the RPH documentation.

MulleDK19 recently fixed something with vehicle passengers in RPH. Maybe check out RPH 36. As for the bus textures, you can create a custom DLC pack, like Alex_Ashfold did with EUP. It's not difficult...basically you'd create a DLC pack of your own, with custom bus models included. Then you can spawn them with your mod. Bingo, you've got buses with custom route displays.

You can't call your Process function from Rage Native UI. In fact, you don't call it at all, LSPDFR does. Your callout class should not be static. Think of static classes as one entity. You can't create an instance of a static class. Non static classes, you have to create an instance of in order to use. I'm on my phone at the moment, so I can't explain it to you in much detail. I suggest you look up some C# tutorials to get an idea of the terminology. You can also check out the examples in the GitHub repository.

See my inheritance example on the GitHub repo: https://github.com/LMSDev/LSPDFR-API/tree/master/API%20Examples/InheritanceExample I've got a callout state enum in there. Its in the CalloutBase class, which is inherited by each of the callout classes.

Press CTRL + T during one of my callouts.

What Luke said. You'll have to not set him as a cop...that should stop LSPDFR from taking control of him. But as Luke said, I don't know what else that will have an effect on.

I forgot to post about this... About 2 weeks ago, I went ahead and created a new mods folder, and started installing my mods from scratch. The hash problem went away, so I'm pretty sure I screwed something up when installing those standalone vehicles. Last night, I just reinstalled the Explorer as a standalone vehicle, but this time I did it in a new custom DLC pack, to keep things clean. I didn't have a chance to see if the hash thing is back, but chances are, the vehicle names should still be fine. It was only one vehicle, with a completely new name and everything.

This is not meant to be rude, or under-value any of the work by the developers above...but to be honest, you have overlooked quite a few scripts. There's EUP by @Alex_Ashfold, just to name one.