You can download PHPInSimMod - PRISM 0.4.1 from that link. Please use this thread to talk about this release.

Thank you.

PHPInSimMod (PRISM) 0.4.1

• Fixed minor crash when running a the `prism reo` command.
  
• Fixed a bug in the Reorder plugin by requesting information about the clients & players before anything else. This should also avoid a bug in other plugins, even if the packet requests are redundant.
  
• Updated colorButtons, distance, gmeter, LVS, reorder, theTime, & welcome plugins to use simple packet syntax.
  
• Simple syntax for packets is now here. You can now have one line both create and send a packet. No more $MTC = new IS_MTC; You can now do it all in one line like, IS_MTC()->UCID(0)->Text('Hello')->Send(); If you need a refrence, you can still edit the object right away like so, $MTC = IS_MTC()->UCID($UCID); This is pretty useful when you know your going to send a message, but it has many possilbe text values. Or you might be sending a diffrent line to the same person.
  
• Fixed bug in `prism exit`, now works correctly.
  
• `prism help` will only show commands available at that clients level. Also made changes in prep for loading and unloading plugins at run time.
  
• Added more detail to ClientHandler about the PRISM admin level of the client. New methods include isPRISMAdmin, isTemporaray, getConnection & getAccessFlags. isAdmin now reports TRUE in the case that the client is a PRISM or LFS admin on the host.
  
• Ensured that UNames are handled as case insenstive throughout the admin module.
  
• Admin plugin updated so that Kick, Ban, Spec & Pit commands are all handled by one method. Basis of loading & unloading plugins at runtime was added.
  
• Removed debug code from IS_MTC class.
  
• Demo Plugin to show Button/ButtonManager usage (plugins/buttonTest.php)
  
• Button class and button manager are now in a usable state.
  
• Fixed pylons plugin (include statement).
  
• Moved packet-dispatching for buttonmanager to statehandler to avoid multiple calls for one packet
  
• Logging improvements. Packets in now show <, packets out now show > in front.
  
• Fixed Typo in Type of IS_BTT
  

Added the change log, let me know what you think!

The second-to last point should have really been "Added tracking of outbound packets"

Looks like a nice update... looking forward to using it D

Ok, so next version, the LFS Strings class that morpha worked on, and database support, and speaking of.

I was thinking of ways to handle this, and I have an idea that I'm not sure any of you are going to like. I was thinking that I would make the database a global object where it's name is it's variable. So if in your config file you make a varable called ... users, you could then do this within your plugin to get access to your users database.

Not sure if that's really a good solution in the long run tho ... what if for example two plugins use the class name users, what am I going to do about that then? I'll have to think of something else.

Quote from GeForz :

The second-to last point should have really been "Added tracking of outbound packets"

Yeah, I need to refractor that slightly also.

Maybe make it or or ?
Code like $users is for drivers/players array, not for db handler.

You see now, if I put it into say, $PRISM->database, that's where it would stay. From there you could do ... $db &= $PRISM->database['users'] to return the user database ... But I think that having this instance out for PRISM and then for anyone else might be a better option. So we could have like $PRISM->database['PRISM'] for all of the PRISM core databases, like the admin, hosts, commands, ect table. The SQL would work as the as a replacement for the config files, or could be used in conjunction with the config files. I really want to enforce permissions for the plugin level database access, so that plugins can't steal other plugins data. I think that would provide a reasonable level of security.

Couldn't you make it so you can specify it on a per plugin basis, but also have it so you can set per server, or even global basis? like...

Like admins, but with a nother level, sure, I can do that.

Before we get to 0.5.0 I want to have support for WebSockets and include a MetaSim plugin.

Just a sidenote:

Pleas DO NOT use GLOBALS

thanks

Quote from GeForz :

Just a sidenote:

Pleas DO NOT use GLOBALS

thanks

Are you talking to me / victor or to the plugin developers?

everyone *g*
well your idea with the global object in the plugins config sounds weird and conflict-provoking if two addon writers make a "users" variable-database-thing.

additionally - as a fan of oop - I hate the thought that some magically vars exists outside of the object-context and you don't know where they come from ^^

I was thinking about that myself, as far as conflict goes. I was thinking that I should make the plugins object have another property called database, or db. From there you'll have access to all of the Databases that are registered to that plugin.

Quote from GeForz :

additionally - as a fan of oop - I hate the thought that some magically vars exists outside of the object-context and you don't know where they come from ^^

I think, far worse than globals, is when someone forces an OPP construct into a place where a global would have done. The main problem with OOP is the idea that everything should be encapsulated in an object. Sometimes globals just make the code simpler.

As with the case of the global PRISM object. Victor and I did this in 0.3.0 because it just made everything so much easier. There is no One True Way, but we should provide a consistent experience as best as we can.

Yeah it's probably the same discussion as where the opening squirly braces belong, so I just continue with the given

I am just concerned about plugin-globals

Actually i find this quite interesting, because I often think "how could i possibly make this program fully OO, while still having access to generic things?"
I usually end up with some static object or global that points to the root of the program. And in c# for example there's always the program itself which is a static object that you can call anywhere in your code.
I can never think of a _clever_ way to live without a static object of sorts. You can, but then you end up passing lots and lots of references / variables to objects. Doesn't make life easier imo. And I've never noticed any downsides to having a static or global object.

But I'm happily proven wrong. It's a subject I'm always unsure of, if I'm doing it right. I guess it's a programming ideology and depends on whether you code things privately or open source. And on the other side, I don't think it has any actual security issues, right?

From a webpage standpoint, I can't see that being a problem. Unless you do something silly like extracting a $_GET or $_REQUEST array into the scope where your global object is, thus over writing it, but then it would cause a crash anyway.

Within PRISM ... Well, a plugin programmer has access to the whole stack, so it's really a moot point.

So, I was looking at some code a while back that filur sent me. It's quite surprising that he still owns my ass when it comes to programming. Considering the code he sent me is around 2 years old, even 2 years ago he was still much better of a programmer then I am now. Quite humbling.

Anyways, I looked to his code for direction on some of the stuff I've been working on in PRISM. Namely the Timers & Cron modules and the LVS plugin. Also going to work on fixing the loging functions of PRISM, so that logs directory will have a purpose.

Oh, and I'm making TINY & SMALL sub types bind-able directly from the registerPacket function.

And the last of the three types of packet styles will be support in this update.

Nobody using Linux as environment?

I warn you all, it's case sensitive!

Quote :

PHP WARNING:
require_once([...]/modules/prism_Button.php): failed to open stream: No such file or directory in [...]/PHPInSimMod.php on line 100

Quote :

PHP WARNING:
require_once([...]/modules/prism_ButtonManager.php): failed to open stream: No such file or directory in [...]/PHPInSimMod.php on line 100

[...] is an edited directory definition btw. No need to put that here.

I solved that by renaming the files of course but...

Quote :

< IS_MSO Packet from s2.
Good lap points - ^7V^1i^7ggen^7 : ^34
< IS_MSO Packet from s2.
Good lap - ^7^7Swift ^7: 1:34.71 ^9(XFR)
< IS_FLG Packet from s2.
< IS_FLG Packet from s2.
< IS_CCH Packet from s2.
< IS_SPX Packet from s2.
< IS_MSO Packet from s2.
Top split 2 - ^7^7Emplitz ^7: 1:12.16 ^9(XRT)
< IS_PLA Packet from s2.
< IS_BFN Packet from s2.

Fatal error: Call to undefined method ButtonManager::clearButtonsForConn() in [...]/modules/prism_statehandler.php on line 331

Not sure why this is happening yet (after a few hours).

Quote from cargame.nl :

Nobody using Linux as environment?

I do from time to time. I'll be sure to fix that.

Quote from cargame.nl :

Not sure why this is happening yet (after a few hours).

That function is commented out.

As soon as I got annoyed by it. How did you know that?

I cannot find any words to say how great that ButtonManager is!

It works extremely well, and is so awesome!

THANK YOU!

Hear that GeForz? You're the man!

[edit] The C++ version of PRISM will be code named Specialist, due to the technology it uses. (C++, PAWN, and SQLite, thus having the same initials as the Army Rank Specialist.)