Ah, I've always wondered why that happens but never bothered to have a look.

Nice find Dave

I found and reported this a while ago, and nothing ever got done about it... D: (but that's my fault for not making a pull request on it)

Quote from T3charmy :

Ok, there is a really annoying bug, When a user is on the server already when Insim starts, their ISP_NCN packet sends twice, so anything done on PRISM connect(While that client is on the server), sends twice...

found the culprit:


<?php 
        # Get information on the clients & players, and their current race state.
        # These are redundant because of the above request for an ISM packet.
        # They must remain in order to avoid an error state in some plugins.
        $ISP->SubT(TINY_NCN)->Send();    # get all connections (ISP_NCN)
?>



Edit: Aha, no I see why I didn't do a pull request

Quote from Dygear :

Yeah, that's a known bug. Not really sure how I am going to fix that yet. I ask for the connections in the case of PRISM starting while there is already a session in progress and I don't have their information yet. The request is needed so that I can populate their information within the state module. I'll probably check to see if there is a session in progress before I request an NCN packet.

Edit 2: So is it safe to remove the 3 lines in the PRISM constructor or not?

Quote from T3charmy :

Edit 2: So is it safe to remove the 3 lines in the PRISM constructor or not?

Yes.

Quote from Dygear :

Yes.

Alright, I'll make that change in the version Jay and I are working on.

Quick notice for everyone. There is an change in PHP 5.5 that breaks some string parsing in the packets module. It's an interesting "gotcha" that you should all be aware of. I noticed this problem in the LVS plugin when parsing the AXI packets the LName was filled with white space at the end. For now you'll want to trim() any string you get from the PRISM packet system until a core patch is applied.

Quote from Dygear :

Quick notice for everyone. There is an change in PHP 5.5 that breaks some string parsing in the packets module. It's an interesting "gotcha" that you should all be aware of. I noticed this problem in the LVS plugin when parsing the AXI packets the LName was filled with white space at the end. For now you'll want to trim() any string you get from the PRISM packet system until a core patch is applied.

Hmm, I noticed that not to long ago, was causing weird issues for me in my server that I hadn't ran in months, I ended up just doing:

and everything is working fine now... Granted, not sure if that causes issues elsewhere.

Toying with MCI for some weeks now.

I wonder if it's an LFS bug or if it's PRISM;


Basically what happens here is someone who leaves the pits but his MCI is earlier then the NPL

actually this occurs with everyone leaving the pits... Also notice that almost everything in the MCI packet is 0 except the PLID and Info 128 (=last compcar in set of MCI packets).

Weird.... Seems like a pointless packet to me.

.

Quote from cargame.nl :

Toying with MCI for some weeks now.

I wonder if it's an LFS bug or if it's PRISM;
...

It's InSim bug. I've been having the same problem using InSim.NET. It's exactly as you said MCI gets recieved before the actual NPL. What i did to fix it, is to make check on MCI if player is out of pits, before i do everything else.

Good to know! Thanks for this feedback

Quote from DarkKostas :

It's InSim bug. I've been having the same problem using InSim.NET. It's exactly as you said MCI gets recieved before the actual NPL. What i did to fix it, is to make check on MCI if player is out of pits, before i do everything else.

Thanks mate, it saves me from tracking that bug down. Glad it was not my fault, lol.

Quote from Dygear :

Quick notice for everyone. There is an change in PHP 5.5 that breaks some string parsing in the packets module. It's an interesting "gotcha" that you should all be aware of. I noticed this problem in the LVS plugin when parsing the AXI packets the LName was filled with white space at the end. For now you'll want to trim() any string you get from the PRISM packet system until a core patch is applied.

Quote from T3charmy :

Hmm, I noticed that not to long ago, was causing weird issues for me in my server that I hadn't ran in months, I ended up just doing:


<?php 
    public function unpack($rawPacket)
    {
        foreach (unpack($this::UNPACK, $rawPacket) as $property => $value)
        {
            $this->$property = trim($value);
        }

        return $this;
    }
?>



and everything is working fine now... Granted, not sure if that causes issues elsewhere.

changed the code a little, and added a trim to all unpack functions(didn't realize there was more then one at first). Submited a pull request. Wanted to get some people to test this before it was merged.

I'm going to give it 24 hours, then T3, if you'd like can you please setup for a PRISM 0.4.5 release. There are a number of enhancements that should be released to everyone.

Quote from Dygear :

I'm going to give it 24 hours, then T3, if you'd like can you please setup for a PRISM 0.4.5 release. There are a number of enhancements that should be released to everyone.

Alright, I'm working on one more feature to push up from my personal codebase without breaking existing functionality of it. Almost done, just doing code cleanup, then will push to my server to do testing, then to my repo for a pull request.

Quote from T3charmy :

Alright, I'm working on one more feature to push up from my personal codebase without breaking existing functionality of it. Almost done, just doing code cleanup, then will push to my server to do testing, then to my repo for a pull request.

Ok, once I get the pull request I should be ready to test it. In the next 24 hours right?

Quote from Dygear :

Ok, once I get the pull request I should be ready to test it. In the next 24 hours right?

Alright, I submitted the pull request for the new feature, Seems to be working great on my server.