This is for the things on the to do list, for each release.

These are the priority levels of each task.

• Items that must get done are in red and if not done will hold back a release.
  
• Items that should get done are in orange and might hold back a release.
  
• Items that might get done are in green are low priority and are not required at all for a release.
  
• Items that are undefined are left in their default text color and have a range of effects on the release cycle.
  
• Items that are Strike-through are items are no longer considered and won't be in the next release.
  

If your a PRISM Dev, you should subscribe to this thread as it's very important that you keep up with this information.

Road Map for 1.0.0 Release
--

• Fully stable, fully functional.
  

Road Map for 0.9.0 Release
-- These are the things that should get done before we consider a 0.5.0 release of PRISM.

• Debug, debug, debug. 0.9.x will take as many releases as it needs until it becomes fully stable in prep for 1.0.0.
  

Road Map for 0.7.0 Release
-- These are the things that should get done before we consider a 0.7.0 release of PRISM.

• All strings in all instances are to be localized aware, clients can pick their language and PRISM will talk to them in their language. This includes the In Game, Telnet and HTTP interfaces.
  

Road Map for 0.5.0 Release
-- These are the things that should get done before we consider a 0.5.0 release of PRISM.

• Refactor all modules that use packets, so that they don't require an intrinsic handlePacket functions. Also making it easier for 3rd party module developers to add functionality to PRISM. Also make sure any of this modules support autoloading. Requires a public static or read-only (pseudo static (via __get()) public variable called $callbacks with the array of methods that wish to have each packet. Support for sub classes or helper class being able to get packets via this mechanism is also a must.
  
• A self update system for the core PRISM files, modules, and plugins. Uses github as the source repo for these file updates. Assigned to filur.
  

Road Map for 0.4.0 Release

• Finish timers. -- Assigned to Dygear.
  

Road Map for 0.3.0 Release
-- These are the things that should get done before we consider a 0.3.0 release of PRISM.

• Don't start Prism through the construct of PHPInSimMod class, but later on, so that $PRISM can be globalled elsewhere for easy access to all handlers (see next item). Assigned to Victor (done)
  
• Restructure the sections that make up PHPInSimMod class. Split up into ConfigHandler, UserHandler, PluginHandler, HostHandler and HttpHandler. - Assigned to Victor (done)
  
• Implement admin interface. - Assigned to Dygear (half done?)
  • Change users.ini format to follow same style as other ini files. - assigned to Victor (done)
    
  • Add interactive startup for user accounts. - assigned to Victor (half done)
    • Update the ADMIN defines to correspond with users.ini state.
      
  • Implement global admins. (Cross Server Admins - Admins on any server PRISM connects too.)
    
  • Implement local admins. (Local Server Admins)
    
  • Implement admin commands.
    • `prism kick <client>`
      
    • `prism ban <client> <time>`
      
    • `prism spec <player/client>`
      
    • `prism pit <player/client>`
      
  • Implement admin functions
    • plugin::isAdmin();
      
    • plugin::isAdminGlobal();
      
    • plugin::isAdminImmune();
      
    • plugin::isAdminLocal();
      
• Reliable http server for web admin pages - Assigned to Victor.
  
• Do proper tests! If the above features all work well, then 0.3.0 will be a good foundation for the stuff that's still to come. - Assigned to all
  

Road Map for 0.2.0 Release
-- These are the things that should get done before we consider a 0.2.0 release of PRISM.

• After ISP_ISI for each connection, a TINY_NCN, TINY_NPL & a TINY_RES packet should be sent to the server. This ensure we have all information on all clients, players and results. (In the case of a mid race join of PRIMS.) - Assigned to Victor.
  
• In the PHPInSimMod::inspectPacket function impalement the PHPInSimMod::$clients & PHPInSimMod::$players arrays. These arrays will be sub divided into their hosts, so plugins can get information on the client or players at any time. This will be used as a data cache for when the plugin programmer needs information on the client or player but they only have the UCID or PLID. - Scraped until further notice.
  • Make the PHPInSimMod::$clients & PHPInSimMod::$players arrays available to plugins via public functions. PHPInSimMod::getClients & PHPInSimMod::getPlayers respectfully would return the sub array for what ever host is getting attention at that time.
    
• All packets that have a string should be updated with their own pack function as so to optimize their size. - Assigned to GeForz.
  • Cherry pick GeForz updates. - Assigned to Dygear.
    
• Implement admin interface. - Assigned to Dygear
  • Implement users.ini.
    • Update the ADMIN defines to correspondent with users.ini state.
      
  • Implement global admins. (Cross Server Admins - Admins on any server PRISM connects too.)
    
  • Implement local admins. (Local Server Admins)
    
  • Implement admin commands.
    • `prism kick <client>`
      
    • `prism ban <client> <time>`
      
    • `prism spec <player/client>`
      
    • `prism pit <player/client>`
      
  • Implement admin functions
    • plugin::isAdmin();
      
    • plugin::isAdminGlobal();
      
    • plugin::isAdminImmune();
      
    • plugin::isAdminLocal();
      
• Finish the packets module so that all packets can be packed and unpacked. - Assigned to GeForz (If he choose to accept).
  • Cherry pick GeForz updates. - Assigned to Dygear.
    
• Webadmin Interface - Assigned to Victor.
  
• Finish all Plugin::register* methods.
  

I've checked all the normal packets for now.

Missing Packets, perhaps someone else knows them better:
- Buttons (Sorry I can't program brain**** )
- Relay/Hosts

It's in my master "branch" http://github.com/GeForz/PRISM

But before you pull it.
Should I change the name back to struct?

Quote from GeForz :

Missing Packets, perhaps someone else knows them better:
- Buttons (Sorry I can't program brain**** )
- Relay/Hosts

I'll handle them.

Quote from GeForz :

But before you pull it.
Should I change the name back to struct?

No I'll cherry pick your updates.

Actually. I will change it back to struct.
And Remove PACK/UNPACK from the "wrong" packets.

Quote from GeForz :

Actually. I will change it back to struct.
And Remove PACK/UNPACK from the "wrong" packets.

Feel free to pick our brains. I do it to Vic all of the time. If your not sure why we did something one way ask us.

Because 0.2.0 is out now, I've updated post#2 to state the goals for 0.3.0.
If I left something out, please let me know.

Sorry guys, my girlfriend slept over this weekend, so I got very little work done. As she left around 12 hours ago, I manged to get to work and have some time to review some of the changes from 0.2.0 to 0.3.0.

I already posted my bug fix for the Prefix command problem. And I'd like to take some time to explain this again here.

The registerSayCommand function is setup in a very specific way. The first argument is the command ($cmd), it expects the string that should be given without the prefix character. This is very important for the prefix agnostic nature of InSim. Admins can setup the prefix character to be anything (within ISI->Prefix & via cvars.ini within prism.) so we have to support all ways. With that in mind, you should never define your command with a prefix character, it destroys cross platform portability.

And now I'm going to go over my todo list, point by point. Yeah, this is going to take some time.

• Implement admin interface. - Assigned to Me! (Not even close to being done.)
  This is not even close to being done due to the points below having to get done first. (And there's a lot of them).
  • Change users.ini format to follow same style as other ini files. - assigned to Victor (done)
    
  • Add interactive startup for user accounts. - assigned to Victor (half done)
    • Update the ADMIN defines to correspond with users.ini state.
      I think I did this already, check my repo.
      
  • Implement global admins. (Cross Server Admins - Admins on any server PRISM connects too.)
    We are going to need to have a discussion on this, because of the changes to the users.ini file I need to know what you have in mind to see if it's better then my current framework idea. (That to be honest, I'm not crazy about.)
    
  • Implement local admins. (Local Server Admins)
    Again, we are going to have to talk about this before I can implement.
    
  • Implement admin commands.
    This is quite a bit tricker then it seems. Because it's a huge leap forward for the admin system as a whole. The commands I have in mind are not by any means basic. A command like `prism kick <client>` will have a very powerful engine behind it when I'm done. This gives great power to the admins of the server, and the users of PRISM. Basicly what I need to do is have a clients list and a players list for these commands to work 100% correctly. While this may not seem like a big deal, it also means that we have to implement a clients and players object for each client we have on the server. And here we come into some things that should be discussed before implemented. Should the players object be a property of the clients object, because you can't have a player that's not attached to the client. Or should they be separate structures with references to each other? Once that is done we can get into the targeting system of PRISM. It is my intentsion to give the admin control to be able to run `prism kick @(EAGLE)` to allow the admin to kick all people with the (EAGLE) tag in their name. You could also run with the targeting system `prism kick @XFR` to kick all of the people in XFRs. How about `prism pit @FO8` to send everyone who is driving FO8s to the pits to change their car as you'll be changin cars for the next race. Even better then that ... `prism pit @!FOX` to pit everyone who is not in a FOX. So there's that to talk about, and program.
    • `prism kick <client>`
      
    • `prism ban <client> <time>`
      
    • `prism spec <player/client>`
      
    • `prism pit <player/client>`
      
  • Implement admin functions
    Hard to do right now, because I'm not quite up to speed with the current state of the users.ini. Once me and Vic get to talk about that, I should be ready to start theses.
    • plugin::isAdmin();
      
    • plugin::isAdminGlobal();
      
    • plugin::isAdminImmune();
      
    • plugin::isAdminLocal();
      

Quote from Dygear :

While this may not seem like a big deal, it also means that we have to implement a clients and players object for each client we have on the server. And here we come into some things that should be discussed before implemented. Should the players object be a property of the clients object, because you can't have a player that's not attached to the client. Or should they be separate structures with references to each other?

I personally always settle for two separate lists. One 'connections' list (UCID) and one 'players' list (PLID). Entries in the latter store their 'parent' UCID value so you know which connection the player belongs to, though you could try referencing to the connection entry directly. I don't do that personally. It's already very easy to get to a connections object, if you have the UCID. And if you have a PLID, you can easily get there too, having a separate array. Otherwise if it'd be a property of the connection object, you'd _always_ have to know both the UCID and the PLID. not sure that's the case. Well, you could loop through the whole list, but you'd rather not, if you can go straight to the entry you are looking for. (you use UCID and PLID as indexes for the connections and players arrays).

So, do not make the players object a property of the clients (connections) object. That won't work. You want a separate list for both connections and players. One reason for this is that a connection can have multiple players.

Almost done with my assignments. We should be close to 0.3.0 very soon. (Next 24 - 48 hours, we pretty much just have to unit test our code.)

Quote from Victor :

So, do not make the players object a property of the clients (connections) object. That won't work. You want a separate list for both connections and players. One reason for this is that a connection can have multiple players.

It may be helpful to plugin writers, especially, if the core were to have a cross reference between the two.
i.e. connection object has a variable and methods to get the player id, or player object and vice versa.

Could be a bit of a pain in the bum to keep in sync sometimes (takeovers for example), but it is very easy to use and determine if a connection is an active player...

Or possibly PRISM abstracts the concept of player and connections totally. Not entirely sure on where I'm going with this as I'm just off to bed and its just popped into my head as I'm typing this, but there could be something very elegant hiding away, if its even remotely sane (which is entirely tenuous given the time and the day I've had so far)

Quote from the_angry_angel :

It may be helpful to plugin writers, especially, if the core were to have a cross reference between the two.
i.e. connection object has a variable and methods to get the player id, or player object and vice versa.

Could be a bit of a pain in the bum to keep in sync sometimes (takeovers for example), but it is very easy to use and determine if a connection is an active player...

Or possibly PRISM abstracts the concept of player and connections totally. Not entirely sure on where I'm going with this as I'm just off to bed and its just popped into my head as I'm typing this, but there could be something very elegant hiding away, if its even remotely sane (which is entirely tenuous given the time and the day I've had so far)

It does, and I went for the both route. I'm also going to add some look up tables for the common ways of referring to clients and players. (Via, UName, PName, UCID & PLID). This should allow for a pretty comprehensive targeting system, and really fast lookups. It's context sensitive, right now I'm writing all of the low level code for what these functions will be built off.

But first I have to make sure I don't break the relay, because I think I'm sending some packets that are no, no's on a relay'ed host. So I'll read over the manual first the fix that part. Everything is coming together quite nicely tho. 0.3.0 will be a vast improvement over what 0.2.0 is, is both usability and functionality. I'm scared to think of the list of new features that have been added by victor in this release. HTTP & Telnet being the hugest things (Telnet working on windows, WITH COLORS IN THE WINDOWS COMMAND CONSOLE!).

Quote from Dygear :

• `prism kick <target>`
  
• `prism ban <target> <time>`
  
• `prism spec <target>`
  
• `prism pit <target>`
  

That is the only thing I have left to do. I'm having a problem with the variable pass-though on return by reference type on some of the functions I'm using that's slowing me down. That and I hurt my finger at work, so it hurts a little to type.

It should be noted that <target> is a special type, that could mean UCID, PLID, Username or Playername. Providing any of these are unique to one player you can kick them based on this information, and it would also allow you to kick users based on just apart of their name, so long as it's unique to that client. (Eg, if I'm the only one who is on the server with the name starting Dy then you could do `!prism kick Dy` and it would kick me from the server.

Waiting on the next major release

Yeah, I'm slowing everything down. I'm pretty sure Victor sent me a message about a week ago telling me he was done on his end so it's just me. As for my excues on why this is not out yet. I've been doing 48 hours of work a week, plus Paramedic school, and I have what I think is a cold but it kinda feels more like the Black Death, so I've been taking it easy and doing things like refactoring how we make and augment packets.

Is now perfectly valid code.

Working on making this valid code as well.

Ah, method chaining. That's a brilliant idea! I'm kind of annoyed I didn't think of that myself, seeing as how much I work with LINQ. You could do code like this:


This completely fixes my issue of having too verbose packet syntax.

Quote from DarkTimes :

Ah, method chaining. That's a brilliant idea! I'm kind of annoyed I didn't think of that myself, seeing as how much I work with LINQ. You could do code like this:

this->sendPacket(IS_TINY()->ReqI(255)->SubT(TINY_NCN))

This completely fixes my issue of having too verbose packet syntax.

Does PHP allow you to specify a default method that gets called when you try to call a method that doesn't exist? I don't know if PHP would have such a thing, but Python and Ruby do. You could have the normal packet sending syntax, but also use the default missing packet stuff to send packets using the method chaining stuff.

Yes, it's called the __call() & __callStatic() magic methods. That's exactly what I implemented in the Struct class so it automagicly filters down to all of the InSim packets that I've defined (as they are extend the struct class and there by get access to it's functions.).

I'm pretty sure I was not the first to do this for InSim packets, I'm pretty sure that honor goes to filur with his lurLFSd system, but as I don't have any of his code any more I really can't be 100% sure. I mean, I do remember he made a static function called emit that allows him to send packets stright away that I might also use, or I might call it send as that's slightly less ambiguous a name for the function. But I also have to find out the function's order of succession in this case. What function is called first? The outside one, or the inside one? I'll find out later.

Well.. now for a bit of a rant.

I can't stand PHP with it's -> way to call methods... a freaking . is so much easier to type.

Quote from Dygear :

I'm pretty sure Victor sent me a message about a week ago telling me he was done on his end

Don't recall But yeah what i have in my current branch is good to go for 0.3. Have also done a clean test run and fixed the problems that glared at me.

Quote from dawesdust_12 :

Well.. now for a bit of a rant.

I can't stand PHP with it's -> way to call methods... a freaking . is so much easier to type.

Yeah, that annoys me a little. Also how you need to use the "new" keyword to create an object even though every object in PHP is declared on the heap.

Quote from Dygear :

As for my excues on why this is not out yet. I've been doing 48 hours of work a week, plus Paramedic school, and I have what I think is a cold but it kinda feels more like the Black Death, so I've been taking it easy and

Actually you don't hear me complaining, I just left a message so that you are not thinking that nobody bothers about this project anyway

I know it takes time. It's no Scirocco but it still takes time

Quote from DarkTimes :

Yeah, that annoys me a little. Also how you need to use the "new" keyword to create an object even though every object in PHP is declared on the heap.

I don't mind the new keyword.. It's just the . as an operator for methods is easier than -> Oh well.

Quote from dawesdust_12 :

Well.. now for a bit of a rant.

I can't stand PHP with it's -> way to call methods... a freaking . is so much easier to type.

Oh, god. I have douche chills from Java.

Quote from Victor :

Don't recall But yeah what i have in my current branch is good to go for 0.3. Have also done a clean test run and fixed the problems that glared at me.

I'll merge and we'll go from there. I might need some help with one or two things that I'm working on.

Quote from DarkTimes :

Yeah, that annoys me a little. Also how you need to use the "new" keyword to create an object even though every object in PHP is declared on the heap.

I'm not 100% sure if I need the new keyword, but I might.

Quote from cargame.nl :

Actually you don't hear me complaining, I just left a message so that you are not thinking that nobody bothers about this project anyway

I know it takes time. It's no Scirocco but it still takes time

I think 0.3.0 became the Christmas Tree update, everyone hanging their own thing on it.

Quote from Dygear :

I'm not 100% sure if I need the new keyword, but I might.

It came from C++. In C++ new means something specific. In PHP it doesn't do anything, it's just syntax noise. In fairness C# and Java also needlessly copied it. I blame Java.