LMS

It has been summed up pretty well, we are basically 1 1/2 people working on the core LSPDFR mod entirely in our free time. From my own perspective, this gives me a few hours every now and then to work on it, time I usually use to work on new features and fix issues. I could use my time to interact more with the community and post about development news and I am sure people would appreciate that (and I also try to be reasonably active on the forums). However, there would not be much to show then as the actual development time would suffer. There have been a few attempts where we tried to have other people share more about the work we do and involve people more but ultimately they all failed due to the lack of interest on their part. Personally I also much prefer the API model over an open source approach. It allows us to keep the complex core maintained by people who know the codebase and allows other developers to extend it in a component fashion. There are many parts of the codebase that I do not want anyone to touch (even from our own team) simply because they rely on specific game hooks, memory patching or Rage Plugin Hook behavior, which I also maintain. All this is integrated in the mod in a way that it can be hard to separate, especially when relying on V behavior too. If you have specific requests for the API to open things up, you are more than welcome to post them in the forums. Our next update will focus mostly on API updates as outline in the forum. I understand that people would like to have a roadmap, but frankly we do not really have one ourselves. We have many different ideas we would like to integrate, yes, but it all boils down to how well we can implement them. More complex features usually take a few iterations before we are happy with them to ship. The great thing about the current ecosystem is that people can do things we would like to do in their own way and for players to enjoy even though we perhaps would not have wanted to use the same approach. As an example: We've always wanted to modify ped response to shots fired and being aimed, especially from tasers. In LSPDFR 0.3, sometimes fellow cops would even flee from you when they saw your weapon, it is just how the game events were set up. Now there were some existing solutions (that also affected this and other behavior) that were very taxing on the framerate since they checked all peds very frequently for unwanted behavior. This was obviously not a solution we could use, so we tried different things. Modifying weapon types. Blocking ped events when shots were fired/on aimed. Suppressing shocking events via natives. Many different things that all worked so-so. Ultimately I went the extra mile and hooked the game's event dispatcher to intercept events, which worked well. Until it did not, because in order for us to intercept and check events, we needed to have the game thread yield so we could process the events from the script VM. So we had to come up with a system to artificially keep game events alive and only let the game process them once we found they were okay to be processed. However, this was bad for some events that were short lived and should only exist one tick (if you delay the damage event it is pretty much impossible to kill anyone and animations just glitch out for instance), so we had to account for that too. Now this gives us ultimate control over every game event fired and we can adjust every ped's response directly without any performance impact. But it took a long time to write and many iterations. Put simply, a roadmap does not make too much sense for us as we never quite know how feasible something is until we try it. I rather announce something once it is in a shape where we would happily release it than teasing something that does not come to life. On a final note, we do have some plans to bring back the development blog in a limited fashion, but it would be like I laid out above, mostly focusing on stuff that has already been mostly finished. So not too different to the current way of having announcement posts every now and then showcasing new (and implemented!) features.

Thanks for your report, we will fix the issue in the next patch.

Can you please attach your log again to make sure it is the same issue?

They are actually deleted the very second the suspect is marked as escaped. There is a system to remember the suspect and spawn them in later, but it is currently not enabled. @Darkmyre Sure!

Happy to hear it works now. To give you an idea of why it failed with a different value, is that the interval multiplier expects a different type of a value than a simple integer. This is why it gets confused. As for your tab, it can sometimes happen when the menu is not loaded fast enough, but overall should happen rarely. You're very welcome, enjoy playing!

Thanks for your report, we will fix this issue in the next update.

Give it a try and post your log again should it still not work.

Bei mir funktioniert es einwandfrei. Stelle bitte sicher, dass deine Agency Fahrzeuge enthält, die SpawnsAmbiently als Flag haben. Das sind dann genau die Fahrzeuge, die zufällig ausgewählt und gespawnt werden.

In your lspdfr.ini, change your WorldEvents.IntervalMultiplier value from 0 to 0.0f.

The Any function returns true if any of the elements in the sequence match a certain criteria: peds.Any(entity => entity.Model == "POLICE"); You are probably looking for the Where function that gives you all elements that match a certain criteria instead. I would recommend looking at examples on how to use these functions for C#.

Can you please PM me your RagePluginHook.log file after you have started LSPDFR?

Every police officer is also a ped, so you could first get all peds using World.GetAllPeds. Now that you got the peds, you can work out which one is a cop.

If you add "Callouts.DisableBigRadar = true" to your lspdfr.ini file, it should no longer show the big radar.

We are looking into exposing the character statistics via the API, but do not have any further information at the moment. What did you have do disable/not use in order to use the character statistics? As for the paycheck, it has been suggested various times alongside with a rank progression system, but we do not have any plans to integrate that at the moment.

Dazu würdest du den Vehicle Tag weglassen und stattdessen ein Type Attribute ergänzen:

Ich habe bisher zumindest noch nichts dazu gelesen, aber kann gut sein, dass ich es übersehen habe. Der Fehler besteht auch erst seit 0.4.1 und nur wenn du ein spezifisches Model verwendest, das schränkt es etwas ein, denke ich. Du könntest es in der Zwischenzeit ohne spezifisches Model (CVPI) versuchen, dann wird ein zufälliges Model der jeweiligen Agency verwendet. Das sollte funktionieren. Wann genau wir das Update releasen, kann ich leider nicht sagen.

Sorry for the late reply, it was a bug in our vehicle cache. It will be fixed in the next update. Sure, I can add that!

Das sieht soweit gut aus. Ich habe es selber getestet und bekomme auch keine Fahrzeuge. Es ist ein Problem im Code, welches ich jetzt behoben habe. Du wirst dich also leider noch bis zum nächsten Update gedulden müssen.

I've added an option as to whether suspects can steal cars in general. However, I am not quite sure about chances for that. The issue being, when is the chance evaluated? Per car they encounter? Per valid car they encounter? Every few seconds or so? I think it leaves a lot of room for different interpretations even if specified, so my suggestions would be to either have a flag whether they can steal or not steal which can be randomized by the developer, if they want to (randomized on ped creation by LSPDFR first). Or having a chance but this chance would only really be evaluated once (i.e. when the chase starts or when the chance is changed) and then based on the chance an internal flag will be set. What do you think?

In your lspdfr.ini file, you can add the entry like this: Chase.DisableCameraFocus = true To learn more about settings, please check this page:

Hi fellow developers, @PNWParksFan and I have been busy discussing a wide range of possible internal values exposed via the API that concern arguably the most core part of LSPDFR: chases. Since it is such an integral part I would like to also get some feedback and suggestions from you to make sure we don't have to go back and forth too much and get it right the first time. Ideally, in a later release some of the values could be shipped as presets to make life a little easier. Please note that while some of the attributes are already implemented others are just suggestions and might not be included in a future release. The current list can be loosely grouped as "Chances" and "Attributes". Chances Surrender chance for when the car is badly damaged Surrender chance for when the car was pitted Surrender chance for when the car was pitted and slowed down significantly as a result Surrender chance for when the car was pitted and crashed as a result Surrender chance for when a tire burst Surrender chance for when a tire burst and the car crashed as a result Average time after which a suspect will surrender once one or most tires have burst Attributes Maximum driving speed Minimum driving speed Maximum running speed Exhaustion interval (after a certain time, the suspect slows down a little) Exhaustion duration (how long the suspect will remain exhausted) Handling ability (general improvement of the suspect's handling over the stock V AI) Handling ability during turns (this is slightly higher than the normal handling ability) Maximum turn aggressiveness (this specifies how early and how fast a suspect will take a turn) Minimum turn aggressiveness (like above) The ones above should all be fairly simple and self explanatory. They are also already used internally for the most part and hence will simply be exposed via the API. The values below are a little bit more "experimental" and any feedback would be greatly appreciated. Handling ability change per burst tire: I am thinking a scale of 0.0f - 1.0f which will affect the handling ability of the suspect like a multiplier (negatively). A value of 0.0f would have no effect at all, whereas a value of 1.0f would reduce the handling ability to 0 if just one tire had burst. The formula would work like this: HandlingAbility = SituationalHandlingAbility (no turn/turn) * (1 - (BurstTireMult * tires burst)). Setting it to 0.25f would thus gradually lower the handling ability for a 4-wheel vehicle until it reaches 0 for when all tires are burst. Good idea, bad idea? Average time for surrendering after a tire burst multiplier, affecting the time per burst tire. Could work much like above, a value of 1.0 would immediately reduce the average time to 0 per burst tire. Another suggestion that came up was setting the maximum speed once at least one tire had burst. I think the handling ability change will tie in with this, but a multiplier like above that lowers it from the current maximum speed could also work. Or do you think a separate fixed maximum value would make more sense? Thanks for your help and please feel free to suggest other values too!

Könntest du bitte einmal ein Beispiel einer Station posten?

You will have to add back the modified weapon(s) you have removed since you last played the game.

Restore that weapon and reload the game. In the next patch I will add a check to automatically discard invalid weapons.

We don't do ETAs here 😛