You can download PHPInSimMod - PRISM 0.1.8 from that link. Please use this thread to talk about this release.
Thank you.
PHPInSimMod (PRISM) 0.1.8
Added packet length check to ensure data integrity.
Memory efficient improved in handlePacket function.
Added emergency defaults for the cvars array.
Made a generic connections.ini file.
Implemented GeForz's error handling system.
Implemented GeForz's __toString function in structs class.
Implemented GeForz's printPacketStructure in strufts class, with some edits.
Implemented GeForz's some other edits.
Neater default cvars handling.
Fixed a duplicate entry in default cvars and added a missing one.
Fixed small udpPort bug in case duplicate udpPort was found in connections config causing prism to listen to a nonexistent socket (would throw php error).
yeah I see dygear has put up the files of version 0.1.7 (in the releases thread)
Dygear - maybe you pushed master to github but forgot to merge current to master first? The master branch on github still has 0.1.7 basically (but with my udpPort fix)
I was wondering why it would not let me push the update. I think when I pulled down your edits, it reverted some of my code back to an earlier state. (Mainly the version number) And that's really quite annoying.
I'm seeing a problem with the concurrent development that is going on. That is while Vic is still working on a project and I'm working on a project some times little parts overlap and cause conflicts. When that happens we get the code pushed back to an earlier state. I know I updated the version string to 0.1.8, because I do it straight after I push an update. As Vic did that last update, I pulled his code and the first thing I do is update the version number to 0.1.8 and move on from there. So I guess when I merged your udp fix, and then GeForz's improvements that caused the string to go backwards.
This is my fault and I'm going to have to figure out something to make sure no more code is lost.
working on concurrent and separate things should be possible with git though. Especially if we both work on different parts of code, then git should merge them all just fine. That's (well it should be) part of the beauty of git. You do your thing, I do mine and in the end it should merge. If there are parts of code git isn't sure about what to do with (ie. if we both edited the same lines of the same function) then it will complain to you about that.
But reverting the version number for example - that's weird. Git knows I haven't changed it, but you have, so it should, on a merge, keep your edit.
You did do a local merge from current to master, right? And then tried to push master to github? Current looks good to me, it contains all edits made by everyone, so if current was merged with master then master should be exactly the same as current at that point in time.
Yeah, sorry about that. Re-uploaded the zip file, with the corrected version.
Relay server is not required, it was just an example put up to show that it can work over the relay system as well. The corrected 0.1.8 version, does have a direct connection option (and it does to connect too 127.0.0.1 with the port of 29999.)
Me? I don't know, It might of been. All information that's from the NLP packet can be found in the MCI packet. Plus I'm pretty sure I wanted to make sure that parser worked.
I had to sync current to master. Current was kind of out of sync because one merge went straight to master, not updating current first. So current was behind on master and that may never happen.
If you've got a current branch on your own computer, please pull it from github so you are in sync again.
I've also made a small improvement to the way the asynchronous connections are done. Already in current.
I have a very small amount of work done for the plugin system, it's not yet ready to merge into the current branch, but I'll update the plugins branch later on when I get a little further with it and I'm happy that it's stable.
I took the liberty to make a start with the interactive startup in case there are missing ini files.
I'm at the point though where I'd like some people to test it, to see if it works at all on everyone's OS. I think it should work fine, but not 100% sure. So before I continue ... please test
from the commit notes :
NOTE - no actual files will be written by the interactive startup so far, so it's completely safe to run this.
NOTE 2 - it'll only ask you for connections.ini details so far. The cvars.ini file will already be generated automatically if it's missing and doesn't require user interaction really. I haven't done anything related to the plugins.ini file though, as that's too early at this point.
UPDATE -Final patch available now : http://www.lfsforum.net/showthread.php?p=1479519#post1479519
I've put these updates in a new branch on github, called the autoini branch.
Remember, when you pull this, pull it to a new branch! Don't merge it with any of your existing branches.
$ php PHPInSimMod.php Loaded cvars.ini Could not find ini file "connections.inii" ***Interactive startup*** You now have the chance to manually enter the details of the host(s) you want to connect to. Afterwards your connection settings will be stored in ./config/connections.ini for future use.
Do you want to connect to a host directly or through the relay? [direct/relay] : direct What is the IP address or hostname of the host? [] : localhost What is the InSim port number of the host? [] : 29999 Do you want to connect to the host via TCP or UDP? [tcp/udp] : tcp What is the administrator password of the host? [] : What is the administrator password of the host? [] : What is the administrator password of the host? [] : none Fatal error encountered. Exiting... Safe shutdown: 09-01-10@22:28:46
Empty password doesn't work and fatal error
Oh well probably because file creation is commented out
Yeah don't mind that fatal error message. Nothing fatal happened
Just ignore that line. It's only there because i hacked this test quickly.
I'd like someone on windows to test this as well btw
EDIT - oh btw, the empty password - isn't an admin pass required? It should be
If an option is required, it'll just keep asking you that question until you've answered it.
Just run that version to test the test. You don't have to delete any files yourself for the test to work.
This is just a test version, not a normally functioning prism.
btw, in order to get rid of that date/timezone message, you should setup the php.ini file for your php install. Google if not sure how to
Note that in order to test it, you must rename or delete the file(s) config/cvars.ini and/or config/connections.ini so that prism will think they do not exist anymore and fire off the interactive startup.
is your plugins branch good for now? Or do you have more edits done already?
I tried that version btw - worked well. The only thing is there are 3 'Safe shutdown' notices when closing. No idea really where that comes from, since the only occurance of that string is in PHPInsImMod.php and there is just one instance of the PHPInSimMod class. So it looks like __destruct() is called 3 times somehow.
How do local config file and interactive come together now?
a) Remove default connections.ini from project?
b) Let autoini write localini and supply a default connections ini with testserver over relay? That would require a interactive startup which asks "no local config found, do you want to create one?"
c) a) and remove localini
d) ?
Oh and @Plugin-System: Did you include dependencies?
Like one person wrote a plugin which handles buttons or a plugin which keeps track of players and someone else writes a plugin which could use the the player-list-plugin-data?
the thought did occur to me that prism could by default have no ini files at all. They'd be generated when you first run prism through the interactive startup.
This makes upgrading prism very easy. You could just overwrite all the default prism files but leave your config folder (and added plugins) untouched. Then after the upgrade you can just start prism and it'll find the ini files you already had.
Or if we do want to supply default config files, then they should be named connections.ini.sample or something to that extend, as to not overwrite any existing ini files upon upgrading.
That reminds me, should there be a some version checking for plugins? Like what minimum version of prism a plugin needs? Or maybe that goes too far for now.
Yes, but I don't want it release as a stable build. 0.2.0 Would be the first stable release, as we have now completed all of the things I set out to do with the core. Interactive startup was one of the last things I wanted done, and now that you completed it, I think it's ready for the first stable release. Yeah, sure, it does not really do anything, but maintaining connections and making sure the data is good but that's really important. So I feel that with your finishing of the ini branch is now good enough for a 0.2.0 branch update.
That's kinda strange, I'll look into that.
I think, that if there are no config files, and they are starting the program then they want to run the program. In order to do that, it needs to know the connection variables, so it has to ask, and it has to know.
A list of clients and a list of players will be held in the PHPInSimMod class, within a array. That will be made available to the plugins. As far as one plugin requiring another, sure we can do that, but it would also mean that required plugin has to be in the plugin list before the dependent plugin to ensure that it's loaded.
