LMS

In IV traffic lights were basically just two different states (one for all roads going top-down, one for all roads going left-right) that could be changed with a little memory editing. I haven't looked into how it is in V, but I would assume it's similar.

Okay thanks for the positive feedback guys, I will set it up soon. If you could drop your GitHub names here (or follow me at https://github.com/LMSDev), that would be great, so I can set up permissions once everything is in place.

To add to Stealth22, this is basically how we gathered all the different ped models and their variations (http://ragepluginhook.net/PedModels.aspx): Having a plugin to spawn them and then take a screenshot. I guess one could also do basic color detection of components via code when spawning in a well lighted environment and freezing the time.

It's just that you have a random distribution between 0 and radius, while my function guarantees to return a position away radius meters from the origin. This is mostly because we randomize the radius before calling the function (also often preserving a required minimum distance).

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?

Yeah, don't worry, it's not that we wanna cut out stuff really. The problem right now is though that we can't really manage external input through proper API classes, but our internal stuff is called directly. This can cause some side effects, because you don't know how you are supposed to use the internal classes or we didn't intend such access at all. I don't wanna hurt API development at all and I'm more than willing to add all the stuff you need in the future, I just don't wanna expose internal classes. @Albo1125: Sorry, but that's just not possible. We can't just expose such crucial components nor allow changes to it. We'd have to think of different ways, like giving you the ability to set a ped as arrested manually for instance.

I sometimes get the issue you described as well, so it seems to be a bug. I will have a look later. About the notes: Sure, I can add that.

I'm on Windows 10 as well, it works fine. Next releases will also be compiled against the VC++ 2015 redist.

The lib is just the compiled version of the AssemblerHelper source file so you don't have to. It is not supposed to work as a plugin, but a normal library. You can reference it from your project and then use its functionality like shown in Class1. I guess you have to place it into the game root folder so your plugin can load it properly when referenced too.

Sure there is, you just have to take AppDomain remoting into account. All API calls have to be made on/in/from the LSPDFR AppDomain. I've attached a very basic example on how it could work. When you go on duty and then run the test plugin code you should get "False" from the first check and "True" from the second. Also added the source since I didn't test it, but you should get the general idea. Helper.rar

Keep in mind that the scope for statics are AppDomains though.

Okay I see, do you need all functions in there or are you just using a few specific ones?

It's totally fine to do it like this. I was more talking about sleeping (also longer than 0 ms which is what Yield does) in the callout's Process function. What you do in a separate game fiber is completely okay and even necessary here. Keep it up!

I don't really think it will work. Plugins run in different AppDomains, so when your plugin is loaded with a reference to LSPDFR, chances are it will load LSPDFR into its own AppDomain again. This is why your plugins are loaded by LSPDFR explicitly, to guarantee they are in the same AppDomain.

Sorry for the confusion, this class is not really meant to be public. You should only really make use of the API namespace, the other public ones will most likely disappear soon.

Yeah, it *should* :P

For the people where the console doesn't show up: What does the log say, swap chain is null? Because that is somewhat out of our control as DirectX appears to fail internally. I'm not yet sure why.

Ist hier nicht erwünscht.

Thanks for that, I'm sure it will help people. A few things I'd like to add... Don't sleep in your main thread!If you do, I will pay you a visit and it won't be nice! No, but seriously, the Process function is called every tick from LSPDFR's CalloutManager and if you decide to sleep there, you will block other callouts from working correctly. If you need to await something, do it in a separate GameFiber (if it requires game logic) or System.Threading.Thread if not.Use logging!Not only as a beginner, you should use logging extensively. You can create overloads of your logging function so that it only happens in debug build (like most LSPDFR logging) or under certain circumstances (such as logging levels), but use it. It will help you to better understand what went wrong on a user's end. Especially since as a beginner you probably have no real experience with debugging or checking crashes via crash offsets. Note that debugging V is unfortunately not really possible right now, as the DRM doesn't really like it. I didn't test on 393 yet, but earlier versions didn't work well.Keep an eye on performanceEvery now and then it might be a good idea to measure the time the main loop (your Process function) takes to run. 1-2 ms? Good! 20ms? Not so good... Don't be afraid to add a lot of general logic, your CPU can handle it. Game calls and poor code (such as unnecessary loops) will most likely be the cause of performance issues.Use commentsI'm not an idiot, I know what I'm doing here. Sure, now you do. But will you remember why you passed that 0x2 value to the native call in 2 weeks? Chances are you will not. And why did you apply the Wait task to the passenger again? Use comments to describe why you are doing such actions. It will help you later on, trust me.

For those worried about Vector3Extensions being removed, you can add the class source file yourself to your projects. Add the file/code like you would any new class and simply reference it in the same as way as the API example shows Here is the source file: http://pastebin.com/6cWT5Wqg (Revived from the original API thread by LukeD, LMS feel free to edit)

Known issues so far: Missing function to retrieve personaIsPedArrested doesn't return true for player arrested peds

Hello fellow developers, welcome to our brand new LSPDFR API Development forum. Great to see you made it here! This is the place to ask questions about working with the API, as well as requesting features. More examples and proper documentation will follow soon as we focus on the mod itself currently. If you have any feedback regarding the very early API implementation though, feel free to share. Thanks!

This is because RAGEPluginHook and LSPDFR are technically very different. One exposes V's scripting functions and one actually uses them. This is the same setup for almost all script-based mods: You have a "script hook" and a mod. It also was the same in GTA IV and we didn't really provide support for the .NET ScriptHook either, at least not actively. Because of the limits we experienced with SHDN on IV (at least until Hazard added me to the repo so we could change some stuff we desperately needed) we decided to in fact have our own implementation, which is RAGEPluginHook. But a) since I'm the only team member of LSPDFR developing it (together with a non-team member) and b) because it's a completely different product with completely different support needs, there is also a separate website/forum. With V we are more close to the "full package" than we were with V. Most people just don't understand that LCPDFR on GTA IV had undergone six years of development, while LSPDFR and RAGEPluginHook is about three months. It just can't be perfect. How not? Does Rockstar help you when the game doesn't work because of hardware/driver issues? I think we already provide a very good support considering the amount of time we have.

It aims to expose LSPDFR functionality, such as pursuits, to developers so they can make use of our features and the experience will be exactly the same. We also provide functions to retrieve data from LSPDFR, such as whether a callout is in progress. The 0.2 API is very very basic as we focus on features and stability more at the moment and hence lacks a lot of internal features, but this will improve over time. Another reason why we didn't implement so many functions is that LSPDFR is a very early version and many things are subject to change or hacky solutions, so exposing them is not always a good idea. The most important feature of the current implementation is the ability to hook into the callback dispatcher so that user-created callouts are dispatched by LSPDFR as well as the ability to create pursuits (though no custimization yet). I plan to bring back the V API dev forum soon so I can get in touch with developers and their needs/ideas/problems.

Implying you don't do your job?!