Skip to content
View in the app

A better way to browse. Learn more.

LCPDFR.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

goigle

Members
  • Joined

  • Last visited

Everything posted by goigle

    Love the new 2016 interceptor, it's good to see it in GTA IV where the NYPD makes sense :D
  1. That's missing the entire point though :p If we could use Drawing.Color to get the colors alex was talking about, we wouldn't need to know it's RGB info in the first place.
  2. I'm feeling pretty lazy right now but you can just spawn blips in each color, take a screenshot, and look at the color of the pixels in the screenshot
  3. Edit: Federal Callouts 0.44 now matches the current specification
  4. I'm just using Color.Yellow for the routes, looks close enough to the GTA V ones if you ask me. @Stealth22 - I'll switch my callouts to use LightBlue instead of blue. I agree, Blue is too blue. I'll change the ped size scale too.
  5. nah man it's not too obvious. In one of the updates recently I made it a little more obvious, for some reason it wasn't displaying the help like I thought it would :^)
  6. I agree with @LukeD. I use a color scheme that is fairly close to Vanilla GTA V. I use green in my subtitles for general, important info (like a hotkey) and red for other information (like specifying a hostile target or a committed crime). I am all for standardizing colors though - it will make all plugins look a lot more professional. If I am correct, Federal Callouts should already be abiding by these standards. Blue for security guards/backup, red for enemies / targeted suspects. The only exception is the drug deal which marks the seller as "green" currently when the player should not move in, and then "red" when he should. I'll change it to yellow now as it's not a big deal. As for routes, I personally prefer keeping them as yellow. What if we created a library with a bunch of default stuff, like colors and such, maybe some commonly used extensions & methods. I feel like I am a library salesman and I realize it's kind of an unpopular idea due to users having trouble with installing libraries and yadda yadda but you can just put the library in your library, I don't remember what the proper term is in .NET but you can merge assemblies together (they have to be the same .NET version which shouldn't be a problem) So, PublicLSPDFRExtensions.dll YourCallouts.dll becomes YourCallouts.dll
  7. Working on a hotfix as we speak edit: Hotifx released
  8. github eta will be closer to this weekend because fuck discrete math
  9. yep I think we all know how that goes, life first man
  10. Also, while not required, I split all of my callouts into separate files for organization and testing. It's a lot easier to read that way too.
  11. Can you show the crash log so I can see where to look?
  12. I don't remember if I mentioned the name of the callout I'm working on but it's basically going to be human trafficking. I'll make it so you can do it from the ground or the air. My custom backup menu will help with that - it will let you send the units in so you don't have to land! I'll also try and get another surveillance callout that can be done from the air created as well. I don't really know why but I feel really inspired to do this right now lol
  13. I decided to go a different way with this: rather than an actual plugin it'll be a standalone tool ran outside of the game that can be bundled with plugins, and as of right now I'm looking at the MIT license.
  14. OK, so ignore my previous thread which is a different (but in the same realm) idea. It was full of other now irrelevant information as well but I cannot delete it :^) Anyway, I'm going to preface this by saying I am making this tool anyway for Federal Callouts (and whatever other plugins I make, when work decides part time < 40 hours) It's going to be similar in some aspects to Albo's troubleshooter but a bit different in terms of functionality. It's probably going to to be FOSS (as long as there aren't any issues with using third party libraries like RPH and LSPDFR which I am pretty sure there aren't, someone mentioned it though). I want it to be FOSS so that if another author wants to use it then they can just bundle a working version of it in their plugin and not worry about license / attribution / etc. The goal is to create a tool that can be bundled with plugins that help users make sure they're installed correctly but also help us, the developers, in helping the users more quickly and efficiently. Here's what I want it to do: Dynamically load plugin specification XML files that contain plugin name, (maybe version), ID, and the files the plugin has. These specification files will be automatically generated (except for name & ID, and when I get to it a dependency field [with library version number]). Make sure all files are in the right location & exist Check for updates of plugins (this will be done outside of the game) Make sure LSPDFR is installed correctly (this is a maybe - albo's tool already does this so it's not high on the priority list) Provide the user with a GUI for editing ini files with minor input sanitation to make sure they don't put words inside integer values or integers in booleans etc (this is medium priority, it'll probably be specified in the plugin specification XML but will not be mandatory) If the user still has trouble, they can automatically generate a debug html file that will have their RPH version, their RPH.log, LSPDFR version, game version, OS, and will log all plugins. They can then simply attach the HTML and the developer can open it for easy viewing. Be completely dynamic so support for other plugins can be added by the plugin without needing to recompile the tool Maintain backwards compatibility as best as possible. Ex. a plugin that doesn't get updated but has an older version bundled (and the user accidentally overwrites the newer version) will still work with newer specification files as best as possible. I'm hoping to upload it to GitHub Tuesday night but it might end up being closer to Friday. It's going to be written with WPF as of right now The idea right now seems OK but I am looking for ideas on how to make it better. I also need a cool hip name for it (other than "Configuration Tool" lmao) :~) edit: oh yeah the point of this thread was to see if there was any interest in people contributing / using, if not I won't bother with github
  15. The meatier update will be out soon, my stupid job kept me until 1am and had me working the same day at 11am so I've literally spent the entire weekend at work :^)
  16. I was thinking MIT, I really don't care if someone copies code It wasn't just your plugins, and they were configured fine before the game updated. The misconfiguration isn't really the point though. Thanks for taking the time to help solve the issue though! It was not just you though (I only have one of your plugins installed). yeah that would work too doesn't really matter in the short term anyway, I got stuck at work because our alarms wouldn't activate and had to spend the night :^)
  17. yup I planned on having it on GitHub with some OS license, I'll work on it sometime tomorrow and post something here
  18. Even then, for now we can create a common library for doing simple things many plugins already recreate. If I started work on the configuration tool / library I mentioned, would anyone be interested? I was thinking of this only applying to LSPDFR plugins so that shouldn't be a problem I wonder if it'd even work as just an API plugin that worked as a library as well? The plugin part would handle checking for updates via the config files and notifying users, and then the library part is self explanatory. It could also be split up, it doesn't really matter.
  19. Hey guys, I just wanted to say that some of the callouts / various API plugins should probably change the way they announce updates and the like to users. I was debugging FC and I hadn't updated any other plugins as I wasn't using them (I forgot to take them out of the LSPDFR folder beforehand). When the game started, I got about 10-15 notifications (not from 10-15 unique plugins) on the left all at once. They were popping up too quickly to read and one had an auto opening video (which you could cancel, however it was hidden by the other update notifications). Personally, I think this will likely just confuse and overwhelm the user. I think some of the plugins have some common libraries (couldn't tell what was out of date :^] ) so if you have multiple plugin groups that check for updates please make a system where they will show up in one popup, not 3 popups per plugin. That said, I was thinking about something. A lot of plugins are starting to have some common features. Player agency detection, update detection, etc. What if we got some developers to work together and make a common plugin library that did all of that? Instead of each callout popping up a notification about updates, it could register a method with the library that checks for updates and then tells the user something along the lines of "<number> of your plugin(s) need updating. Press <key> to display." It could maybe even include a configuration tool for any plugin that wanted it. A plugin just specifies maybe an XML file that lays out what the INI should have (and the value type), puts it in maybe LSPDFR/Configs and then when the user opens the configuration tool it loads all of the config files and gives the user a nice simple WPF GUI to edit their INI files with. Additionally, we could make it detect proper installation of each plugin with a plugin developer defined file (wouldn't be too hard - we could even automatically generate it). Thoughts?
  20. That's silly, police pull over police in real life. Granted, not often, but it does happen.
  21. When you create a persona object, there is a constructor for all of that: Oddly, it appears the only way to set a Persona wanted is when you create one in the constructor which is a tad annoying seeing as you have to define everything. I'd recommend copying most of that info from an existing persona for simplicity's sake.
  22. Yes everything is fine sorry haha I started work again so I've been extremely busy along with class, talking to my manager about lowering my hours. I'm hoping to get a new callout out soon - it might not happen. I have another feature I am trying to make, basically a command feature I guess which will mesh in with the drug deal callout and any future surveillance style callouts. I hope to have it where you can have AI backup waiting at a certain location (similar to how real sting operations would already have backup close by) defined by you and then when you're moving in you can automatically tell them to move in as well. Hopefully it'll make taking someone down a little more awesome, as it won't be a single person doing it but rather as many AI as you want.
  23. can you explain what you mean more?
  24. Hmm that's interesting, I suppose I could add some helicopter based callouts. I am currently meeting some deadlines with other projects I am working on (and some homework due friday :^) ) but I will start ASAP

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.