Wow, these are stunning!
Cool, I needed some brakes for my car, but I think I'm going to do an all 'round setup. Do Brembo Brakes deal ship to the US? (They should seeing as they are american brakes.)
[Edit] UK shipping only, crap.
[Edit] UK shipping only, crap.
Last edited by Dygear, .
So at the end of the day, it does not matter what order I feed the points into the function.
As I get deep and deeper into this, I'm seeing some of the power, and some of the problems with this setup. First off the problems. Where as I can provide it with a set of points, do I have to provide the inside edge first, then the outside?Should I make sure that I supply the left side of the road, then the right side should it be the other way around when the track is in reverse? Does any of this matter really?
The power of it really comes from the fact that no matter what layout is loaded, the forward or the reverse, I will be able to tell if they are on the track or not no matter the direction of the client. This becomes pretty important for the open track types should someone want to support them in the future. I don't have any plans right now of supporting unofficial tracks, however it should be pretty easy for someone else to make their own nodes should they need too using a path making plugin for PRISM.
On that subject, because I'm supporting making paths within PRISM, should someone need to for what ever reason. I'm going to be doing quite a large update to the PTH module, that will allow it to both read and write pth files. I'm also making it much more OOP, where everything within the object is an object. This mean that you can do $PTH->Nodes[$NodeID]->Limit->Left->toPoint(); or $PTH->roadToPoly(); This should provide for a pretty powerful syntax that is simply not seen within the LFS tool chest.
The power of it really comes from the fact that no matter what layout is loaded, the forward or the reverse, I will be able to tell if they are on the track or not no matter the direction of the client. This becomes pretty important for the open track types should someone want to support them in the future. I don't have any plans right now of supporting unofficial tracks, however it should be pretty easy for someone else to make their own nodes should they need too using a path making plugin for PRISM.
On that subject, because I'm supporting making paths within PRISM, should someone need to for what ever reason. I'm going to be doing quite a large update to the PTH module, that will allow it to both read and write pth files. I'm also making it much more OOP, where everything within the object is an object. This mean that you can do $PTH->Nodes[$NodeID]->Limit->Left->toPoint(); or $PTH->roadToPoly(); This should provide for a pretty powerful syntax that is simply not seen within the LFS tool chest.
Last edited by Dygear, .
Funny you should say that, as that's what I am attempting right now!
<?php
php
/*# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # *
# #
# This file contains a PHP adaptation of code (imagemap.c) originally #
# written by Brian J. Fox ([email protected]) for MetaHTML 5.01 #
# #
# http://directory.fsf.org/GNU/metahtml.html #
# #
# Draw a horizontal line from $X, $Y extending inf in the positive #
# X-axis. Count the number of times that line crosses the lines created #
# by connecting adjacent vertices of the polygon. If that number is #
# even, then $X, $Y is "outside" of the polygon, if odd, then "inside". #
* # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #*/
class Point
{
public $x;
public $y;
};
function inPoly ($X, $Y, array $points)
{
$min_x = $max_x = $min_y = $max_y = NULL;
# Count vertices
$vertices = count($points);
# Close the polygon if it isn't already closed.
$i = $vertices - 1;
if (($points[$i]->x != $points[0]->x) OR ($points[$i]->y != $points[0]->y))
{
++$i;
++$vertices;
$points[$i] = new Point;
$points[$i]->x = $points[0]->x;
$points[$i]->y = $points[0]->y;
$points[$i + 1] = NULL;
}
# Now check to see if the point falls within the rectangle which encloses the entire polygon.
# If not, it certainly isn't inside.
for ($i = 0; $points[$i] != NULL; ++$i)
{
$min_x = (($min_x === NULL) OR ($points[$i]->x < $min_x)) ? $points[$i]->x : $min_x;
$min_y = (($min_y === NULL) OR ($points[$i]->y < $min_y)) ? $points[$i]->y : $min_y;
$max_x = (($max_x === NULL) OR ($points[$i]->x > $max_x)) ? $points[$i]->x : $max_x;
$max_y = (($max_y === NULL) OR ($points[$i]->y > $max_y)) ? $points[$i]->y : $max_y;
}
# Is $X, $Y within the rectangle defined by $min_x, $max_y, $max_x, $min_y?
if (($X < $min_x) OR ($X > $max_x) OR ($Y < $min_y) OR ($Y > $max_y))
return FALSE;
# The point falls within the polygon. Check adjacent vertices.
$lines_crossed = 0;
for ($i = 1; $points[$i] != NULL; ++$i)
{
$p1 =& $points[$i - 1];
$p2 =& $points[$i];
$min_x = min ($p1->x, $p2->x);
$max_x = max ($p1->x, $p2->x);
$min_y = min ($p1->y, $p2->y);
$max_y = max ($p1->y, $p2->y);
# We need to know if the point falls within the rectangle defined by the maximum vertices of the vector.
if (($X < $min_x) OR ($X > $max_x) OR ($Y < $min_y) OR ($Y > $max_y))
{
# Not within the rectangle. Great!
# If it is to the left of the rectangle and in between the $Y then it crosses the line.
if (($X < $min_x) AND ($Y > $min_y) AND ($Y < $max_y))
++$lines_crossed;
continue;
}
# Find the intersection of the line -inf $Y, +inf, $Y] and $p1-x, $p1-y, $p2-x, $p2-y].
# If the location of the intercept is to the right of $X, then the line will be crossed.
$slope = ($p1->y - $p2->y) / ($p1->x - $p2->x);
if ((($Y - ($p1->y - ($slope * $p1->x))) / $slope) >= $X)
++$lines_crossed;
}
return ($lines_crossed & 1) ? TRUE : FALSE;
}
?>
Last edited by Dygear, .
Error is due to the inPoly function, going to fix it tonight.
Yeah, that did not work. If you download this version of PRISM from here and then download the LVS patch file from this thread, you'll have all of the information I have to see what I am doing.
Just extract to the same location, the PRISM file first then the LVS patch, and you'll have everything I have up until this point.
Important locations:
Just extract to the same location, the PRISM file first then the LVS patch, and you'll have everything I have up until this point.
Important locations:
- $PRISMDIR/data/pth/* - Has all of the pth files that I'm using.
- $PRISMDIR/modules/prism_plugins.php - Line 449 is the start of the inPoly function.
- $PRISMDIR/modules/prism_pth.php - Is the PTH file parser.
- $PRISMDIR/plugins/LVS.php - Is the Lap Verification System Plugin, you'll need to activate this plugin to see what I am doing.
Last edited by Dygear, .
Yeah, had a feeling. I'm heading home now (Girlfriend is driving) so I'll make the changes to the source code and see how it works after I've had something to eat.
I'm doing it straight from the MCI packets, and from the PTH file.
No harm inflected, I found it quite amusing.
You see, this is why I love Germans. They are just so direct! Thank you, avetere, I'll take a closer look at your approach.
<?php
public function toPolyLimit()
{
return array
(
array
(
'x' => $this->Center->X + $this->Limit->Left * cos(atan2($this->Direction->X, $this->Direction->Y)),
'y' => $this->Center->Y + $this->Limit->Left * sin(atan2($this->Direction->X, $this->Direction->Y))
), array
(
'x' => $this->Center->X + $this->Limit->Right * cos(atan2($this->Direction->X, $this->Direction->Y)),
'y' => $this->Center->Y + $this->Limit->Right * sin(atan2($this->Direction->X, $this->Direction->Y))
)
);
}
public function toPolyRoad()
{
return array
(
array
(
'x' => $this->Center->X + $this->Road->Left * cos(atan2($this->Direction->X, $this->Direction->Y)),
'y' => $this->Center->Y + $this->Road->Left * sin(atan2($this->Direction->X, $this->Direction->Y))
), array
(
'x' => $this->Center->X + $this->Road->Right * cos(atan2($this->Direction->X, $this->Direction->Y)),
'y' => $this->Center->Y + $this->Road->Right * sin(atan2($this->Direction->X, $this->Direction->Y))
)
);
}
?>
Last edited by Dygear, .
Ok, if you could explain this part to me. Should it not be that the Road and Limit would be giving me the delta from that of the center of the node's X & Y? There by all I should have to do is add them to the X & Y coords to get the information I need. Or am I missing some bit of information.
I'm working a something for LVS. I'm just not getting all of the parts down in my head and it's confusing me a little bit.
So, let's think it out ... We need to know if the player is in node's polygon. To do this we need to get each node's polygon, and to do that we need to load the pth file. So we are going to need to know what track we are on, for this we are going to have to hook into the State packet (IS_STA). We are also going to need to have the pth files some where that is known. (I've made it so that they are stored in $PRISM/data/pth.
Now that we have that down, we need to know the Node the player is currently in, as well as the player's X & Y coords. For this we can only hook into the MCI packet, as it is the only packet that offers this level of detail.
I am going to update the toPolyRoad() function to the Node class within the PTH module so that the code really is as simple as that.
Speaking of those changes to the Node class, here they are.
Couple this with the lfs provided PTH files found on lfs.net and extract them to your $PRISM/data/pth directory and you'll be all set to go with these.
This is providing that I'm not completely out of my mind, as all of this is very much untested.
So, let's think it out ... We need to know if the player is in node's polygon. To do this we need to get each node's polygon, and to do that we need to load the pth file. So we are going to need to know what track we are on, for this we are going to have to hook into the State packet (IS_STA). We are also going to need to have the pth files some where that is known. (I've made it so that they are stored in $PRISM/data/pth.
<?php
public function onTrackChange(IS_STA $STA)
{
$this->PTH = new PTH(ROOTDIR . '/data/pth/' . $STA->Track . '.pth');
}
?>
<?php
public function onMultiCarInfo(IS_MCI $MCI)
{
foreach ($MCI->Info as $Info)
{
if ($this->isInPoly($Info->X, $Info->Y, $this->PTH->Nodes[$Info->Node]->toPolyRoad())
continue; # They are within the node.
# If we get here, then they are NOT on the track.
}
}
?>
Speaking of those changes to the Node class, here they are.
<?php
public function toPolyLimit()
{
return array
(
array
(
'x' => $this->Center->X + $this->Limit->Left,
'y' => $this->Center->Y + $this->Limit->Left
), array
(
'x' => $this->Cetner->X + $this->Limit->Right,
'y' => $this->Cetner->Y + $this->Limit->Right
)
);
}
public function toPolyRoad()
{
return array
(
array
(
'x' => $this->Center->X + $this->Road->Left,
'y' => $this->Center->Y + $this->Road->Left
), array
(
'x' => $this->Cetner->X + $this->Road->Right,
'y' => $this->Cetner->Y + $this->Road->Right
)
);
}
?>
This is providing that I'm not completely out of my mind, as all of this is very much untested.
Last edited by Dygear, .
I tend to shy away from adding a property that does not belong there, but I agree that the information should be more flexible. I think in the case you described, there will be a proper fix for it in 2.0.0 as you can say how you want the data given to you.
If they happen to also take the whole BBC gang with them, minus Eddie, I'll be quite happy.
BTW, 0.3.0 works with the official 0.4.2 build of PRISM, so you can see what I have been up too.
Nope, over sight on my part. Thanks, going to fix this now.
I'm just pissed because they are messing with the best thing in years. We have it on the BBC, so there are no commercials, we have Martin Brundle and David Coulthard, arguably the best duo since Murry and Martin. More then anything, we are losing Martin and David for half the season, and I just don't know why they felt the need to do this. Just when it get's to be great, they have ruin it.
PHPInSimMod - PRISM 0.4.2 Discussion
You can download PHPInSimMod - PRISM 0.4.2 from that link. Please use this thread to talk about this release.
Thank you.
PHPInSimMod (PRISM) 0.4.2
Thank you.
PHPInSimMod (PRISM) 0.4.2
- Version changed to 0.4.2
- Added timeToString & timeToStr functions.
- Changes to this file allow for the `prism exit` command be used to restart, it also will automaticly restart PRISM in the event of a crash.
- Fixed an error where the Player class functions would check Flags and not the correct PType property.
- Removed module prism_state, as it was no longer used by any part of prism. Everything has already been moved over to the current State Handler.
- Updated CRON to reflect up coming changes (Thanks filur).
- Updated to current version of LVS.
PHPInSimMod (PRISM) 0.4.2
PHPInSimMod (PRISM) 0.4.2
- Version changed to 0.4.2
- Added timeToString & timeToStr functions.
- Changes to this file allow for the `prism exit` command be used to restart, it also will automaticly restart PRISM in the event of a crash.
- Fixed an error where the Player class functions would check Flags and not the correct PType property.
- Removed module prism_state, as it was no longer used by any part of prism. Everything has already been moved over to the current State Handler.
- Updated CRON to reflect up coming changes (Thanks filur).
- Updated to current version of LVS.
0.3.0
- Now supports single player races as well.
- Removed a lot of code that was not needed right now.
- File format is now UTF-8 to support the delta (Δ) character.
Ok, sorry, I'm just a little confused without the context on why you would want these.
S2Y version SMX meshes and PTH files, includes all but the AS7 and AS7R Paths. Are you ALSO looking for the older versions of the paths so that you can see what was updated between versions if anything?
@Victor & Scawen, you're missing the AS7 and AS7R path files from the SMX_PTH_S2Y zip, can you please advise.
@Victor & Scawen, you're missing the AS7 and AS7R path files from the SMX_PTH_S2Y zip, can you please advise.
Manual input into the config file that was not sanitized by the LFS game name parser?
[edit] Oh never mind, apparently Krammeth beat me to it.
FGED GREDG RDFGDR GSFDG