cp702

Not to mention the really fun stuff: Giving press conferences and setting budgets (I know, hard to believe the excitement!)
Police ranks (and army ranks, and really just about any rank system) aren't a matter of "you're good, so we're going to give you a higher rank and keep you on the same job." Paygrades can work like that, but not ranks. Increasing rank means you're turning into more and more of a supervisor, and less and less of a front-line worker. At the high end, a police chief's job in a big department is more similar to the job of the director of the city parks department than it is to the job of a patrolman. A police chief (and those a couple levels down from the very top of the hierarchy) is a bureaucrat, whose main connection to policing is that he was a cop and he supervises cops, and that he still considers cops to be his colleagues. It's kind of like the difference between a four-star general and an infantryman, except the general still wears a uniform.

Rockstar, after deciding to have multiple law enforcement agencies ingame, forgot to tell their art staff what was going on. Thus, the voice issues (SAHP also has LSPD voices for the white one), as well as the LSPD having a prominent LSSD logo in their patch and on their hats, and some other things. Not as bad as IV (which was the worst for this, since they had a state police force whose only non-LCPD traits were some different voices, different hats, different pants, and one different shirt), but not well-done either (unlike Saints Row 2, which had 2 primary LE chains with different patrol cops with their own voices, different cars, different SWAT teams, different air units and armored units, and even different strength of response).

Rockstar, after deciding to have multiple law enforcement agencies ingame, forgot to tell their art staff what was going on. Thus, the voice issues (SAHP also has LSPD voices for the white one), as well as the LSPD having a prominent LSSD logo in their patch and on their hats, and some other things. Not as bad as IV (which was the worst for this, since they had a state police force whose only non-LCPD traits were some different voices, different hats, different pants, and one different shirt), but not well-done either (unlike Saints Row 2, which had 2 primary LE chains with different patrol cops with their own voices, different cars, different SWAT teams, different air units and armored units, and even different strength of response).

For fuck's sake. From the forum description:
 
This thread is a pretty good example of why we removed politics as a category. It's a zombie thread that should never have been revived, which in the revival lost all connection to the actual attack in November 2017 that spawned it. I'm locking this.
 

If you feel this topic has been closed in error, please report this post.

The indicator script was considered impossible (or nearly so) by a lot of people before Lil-rich actually did it; I had to see it ingame before I believed he wasn't joking.

Faracus: Nice find!

It looks like your LSPDFR stations_sahp.xml is invalid. Could you post that file?

It's required because the author wants greater control of their software. People can make their own judgement call as to whether they want to tolerate that or not, but I don't think it's fair to dress it up as some sort of thing that's a requirement for better synchronization.

It's not an acronym, it's the word "lore:" to quote Urban Dictionary, "the collective history and the sum of all knowledge available about a certain fantasy or sci-fi universe." Lore mods are designed to fit into the lore of the GTA HD universe (which includes IV, EFLC, and V). For instance, a lore texture is one for a department that fits into the V world (whether that's a real department like the LSPD or an invented one like the Blaine County Sheriff or Del Perro PD). A lore model is one that's generally based on Rockstar's vehicles, normally coming from IV or V, not real life cars. Lore models might be different from any car in the stock game, like some of Lt. Caine's creations, but they're critically *not* recreations of real vehicles. If you combine the back of the V ambulance with the cab of the Bison, that's different from the ambulance Rockstar created (which uses a Burrito cab), but it's still lore because it's based on GTA cars. If you converted a model from Max Payne 3, that'd generally be considered lore because MP3 also doesn't use real-life cars. If you converted a Dodge Ram cab from a racing game, that'd be a real-life vehicle and so not lore.

The biggest catch is that LSPDFR uses zero-indexing while EUP uses one-indexing. In other words, EUP "Upper Body 5" is LSPDFR "uppr 4".

Plugins compatible with 0.4.1 will not need to be recompiled to support 0.4.2 unless mod authors intentionally put version checking in to prevent their mod from working on newer versions. There are a bunch of new API methods which will open up many new possibilities for mod authors, but the previous API functions are all fully backwards compatible. This is a much less disruptive change than 0.3 -> 0.4. 

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.

Check that your plugins are all fully updated.

@LMS @Sam First off I don't want to sound like an insatiable bastard so let me preface by saying that you guys did an ASTOUNDINGLY AWESOME job creating 0.4! I am a software developer myself and I know the huge amount of work that must be put into designing and implementing this. However if you are looking for ideas here's a few that I felt could be a good addition/improvement to the current system. (Apologies if any of them are already implemented!)
 
AmbientSpawn livery issue. I created this topic, but TL;DR - it seems like there is a bug where ambient spawn vehicles do not always use the livery designated in agency.xml. Full details in the linked topic. Let me know if I can help reproducing this issue!  
Police-related spawn scenarios. For these, I wish the scenarios are consistent with the character's agency. For example, I have a BCSO deputy but he can spawn in front of a LAPD station or in a CHP cruiser, which breaks immersion. It'll be better if the system can utilize Agency and Station data so that the character is always spawned in the station or the vehicle that corresponds to their agency (if defined).

As a nice to have, it'll be rocking if the game can recognize the regions of the character's agency during this process and only spawn the character into their jurisdiction (except for the apartment/police station scenarios, ofc). I know it's hard to make it perfect but adding a few more scenarios that are scattered in different areas, and filtering those when picking a spawn event should be a good starting point and cover the majority of player's needs.

An alternative approach is to have an additional "Go to Nearest Police Station of My Agency" action in the LSPDFR pause menu so player can quickly go to their jurisdiction if spawned in a wrong area (assuming the station is within it's jurisdiction - but that's the player's responsibility to ensure that :)  
Randomizing starting character. Currently when you start the game it will always load the last played character. I think it's a good idea to add an option to randomly choose a character so I don't have to make the (tough) decision of which agency to role-play with every time. (yes, indecisiveness!)  
Non-pursuit backup units. When I call in a code 2/3 backup unit I wish they could participate in what I'm doing, instead of just standing there looking at me. For example if I am pulling a vehicle over and ordering a driver out with gunpoint, they should also point their gun at the suspect. This helps with immersion in cases where I like to execute a felony stop (such as for a stolen vehicle or felony warrant).  
Default vehicle. This is a minor one, but it'll be great if game can memorize the livery/extras of the default vehicle of a character, instead of only spawning with the first livery and random extras.  
Police garage. Again, super minor but I wish when cycling through the vehicles in a police garage it can automatically select the livery associated with the current agency instead of using a random livery.  
Hopefully these ideas are not too crazy 😉 -- thanks!
 
 

One thing I can think of: It'd be nice to have the ability to stick plugin triggers on the backup and/or interaction menu. What I'm imagining is a function
RegisterBackupType(ResponseType type, string name, Action<Vector3> callback) This function would append an entry with the given name to the end of the given no-agency backup list (i.e. what you see when "None" is selected). When chosen, this entry would call the callback function with the target position (this would be flexible -- if you have something like responding backup to a waypoint if the user has set one, the fact that you pass in the target location would let addons seamlessly work with that). LSPDFR's role could be limited to calling the callback, with no attempt to manage the response unless the plugin calls additional API functions. That way, something like a coroner or tow truck mod could be integrated into the normal backup menu. I suppose this could be done in a more OO way by passing an object that supports an ICustomBackupPlugin interface, which may fit better with the rest of the API, although I've always kinda preferred function pointers and delegates for this sort of simple largely-stateless thing.

This is going to seem weird, but I promise there's a reason. You're in Saudi Arabia, your language is set to Arabic, and you're using the Hijri calendar, right?

One thing I can think of: It'd be nice to have the ability to stick plugin triggers on the backup and/or interaction menu. What I'm imagining is a function
RegisterBackupType(ResponseType type, string name, Action<Vector3> callback) This function would append an entry with the given name to the end of the given no-agency backup list (i.e. what you see when "None" is selected). When chosen, this entry would call the callback function with the target position (this would be flexible -- if you have something like responding backup to a waypoint if the user has set one, the fact that you pass in the target location would let addons seamlessly work with that). LSPDFR's role could be limited to calling the callback, with no attempt to manage the response unless the plugin calls additional API functions. That way, something like a coroner or tow truck mod could be integrated into the normal backup menu. I suppose this could be done in a more OO way by passing an object that supports an ICustomBackupPlugin interface, which may fit better with the rest of the API, although I've always kinda preferred function pointers and delegates for this sort of simple largely-stateless thing.

Will LSPDFR sync related features be added to the API at some point in the future? It would be cool for callouts/plugins to be able to add their own stats and activities to the activity feed. E.g. "Bob Vance just freed 5 hostages at the Pacific Standard Bank", "EMS just saved 2 people on Vespucci Boulevard... sadly, 3 people did not make it", etc. 

You learn something new every day.  I did not expect pulling over a boat to go that smoothly.
I'm thinking we could allow boats to be blipped again and then simply disable the new logic for boats and just make them stop where they are.

Despite the custom system, I did backup regions, stations, backup, and duty selection by modifying the default files. Especially for backup regions and backup, it makes more sense to me to have the one file integrating *every* change so I don’t have to worry about conflicts. I mostly use the custom folder for outfits, inventory, and agencies.

Just wanted to drop by and say thank you @Will Zoftrak for taking the initiative to make a list like this, and to keep it up to date.  Really cool of you, and a great example for the rest of the community.

There's just nothing that makes this girl angry!
 

I believe it is a requirement, and that LSPDFR literally looks for files matching “custom/outfits_*.xml” or equivalent.

I feel like Yakety Sax would be better, to be honest.

One thing I can think of: It'd be nice to have the ability to stick plugin triggers on the backup and/or interaction menu. What I'm imagining is a function
RegisterBackupType(ResponseType type, string name, Action<Vector3> callback) This function would append an entry with the given name to the end of the given no-agency backup list (i.e. what you see when "None" is selected). When chosen, this entry would call the callback function with the target position (this would be flexible -- if you have something like responding backup to a waypoint if the user has set one, the fact that you pass in the target location would let addons seamlessly work with that). LSPDFR's role could be limited to calling the callback, with no attempt to manage the response unless the plugin calls additional API functions. That way, something like a coroner or tow truck mod could be integrated into the normal backup menu. I suppose this could be done in a more OO way by passing an object that supports an ICustomBackupPlugin interface, which may fit better with the rest of the API, although I've always kinda preferred function pointers and delegates for this sort of simple largely-stateless thing.

One thing I can think of: It'd be nice to have the ability to stick plugin triggers on the backup and/or interaction menu. What I'm imagining is a function
RegisterBackupType(ResponseType type, string name, Action<Vector3> callback) This function would append an entry with the given name to the end of the given no-agency backup list (i.e. what you see when "None" is selected). When chosen, this entry would call the callback function with the target position (this would be flexible -- if you have something like responding backup to a waypoint if the user has set one, the fact that you pass in the target location would let addons seamlessly work with that). LSPDFR's role could be limited to calling the callback, with no attempt to manage the response unless the plugin calls additional API functions. That way, something like a coroner or tow truck mod could be integrated into the normal backup menu. I suppose this could be done in a more OO way by passing an object that supports an ICustomBackupPlugin interface, which may fit better with the rest of the API, although I've always kinda preferred function pointers and delegates for this sort of simple largely-stateless thing.