This would work off of the HTTP interface, so things like HTTP status codes would be used, and the transport medium for basic information on the plugins available would JSON.
Hip Tip to filur. Who by the way has done something like this for lurLFSd, many years ago. So the idea is not new, obviously, and it's also not new to LFS.
In that case, use this debug.bat script, and post the whole deb.log here. Also, if it closes right after, how do you know where the error is coming from?
debug.bat
@echo off php -e PHPInSimMod.php %1 %2 > deb.log pause
I need some people that are willing to test some of the plugins that come with the next update of PRISM. They are already on the github account, but before I release them in the wild, I would like for 3 or 4 people along with me to get on a server and make sure everything works when running from a client, and running from a dedicated server. If anyone wishes to sign up for this, please just reply below, along with the times you are available (Please include the timezone in your post so I can coordinate times with everyone.)
I've forwarded your request to Victor who is responsible for the packet handling modules with PRISM. If he want's to do it he will, if not, I'll get around to it at some point. But I would not expect it any time soon if I have to do it.
On the subject of installers, I was thinking about this and how some installers cause some Anti-Virus programs to cause a false positive. This would be the case with NSIS when using the Built-in NSISdl plugin that I intend on using. The NSIS Wiki has a warning about this plugin giving a false positive. This is a problem as I've built up a reputation of providing safe applications used by many websites, on many servers, and now many clients. I feel that even the look of impropriety could tarnish that image.
The problem boils down to this. I want to make a installer / updater that uses PRISM's github as a means of keeping everyone up to date. But in order to do that, I would have to use the Built-in NSISdl plugin and that would cause some Anti-Virus plugins to say that my installer / updater in virus. Even tho this is a false positive, I don't like the idea of that at all.
I'll have a look at it later, I'm going to sleep now. Just a note, I've never had that problem, so I don't really know what could be causing it. So if you can give me more information about the state of PRISM, and plugins running, the call stack trace that PRISM gives, that would be helpful.
You could of submitted that to your repo as you have done before, and sent me a pull request. I would of merged it like the last few updates you've sent me.
URL: iTunes VERSION: 0.4.3 DESCRIPTION: In Game iTunes HUD DEPENDENCIES: COM functions are only available for the Windows version of PHP. .Net support requires PHP 5 and the .Net runtime. You do not need to load any additional extensions in order to use this plugin.
This plugin allows for users to interact with iTunes while still racing. You can call up the iTunes interface by saying `iTunes` in chat. That will bring up the button interface.
I am planning on making navigation much easier for the next version of this plugin. So you can click on the Artist's name, and you'll be able to explore all of the artists within your iTunes library. The same will be true of the Album, where if you click on that, it will show other albums by the currently playing artist. Should you click on the song, it will show other songs available within the current Artist & Album selection.
I've completly lost my train of though on this, but I've uploaded the changes to the PTH parser within PRISM, and I would ask that you take a look at that, along with the LVS plugin.
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.
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.
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.
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.