The online racing simulator
PHPInSimMod - PRISM 0.4.3 Discussion
(122 posts, started )
Not very useful post maybe but I still want to share my latest experiences.

First some positive news.

drawPath works like a charm ... Added some examples as attachment for fun. But, the detailedness of node segments is low. Maybe there is an easy way to improve that? Might have a negative impact on memory consumption because I initially already run out of the 32M memory reserved for PHP scripts. After increasing it to 64M this feature worked fine. Otherwise just let it be, I think it is not that important.

So drawPath seem to work good but at the same time somehow these whole custom pth processing does not work anymore. It reports once 'you are on the track' (no matter where you are, even if you are in a lake it still says that)... If I print_r pth then everything is there in the arrays (which is logical otherwise drawPath would fail too).

And still no go. While... LVS is working perfectly fine for original PTH files.

Before those changes you made it also worked much better then its doing atm. Before it reported falsely only three times a lap.. Off track... While it wasnt the case... Now.. Like I said.. Nothing much anymore considering custom PTH's.

But eehhh maybe there needs to be a more expert look from Victor onto this whole PTH matter, or just some rest and a short break to regain energy

A11, B11R and BL1R
Attached images
A11.png
B11R.png
BL1R.png
i already have an improved drawPath method and a working custom path checking. But I want to experiment a bit more with detection methods. The one I have atm is very fast when all racers are on the path, but can be relatively slow when they go off the path. I'm experimenting with some different methods of detection.
I hope to have a pretty much final version uploaded to github tomorrow. Don't have a lot of time today.
Quote from nl2dav :[J]ust some rest and a short break to regain energy

I did sleep last night for 6 glorious hours, but now I'm at work so I'll go over the code change I made with a fine tooth comb later on. When adding back the Node, Direction, Limit and Road classes, I might of missed a divide sign, or minus sign some where.

Quote from Victor :Don't have a lot of time today.

That's fine, thank you for all your help.
I've pushed the updates to a new branch called "drawpath".
It contains the updated drawPath method and it features support for custom pth files.

The way the latter must be used is simply to tell the PTH object it's a custom path file. You set that in the constructor via an additional boolean argument.
So, a custom PTH is loaded with $this->pth = new pth($path, true);
A regular PTH can still be loaded with $this->pth = new pth($path);
And that's it!

(now follows more specific info, not required for generic users of prism to know)

When creating a custom PTH the PTH class will create an additional polygon storage object, using the new PolyGrid class in prism_geometry.php.
An actual polygon quadtree appeared way too elaborate for prism, so i went with a simple grid instead. You can have a look at the code to see how it works if you're interested. It just splits up the single large polygon array we already had into small arrays, based on each polygon's position on the gridmap. Then you can simply request such a smaller polygon array according to the racer's position (2d point) and loop through it to see if the point is inside any polygon.
As such, $NodeID is not used (of course, it's always 0), however it is returned. So :

<?php 
// We are using a custom path, so :
// $CompCar->Node is 0 here
$this->pth->isOnRoad($CompCar->X$CompCar->Y$CompCar->Node);
// $CompCar->Node now holds the node id of the custom path's node the racer is on.
?>

Might be handy if you'd need the nodeID for something else. You can simply look it up this way. When using a custom PTH of course.

So Dygear, important for you to do is :
In LVS.php detect whether a PTH is default or custom and indicate this in the PTH's constructor.
Have you a mechanism for allowing prism users to add the names of the custom paths they're using? Will that be / is that tied to an autox layout's name so the custom path loading happens automatically, as long as the PTH file is provided in prism/data?
Quote from Victor :yeah. Not sure why i never thought of doing that in the first place. Anyway, I asked him if it's ok for prism to include it. We'll know soon.

EQW replied that it's ok for prism to use the updated KY2.pth file.
So dygear, feel free to include it in the next release.
Quote from Victor :As such, $NodeID is not used (of course, it's always 0), however it is returned.

Quote from Victor :Might be handy if you'd need the nodeID for something else. You can simply look it up this way. When using a custom PTH of course.

That's awesome, I'm sure that information will be useful.

Quote from Victor :Have you a mechanism for allowing prism users to add the names of the custom paths they're using? Will that be / is that tied to an autox layout's name so the custom path loading happens automatically, as long as the PTH file is provided in prism/data?

It is tied to the autox layout name right now. For example, is the track BL1X or BL1Y is loaded, and the B11.lyt file is loaded, then PRISM will look in the $PRISM/data/pth/ directory for a file called B11.pth. That mechanism is already in place, I'll just have to add the Bool TRUE when calling the PTH constructor.

Quote from Victor :EQW replied that it's ok for prism to use the updated KY2.pth file.
So dygear, feel free to include it in the next release.

Excellent, you might also want to notify Scawen to include this file in the next patch for LFS.

After merging the branches, PRISM is crashing PHP (5.4.0). I'm going to have to pin point the problem, as this might be a bug in PHP itself. (Only of the perks / drawbacks of being on the edge of with PHP is capable of, some times you go past it's limit and don't even know it.)

Yep! Seems we've found a bug in PHP. Sending my results to Vic to confirm, to see if he can reproduce on his system.

Vic, I forgot the mention in the PM that you should also remove the LVS plugin from the plugins.ini, and just leave TimingAndScoring in there. When you do that, you'll see PHP crash HARD when you get to a split time.
#82 - PoVo
Quote from Victor :EQW replied that it's ok for prism to use the updated KY2.pth file.

I asked him yesterday to go to LFS forum to check this message yes. So he is still alive, well sort of
Quote from PoVo :I've recreated one of my issue posts:
https://github.com/Dygear/PRISM/issues/32

Seems like this is still happening

Ok. I'll have to call trim on the data within the unpack function for that packet. I'll get around to it.

[EDIT] Fixed in my version.

I fixed the buttons on dedicated hosts, the only thing stoping a release is the LVS plugin and PTH parser. Seems there is an issue.

PHP NOTICE:
Uninitialized string offset: 92 in C:\Users\Dygear\PRISM\modules\prism_pth.php on line 137
1 :: isOnPath in C:\Users\Dygear\PRISM\modules\prism_pth.php:103
2 :: isOnRoad in C:\Users\Dygear\PRISM\plugins\LVS.php:119
3 :: onCarInfo in C:\Users\Dygear\PRISM\modules\prism_plugins.php:156
4 :: dispatchPacket in C:\Users\Dygear\PRISM\modules\prism_hosts.php:577
5 :: inspectPacket in C:\Users\Dygear\PRISM\modules\prism_hosts.php:487
6 :: handlePacket in C:\Users\Dygear\PRISM\modules\prism_hosts.php:353
7 :: checkTraffic in C:\Users\Dygear\PRISM\PHPInSimMod.php:228

Fatal error: Cannot access empty property in C:\Users\Dygear\PRISM\modules\prism_pth.php on line 137

Quote from Dygear :I fixed the buttons on dedicated hosts, the only thing stoping a release is the LVS plugin and PTH parser. Seems there is an issue.

PHP NOTICE:
Uninitialized string offset: 92 in C:\Users\Dygear\PRISM\modules\prism_pth.php on line 137
1 :: isOnPath in C:\Users\Dygear\PRISM\modules\prism_pth.php:103
2 :: isOnRoad in C:\Users\Dygear\PRISM\plugins\LVS.php:119
3 :: onCarInfo in C:\Users\Dygear\PRISM\modules\prism_plugins.php:156
4 :: dispatchPacket in C:\Users\Dygear\PRISM\modules\prism_hosts.php:577
5 :: inspectPacket in C:\Users\Dygear\PRISM\modules\prism_hosts.php:487
6 :: handlePacket in C:\Users\Dygear\PRISM\modules\prism_hosts.php:353
7 :: checkTraffic in C:\Users\Dygear\PRISM\PHPInSimMod.php:228

Fatal error: Cannot access empty property in C:\Users\Dygear\PRISM\modules\prism_pth.php on line 137


uhm, maybe in $this->$limitRoad[$NodeID] php thinks it wants the $NodeID'th character of the string kept in $limitRoad?
I wonder if that's only happening in your php5.4 though. I never saw that one.

EDIT - I pushed a possible fix to github. Still in the drawpath branch.
Quote from Victor :uhm, maybe in $this->$limitRoad[$NodeID] php thinks it wants the $NodeID'th character of the string kept in $limitRoad?
I wonder if that's only happening in your php5.4 though. I never saw that one.

EDIT - I pushed a possible fix to github. Still in the drawpath branch.

Yeah, odd bug. I'll take a look at your patch and let you know how it goes. I'm at work right now and I just got a call so I'll have to check it out later.

Quote from Victor :EDIT - I pushed a possible fix to github. Still in the drawpath branch.

Yep, that fixed it, but in me merging the changes, it broke the button interface again on dedicated hosts. So, I'm going to have to pin point where that problem is.
#87 - PoVo
Quote from Dygear :Ok. I'll have to call trim on the data within the unpack function for that packet. I'll get around to it.

[EDIT] Fixed in my version.

When are you going to push that into the master repo?
Once I fixed the buttons.
This is not directly about PRISM, so if you feel it doesn't belong here feel free to remove it.
But I was searching around and found Victor and Dygear talking about pth and drawing a couple posts up.

I am trying to do something in the same direction, but I have some small problem, and hope you have any idea what I'm doing wrong.

I am saving my driven X/Y coordinates, and then using a function that convert the coordinates to metres, and add 1280 to each point (so it will fit nicely into a 2560x2560 image), and then draw a polygon between the 'points', resulting in a some sort of racing line. But once I have generated the polygon and saved it as an image, it is vertically flipped somehow. Flipping the image vertically will make it matches the "S2 Track bitmaps" image perfect.

Any ideas why it is actually 'vertically wrong'?

Oh ps. I'm not using PRISM for doing this..
Quote from MariusMM :Any ideas why it is actually 'vertically wrong'?

Honestly, I have no idea, Vic has always done it that way, and I never asked him why.
All right, maybe it's supposed to happen then. I was thinking it was an error in my code.

Anyway, I managed to fix it by doing this before saving the image:
image.RotateFlip(RotateFlipType.RotateNoneFlipY);

So now the racing line fit's perfectly on top of the bitmaps that can be downloaded on lfs.net
directx uses a flipped y axis. So it's normal to flip y in other applications.
Quote from Victor :directx uses a flipped y axis. So it's normal to flip y in other applications.

Good to know.
Quote from Dygear :Once I fixed the buttons.

Would be nice to get a bugfree release of all the progress being made the last month(s).
Is the &$username done on purpose?


<?php 
    
public function getAdminInfo(&$username)
    {
        
$username strToLower($username);
?>

I was just curious because it seemed to cause issues with


<?php 
    
protected function canUserAccessCommand($UCID$cmd)
    {
        
# Hosts are automatic admins so due to their nature, they have full access.
        # Commands that have no premission level don't require this check.
        
if ($UCID == OR $cmd['accessLevel'] == -1)
            return 
TRUE;

        global 
$PRISM;
        
$adminInfo $PRISM->admins->getAdminInfo($this->getClientByUCID($UCID)->UName);
        return (
$cmd['accessLevel'] & $adminInfo['accessFlags']) ? TRUE FALSE;
    }
?>

That worked in past version of PHP to keep the memory footprint down, as you only ever had one variable with many references, but in the newer versions of PHP, it optimizes that for you so you don't have to do it any more. Although Vic said that LFS handles usernames as case insensitive.
-
(ricardoboy10) DELETED by Dygear : Adds no value to the discussion.
Alright, I'm trying to add ability to have alternating text like seen in LFSLapper(%at%)

I came up with this:


<?php 
    
public function Text($val)
    {
        if (!
is_array($val))
            
$this->Text $val;
        else{
            
$this->tStage 0;
            
$this->tArray $val;
            
$this->Text $val[0];
            
$this->createTimer($this->key.'_'.$this->UCID.'_TextAlt''nextText'1Timer::REPEAT); #Added Names to my Timers
            
console($this->tStage);
            
console(count($this->tArray));
        }
        return 
$this;
    }
    protected function 
nextText(){
        
$this->tStage += 1;
        
console($this->tStage);
        if(
$this->tStage >= count($this->tArray) ){
            
console($this->tStage);
            
$this->tStage 0;
        }
        
$this->Text $val[$this->tStage];
    }
?>

But the timer never gets created?

P.S. I added this to the module prism_button.php ... It creates the button fine and everything, but like I said, the timer doesn't get created...

Other timers made in plugins work perfectly fine, only this specific spot do timers not work...
If it's in button class you can't user timer's. Why? because when you call $this->createTimer you call Button::createTimer and it doesn't exists.

Name "Button" is example here.
Quote from misiek08 :If it's in button class you can't user timer's. Why? because when you call $this->createTimer you call Button::createTimer and it doesn't exists.

Name "Button" is example here.

I also tried Timers:: but then it spits out an error saying wrong permissions... tried changing to public, still nothing, but error went away... But I think I just thought of a way, I could easily implement this as a plugin ... maybe... I'll have to actually try it to be sure...
I think that it's impossible to use Timer outside the plugins.

PHPInSimMod - PRISM 0.4.3 Discussion
(122 posts, started )