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

Thank you.

PHPInSimMod (PRISM) 0.4.0

• Added a Button handler, that should be used to ensure no button colisions occur.
  • Includes Button class, to be used in place of IS_BTN directly.
    
  • Includes Singlton Button Manager.
    
  • Added an implementable callback called 'onButtonRequest' for plugins.
    
• Changed around the registerSayCommand's callback functions order of args, was done in a pervious version but never documented. Beware!
  
• Added packet Size default value to IS_CON.
  
• Added object list to the prism_layoutobject thanks to T3charmy.
  
• Can now also send IS_AXM packets. But be careful as the Info limit of 30 not enforced at the packet level, it must be done so within the plugin.
  
• Fixed sent size in IS_HLV & IS_OBH to the CarContOBJ parser.
  
• Fixed Undefined variable: command in canUserAccessCommand
  
• Fixed IS_ACR's UNPACK definition, now reads correctly.
  
• Fixed UNPACK definition of IS_AXM, packet now works as expected when reciving.
  
• Fixed crash when IS_OBH is sent due to CarContOBJ->Sp3 being set to protected, change to private.
  
• Fixed Undefined variable in prism_plugins (line 252).
  
• Fixed IS_PLC's PACK and UNPACK (Thanks Krammeh).
  

Is it currently not recommended that anyone use this version that's not very brave. This is not a stable release, but there have been many improvements that GeForz has added in the way of the button interface. This is a experimental test version (as really they all are, but this one more so), and should be used at your own risk only.

Good luck, and good hunting!

testing now :] I will be converting my cruise app over to the new button manager some time tonight, so feel free to come test it out =]

Edit: you forgot to include Layout Object :/
Edit2: NVM, you just forgot to remove the include from the pylons.php

Quote from Fire_optikz001 :

testing now :] I will be converting my cruise app over to the new button manager some time tonight, so feel free to come test it out =]

Sweet! I might just do that!

hmm question, is it currently possible to update an existing button VIA the new button manager? cause when you currently try to resend the button, it just keeps adding buttons, but not deleting the old ones :/

the easy way to add this if it doesn't exist, would be to check if the button(key) exist, if it doesn't add it, if it does, update it

can you still use $... = new IS_BTN?

Quote from Krammeh :

can you still use $... = new IS_BTN?

yes you can

*whew*. Written my own button management system, that allows me to use named buttons, send updates (and only sends if previous send is different)

ok I fixed it...

added

to registerbutton, and now it only sets the ClickID when needed(AKA new button), also, when you guys made the button queue, it should go on a per user not a per host basics

so added this: final product(posting to GitHub now):
BTW Dygear, look for this account, not Fire_optikz001 :P Not even quite sure how I managed to get logged into Fire_optik001... :P

OK, impressive guys. It really gets going now a bit, huh

I cannot do anything with the button interface yet because I have Airio running next to it but respect for the effort anyway

I noticed in a previous release the lap validate routine, which is unfinished at the moment but again, very very good to see progress there.

It's the basic structure of an real InSim coming to life

Quote from cargame.nl :

It's the basic structure of an real InSim coming to life

Much thanks to the community around me. This update was really put up together by GeForz, I just made it work within the current system. We have a long way to go, Version 0.4.0, vs Version 1.0.0 ...

Quote from cargame.nl :

OK, impressive guys. It really gets going now a bit, huh

It does also help that I'm out of Medic school, and that I've passed all of my exams.

But while some of this is still not over. I have 4 days, where I am to be cleared as a Paramedic at my job, because it's a title upgrade I have to go through some on site training on the Vent and IABP and things like that. So while I'm doing that I hope that you all give the 0.4.0 branch a really good run down on what works well, what does not and what needs to be changed, and what should say the same.

Quote from T3charmy :

ok I fixed it...

I realized that I did that packet system wrong from a fundamental point of view. Button packets are going to have to sent to the button class, and bypass the plugin system altogether for this to function efficiently. Although, it's not going to look pretty in the core the first time I implement it. I do expect that some other pass-throughs it will get better. That said, I would also refactor some of your code T3, you did a good job, but I have some other more concise ideas for this, although your theory is correct.

Quote from T3charmy :

ok I fixed it...

added


<?php 
if (!empty($BTN->ClickID)) { return PLUGIN_CONTINUE; }
?>



to registerbutton, and now it only sets the ClickID when needed(AKA new button), also, when you guys made the button queue, it should go on a per user not a per host basics

so added this:


<?php 
self::$ids[$hostId][$BTN->UCID]
?>



final product(posting to GitHub now):


<?php 
    public static function registerButton(Button $BTN, $hostId = null)
    {
        if (!empty($BTN->ClickID)) { return PLUGIN_CONTINUE; }
        if ($hostId === NULL)
        {
            global $PRISM;
            $hostId = $PRISM->hosts->curHostID;
        }
        
        // next id: may be 0 - 239
        $id = 0;
        if (isset(self::$ids[$hostId][$BTN->UCID]))
        {
            $id = self::$ids[$hostId][$BTN->UCID];
        }
        
        $BTN->ReqI = $id + 1; // may not be zero -_-
        $BTN->ClickID = $id;
        
        self::$ids[$hostId][$BTN->UCID] = $id + 1;
    }
?>



BTW Dygear, look for this account, not Fire_optikz001 :P Not even quite sure how I managed to get logged into Fire_optik001... :P

jeah thats one of the things i wasnt sure of. so its 239 buttons per conn and if you send a button to ucid 255 the clickid would need to be free for every user?

Quote from Dygear :

I realized that I did that packet system wrong from a fundamental point of view. Button packets are going to have to sent to the button class, and bypass the plugin system altogether for this to function efficiently. Although, it's not going to look pretty in the core the first time I implement it. I do expect that some other pass-throughs it will get better. That said, I would also refactor some of your code T3, you did a good job, but I have some other more concise ideas for this, although your theory is correct.

Altleast it gets the job done?

Quote from GeForz :

jeah thats one of the things i wasnt sure of. so its 239 buttons per conn and if you send a button to ucid 255 the clickid would need to be free for every user?

oh yea... didn't think about that :/ hmm well an option would be if UCID 255 subtract from 239 and keep going down

Quote from T3charmy :

Quote from GeForz :

jeah thats one of the things i wasnt sure of. so its 239 buttons per conn and if you send a button to ucid 255 the clickid would need to be free for every user?

oh yea... didn't think about that :/ hmm well an option would be if UCID 255 subtract from 239 and keep going down

It can be any ClickID as long as it's tracked on a per use basis. Named buttons offer a better solution as the name is the key, and the ClickID for each user could be stored as it's value. So when you want to send the same button all users, label it. Within the button handler, it will find the next available ClickID for each client and return it back to the system. This is then saved in an array that will have the buttons label as a first level key. After that, it will cantain an array that will have the Key as the UCID, and the ClickID as it's value. That would look like this ...
You guys are giving me some great ideas to do with how to handle buttons within PRISM. Please keep the discussion going!

each button in mine has a life expectancy, no matter how many times you ask the button to update it wont update until that expectancy has passed.

That way, each user can !setting uispeed 0,1,2,3,4,5,6,7,8,9,10 - 0 being instant, 10 being 10 seconds.

Of course some buttons need to be updated upon request (menus and suchlike) - so those have 0 as the expectancy!

Hope this idea helps you, Dygear.

Kinda like a Time to Live? Interesting.

That does bring up a good point ... Timed buttons. Where a button must only display for some time, the delete it's self. This comes to a point where I must think how to setup the API to allow for buttons to have their own callbacks within plugins, so things like a count down clock could be done easily.

Quote from Dygear :

Kinda like a Time to Live? Interesting.

That does bring up a good point ... Timed buttons. Where a button must only display for some time, the delete it's self. This comes to a point where I must think how to setup the API to allow for buttons to have their own callbacks within plugins, so things like a count down clock could be done easily.

Kinda, like what LFSLapper has? that was one of the things that I really liked about LFSLapper... I just didn't know if it was possible :P

Quote from Dygear :

Kinda like a Time to Live? Interesting.

That does bring up a good point ... Timed buttons. Where a button must only display for some time, the delete it's self. This comes to a point where I must think how to setup the API to allow for buttons to have their own callbacks within plugins, so things like a count down clock could be done easily.

not quite, it doesn't ever remove itself - it just allows PRISM to send the same button.

Imagine a distance counting in how many feet that you have done, you dont wanna send a button every single MCI that you receive - you only wanna update it every 3 seconds for instance.

With GeForz working on the Button Manager, and Morpha working on the LFS String class, I'll work on the not so sexy stuff. I'm going to work on the loging functions of PRISM so that the console function logs to a file, like it should. This should help with some debugging later down the road. .

Ehhrr there couldn't be a sexier thing then LVS

Yeah, but the fact that the log system does not work is slightly embarrassing considering the amount of time the code and configuration opens have been there. But your right, I should work on LVS as well.

I don't know if anyone else has tested what GeForz has made with the pylons plugin, but that was cool. I just did like a lap with it, and it's basically the arrow marks the follow you around the track, but even cooler then that, it also shows your angle of attack into the corner, so the front of the arrow might be pointing into the corner even if your going straight. It's very cool. Great for visualizer what your doing on the track with the car.

Ok, I have a 0.4.1 build that is a simple merge of what GeForz has done. Is there anything that anyone would like to see in 0.4.1 outside of the scope of buttons?

Ehhh yes but you already know

Quote from cargame.nl :

Ehhh yes but you already know

Just a quick refresh to make sure that I did not miss anything, if you don't mind.

Is it just the lap validation plugin that you want, or did you have something else?

So, pretty big news. I just worked on an update to that allows for packets to be made and sent with one line. Both this and this are completely valid PRISM code. So, I'm pretty sure at this point, that we've reached nirvana when it comes to the PRISM packets module, and I'm happy enough with it now to call it functionally complete. While that's not fundamentally complete, no huge major changes will need to be made to make everything work as far as the raw packet stuff goes. From here, we just need to add things like packet scoped functions, like assigning blame in the collision packet, things like that.

I just want to make something clear here. I program to make your lives easy. What I did was take away one line of code for each time you make a packet. I did this so that everyone's code is more concise. That's a pretty big deal for me. I don't like syntax noise, and I'll get rid of it as much as I can while giving you the fastest product possible. I hope you enjoy these little tweaks to make your lives easier. They might not come quickly, but they do come.