yaucpthomas

Get the perfect pull over location, even on the highway!

I thought it might be a nice idea to add a LSPDFR GitHub repo, where we (this explicitly includes you!), could maintain some general helper library specially for policing related modifications. This could cover things like the Vector3Extensions and other stuff like useful callout positions you guys mentioned somewhere. I would give a few of you admin as well, as I won't be able to manage it all the time. Pretty much depends on whether you think you would contribute there. Let me know.
Just like LCPDFR, examples would also go there.
What do you think?

So being that I am a software developer for a living, I thought I would create this thread to share some tips with fellow developers...especially those who are new.
Anyone can contribute to this topic...I myself am a newbie when it comes to RAGE Plugin Hook and LSPDFR. So anything useful that you come across, feel free to post it!
Some of what I have written below may not make sense to a new programmer, so if you have questions, or it seems like I am speaking Martian, feel free to ask questions!!
I'll start off by saying...
ORGANIZE YOUR CODE!! This means folders and namespaces for just about everything. Don't keep all your classes at the root level, and do not, for god's sake, do every part of your code in the Main class. Feel free to ask questions about this if you are confused, but LukeD's example API is a great way to start with namespaces.
  Take advantage of inheritance and polymorphism! Use base classes and interfaces for everything! (Callouts, pedestrians, vehicles, etc) For example, I have started on the framework for my callout plugin. I have a CalloutBase class, which inherits the LSPDFR Callout class, and it has all of my method overrides. The overridden methods in CalloutBase perform any actions which are common to all of my callouts. Each callout type will have its own class, which would, you guessed it: inherit the CalloutBase class. My CalloutBase class implements my "ICalloutBase" interface. The interface is for declaring methods or properties that CalloutBase may not be able to do anything with, but if you use the abstract keyword in C# (or MustOverride in VB.NET), then each callout class/type you create would have it's own set of actions for that function. For example, my ICalloutBase interface declares a method called "OnArrivalAtScene()". The CalloutBase class implements this as an abstract method, meaning, any class that inherits CalloutBase (say, ShotsFiredCall, for example) has to have a method called "OnArrivalAtScene", which would be a set of actions for the program to take when the officer arrives on scene OF THE SHOTS FIRED CALL ONLY. The abstract method I just created would be called in the Process() method of the CalloutBase class. Remember, Process() is an LSPDFR method that is called continuously. CalloutBase performs actions which are common to ALL callouts, including calling the OnArrivalAtScene() method. In CalloutBase.Process(), I check to see if the player's location is getting close to my callout location. If so, and if the callout state is still "Unit Responding", then OnArrivalAtScene() is called, and the state is changed to "At Scene". Now, when you create a ShotsFiredCall class, there is no need to call OnArrivalAtScene() from ShotsFiredCall.Process(), because CalloutBase.Process() has already done it for you! The example I stated above requires you to track the state of the callout (i.e. Dispatched, Unit Responding, At Scene, Call Completed, Call Cancelled, etc), but it just gives you an idea on how efficient you can make your code. Its a bit of legwork in the beginning, but it pays off BIG TIME as your plugin grows and matures. Using base classes and interfaces is not only useful for Callout classes. You can use them to track which Peds are suspects, and which are civilians, or what role a certain vehicle plays in your callout. You can add properties to Peds that don't exist in the Rage Plugin, like "MyPlugin.MySuspect.IsBankRobber", for a simple example.
  ERROR HANDLING!! Always, always, ALWAYS use proper error handling. One bad block of code can crash a user's entire game. Use Try...Catch blocks, and use the Catch block to log exceptions, so that when a user says "Your plugin is shit!!", then their log file will tell you what is wrong. Always use Ped.Exists or Vehicle.Exists (I think its called Exists for cars) to make sure that GTA V has not disposed of your object. GTA V does not mess around in terms of garbage collection and memory management. Always check if an object is null, and then if it has an Exists property, check that as well.
  ANYONE CAN CODE!! VB.NET and C# are both very easy to learn. It does take years to master programming, and a university education in Computer Science or Software Engineering definitely helps. But if you're a newbie, and want to learn, jump in with both feet! Search Google for tutorials, or buy a book at your local book store. I guarantee that you can write a Hello World! program in less than 5 minutes!
  VISUAL STUDIO IS FREE!! That's right! Visual Studio Community Edition 2013 is completely free. It doesn't have all the features that the pros use, but who cares? You aren't a software company!
  USE A CODE REPO AND SOURCE CONTROL!! When you download Visual Studio Community, you get the option of creating a Visual Studio Online account. DO IT! Visual Studio Online gives you free and unlimited access to code repositories where you can store and back up your code. If any programmers are reading this, they provide both TFS and Git based repos. Source Control allows you to keep track of each change you make to your code. Last update crashed everyone's GTA? No problem, just roll back your changes! Computer hard drive crash? Laptop stolen? No problem! Once you're up and running, install Visual Studio again, connect to your code repo, and all your code is back! For those that use TFS, you can create work items for yourself to track all changes that you need to make to your plugin. Each time you check in code, you can tie a set of changes (called a changeset) to a specific work item.
  BRANCH YOUR CODE!! This, at an elementary level, means to maintain two copies of your code. Your main branch (also referred to as your 'master' or 'trunk' branch) contains the most stable version of your code. Your second branch is called your 'dev', or development branch. All of your code changes and testing should be made on the dev branch. When you're ready to release, you merge all of the relevant changes from your dev branch to the trunk. This allows you to make different code changes to your project, all in parallel. This allowed me to recently release a LSPDFR 0.3 compatibility patch for Code 3 Callouts (I made those code changes in my trunk branch), while still working on the next update in my dev branch. See this MSDN link for more details: https://msdn.microsoft.com/en-us/library/ee782536.aspx 
  CHECK ALL DEPENDENCIES ON STARTUP!! Check file versions on EVERY DLL or assembly referenced by your project. You don't need to check the Microsoft .NET ones, but you should be checking file versions on RagePluginHook.exe, the LSPDFR DLL, and any other DLL (including RageNative UI, a Common DLL you've written yourself, etc) that is used by your project and needs to be installed in the GTA V folder. And NO, do NOT, I repeat, NOT use the Assembly class to load the DLL's into memory. That is just a waste of resources. Use the GetVersionInfo function of the System.Diagnostics.FileVersionInfo class instead.
  More to come...

This is the final part of our LSPDFR 0.2 preview series.  For more information about the changes we're making with 0.2, take a look at the previous installments in this series, found here:: http://www.lcpdfr.com/forums/forum/880-news-updates/
LSPDFR 0.2 not only goes some way in addressing a lot of the feedback we received as far as features were concerned, but it also includes a large number of fixes for issues reported to us.  A full list of these fixes will be published with the release, although among the things we sorted out are many of the frustrations people had with arresting, as well as traffic stop suspects reversing into players and the problems with detecting vehicles for traffic stops.
Aside from these fixes and the features we've already covered, there's still more to talk about.  One of the big things that we saw people wanted was the return of the stun gun.  Thankfully, with the inclusion of a stun gun in the game, this was quite an easy task unlike in LCPDFR.  LSPDFR 0.2 introduces support for both the player and all AI officers to use stun guns.  The AI support has been somewhat improved since LCPDFR 1.1, with more fluid animations and better mechanics in general thanks to the stun gun already being present in the game.  Players are also now given a stun gun when going on duty, and we've been experimenting with AI configuration flags to make suspects tougher, so that they don't die after one hit - currently this works for all callout spawned criminals, and we hope to expand it universally.

Stun guns make their return in LSPDFR 0.2, with player and enhanced AI support.  Shown is an AI officer drawing his.
One of the other main things that we've been experimenting with in 0.2 is audio.  GTA V comes with a massive amount of police related audio which is fantastic, and we're looking to take advantage of this as much as we can.  For 0.2, we've introduced a basic version of the Police Scanner seen in LCPDFR 1.1, with a couple of key differences:
The weird clicking noises between sounds have been drastically reduced. More variations of audio lines are present. You will now hear other officers talk on the radio too. Of course, this is still very much an experimental system and we'll be looking to make extensions and improvements in future versions.
As this is the final installment in this update series, instead of promising another article the next day, we'll promise something else: LSPDFR 0.2 - coming very, very soon.

Nice.  Can't wait to make sure I plug plate-checker into it, at the least.

Following on from the massive debut of LSPDFR on GTA V a mere two weeks ago, we're proud to announce the next installment in the series - LSPDFR 0.2 - featuring not only numerous enhancements and fixes, but also some highly requested features.
Indeed, while originally versioned as 0.1.1, the number of changes introduced in 0.2 seemed too significant to be represented by only a minor increment. LSPDFR 0.2 goes some way in adressing much of the feedback after the first public release and is our first response, pun most definitely intended, to thousands of the comments we've received since then through the forums, YouTube and social media.
From the electroshocking glory of stun guns, to a blast from the past with the LCPDFR style search areas and pursuit blipping, LSPDFR 0.2 packs a serious punch and is a major improvement from our first offering.

Asking for ID in traffic stops - one of the many suggestions that have made their way into LSPDFR 0.2.
 
For those of you familiar with LCPDFR 1.1, the lack of search areas and blips in LSPDFR pursuits might have been confusing.  Fear no more, however, as we've reintroduced the system with much the same aesthetic style as that of before.  There are, however, some notable improvements including the way in which each unit in the pursuit is now being uniquely marked on the game's map.  This means that the legend at the side of the map can be used to highlight each different type of police vehicle currently involved.
We'll have more to share regarding the features in LSPDFR 0.2 tomorrow, when we'll move away from the pursuits and action sequences, and take a look at how 0.2 brings about better support of routine police work - something I know a lot of people are looking for.