It's been a few months since 0.4.1. What's going on? Any subjects of interest? Any need for feedback or testing? Any plans or roadmaps? Any trends in bugs or issues? Any problems or technological challenges?

Stuff is going on. We have a testing team already (there's no application process), and we don't generally share development progress unless we want to build hype.

I apologize in advance for being blunt about this question:

 

Why?

 

I'm going to get a bit real, here - because this has been on my mind for a while: 

 

I'm not aware of any reason you'd want to not take advantage of transparency towards the community - especially with the purpose of trying to build hype - other than the possibility you're trying to launch a game company off the shoulders of a constellation of community mods and trying to protect the core code as a company asset. 

 

I honestly would not blame the team for this - they are certainly not the first ones around to try to make a mod into a serviceable full game. (Post Scriptum comes to mind, even though that game is far from complete, far from optimized, and bit off far more than it could chew even after its official release. Definitely something people should learn from.)

 

Let's assume this is not the team's intention - First: it serves little purpose in development on a community scale in the development age of 2019. 

If you are amateurs and working people - you need all the help you can get. There's clearly several things wrong with GTA5, there's several things wrong with LSPDFR. We have the combined power to report and turn over revisions quickly and in an organized manner using the tools of our age. 

Second: Consider how much of LSPDFR is (currently) enabled and carried by plugins made by the community, I think you (you all, ofc) owe it to the community to let us know what's being worked on and being fixed so we can adjust our priorities accordingly. It's 2019, not 1992. I would not mind plying my knowledge and skills provided I'm not wasting my time. I don't care about hype - I care about active development, fast turnaround on issues I put time into reporting on and dealing with, and continuous and fast improvement.

Third: What do you need to hype the mod for? If the site is run by advertising revenue - and you are short? Just tell us. Just - Tell - Us. The only function hype serves is to generate revenue. You're trying to make money. I understand it's all free, but this would be absolutely no problem if the company were up front with us. Just. Tell us. Be transparent. 

 

Fourth: This is definitely not about quality control, either. You are hard-pressed to say that not bringing attention to what you're working on will benefit whatever QA processes you have right now. Internal QA will simply not catch what the entire community may be able to, and not making yourselves aware of current issues by sharing your work and discussing it with users/players is also very 1990's.

I'm gonna end on that - please understand I say all of this with genuine respect and concern - If there's bad news, if there's problems, if there's reasons I'm not hitting upon - I personally prefer the team is up front about it.

 

Thanks for your work - please keep it up.

 

I honestly don't think the team behind LSPDFR owes the community to build hype or being transparent on what's going on behind the scenes. Don't forget that the mod itself is free to download and no one is being forced to create additional content (mods, callouts, textures etc.) or to financially support the project. Any contributions made towards LSPDFR is done willingly either because you want to support the mod itself or its community.

Edited May 3, 20196 yr by Xalius

On 5/3/2019 at 6:20 AM, Starsickle said:

I apologize in advance for being blunt about this question:

 

Why?

 

I'm going to get a bit real, here - because this has been on my mind for a while: 

 

I'm not aware of any reason you'd want to not take advantage of transparency towards the community - especially with the purpose of trying to build hype - other than the possibility you're trying to launch a game company off the shoulders of a constellation of community mods and trying to protect the core code as a company asset. 

 

I honestly would not blame the team for this - they are certainly not the first ones around to try to make a mod into a serviceable full game. (Post Scriptum comes to mind, even though that game is far from complete, far from optimized, and bit off far more than it could chew even after its official release. Definitely something people should learn from.)

 

Let's assume this is not the team's intention - First: it serves little purpose in development on a community scale in the development age of 2019. 

If you are amateurs and working people - you need all the help you can get. There's clearly several things wrong with GTA5, there's several things wrong with LSPDFR. We have the combined power to report and turn over revisions quickly and in an organized manner using the tools of our age. 

Second: Consider how much of LSPDFR is (currently) enabled and carried by plugins made by the community, I think you (you all, ofc) owe it to the community to let us know what's being worked on and being fixed so we can adjust our priorities accordingly. It's 2019, not 1992. I would not mind plying my knowledge and skills provided I'm not wasting my time. I don't care about hype - I care about active development, fast turnaround on issues I put time into reporting on and dealing with, and continuous and fast improvement.

Third: What do you need to hype the mod for? If the site is run by advertising revenue - and you are short? Just tell us. Just - Tell - Us. The only function hype serves is to generate revenue. You're trying to make money. I understand it's all free, but this would be absolutely no problem if the company were up front with us. Just. Tell us. Be transparent. 

 

Fourth: This is definitely not about quality control, either. You are hard-pressed to say that not bringing attention to what you're working on will benefit whatever QA processes you have right now. Internal QA will simply not catch what the entire community may be able to, and not making yourselves aware of current issues by sharing your work and discussing it with users/players is also very 1990's.

I'm gonna end on that - please understand I say all of this with genuine respect and concern - If there's bad news, if there's problems, if there's reasons I'm not hitting upon - I personally prefer the team is up front about it.

 

Thanks for your work - please keep it up.

 

 

I get where you are coming from, and I wish for the same. But I don't think it's done with ill intent. 

 

The dev team is tiny, have families/work/priorities. So their time is limited, being more transparent and more engaging simply adds a lot more work. I know this is a simple answer, but I dont think its far off the truth. The devs most likely don't have as much time or passion anymore as they used to (very obvious in the amount of updates).

 

That said, a roadmap, no matter how long it takes, would be nice, to at least give the mod a clear future, even if they don't reach it.  

Edited May 7, 20196 yr by FKDZ

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.

I'll answer in a more blunt way.

 

It's just the way we've always done it. We have certain traditions on this site, and one of them has been building hype and excitement before major releases of the modification. It's not for any particular reason, at least not that I'm aware of, and most definitely not for any monetary purpose.

 

If anything, it makes it more fun. There would be no fun if everyone knew all the features of the mod before it's released.