minipunch

For time calculations I would use DateTime.UtcNow instead of DateTime.Now. Using this approach it will have better performance since it doesn't need to convert the time to the current user time zone, I would use DateTime.Now only for cases where the current time needs to be displayed to the user.(https://blogs.msdn.microsoft.com/kirillosenkov/2012/01/10/datetime-utcnow-is-generally-preferable-to-datetime-now/)
Though probably you won't notice the performance gain unless you need to get the current time lots of times in loop.
 
I don't think the OP will need a better time accuracy for what he wants but in case he needs it, he can use System.Diagnostics.Stopwatch
Stopwatch sw = new Stopwatch(); sw.Start(); //... sw.Stop(); TimeSpan elapsedTs = sw.Elapsed; long elapsedMs = sw.ElapsedMilliseconds; long elapsedTicks = sw.ElapsedTicks;

If you end up making this, it would be cool if the user could get statistics from it. I don't know if your planning on releasing it with a callout mod or completely standalone to work with all callouts, but things like average response time, slowest and fastest response times and stuff like that would be really neat.
Sorry I can't help with what your doing, I couldn't code to save my life..

That's actually really smart, I used to just sleep a GameFiber but this is much more efficient 
For the OP: just to clarify the above pseudocode a bit:
DateTime now = DateTime.Now; //when call is accepted //Wait until the player is at the location DateTime later = DateTime.Now; TimeSpan elapsedtime = later - now; int responsetime = (int)Math.Round(elapsedtime.TotalSeconds); Hope it helps 

I have some code for this back home but am traveling at the moment. For weapons the process is different from objects. For objects, first spawn the object, then use .AttachTo. The difficult part is getting the right bone ID. You have to use a native for it, and pass in one of the ped bone ID enum values. There's example code our there on the web, but if you havent figured it out by the time I get home I'll post some code for you. 

Was going through the rage forums last night and came across this
http://forums.ragepluginhook.net/default.aspx?g=posts&t=543

Cyan did indeed post it:
 
 

A.  Good luck finding animations- there's like 34,000 of them and they're a pain to sort through, haha.
B. Here's an example: 
EMT2.Tasks.PlayAnimation("amb@medic@standing@tendtodead@idle_a", "idle_b", 5, AnimationFlags.None);  

dispatch we are code 4 i will be 10-8

Why don't you create an object rather than a pickup?
/* Where modelHash is your weapon hash * x,y,z is the ped position * 1st bool is networkHandle * 2nd bool is createHandle * 3rd bool is dynamic */ NativeFunction.Natives.CreateObject(modelHash, x, y, z, true, true, true); or without the natives :
Rage.Object weapon; Vector3 coords = myPed.Position; // spawn position string weaponModel = ""; // replace it with the objectname (not in hash) weapon = new Rage.Object(weaponModel, coords); // as it is an object, it can not be picked up NativeFunction.Natives.PlaceObjectOnGroundProperly(weapon); // just in case  

That's actually an awesome idea - some sort of status check, and if you don't answer, it'll send backup. Hmm. I like it. I wanted to implement an "interaction" system so that there's more than just a one-off statement (i.e. you conduct a traffic stop and dispatch asks if you need an additional, etc.). Sometime in the future, perhaps.

Wow! This seems awesome! Nice work man! 

Anyone interested,
I have released an API for VocalDispatch, as well as added the ability to add custom events/phrases, for use with both default and third party functions. Some ideas of what the API can be used for are:
Providing custom backup behavior during a callout. Adding new functions entirely (coroner request, etc.). Adding status phrases that can be used in place of menus. There is an example project, as well as a step-by-step API usage guide available on GitHub here. Support requests, questions, and comments for the API can be posted either here or on GitHub, I will monitor both.

Basically, any time you do anything which takes any time to process, you need a game fiber. Otherwise it freezes up the game because nothing else can run while that code is executing if it's not in a separate fiber. So, if you have any kind of while or for loop, if you have any kind of task that you're waiting to complete, any time you want to sleep, etc. 
It's generally good practice to have most of your code in a game fiber so it doesn't freeze up the main game. 

Thank you for your response, Darkmyre. You're right. I didn't need that Rage.Attributes line, but that wasn't the entire problem.
I was also putting my compiled .dll file into the wrong folder. It needed to go into the "../plugins/LSPDFR" folder instead of just "../plugins" folder.
I realized this after looking closer at the folder structure of other people's call out releases.

You only need the Rage.Attributes line if making a standalone plugin (ie, not an LSPDFR plugin). Not sure if it makes a difference, but my main class is defined as public not internal.
I can tell you it's definitely not VS2015, as I've been using that from the beginning and it works just fine for callouts / rage plugins in general.