LMS

To add to what @LtFlash said, if you require certain actions to be executed most of the time and still want to use a state enum, you can use bit flags. Basically that allows you to have one state variable, which can contain several states at once. So maybe you want the CheckConditions part executed most of the time as well, so you can specify that along with the "real" state. LSPDFR exposes such functionality through RegisterStateCallback for callouts.

Yield does not stop execution for ever, it just returns control of the current thread to the caller, so other things can be processed. It's basically what Non-preemptive multitasking (cooperating threads) are to operating systems. The OS (in this case RAGE Plugin Hook) expects the callee to hand back control every now and then so it can process other waiting tasks. If this does not happen, the whole system will come to a halt (since RPH is only pseudo-multithreading this will cause the game to freeze). So what happens when you call Yield, is that execution in your plugin is paused, all other waiting tasks (other script threads) are executed, and then control is handed back to you and your code is resumed. So you effectively only pause your code for one game tick before it executes again. To prevent things from being executed every tick, use variables indicating whether something has been done already, such as introducing a Boolean hasBlipBeenCreated or checking for the existence of the blip and only creating it, if it doesn't exist.

The new Cop creation might achieve just that for 0.2 (tbh it's a long time, I can't recall completely anymore). For 0.3 though, we will provide an API function to set up a ped as a cop. That means that right after spawning the same stuff gets applied LSPDFR applies internally to a cop. This also makes the cop available for chases etc. as LSPDFR properly recognizes it.

Please do not use the Cop class as it will be removed in the next update. You can spawn a ped using new Ped. As for the position, no need for Vector3.Add, simply pass the position as a Vector3.

You may want to try one of these approaches: After randomly getting a point, check if the distance exceeds your maximum distance. If so, get a new random point. Do this until you have found a valid point (adding some kind of maximum number of attempts is a good idea btw). From a maths point of view, you could apply the closest pair of points problem to this. Yours is slighty different in the regard that you allow multiple points within a range, but a little altered algorithm should work here. Note that bruting takes O(n²) here, so I'd go for a divide and conquer algorithm, which should take O(n log n).

Due to the way this mod achieves synchronization, I doubt it will get much better.

There should be no difference between code targeting Alex's C++ Hook, the open source .NET Hook or RAGE Plugin Hook, because this mod seem to sync existing entities.

The current project state would not fit our requirements, no. If we should ever consider to actively develop a multiplayer version, we'd evaluate the available solutions, so this one might still help then.

From skimming the source I can tell that it's achieving the multiplayer functionality in a very different way (compared to both, FiveM and GTA MP). It is entirely native based and while that will definitely cause a lack of certain features and different issues, it might be an approach Rockstar can't ban so easily. At least from a coding point of view, I find it much harder to justify a ban of something just using script functions compared to something that hooks into the game in a lot of different places or proxies GTA O. Question is how well it will perform though.

Since we've been focused on actual gameplay mostly, I can't give any binding statements regarding the API yet. We have some plans to overhaul the API, including the already announced changes to making some functions and classes private, which will ship with the initial 0.3 release. While there will be some small additions, chances are we will release a separate more API-focused release shortly after rather than including it all in the 0.3 release already. This is mostly a decision due to time constraints on our side, because we do not want to delay a possible 0.3 due to API issues. I don't want to give you the impression we're no longer working on the API though, it's something we are very interesting in and it will definitely be improved soon!

That's correct, the latest release does no longer block pirated game versions.

Du scheinst gar keine Log zu haben. Sicher, dass du das VC++ 2015 redist (x64) installiert hast?

Sollte mit dem neuesten Update (0.26) funktionieren, bitte einmal testen und Rückmeldung geben.

We will most likely impose no limit for different vehicles per backup type. It will just be selected randomly.

You should be able to merge it into the LSPDFR repo (if you want) yourselves. Just create a new folder. I will see if I can add something to it from our code when I get some time.

You simple pass a floating point value as radius that is higher than your minimum. We randomize before the call/have a helper call to do minimum and maximum logic. The function itself has no limits.

My personal opinion on this is that whoever makes something, should be allowed to say how it should be used. That this can not always be enforced is another story. But if people take proactive measures to prevent theft/editing/whatever, it is their right. I also sometimes decide to make it harder to translate my code back to source code and sometimes I released stuff without any protections or in source form. But that's up to me. Sure, there can be idiots hiding behind these "rules" and doing it only to tease people, but on the other hand, I personally never understood all the hype. It's just a model, it's not that it's a complete game changer or that it is completely unique in every regard and nothing else available. If it was a huge collection or in terms of coding a big modification, I could understand it a little bit better, but then again where is the point in working on such a big project without a community around it. Too much drama for something that doesn't happen that often and doesn't really have any effect.

I could imagine open sourcing it at some point, but not anytime soon. I know that this probably not what you expected to hear, as the longer we wait the more IV might die, but as Cyan mentioned it's closely related to LSPDFR atm and would also need a clean up in some areas (server communication, authentication) to remove sensitive stuff. Your best bet would be to bring this up again next year.

Okay you have been added. Feel free to use the code available there (not much yet, I admit...) or contribute your own code. Official thread: http://www.lcpdfr.com/forums/topic/53743-github-repository/ This will become a discussion thread for the repo.

The official GitHub repository is live at: https://github.com/LMSDev/LSPDFR-API You can use it as a resource for code helping you develop your plugins or give something back by contributing your own code. Everyone can participate and it's managed by the community! For now, it's just a collection of different pieces of code, but once it's growing we can make a nice library of it. Discuss it here: http://www.lcpdfr.com/forums/topic/53530-github-repo-talk-thread/ Important: The GitHub repo should be kept clean in both regards, code and issues. Especially for issues, the forum should serve as a DiscussionHub™ while confirmed issues should be added there. Issues should start with [BUG] in their name and labeled bug. As for API requests, I think it would be great if we used GitHub for those as well. So please add your requests to it. Also those you mentioned earlier... as I.. tend to forget things sometimes. Requests should start with [REQ] in their name and labeled enhancement. The label acknowledged should only be added by the LSPDFR team to show that we are aware of this issue/agree with the request.

Ok, it's been set up at https://github.com/LMSDev/LSPDFR-API. I will add all of the people who replied here soon, but if you don't feel comfortable with Git or managing a repo yet, please tell me. This way we can ensure only people who have some experience have full access while everyone else can still contribute but needs their contribution checked (so called pull requests). I just want to prevent things like temp files (bin, obj etc.) cluttering the repo. Of course you can always be granted full access later on, if you feel that you are familiar with Git then.

@luminouscarcass: The d3dcompiler_47 dependency was introduced by compiling against the latest DirectX SDK on Windows 10, while beforehand it was an older SDK and only required d3dcompiler_43. Unfortunately people on Windows 8.0 or below seemed to have trouble getting the _47 one to work, so I recompiled without linking now and do the linking dynamically at runtime for the proper version. That was most likely causing your issue, but should be fixed by the 0.22 version. @Adzie: You may wanna post a crash report so the issue can be fixed.

It's just the diagnostics tool that won't work then. If you can't get it to recognize the folder properly, you can still manually edit the .ini file in the correct GTA IV directory.

You will be able to enjoy this soon :)