Where is this code? Is it in a plugin? Also, is the value of $hostId correct?
I've accepted the 2 pull requests by paXton, and I'm working on fixing the bug he reported here. If I do find a solution today, expect a new version of PRISM by tonight.
While I am at it, there is a known Bug with PHP 5.4.0 Beta 1, that reports the following, and has a fatal on the other.
As right now, PHP 5.4 is still in beta, we are not going to work to actively fix these bugs, unless these problems persist into the Release Candidate. I'm also reporting these to the PHP dev team as bugs.
Ok. I've fixed the bug as reported by paXton with the State Handler clearing the client or player data before the plugin has had a chance to handle it. I'm going to submit this to github very soon, so that you can test this out. I've also added 3 packets in total that will be reported to the plugins before they are reported to the state handler. These packets are IS_PLL (Player Leave), CNL (Connection Leave) and CPR (Connection Player Rename). The last one is there so you can find both their old name from the state handler, and their new name from the packet. If you can think of any other packets that you would like to see handled in the same way, let me know.
I've accepted the 2 pull requests by paXton, and I'm working on fixing the bug he reported here. If I do find a solution today, expect a new version of PRISM by tonight.
While I am at it, there is a known Bug with PHP 5.4.0 Beta 1, that reports the following, and has a fatal on the other.
C:\Users\Dygear\PRISM>php PHPInSimMod.php
Strict Standards: Declaration of IR_HOS::unpack() should be compatible with that of Struct::unpack() in C:\Users\Dygear\PRISM\mo
dules\prism_packets.php on line 2853
Fatal error: Cannot re-assign auto-global variable _GET in C:\Users\Dygear\PRISM\modules\prism_phpparser.php on line 15
As right now, PHP 5.4 is still in beta, we are not going to work to actively fix these bugs, unless these problems persist into the Release Candidate. I'm also reporting these to the PHP dev team as bugs.
Ok. I've fixed the bug as reported by paXton with the State Handler clearing the client or player data before the plugin has had a chance to handle it. I'm going to submit this to github very soon, so that you can test this out. I've also added 3 packets in total that will be reported to the plugins before they are reported to the state handler. These packets are IS_PLL (Player Leave), CNL (Connection Leave) and CPR (Connection Player Rename). The last one is there so you can find both their old name from the state handler, and their new name from the packet. If you can think of any other packets that you would like to see handled in the same way, let me know.
Last edited by Dygear, .
Reason : Merged Posts
Putting your post in a forum that has nothing to do with accounts is not the first step in getting something done. Also, you CAN PM the devs, they DO respond when they need too. If you have not gotten an answer from them it's because they did not get enough information, and I'm sure they will not jump on MSN so that they can talk to you. So what you SHOULD do is detail what happened, with everything in it in one post so that it can be reviewed by the mods, and if the mods think that you have a case they will bring it up to the devs.
No, he is right. I have to change the order that client leave messages are processed within the packet handler module, so that the leave packets are sent to the state module last, so they are still on the list should a plugin (like his is) asks for information from the getUserByPLID native.
I'm aware of the bug, It's just a not a 'known' public bug until now.
Merging with the main topic.
Also, if you could report this on GitHub I'll keep it in mind for the next version.
I'm aware of the bug, It's just a not a 'known' public bug until now.
Merging with the main topic.
Also, if you could report this on GitHub I'll keep it in mind for the next version.
I don't currently have any support for outgauge code, but I'll consider it for the next update.
Make sure the Flags for that host does not include ISF_LOCAL, or only in single player will you be able to use the InSim application, or just one your client when connected to servers.
// The ISF_LOCAL flag is important if your program creates buttons.
// It should be set if your program is not a host control system.
// If set, then buttons are created in the local button area, so
// avoiding conflict with the host buttons and allowing the user
// to switch them with SHIFT+B rather than SHIFT+I.It's hard to document what is not a finished product. Things change.
Is something like this ok for documentation? I am trying to follow the PHP Manual Syntax as much as possible.
Is something like this ok for documentation? I am trying to follow the PHP Manual Syntax as much as possible.
Last edited by Dygear, .
Wow, thank you! I was wondering if anything was going to happen with PRISM, as I've not posted an update in quite a while. Turns out that might of been the best thing for it, now with a stable API people are using it!
About the plugin, you could change your URL to 'http://www.lfsforum.net/showthread.php?t=76342' so that when the web interface is done, it will link to here, this thread so that people can get support for your plugin should they need it.
Sonic Boom, if you have a military base in your area you'll hear it when they go faster then sound.
I've been getting hammer at work, and in life for the past month. I work as a Paramedic and I live in New York, on Long Island and we just had Hurricane Irene where we had to evacuate some hospitals and nursing homes so that was a week of hell. Then my good friend is the CCU in critical condition so I've been spending a few nights there.
But I'm sure this will work, I've just not had the chance to do this yet.
I was also reprogramming much of this PTH parser, because I wanted to provide much more power to it. So once that is released here, it should be quite a bit better to use, and make it quite a bit easier to handle.
But I'm sure this will work, I've just not had the chance to do this yet.
I was also reprogramming much of this PTH parser, because I wanted to provide much more power to it. So once that is released here, it should be quite a bit better to use, and make it quite a bit easier to handle.
I think that is pretty simple. There are no points awarded for what you do on a Saturday, so do what's best for Sunday.
Yeah, I think DRS going to be pretty worthless, the rear wing is TINY.
Really!? I seem to remember that suite too, I just did not remember that being the outcome.
If the dev is still around and only the publisher went bankrupt I still think this is not correct. Does SimBin distribute GTL or GTR2 at all?
No, not directly, but there is a PHP one.
<?php
str_replace($search, $replace, $subject);
str_replace($needle, $haystack, $subject);
$Text = str_replace('^0', '', $Text);
$Text = str_replace(
array('^0'),
array(''),
$Text
);
?>
Ah, ok. About that error ...
You just happened to stumble upon something that myself and Victor tried really hard to hide. This is an issue with the PHP langauge on the Windows side. It only happens on Windows, no other OS is effected by this error. Simply because of the way Windows handles streams, it causes that error the spam the error console unless handled. As we handle that error in the main PRISM code, most users don't see it. As you are hooking directly into the PHP error handler you are seeing this message. It is unfortunately not something I can work around.
This is where we first found the bug, and reported it to the PHP bug list, and this is anyone one. So at this point, it's a fairly well known PHP bug, just one that PHP is not moving quickly to fix. When we started PHPInSimMod, we wanted to push the boundaries of PHP, and as we are starting to see some of it's cracks I think we have succeeded.
You just happened to stumble upon something that myself and Victor tried really hard to hide. This is an issue with the PHP langauge on the Windows side. It only happens on Windows, no other OS is effected by this error. Simply because of the way Windows handles streams, it causes that error the spam the error console unless handled. As we handle that error in the main PRISM code, most users don't see it. As you are hooking directly into the PHP error handler you are seeing this message. It is unfortunately not something I can work around.
This is where we first found the bug, and reported it to the PHP bug list, and this is anyone one. So at this point, it's a fairly well known PHP bug, just one that PHP is not moving quickly to fix. When we started PHPInSimMod, we wanted to push the boundaries of PHP, and as we are starting to see some of it's cracks I think we have succeeded.
Last edited by Dygear, .
Well you are over writing the default handlers for error and shutdown, and I am not sure if you can send a packet after an error has happened within PHP as you are using a PHP resource. This might be causing the error you are having.
Second thing you might want to try is adding a return false to onPrismError at the very end. Also adding a echo statement to see if it ever get's there might also help.
Third you know you can do this right?
Second thing you might want to try is adding a return false to onPrismError at the very end. Also adding a echo statement to see if it ever get's there might also help.
Third you know you can do this right?
<?php
IS_MTC()->Sound(SND_ERROR)->UCID(255)->Text('Text')->Send();
?>
<?php
public function onPrismError($eNo, $eStr)
{
IS_MTC()->Sound(SND_ERROR)->UCID(255)->Text("^1ERROR: ^7['{$eNo}'] {$eStr}")->Send();
return FALSE;
}
public function onPrismClose()
{
IS_MTC()->Sound(SND_ERROR)->UCID(255)->Text('^1FATAL ERROR. Restarting...')->Send();
Cruise::sqlSaveAll();
}
public function __construct()
{
set_error_handler(array($this, 'onPrismError'));
register_shutdown_function(array($this, 'onPrismClose'));
}
?>
Last edited by Dygear, .
I'm sorry but that's just stupid. Heidfeld, is at the end of the day an employee of Renault, and they can use him to bake cookies if they see fit. It does not matter as along as they pay him.
Cool, thanks for the fact check, good to know there is something to it.
I've been told this is true of diesel engines, where if you take them on the motorway and run them flat out for a few miles it has the effect of 'cleaning out the headers', making it run better. I've heard this from many diesel mechanics.
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, .
FGED GREDG RDFGDR GSFDG