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

Thank you.

PHPInSimMod (PRISM) 0.3.1

• Added timers.
  • Plugin::createTimer() function added.
    
  • Plugin::getTimeout() function added.
    
  • Plugin::sortTimers() function added.
    
  • Plugin::executeTimers() function added.
    
• Fixed `prism version crashing PRISM.
  
• Fixed the prefix var being staticly set to '!', can now be anything as long as you provide it's value in hosts.ini, falls back to '!' tho, or what ever the prefix value found in cvars.ini.
  
• Fixed `the time` & `thetime` command not displaying when you've not been a player yet.
  
• Fixed information being printed to console not chat.
  
• Fixed the way text is sent to the screen when you go past the limit of the packet, now smartly spans muliple messages where available.
  
• Fixed buttons only being sent to local client.
  
• Callback say commands now only accept the command and ucid of the client, plid is no longer given.
  
• Plugin::getUserNameByUCID() is depcracated along with some other functions and are no longer defined. Use Plugin::get[Client/Player]By[UCID,PLID,UName,PName]()->[UName,PName,UCID,PLID,ect] to get the value of the user.
  
• Changed the debug level so that packets are not reported to the PRISM console.
  
• Tweaked the output of some say commands to make them look better.
  
• Rewrite of the index.php file for the www server to make it cleaner, and more useful.
  
• Added G-Meter plugin.
  
• Added a distance plugin to show people how to get the total distance of a client, in the most accurate way.
  
• Added method plugins::getStateByID().
  
• Added CSS for index.php.
  
• Added many docs about the API, please read over them, I've also added url's for the source materal of these docs as we are going to start using their API syntax alot more.
  
• Added pth & smx file parsers in the modules.
  

Yes, I was updating sometimes from github. Changes are big. Tell me please - will every of actual function work in the future or you are rewriting all the API and functions in the future will be different?

EDIT:
I have the first question: why u are doing: ->Send()->W(0)->H(0); ??

Quote from misiek08 :

Yes, I was updating sometimes from github. Changes are big. Tell me please - will every of actual function work in the future or you are rewriting all the API and functions in the future will be different?

There will be some changes, but not without the community knowing first ... They should only be trivial from this point on. So you should be pretty safe to start working on what ever you wish. I think the only thing that I wanted to change but have not yet was how the commands are registered with PRISM. Right now we have the registerSayCommand, and registerConsoleCommand, I think I'll be renaming these functions into regSayCmd, regConsoelCmd just to make the syntax more like AMX Mod X'es and Source Mod's syntax.

[My Edit Answer to Your Edit Question]

Quote from misiek08 :

I have the first question: why u are doing: ->Send()->W(0)->H(0); ??

When you chain methods in the packets classes, PHP executes these commands from left to right. So I setup the demissions of the button and then the basic detail and send the packet. From there, I set it's width and hight to zero to tell LFS to ignore all details of the packet except the Text field and the ClickID, so that I update only the text in that button. Strictly speaking, you don't have to do that ... It's just an interesting trick that I put in there that really makes no different to how PRISM handles the buttons ... right now.

Quote from Dygear :

Fixed the way text is sent to the screen when you go past the limit of the packet, now smartly spans muliple messages where available.

I wouldn't say smartly, it doesn't preserve colours, escape sequences and charsets. You'll have lines ending in '^' followed by a line starting with [0-9vacdsqtlrLGCJETBHSK], multi-byte characters could be cut up mid-sequence and even if not, will be output as complete garbage in subsequent lines due to the assumed latin-1 charset. I cannot offer a solution, but it shouldn't be too difficult

Quote from Dygear :

From there, I set it's width and hight to zero to tell LFS to ignore all details of the packet except the Text field and the ClickID, so that I update only the text in that button.

Bad idea, always send the dimensions or you will have "Invalid dimensions" errors popping up eventually, I guarantee it. Just takes someone to Shift+I, or in rare cases just to join at the wrong time, or to join when the connection queue is desynchronising (you'll find a discussion about this bug somewhere in the InSim improvement suggestions thread I think) or some other bug, it just happens, trust me.

Overall though I'm very impressed with the progress PRISM has made and still appears to be making

Quote from morpha :

I wouldn't say smartly, it doesn't preserve colours, escape sequences and charsets. You'll have lines ending in '^' followed by a line starting with [0-9vacdsqtlrLGCJETBHSK], multi-byte characters could be cut up mid-sequence and even if not, will be output as complete garbage in subsequent lines due to the assumed latin-1 charset.

You right, I was just so happy to have gotten that far ... I tried a few thing and when it did finally work I was over the moon and forgot all about the other things. So yes, it does not preserve color's or code page across the spaning lines. I'll be sure to put that into 0.3.2 or die trying.

Quote from morpha :

I cannot offer a solution, but it shouldn't be too difficult

Oh come on morpha! You where one of the guys that where so happy to be pushing PHP to it's limits! Where did that enthusiasm go? What happed to it?

Quote from morpha :

Bad idea, always send the dimensions or you will have "Invalid dimensions" errors popping up eventually, I guarantee it. Just takes someone to Shift+I, or in rare cases just to join at the wrong time, or to join when the connection queue is desynchronising (you'll find a discussion about this bug somewhere in the InSim improvement suggestions thread I think) or some other bug, it just happens, trust me.

Yes, again your correct. I should be capturing the Shift+I event and I ignore it completely. That will also be fixed in 0.3.2 as it's an unacceptable oversight. The idea behind the zero width & height button detail is that you could update the button without knowing where it was on screen. Not sure how useful that is any more come to think of it.

Quote from morpha :

Overall though I'm very impressed with the progress PRISM has made and still appears to be making

It's largely thanks to the community and the people who work on this project. Obviously Victor is a huge part of that as well as all of the past devs. I just continue to work towards a point where PRISM is the pinnacle of InSim addons written in any language. I'm very close to that, but it's going to be a few months before I can really start working on this project again like I had when Vic and me where working in tandem night after night on the 0.1.x & 0.2.x branches.

Quote from Dygear :

Oh come on morpha! You where one of the guys that where so happy to be pushing PHP to it's limits! Where did that enthusiasm go? What happed to it?

It just suddenly faded, could return just as quickly, who knows

Quote from Dygear :

Yes, again your correct. I should be capturing the Shift+I event and I ignore it completely. That will also be fixed in 0.3.2 as it's an unacceptable oversight. The idea behind the zero width & height button detail is that you could update the button without knowing where it was on screen. Not sure how useful that is any more come to think of it.

Even if you account for Shift+I the invalid dimensions issue is not completely resolved. The client clears the buttons immediately, but the server could (and in my case did quite frequently) still send buttons before the BFN_USER_CLEAR reaches it, resulting in invalid dimensions. The only bulletproof solution is to always send the dimensions, which PRISM can maintain a list of so that the plugin does not have to.

How to handle this properly depends on what you want Shift+I to do of course, in my case I wanted to preserve the original meaning, i.e. clear all buttons and keep them turned off until Shift+I'd again (sending a BFN_REQUEST), translates to $user->receive_buttons == false if you will. To make sure this works, I do this (essentially):

• receive BFN_USER_CLEAR
• set $user->receive_buttons to false, stopping the button manager from sending buttons to that connection.
• send a BFN_CLEAR to clear any buttons that might have been sent between the client side clear and the arrival of the BFN_USER_CLEAR, or more accurately the $user->receive_buttons = false.

So Shift+I is used to set if you do or do not want to receive buttons? The initial value for every client is of course to receive the buttons, but that could be turned off with Shift+I. Should that be respected across sessions?

That's up to you, the documentation leaves plenty of room for various interpretations and the client will happily display buttons sent, even if the user just hit Shift+I. Basically it's:
Buttons visible: Shift+I -> BFN_USER_CLEAR
No buttons visible: Shift+I -> BFN_REQUEST

That also means it is possible for an InSim app to receive a USER_CLEAR and a REQUEST in such quick succession that the USER_CLEAR will not have finished processing by the time the REQUEST is received, because the client does not wait for acknowledgement of the receiving InSim app.

I believe Lapper brings up a menu when it receives a USER_CLEAR, but as I said, I wanted to stick to what my interpretation of the documentation tells me it was intended for, simply clearing or requesting buttons.

@Dygear - you said and I know it - PHP executes script from left to right in this example. So if you do IS_BTN_and_text_x_y_.....->Send()->W(0)->H(0); you send button with dimensions specified (or not - that's bad) before Send() and W(0) and H(0) doesn't make sense, because LFS is not receiving it. It's after Send()!

Quote from morpha :

my interpretation

I really, really don't like that this is open to interpretation. I want to know what Scawen had in mind when he programmed this into the InSim system. If I come up with a different idea then he had planned and he makes future edits, then the whole system might malfunction. Not to mention the undefined behavior makes it impossible to make an consistent experienced across the InSim applications out there.

Quote from misiek08 :

PHP executes script from left to right in this example.

Yep that's correct, I send the packet, then set it's width & height to zero. I do this because I still have that button's instance in scope. So when I call the send function again at a later time on that instance, all contents of the packet are ignored but the text field because I set it's width and height to zero.

Quote from misiek08 :

You send button with dimensions specified before Send() and W(0) and H(0) doesn't make sense, because LFS is not receiving it. It's after Send()!

That's right, after I send the packet with it's width and height specified, I then send this data to the server. From there I set it's width and height to zero because I want LFS to skip most of the packet as I'm not moving it or changing it's dimensions just it's text data.

A quick note about PRISM releases for the next 3 months. They are almost suspended because I have to finish up 600 hours of rotations in the next 3 months. (200 hours a month, or 50 hours a week.) Along with the 40 hours a week I'm doing at work, I have no time to even sleep anymore. So don't expect much in the way of PRISM releases until around February. I'll of course try to update PRISM if I have a free minute and I see that some of the core devs have submitted patches. (That would be Victor, GeForz, Morpha & Ripnet)

Deep in the heart of the state of the art.

Quote from Dygear :

The idea behind the zero width & height button detail is that you could update the button without knowing where it was on screen. Not sure how useful that is any more come to think of it.

the current way of BTNs = array(); seems like a great solution to this problem... i could see it coming very in handy with some of my future plugins that i plan to create.

Quote from Fire_optikz001 :

the current way of BTNs = array(); seems like a great solution to this problem... i could see it coming very in handy with some of my future plugins that i plan to create.

I think you should always keep a record of the buttons that you have in use. I plan on making this a global construct in the comming versions, but there is no time frame for that. (Three months of paramedic school left, so it would be after that.)

Definitely, but PRISM should never send BTNs with invalid dimensions to the InSim host. It should keep a list of buttons with all their parameters and always send the complete BTN, the packet size remains the same so it really doesn't matter.

The added advantage is that PRISM can determine if it's actually necessary to send a button at all, which is particularly useful with high frequency triggers like MCI/CompCar at 50ms/20Hz. For example, if the application is to send the yaw angle as integer, it's likely to remain identical for several packets in succession, so sending the button again would be a complete waste of bandwidth and CPU cycles.

A sendButton() function/method would therefore check the provided BTN against the list of stored BTNs, compare BStyle, dimensions and Text and only send the new BTN if something's changed. It could also allow for a simple text update, like sendButton(ClickID, newText);

Quote from morpha :

A sendButton() function/method would therefore check the provided BTN against the list of stored BTNs, compare BStyle, dimensions and Text and only send the new BTN if something's changed. It could also allow for a simple text update, like sendButton(ClickID, newText);

I'm not a fan of the ClickID's at all, I can't wait to get higher then that and just let PRISM handle it for me. (I do mean that I'll have to program SOMETHING, but I'll program it once, and never hard to worry about ClickIDs ever again.)

Quote from Dygear :

I'll program it once, and never have to worry about ClickIDs ever again.

Quote from Dygear :

I'm not a fan of the ClickID's at all, I can't wait to get higher then that and just let PRISM handle it for me. (I do mean that I'll have to program SOMETHING, but I'll program it once, and never hard to worry about ClickIDs ever again.)

couldn't you program what LFSLapper has? and go by a button "name" instead of a click ID?

A unique identifier is one thing, but I think what Dygear has in mind is an abstract button class with, among others, an update method. You wouldn't identify the button by a string or integer, but by the reference to the associated object.

Quote from morpha :

A unique identifier is one thing, but I think what Dygear has in mind is an abstract button class with, among others, an update method. You wouldn't identify the button by a string or integer, but by the reference to the associated object.

Pretty much what I had in mind. As long as your plugin holds on to the reference the button will stay. As soon as your button is dereferenced by the plugin it should be cleaned up my the garbage collection within PHP. (But I'll have to be sure of that before I get to version 0.5.0)

Quote from Fire_optikz001 :

couldn't you program what LFSLapper has? and go by a button "name" instead of a click ID?

You can name your reference anything you want, if you want to. It could be stored in an associative array if you want, but as soon as your plugin dereference that button it will no longer be displayed and it will be deleted for memory as well.

Quote from filur :

Yeah, I had a feeling you would like that.