The online racing simulator
PHPInSimMod - PRISM 0.1.7 Discussion
(18 posts, started )
#1 - Victor
PHPInSimMod - PRISM 0.1.7 Discussion
You can download PHPInSimMod - PRISM 0.1.7 from that link. Please use this thread to talk about this release.

Thank you.

PHPInSimMod (PRISM) 0.1.7
  • Added multi-connection capability
  • Added UDP support, including secondary UDP port
  • Two more ini files, connections.ini and plugins.ini
  • Several small fixes
#2 - GeForz
So this is now officially "dev approved"?

Anyways I just checked it out and looked into it and I have 2 minor additions:
-Bug: Currently all hosts without UDPport are excluded

<?php 
$udpPort        = isset($v['udpPort']) ? (int) $v['udpPort'] : 0;
...
if ($udpPort < 1 || $udpPort > 65535)
                {
                    console('Invalid port '.$udpPort.' for '.$hostID);
                    console('Host '.$hostID.' will be excluded.');
?>

-get rid of those "return FALSE" and use Exceptions :/
-
(DarkTimes) DELETED by DarkTimes
#3 - Victor
#4 - DarkTimes
I was looking through the source and a part of the code sent off some warning signals. In prism_packets.php from lines 47 to 58 there is this code:

if (isset($this->Type))
echo $TYPEs[$this->Type] . ' Object {' . PHP_EOL;
return;
echo $TYPEs[$this->Type] . ' Object {' . PHP_EOL;
foreach ($this as $property => $value)
{
$pkFnkFormat = $unPackFormat[++$propertyNumber];
# Assign the value to the unpacked packet.
$this->$property = $pkClass[$property];
echo "\t{$pkFnkFormat}\t{$property}\t= " . var_export($this->$property, TRUE) . PHP_EOL;
}
echo '}' . PHP_EOL;

The return statement on line 3 makes the rest of the code unreachable.

Edit: Yeah, the console output looks weird until you comment out those first three lines.
#5 - Victor
I had put that there when testing multiple connections, all with mci packets. The packet debug data was too much then

ps yeah the debugging can be nicer and not persistent, etc, etc, but that's not my department I wanted to do the sockets bit and I'll prolly make a plugin later on.
#6 - DarkTimes
Ah OK, that's cool. As I say, it just stuck out in the code as looking weird.

I've got the framework up and running here now and it seems to work great. My PHP skills are terrible, so I don't think I'll be able to contribute anything useful, but I might try to write a plugin when it's more complete.
#7 - GeForz
#8 - Dygear
Quote from Victor :I had put that there when testing multiple connections, all with mci packets. The packet debug data was too much then

ps yeah the debugging can be nicer and not persistent, etc, etc, but that's not my department I wanted to do the sockets bit and I'll prolly make a plugin later on.

Yeah, I'll remove that by the next version.
#9 - GeForz
#10 - Dygear
Quote from GeForz :So, after vic told me how to use git, I decided to try it and forked the project and did some changes:
http://github.com/GeForz/PRISM/compare/packetFix...dev (ignore connections.ini )

If you incorporate those changes please let me know how that works in git

Awesome mate! I'll have a look at those changes after I'm done with work as I'm on my ambulance right now. When I'm done with my cardiology exam, in about 12 hours from now, I'll review your code and merge it with the master branch.

Also feel free to jump onto the [url=irc://irc.gamesurge.net/liveforspeed]#LiveForSpeed[/url] IRC as me a Vic meet there when we are programming to pick each others brains. (Or just have some one else to rant an idea to.)

That reminds me, I really have to post the programming standard.
#11 - Victor
I've created a new branch in our repo on github called 'current', which should be used for adding patches we make. Like the beta test branch, or nightly builds, etc. So dygear, please sync with that before you checkout geforz's updates.
Then whenever we think the current branch is good enough for a release, all we have to do is merge current with master.

I added a quick packet length check in the handlePacket() method (it's in current already), with the following question for you all for when a wrong packet size is detected :

// Do we want to do anything else at this point?
// Count errors? Disconnect host?
// My preference would go towards counting the amount of times this error occurs and hang up after perhaps 3 errors.
#12 - dawesdust_12
Quote from Dygear :
Also feel free to jump onto the [url=irc://irc.gamesurge.net/liveforspeed]#LiveForSpeed[/url] IRC as me a Vic meet there when we are programming to pick each others brains. (Or just have some one else to rant an idea to.)

Reading this "GO ON IRC!" really makes me regret getting banned.
#13 - Dygear
Quote from Victor :I've created a new branch in our repo on github called 'current', which should be used for adding patches we make. Like the beta test branch, or nightly builds, etc.

Oh I got ya, it's for the work we are doing that's in progress, that's a great idea! I think I might want to do some house cleaning on the master branch then.

Quote from Victor :I added a quick packet length check in the handlePacket() method (it's in current already), with the following question for you all for when a wrong packet size is detected :

Awesome. I will look into that one! Thanks for the quick implementation.

Quote from Victor :// Do we want to do anything else at this point?
// Count errors? Disconnect host?
// My preference would go towards counting the amount of times this error occurs and hang up after perhaps 3 errors.

At this point, I think we are ready for a new release. We have enough new things that should be tested by the community.

As for our next steps; Yes I think a error count would be a great idea. That a disconnect ,with reconnect, should be an option in the cvars file or connections file. The default behavior should be discussed. I think that a count on errors again is great, but how about a threshold of errors per day, hour, minute, or # of packets. Again with discussion on safe values.
#14 - GeForz
#15 - Dygear
#16 - GeForz
Bug report:
Move lines 92-95 in prism_packets to line 74
#17 - Dygear
Quote from GeForz :Bug report:
Move lines 92-95 in prism_packets to line 74

Not being in front of my computer right now I'm not 100% sure you mean what I am thinking of, but if it's the foreach loop in the packet unpack function ...

If I put it up there I get an missing data in the tyres array (as in the IS_PIT & IS_NPL struct) so it's at the bottom to make sure the packet is fully parses into the array before we set it's value into the packet class.
#18 - GeForz
Jeah that's what I mean.

first do the tyre stuff
then assign the parsed properties to the packet fields
then do NLP and MCI parsing (they currently rely on NumC/NumP beeing set before.)

PHPInSimMod - PRISM 0.1.7 Discussion
(18 posts, started )
FGED GREDG RDFGDR GSFDG