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

Thank you.

PHPInSimMod (PRISM) 0.4.3
  • Updated to Version 0.4.3.
    Updates to support PHP 5.4.0.
    • Fixed parse error when used with PHP 5.4 RC1.
    • Fixed fatal error when used with PHP 5.4 RC1.
    • Fixed STRICT warning when calling the interactive query method in a static context on PHP 5.4.0.
    State Handler Fixes and Improvements
    • Massive update to state handler, the classes are now much better devided into their roles, lots of redundant code removed, still need to check TOC packet, and for 5.3.x compatability.
    • Added some functions to the Client & Player Hanlder.
    • ISP_TOC handling done.
    PTH & SMX module fixes and improvements
    • Added the Data Directory, that includes the PTH files used for the LVS plugin, and by the PTH module.
    • Moved the inPoly method into the pth parser, and added some new methods to use that can be found in the LVS example plugin.
    • Completly rewrote the PTH parer (twice).
    • Fixed PTH parser, was using l, but needed V because some numbers where too large.
    • Fixed small errors in the pth parser.
    • Completly rewrote the SMX parer.
    • Fixed SMX parser, was using l, but needed V because some numbers where too large.
    OutGuage Support
    • First draft of OutGauge support. Has config and network facilities and parses packet. Needs a method to actually do something with it.
    • Added OSP & OGP consts, and added their ID's to the TYPEs array.
    • Updates the OutSimPack's & OutGuagePack's PACK, UNPACK and added LENGTH and added a special unpack method to both.
    • Made OutGuage code cross refrence the information from the OutGuagePack class. That also made the code much more concise.
    General Fixes and Corrections
    • Fixed crash on player pitting.
    • Made the dedicated or listen server, answer choices make sense.
    • Slight Change for T3, to allow for plugin defined parameters to be received by the onClick handler.
    • Changed the string type for the Plate's from a NULL Padded (a) string to a SPACE Padded string (A), in response to a bug report 29 by PoVo. This effects, CPR, NPL and RES packets.
    • Fixes issue 26, reported by PoVo, where a client presses Shift + I PRISM would crash.
    • PoVo confirmed fix for the button interface, un-commented ButtonManager::buttonsForHost();
    • Fixed bug when pitting due to the handling of the Tyres.
    • Added some questions to the interactive start for the hosts, so we can find out what flags to set. I've also added default ports to both HTTP and Telnet.
    • Fixed bug where no plugins are loaded when PRISM_DEBUG_CORE is not set.
    • Fixed duplicate port-check.
    • Fixed data types for ints in the packests, where their signed long machine byte order variant, now they all are unsigned long little endian byte order as they should be.
    • Fixed PACK/UNPACK in IS_RST
    • Fixed PACK string of IS_MTC, so that sound does work.
    • Fixed a capital K in parent::unpack in the IS_HLV class.
    • Fixed missing semi-colon after class for IS_TINY.
    Plugin Update, Changes and Improvements
    • Added iTunes control plugin (Works only on Windows)
    • Added Timing & Scoring plugin.
    • Removed some testing plugins that are no longer needed. (AutoX, Button Test, Color Buttons, Contact, Distance, Gap Monitor & GapMon, and Pylons.
    • Fixed a bug with the PLL, CNL & CPR packets going to the state handler first, removing inforemoving information from the plugin's scope before they have had a chance to use it.
    • Added IS_CPR (Client Player Rename) to list of packets that are sent to the plugin before they are handled by the State Handler.
#2 - Dygear
I strongly recommend that you backup your current version of prism, before upgrading to this version!

Please let me know of any bugs you should find, as I'm sure that they are going to be a few with the statehandler, and I know of one already with the LVS plugin, but it's more to do with the pth parser. Anyway, thank you for your continued support!
#3 - cargame.nl
Awesome. Will take a look after some sleep.
#4 - T3charmy
Nice update, Also something came to mind, Would it be possible to give Timers Names... This way we can unset timers?

Edit: Either I'm doing something wrong, or buttons(using new Button) don't seem to work in this release
#5 - Dygear
Quote from T3charmy :Nice update, Also something came to mind, Would it be possible to give Timers Names... This way we can unset timers?

Show me how you want it to work.

Quote from T3charmy :Edit: Either I'm doing something wrong, or buttons(using new Button) don't seem to work in this release

Ya know, I don't know. I don't think I did any testing with buttons, I really did not expect them to stop working. I'd be pissed if I did something silly and it caused a huge bug like that. Can you post some example code that was working in 0.4.2, but is not working in 0.4.3?
#6 - PoVo
Awesome work, will check it out.
#7 - cargame.nl
Hhmm LVS always says that I am on the track no matter what.

And that not one time but all the time.

#8 - T3charmy
Quote from Dygear :Show me how you want it to work.

First Param would be Timer name, I figured now would be a good time to ask since 5.0 will break compatibility...


<?php 
$this->createTimer("HealthTimer_{$UName}", 'HealthTimer', 30, Timer::REPEAT, array($UName));
?>


<?php 
$this->removeTimer("HealthTimer_{$UName}");
?>

Edit: See Attatchment(I made it for you, but, It's probably horrible PHP compared to you, but it is FULLY working)
Edit2: Just noticed, But Giving the timers names fixed this bug aswell;
Edit3: Something just came to mind, when unsetting a timer, might be a good idea to check if timer exist, not sure if PHP throws an error or not when trying to unset something that doesn't exist
Edit4: Doesn't seem like it throws an error so.. Not really that important to worry about, but, I will leave that up to you :P

Quote from Dygear :Ya know, I don't know. I don't think I did any testing with buttons, I really did not expect them to stop working. I'd be pissed if I did something silly and it caused a huge bug like that. Can you post some example code that was working in 0.4.2, but is not working in 0.4.3?


<?php 
    public function InitButton($Name, $Group, $T=0, $L=0, $W=1, $H=1, $BStyle=null, $Text='')
    {
        $Button = new Button($this->UCID, $Name, $Group);
        $Button->T($T)->L($L)->W($W)->H($H);
        $Button->BStyle($BStyle);
        $Button->Text($Text);
        $Button->Send();
        #IS_MTC()->UCID($this->UCID)->Text('^2> ^7Buttons No Work??.')->Send();
    }
    public function UpdateButton($Name, $Text='')
    {
        $Button = ButtonManager::getButtonForKey($this->UCID, $Name);
        $Button->Text($Text);
        $Button->Send();
    }
?>

Attached files
prism_timers.txt - 3.5 KB - 705 views
#9 - T3charmy
Quote from cargame.nl :Hhmm LVS always says that I am on the track no matter what.

And that not one time but all the time.

Quote from Dygear :I know of one already with the LVS plugin, but it's more to do with the pth parser.

I think this is what He may have been refering to...
#10 - Dygear
I'll look into fixing both the timers and the buttons in the next release, as that's a pretty huge over sight on my part. :sorry:

I'll also ask around for how to do the pth parsing correctly on getting the size of the node, because, I'm really getting something wrong for sure on the size of the nodes. I hope I can get in contact with scawen, and maybe he could explain how he does the calculations.
#11 - T3charmy
Quote from Dygear :I'll look into fixing both the timers and the buttons in the next release, as that's a pretty huge over sight on my part. :sorry:

I'll also ask around for how to do the pth parsing correctly on getting the size of the node, because, I'm really getting something wrong for sure on the size of the nodes. I hope I can get in contact with scawen, and maybe he could explain how he does the calculations.

I have. timers working with names now I attatched it to my previous post, not sure if you saw that or not, would be a nice sttarting point for you.... I figure you would take that and make the code a bit cleaner...
#12 - Dygear
Yeah, I saw it. I just don't know if I want to break that compatibly in this branch.
#13 - T3charmy
Quote from Dygear :Yeah, I saw it. I just don't know if I want to break that compatibly in this branch.

I was just suggesting that it be added with 5.0 since If I remember correctly you said that it would most likely break the compatibility with existing plugins anyways
#14 - Dygear
Quote from T3charmy :I was just suggesting that it be added with 5.0 since If I remember correctly you said that it would most likely break the compatibility with existing plugins anyways

Then we are on the same page. I'll do this if I don't come up with something that I think it better. But if I did, I'll ask the community first if they think it's better.
#15 - Dygear
LVS and PTH parser now works on the repo. Please do take a look at it, and report back.
#16 - cargame.nl
Hhhhmm...

Looking better already ...

But it's not functioning one hundred percent. Some cars (like me) are not getting a message at all, doesn't seem to work for some reason.. For other it seem to work if I see the MTC announcements in chat. But I also experienced a off track report on the straight of KY3 when I nowhere was near the sides of the road.

So.. Hmm..

(Trying it live on the main server btw).
#17 - cargame.nl
Example;

Quote :PHP NOTICE:
Undefined offset: 323 in /prism043a/modules/prism_pth.php on line 74
1 :: isOnRoad in /prism043a/plugins/LVS.php:86
2 :: onCarInfo in /prism043a/modules/prism_plugins.php:156
3 :: dispatchPacket in /prism043a/modules/prism_hosts.php:577
4 :: inspectPacket in /prism043a/modules/prism_hosts.php:487
5 :: handlePacket in /prism043a/modules/prism_hosts.php:340
6 :: checkTraffic in /prism043a/prism_ot.php:228
UNKNOWN:
Argument 4 passed to PTH::inPoly() must be an array, null given, called in /prism043a/modules/prism_pth.php on line 74 and defined in /prism043a/modules/prism_pth.php on line 91
1 :: inPoly in /prism043a/modules/prism_pth.php:74
2 :: isOnRoad in /prism043a/plugins/LVS.php:86
3 :: onCarInfo in /prism043a/modules/prism_plugins.php:156
4 :: dispatchPacket in /prism043a/modules/prism_hosts.php:577
5 :: inspectPacket in /prism043a/modules/prism_hosts.php:487
6 :: handlePacket in /prism043a/modules/prism_hosts.php:340
7 :: checkTraffic in /prism043a/prism_ot.php:228
IS_MCI Object
(
[Sizerotected] => 60
[Typerotected] => 38
[ReqI] => 0
[NumC] => 2
[Info] => Array
(
[0] => CompCar Object
(
[Node] => 322
[Lap] => 5
[PLID] => 5
[Position] => 1
[Info] => 64
[Sp3rotected] => 0
[X] => 805767
[Y] => 25625361
[Z] => 21212
[Speed] => 14396
[Direction] => 63605
[Heading] => 63789
[AngVel] => 225
)

[1] => CompCar Object
(
[Node] => 248
[Lap] => 3
[PLID] => 31
[Position] => 2
[Info] => 128
[Sp3rotected] => 0
[X] => -8466906
[Y] => -20317913
[Z] => 40456
[Speed] => 9185
[Direction] => 59057
[Heading] => 58026
[AngVel] => -514
)

)

)

PLID5
X805767
Y25625361
Node322

Somehow it only seem to happen to me. Like I said I wonder if LVS work for all cars anyhow.

This is BL1 just after S/F, before T1.

Yes, I made a small debug info message when LVS is going to report when you go off track.

Other strange thing is that this isn't happening every lap while I try to follow the exact same raceline.
#18 - Dygear
It seems to happen when you get to the end of the pth array, something that I thought I had fixed in this version. I'll take a look at it. Thanks for the report.
#19 - Victor
I took the liberty to write another path detection interpretation. It's on github in the vic_pth branch. Feel free to use it or not.
Main difference I guess is the addition of prism_geometry.php where point and polygon classes and the poly->contains(point) detection happens, instead of in prism_pth.php. Also the detection algorythm is a lot shorter. It's using solution 3 from http://paulbourke.net/geometry/insidepoly/ which is really simple and totally reliable for our purpose.
Also I just know toPoly() can be faster, but I've spent all night banging my head into the monitor wondering why the faster method didn't work! It does work with my path drawing class elsewhere, but not in prism for some reason.
So i just copied your original instead and adjusted it a little so that actual polygons are stored in the polyRoad and polyLimit arrays, rather than just 2 points.

OH almost forgot one major point : Why did you say you had to use V instead of l? (small L) They are both 32 bit and l is signed which is what you need; V is unsigned.
For my implementation i have used 'l', but I also changed the CompCar coordinate values to 'l'. I know this may upset some, but this works fine here and I don't really see why it wouldn't work elsewhere imo. So if you disagree with this change, please can you elaborate on what's wrong with it? I'm curious.
#20 - Dygear
Quote from Victor :I took the liberty to write another path detection interpretation. It's on github in the vic_pth branch. Feel free to use it or not.
Main difference I guess is the addition of prism_geometry.php where point and polygon classes and the poly->contains(point) detection happens, instead of in prism_pth.php. Also the detection algorythm is a lot shorter. It's using solution 3 from http://paulbourke.net/geometry/insidepoly/ which is really simple and totally reliable for our purpose.

Thank you, I'll look into this!

Quote from Victor :OH almost forgot one major point : Why did you say you had to use V instead of l? (small L) They are both 32 bit and l is signed which is what you need; V is unsigned.

I'm pretty sure I read that these should be unsigned, not signed.
#21 - Victor
pushed a fix to the same branch just now.

As for the coordinates in insim packets, they should be signed (jebus, i wrote unsigned first). So that 0,0,0 lies at the center of the world and coordinateds go smoothly from positive to negative. If you use unsigned, then you'll get weird jumps at the center (from 0 -> 65536 * 65536 (0xFFFFFFFF) )

EDIT - if you use a 32bit OS to run php on, it might actually turn out that the unsigned V ends up as a signed 32 bit int, because 32bit php cannot do unsigned 32bit int. The largest integers on php are always the largest native int supported by the OS, and they are always signed. So on a 32bit OS that's a signed 32bit integer. On a 64bit OS it's a signed 64bit integer.
So, if you import an unsigned 32 bit integer (like with V) on a 32bit OS, php will convert that value to a signed integer. As such it may look like it works ok, but it won't on a 64bit OS. Because there it will not be converted to a signed int, as it simply fits fine in the largest value php supports on a 64bit OS (a 64 bit signed int)
#22 - cargame.nl
edit: never mind...

When pressing download on github I get the wrong branch
#23 - Victor
#24 - Victor
pushed another update with an even simpler path detection. All that is needed to determine if a point is on the path is to check if the point is within the left and right 'sides' of the node polygon. You can skip the top and bottom sides because we already know the point is in between them; we already have the node ID.
This method should also be more robust than previous, because I believe there sometimes could be a false negative when crossing from one node to the next, under certain circumstances. This shouldn't happen anymore.
#25 - Victor
One other thing, about prism in general. When I tested this path stuff on a local, single player instance, I noticed the MTC packets telling me I'm on or off the road do not work (of course).
Do you take this into account in other places where info is sent to the racer directly through MTC packets? Because they won't work when prism is connected to a offline, single player LFS client.
Or should prism not be used in single player mode?
1
345

PHPInSimMod - PRISM 0.4.3 Discussion
(120 posts, started )
FGED GREDG RDFGDR GSFDG