LMS

Hm, in fact LCPDFR Networking is not even used when LCPDFR didn't detect a working internet connection. I've just released a small fix addressing a few small issues though, could you please redownload 1.1 and see if it helps?

For those of you having problems with connecting to each other in MP and a few other minor problems, a small fix has been released. Simply redownload. No need to update when you don't run into any problems.

Could you elaborate a little? How does having no internet connection cause a lag?

Having a look right now, will get back to you soon. Edit: I've pushed a new release trying to address your issue. Please re-download LCPDFR and let me know if it works.

There is not much you can do about it, the engine is just "confused" that a certain vehicle reports to have a driver but accessing the actual ped fails. Can be a sign for slowly running out of memory, but hard to narrow down really. IV does this sometimes.

If connection couldn't be established, it's definitely a firewall and/or port forwarding issue. The command connects directly over the internet, no master server stuff in between or anything. Make sure you forwarded UDP.

You are most likely missing the language file in the en-US folder. Download manual install and copy it to your folder.

As I wrote in the initial post, the LCPDFR networking connection is completely independent of GTA IV (since we can't just hijack it). So both of you have to join the same game. If LCPDFR detects your networking session, it will look up the host IP from our server and try to connect to it. If that doesn't work, net_connect can be used as a fallback. If that fails to establish a connection, it's a firewall and/or port forwarding issue as at that point it bypasses all of our services and directly connects over the internet.

Thanks for all your kind words! Yes, you host a game as usual. Then, if LCPDFR detected your networking session, it will display a helpbox. If not, reload scripts. Same for client.

Sample and documentation have been updated to reflect changes made in 1.1. A simple networking example has been added to the sample.

Just tried it in-game, works fine on my end. Do you aim at the vehicle using the QAM? If the indicator is red, it has recognized the car. You should , but I didn't test it.

Hello, it's time for another update. As stated >here earlier we've decided to release smaller patches but more often. This version is called 1.1 since we've proven ourselves to know the alphabet quite well by now I guess. Among various fixes (detailed changelog at the end of this posting), we also want to share some great news with you. After a lot of consideration we've decided to make our early netcode, we implemented during development of 1.0 but never finished, available through the API. We've also polished it a little so clients can connect automatically using our master server. Clients can still use net_connect IP[:port] to connect to servers manually in case there are issues with the automatic connection. What does it offer? Very very basic things like syncing blip creation for peds and vehicles (changes to blips except for deleting are not synced btw) and callout messages. Search areas during pursuits are also synced. I hope you aren't disappointed, this is how it is and how far we got back then and we decided it would be better to at least give you basic functionality (which you can extend!) instead of never releasing it at all. Callouts are host only. How does it work? Put simply, we establish a UDP connection between the client and server. This is completely independent of your game session, so yes, in theory you could also connect to a host's IP from another GTA game session. But we don't really encourage you to do so... So what to do as a host? If you are hosting the game, LCPDFR will recognize this automatically. Sometimes scripts are loaded in the lobby already and detection of network game might fail, so either check if you get the helpbox stating you are in a network session or simply reload scripts once in-game. Also make sure to forward UDP port 1337 (or whatever you set it to from the ini file) so clients can actually reach you. If you have a UPnP cabable router, LCPDFR will try to automatically forward ports for you. So what to do as a client? Join a game and see if you get a helpbox stating you are in a network game. If not, reload scripts. Once LCPDFR has detected your network session, it will try to retrieve the host's IP and port from our masterserver. If that works, you don't have to do anything, you will be connected automatically. If it fails (you will get notified), you can still use net_connect IP[:port] to connect. Note that port is optional. I'm an API developer, what can I do? I will update the GitHub repo with a basic example. Also check the new Networking class which provides access to our functions. You may have to add the LCPDFR.Networking lib to your project. For more questions, please use the dedicated API forums. Appendix On a final note I have to thank LukeD and ineseri for their efforts in helping me testing our networking code. From the early attempts of just establishing a connection to ironing out issues with the master server the two of you never hesitated to join me for a session when I asked. Thanks for that! Also big thanks to Cyan for finishing the master server to allow automatic connecting now. Change log API Added SetPursuitTactics and SetPursuitHelicopterTactics Added GetArrestedPeds to get all peds the player is currently taking care of LVehicle: Added SirenMuted CheckpointControl Added back QAM entries (sorry!) Pullover Fixed stats glitch (thanks to EvilJackCarver for reporting) Networking Basic network engine syncing blips (no attributes), callout messages and search areas. Better detection of network players Misc A few crash fixes Reduced obfuscation level to please AV software

Fixing Rockstar's laziness!

Yes, I did check the links as I take it seriously. But it looks to me you did not. Read the second one again: "Riskware.Confuser!", "TR/Confuser", "MSIL.Bladabindi", "Confuser.dmcsmu". The third one is the best one really. We are obfuscating the MSIL code to prevent it from being decompiled. We don't obfuscate OpenCandy, but LCPDFR! Hence MSIL! That's all. There is no OpenCandy included in the alternative install nor anything you could possibly call "malware". I highly doubt you know anything about it. If you did, you would have made your own analysis instead of running it through an online service. At the end of the day: If you are in doubt, you don't have to use it. But I can assure you there is nothing wrong with it. Go fire IDA on it and see for yourself if you wish.

Before making false accusations, why don't you double check? The normal installation gets "detected" as OpenCandy, which we don't try to hide. The alternative version gets detected for another reason, namely being "confused". This is because we obfuscate our code to prevent it from being decompiled. How is this supposed to be malware? It's common knowledge that AV software treats packers/obfuscaters as risky sometimes, because it could be used to hide stuff. Please, next time before you accuse of something like this, check the details. You're spooking people only because you have no idea of IT and/or didn't check the details.

Unwinding the stack eventually leads to audio engine initialization related calls, but that's all I could gather.

When GTA V was released for PC back in January. Probably something like getting my driver's license, 18 birthday or graduation.

Do you mean the peds that are currently following the player, i.e. where the player opted to take them to the PD? If so, that should be easy to add. Great to hear! :)

Added SetPursuitTactics and SetPursuitHelicopterTactics to the API :) Will be available soon.

No, I don't think you can control that. The only kind of control about behavior is forcing suspects to fight.

Yeah right, that might be. You are using the whole bit flags concept incorrectly. In your case, a normal (non-flags) enum would do, as you don't need the State property to cover two cases at the same time. This is useful when you want a certain check to occur all the time, but don't want to call it explicitly from other states, so you can combine them. But when you make use of bitfields, you have to set the values to powers of two. It also recommended not to use 0x0 for an actual state, but rather as a None field. I will show you why below (that's also your main issue here). The first column is how the flags look like in your setup in memory, the second one is how they should look like: Away 00000000 00000001 Close 00000001 00000010 Scenario 00000010 00000100 Wait 00000011 00001000 End 00000100 00010000 They are compared each tick using a logical AND operation. So what happens when State is set to End is this (first iteration, comparing against EState.Away): 00000100 (State) 00000000 (EState.Away) ------------- 00000000 The result of the operation is 0, which you have defined as being EState.Away. Hence that state is called, setting State to EState.Close again, which then triggers the next state etc. That's why all states are called again. So never use 0 for an actual state value and use power of twos as values when working with flags. I hope this cleared it up a little.

LtFlash, from a quick check I can tell that the State property is not changed by LCPDFR. I'd recommend having a look at your code again and verify you didn't miss a reference. State is only changed when you assign it, internally we just have a loop comparing its value against all registered states. In fact, State also supports flags, so you could have more than one state at the same time (not that this is always a wise design choice...). Let me know if issues persist. 2.) Not sure how I can help you with that, just a typo. Will change.

Hot girl > hot car

It's not that I organized my whole university schedule to fit this date... ARGH!

Hm okay. Do you have the latest Error Reporter then (08 Jan 2015)?