I've merged our patches into current and I've renamed cvars.ini to cvars-sample.ini and connections.ini to connections-sample.ini .
This has been pushed to github current branch.

I haven't bumped the version number yet. I dunno if i can write a version number like 0.2.0RC1 in prism? I mean, I can, but could that present problems later on? I guess anywhere there is a version check done, it should be kept in mind that the version string can contain alphanumerics.

hmm i should add that .gitignore like geforz mentioned, as so to ignore cvars.ini and connections.ini if they're in your development folder.

--

current branch on github : http://github.com/Dygear/PRISM/tree/current
plain zip download of 'current' : http://github.com/Dygear/PRISM/archives/current

Quote from Victor :

I've merged our patches into current and I've renamed cvars.ini to cvars-sample.ini and connections.ini to connections-sample.ini.
This has been pushed to github current branch.

Ok. I just want to add one more thing before we move onto RC1. I'll commit that later today. (It's very small in fact, it should be ready in the next hour.)

Quote from Victor :

I haven't bumped the version number yet. I dunno if i can write a version number like 0.2.0RC1 in prism? I mean, I can, but could that present problems later on? I guess anywhere there is a version check done, it should be kept in mind that the version string can contain alphanumerics.

Eh, how about "0.2.0 RC1", so I can explode the string to versionNumber and versionString and then split versionNumber into core, major and minior. The core revision version number will only be changed when we do a rewrite of the PHPInSimMod class, technically that has happed already but I digress. The major revision number should be updated to the traditional even-odd system version numbering system. The minor number being changed whenever security patches, bug fixes, new features or modules are implemented in the core.

Quote from Victor :

hmm i should add that .gitignore like geforz mentioned, as so to ignore cvars.ini and connections.ini if they're in your development folder.

Yeah, I think we all have our own config files at this point, and I'm quite happy with the default sample ini files right now.

Quote from Victor :

current branch on github : http://github.com/Dygear/PRISM/tree/current
plain zip download of 'current' : http://github.com/Dygear/PRISM/archives/current

I'll pull that into my current and have a look.

Ok, these are the mile stones we need to clear before we get to 0.2.0 RC1. I think we should still have a 0.1.9 release, just to shake things out. From there we can move to 0.2.0 RC1.

• queryPlugins in the Interactive class must be completed. - Victor will do.
  1. For each plugin file found in the plugins dir, it must loop trough asking if they want this plugin active.
     
  2. If they don't, skip to the next file.
     
  3. If they do, then you have to ask what host this plugin should get packets from. (It should use the connections alias / section name to idenifiy the host.)
     
  4. Ask if this plugin should get a packets from another connection.
     
  5. If yes, go back to step 3.
     
  6. If no, go onto the next file.
     
• Make sure that plugins only get packets from their subscribed hosts. (Respect plugins.ini addhost var.) - Done by Dygear (& Pushed to plugins.)
  
• Make the section name alaisable (So you can name the connection.) - Done by Dygear (& Pushed to autoini).
  
• Make sure that the registerPacket function accepts a variable number of packets. - Done by Dygear (& Pushed to plugins).
  

plugins auto ini sounds easy enough. I'll give that a go tonight.

I've got 2 of the 4 down now, with you doing the top, I'll work on the making sure that plugins only get packets from their subscribed hosts.

Alright, I've done my three.

how should hosts be separated in the plugins.ini file, if more than one host selected, but not all hosts are tied to a plugin?

in quotes, separated by spaces? (thereby not allowing quotes in hostIDs)

eg

[FOM]
; Formula One Management - F1 Style Overlays for Live For Speed via Buttons
useHosts = 'host 1' 'host 2'
(or double quotes..)

?

I'd prefer the following but parse_ini_file() doesn't work like that (for obvious reasons)
useHost = "host1"
useHost = "host2"
etc...

so just mean to say, that's no option.

We can just use a CSV style format for the hostnames.

useHosts = ""Host Name 1","Host Name 2","Host Name 3""

And then just explode the string.

If you prefer the other way, we could make another INI parser or have a look around for one.

I tend to agree with you on that tho. It does look better, and I would expect it to be easier.

I'll just make it csv style for now. Am almost done, so I'll push this to github quite soon and then we can ponder for a night about refinements.

Plugin system is ready for some testing on the most basic of levels. I just updated that branch.

I've pushed the plugins auto ini stuff to a new branch called 'pluginsautoini'.

oh .. i'm not parsing the useHosts value yet, so i guess it's broken
But you can have a look at the way the interactive plugin stuff works. I tried to do it a bit different than you enumerated it some posts ago. I hope it's intuitive enough

I've added the plugin-useHosts value parser.

been running your version for a while - it works

the plugins look easy enough as well. Create a function to handle something, register it in the constructor, done. Should be good.
Now for some documentation

Quote from Victor :

been running your version for a while - it works

the plugins look easy enough as well. Create a function to handle something, register it in the constructor, done. Should be good.
Now for some documentation

This is only the beginning! But I'm glad it's working without errors.

ohyeah i still see the triple shutdown msg though. Do you not see that? If not, I'll try and debug it from my end.

oic - you extend the plugins class onto the PHPInSimMod class

abstract class plugins extends PHPInSimMod

so with two plugins, there are in total 3 PHPInSimMod instances, hence 3 shutdown messages.
May I ask why you do that extension? Almost everything in PHPInSimMod is private, so cannot be acessed anyway? (you wouldn't even want plugins to be able to get there :P)

Yeah, I fixed that in my version. I had a plan for it, but it did not quite work out. I'll push the update when I get back down stairs.

Ok, I pushed it again to the plugins branch, because I've still not synced with the autoini branch yet.

Only one thing left now, and that's timers and all of the basic functionally that is needed for plugins to really work well is done. I'm happy with the current state of the plugins branch for today. Vic if you care to merge that into the autoini, and then again into current I'll pull down the current branch later tonight (when I'm at work) and finish off the rest of timers thing and we can move on.

I just also wanted to take this time to say thank you to Victor and GeForz for putting up with me, you guys are awesome .

okidoki, that's merged into current (and on github of course). Looking good.

Note that I added the .gitignore - once you pull current you'll have that too. It'll ignore the user created ini files, so you can create those and keep them and git will just ignore them, so you don't have to worry about them.

If you have any open tasks just let me know

Quote from GeForz :

If you have any open tasks just let me know

Nothing that I can think of right now, but I'll let you know.

Quote from Victor :

okidoki, that's merged into current (and on github of course). Looking good.

Note that I added the .gitignore - once you pull current you'll have that too. It'll ignore the user created ini files, so you can create those and keep them and git will just ignore them, so you don't have to worry about them.

Awesome! Pulling now!