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

Thank you.

PHPInSimMod (PRISM) 0.2.0

• Updated the packet filter to be compatable with Victor's useHost CSV changes.
  
• Does not print_r($this); on each onSay function call in theTime plugin.
  
• Major structure changes thoughout the Plugins & PHPInSimMod Class.
  
• Added basic admin system to PRISM.
  
• Fixed NULL sleep bugs that came to the surface.
  
• Prefixed say commands now work as they should.
  
• plugin::register* commands done.
  
• Admin levels setup.
  

wow, i just realized that i could already start on a very basic cruise plugin... all i really need is something to measure distance, get current location (x,y,z) and buttons... cif i was to do a very basic one it would only store cash... problem is i don't know how to get the username

Quote from Fire_optikz001 :

wow, i just realized that i could already start on a very basic cruise plugin

Everyone has full access to the InSim system, at the lowest level from version 0.1.8 onwards. I'll be adding the higher level abstraction to PRISM around version 0.5.0.

Quote from Fire_optikz001 :

all i really need is something to measure distance, get current location (x,y,z) and buttons

The measure distance thing can be done by getting the cords of the last MCI packet, and the current MCI packets. From there you have to do some maths! As for the current location, that's in the MCI packets so sign up for that in the registerPacket function. Buttons are not quite working right now ... so I'll look over their packet definitions.

Quote from Fire_optikz001 :

cif i was to do a very basic one it would only store cash... problem is i don't know how to get the username

Sign up for the IS_NPL NewPLayer, packet. Sign up for the IS_CPR (Connection (Player) Renamed), and IS_NCN (New Connection). You can get the UName from these packets.

Quote from Dygear :

Everyone has full access to the InSim system, at the lowest level from version 0.1.8 onwards. I'll be adding the higher level abstraction to PRISM around version 0.5.0.



The measure distance thing can be done by getting the cords of the last MCI packet, and the current MCI packets. From there you have to do some maths! As for the current location, that's in the MCI packets so sign up for that in the registerPacket function. Buttons are not quite working right now ... so I'll look over their packet definitions.



Sign up for the IS_NPL NewPLayer, packet. Sign up for the IS_CPR (Connection (Player) Renamed), and IS_NCN (New Connection). You can get the UName from these packets.

The constants are named ISP_xxx
-> ISP_MCI, ISP_CPR etc.

Quote from GeForz :

The constants are named ISP_xxx
-> ISP_MCI, ISP_CPR etc.

tried that .... gives me

ok now it doesn't.... but for some reason the MCI packet isn't sent/found by PRISM

Quote from Fire_optikz001 :

tried that .... gives me

ok now it doesn't.... but for some reason the MCI packet isn't sent/found by PRISM

I'll look into it after my bloc party is over.

Quote from Dygear :

I'll look into it after my bloc party is over.

That's because of the NPL in the connections module

Quote from GeForz :

That's because of the NPL in the connections module

how to fix? o.o

in ./modules/prism_connections.php, find this line :

change the ISF_NLP to ISF_MCI

... or wait for the next release.

Quote from Victor :

in ./modules/prism_connections.php, find this line :


<?php 
$ISP->Flags        = ISF_LOCAL | ISF_MSO_COLS | ISF_NLP;
?>



change the ISF_NLP to ISF_MCI

... or wait for the next release.

Thanks

Hi,

Firstly, excellent work with PRISM, I'm looking forward to see the development, secondly sorry if this post dosen't belong here, and lastly I am very much a hobby programmer, so I fall into the little knowledge and dangerous catergory

I'm trying to create something to help the Absolute Beginner League with the Le-mans series of races, where the week leading up to the event is the qualification time, and on race night the grid is automatically sorted.

Also when the open league has more than 32 racers, the event can be set over two servers. Qualification can be done on either server then the grid re-ordered to the qualifing times.

Everything is administered via a web page, so racers can see what is happening and where.


I realise 0.3 is due imminently, but though I'd share my experience.

The registerPacket works excellent for ISP_NCN, ISP_CNL, ISP_NPL, ISP_LAP, but I hit a few problems with the ISP_REO package.

I couldn't get or construct any sort of packet with $PLID in IS_REO, so I changed it to this. (unfortunately, due to skills, I'm still looking into a way of tyding this up)

const PACK = 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC';
const UNPACK = 'CSize/CType/CReqI/CNumP/CPLID01/CPLID02/CPLID03/CPLID04/CPLID05/CPLID06/..
..CPLID07/CPLID08/CPLID09/CPLID10/CPLID11/CPLID12/CPLID13/CPLID14/CPLID15/..
..CPLID16/CPLID17/CPLID18/CPLID19/CPLID20/CPLID21/CPLID22/CPLID23/CPLID24/..
..CPLID25/CPLID26/CPLID27/CPLID28/CPLID29/CPLID30/CPLID31/CPLID32';
public $Size = 36; // 36
public $Type = ISP_REO;// ISP_REO
public $ReqI; // 0 unless this is a reply to an TINY_REO request
public $NumP; // number of players in race
public $PLID01; // all PLIDs in new order
public $PLID02;
public $PLID03;
public $PLID04;
public $PLID05;
public $PLID06;
public $PLID07;
public $PLID08;
public $PLID09;
public $PLID10;
public $PLID11;
public $PLID12;
public $PLID13;
public $PLID14;
public $PLID15;
public $PLID16;
public $PLID17;
public $PLID18;
public $PLID19;
public $PLID20;
public $PLID21;
public $PLID22;
public $PLID23;
public $PLID24;
public $PLID25;
public $PLID26;
public $PLID27;
public $PLID28;
public $PLID29;
public $PLID30;
public $PLID31;
public $PLID32;



The only other thing I run into was having some sort of call-back for external commands, to elaborate on the html page I have 'send msg' & 'send re-order' and use MySql to store the command. I then used the ISP_NLP request (as it happens most often) to check the databse and process the commands - I can see this is proberbly not the best way to go about this.




I've attached my latest development pakage, if its of any interest..

Quote from DK-77 :

(unfortunately, due to skills, I'm still looking into a way of tyding this up)

You and me both. I'm not sure how to handle the IS_REO packet. I don't know very much about it but I will do my best to learn about it and see if I can't come up with a good solution for you and everyone else.

Quote from DK-77 :

The only other thing I run into was having some sort of call-back for external commands, to elaborate on the html page I have 'send msg' & 'send re-order' and use MySql to store the command. I then used the ISP_NLP request (as it happens most often) to check the databse and process the commands - I can see this is proberbly not the best way to go about this.

The web interface is really Victors field, but I like that your using it .

Quote from DK-77 :

I've attached my latest development pakage, if its of any interest..

It takes balls of steel to share code these days, so thank you very much for the contribution.

Quote from Dygear :

The web interface is really Victors field, but I like that your using it .

The html is my own, I've seen that Victors branch has html, but haven't had a chance to have a look yet - but I will. Most of the my code was orginally using Ripnets phpInsim (which I got out of my depth with), and I've transfered it over to PRISM

Quote from Dygear :

It takes balls of steel to share code these days, so thank you very much for the contribution.

And thank you for PRISM , and hopefully I can have get a usable plugin ready to share for your release

i recommend not looking too much at my http/html part just yet, until prism 0.3.0 or so. Atm I'm trying to settle on a good way of doing things, which means things change a lot on a daily basis.
But I'll holler when I think it'll be usable for others. And I'll accompany it with a document to explain and an example php file (it already has something like that).

Btw vic are you planning on http plugins? I had to hardcode my json output handling into your source... *g*

Quote from DK-77 :

The only other thing I run into was having some sort of call-back for external commands, to elaborate on the html page I have 'send msg' & 'send re-order' and use MySql to store the command. I then used the ISP_NLP request (as it happens most often) to check the databse and process the commands - I can see this is proberbly not the best way to go about this.

Having read your post again ...

I think there are 3 options :

1) store results in sql, to recall for web display. And store commands from the web in sql, and recall that in your race administration prism plugin. Not recommended - uses a shit load of db queries that return empty and won't work -instantly-.

2) store results internally (and in sql if you like) and use the PRISM webserver for race results / administration. Because this webserver is part of PRISM, you can call functions in your plugin directly. So a web admin command coming in via a http request can be processed instantly.

3) store results internally (and in sql if you like) and use the telnet interface to send commands (and retrieve data), using your regular web server and regular php scripts. This has not been implemented yet, but it's been roaming in my head.
Just see it like retrieving data from sql, but then via another interface. And you can send commands there as well, which will be processed instantly.

---
Options 2 will probably work well, but remember it's a http server written in php and inside PRISM. It has its shortcomings because of that, both perfomance wise and programming wise. However, the direct communication part, between www and prism is very nice and simplifies a number of things. And it responds instantly. Also those shortcomings don't mean you can only write simple scripts - you can go all out if you want; you just have to follow some rules.

I've attached a first version of a document that will be included with prism v0.3.0, explaining a bit more about how to write your own web pages for the prism webserver.

Quote from GeForz :

Btw vic are you planning on http plugins? I had to hardcode my json output handling into your source... *g*

don't the regular php json functions work?
And you can of course just include your own classes into your web-php scripts. No need to add code to the core files.

Could I ask a question?

Until the html part is ready I want to call a function (ABLAS_main) in the plugin I've called ABLAS from the main loop.

I have two connections S2L and MID

within the main loop after this line
(line 504) foreach ($this->hosts as $hostID => $host)

I use
$this->plugins['ABLAS']->ABLAS_main();

It sort of works, but only ever executes the function as the S2L conection.


What is the correct method to call a plugin function from the main loop?


Or have I gone completely off-course... sorry I've spend hours trying to figure it out and now can't see the wood from the trees

Many Thanks

Ok first of all, as a plugin programmer you will never have to add code to any of the core Prism files. If there is a feature missing from the Prism core, please ask for it here. Or you can write it yourself, but as said before, development is going really fast at the moment so you'd have to make sure you're not working in a too old version. And by now, v0.2.0 is kinda old already, even if it's just been released a few days ago

So having said that ... I think I'd like to really recommend you to wait until the next version of Prism, which I'm guessing will be later this week.

The overall point about plugin writing though, is that all the features that you need to write your plugin must already be there in Prism. So you'd only have to write plugin code inside your own plugin php file(s). No need to touch the Prism core files.

However, we're still early in development and plugin functionality at the moment is minimal at best. We're laying the foundation for the plugins at the moment and that should be done in v0.3.0. After that release we'll start to add all the functionalities that plugins need to function properly.

Oh and we'll have to write some documentation as well, to inform people of the functionalities that can be made use of, and how. I'm pretty sure by that time things will become a lot more clear for everyone.

EDIT - for fun, have a look at this : http://github.com/Dygear/PRISM/compare/master...current
Click the Files Changed (30) tab to see all the changes made since v0.2.0 - it's massive

Okay, thanks Victor.

I never planned on putting any code into the core, was just tinkering and playing around with some ideas until 0.3.0 was released

I shall wait patiently

Quote from Victor :

Ok first of all, as a plugin programmer you will never have to add code to any of the core Prism files. If there is a feature missing from the Prism core, please ask for it here.

Quote from Victor :

The overall point about plugin writing though, is that all the features that you need to write your plugin must already be there in Prism. So you'd only have to write plugin code inside your own plugin php file(s). No need to touch the Prism core files.

Yeah, and I would like to add my voice to this as well. If you ever feel like you can't do something within PRISM without editing the core, then I have failed. Plugins are pretty powerful within the PRISM architecture and are pretty much the life blood of the system outside of the PRISMs internal connection maintenance with InSim or the browsers.

Quote from Victor :

Or you can write it yourself, but as said before, development is going really fast at the moment so you'd have to make sure you're not working in a too old version. And by now, v0.2.0 is kinda old already, even if it's just been released a few days ago

Victor right there having a aptitude for the understatement right there. For those who have not looked at github, PRISM from 0.2.0 to 0.3.0 has been redesigned pretty much from the ground up by Victor himself. In fact, this week Victor over took me in changes to the code, so he has been doing most of the leg work for the past few days.

Quote from Victor :

So having said that ... I think I'd like to really recommend you to wait until the next version of Prism, which I'm guessing will be later this week.

Should be by Friday, if all goes well and I get some sleep between now and there.

Quote from Victor :

However, we're still early in development and plugin functionality at the moment is minimal at best. We're laying the foundation for the plugins at the moment and that should be done in v0.3.0. After that release we'll start to add all the functionalities that plugins need to function properly.

Not so much done, as providing basic functionality to where you can do everything that PRISM offers with plugins on the most basic level. There will be no high level abstraction, just the bare basics of the plugin system and packet level interface.

Quote from Victor :

Oh and we'll have to write some documentation as well, to inform people of the functionalities that can be made use of, and how. I'm pretty sure by that time things will become a lot more clear for everyone.

I think this will take up most of the time, and I'm usually better in a question answer format so I'll try and work on something like that for the users and post it on here.

Quote from Victor :

EDIT - for fun, have a look at this : http://github.com/Dygear/PRISM/compare/master...current
Click the Files Changed (30) tab to see all the changes made since v0.2.0 - it's massive

Wow, I've never seen that page before. Very cool. Insane to think how far we have come in such a short time. Considering we are 3 weeks into the project, how far we have come has far exceeded what I expected.

Quote from Dygear :

You and me both. I'm not sure how to handle the IS_REO packet. I don't know very much about it but I will do my best to learn about it and see if I can't come up with a good solution for you and everyone else.

I already had done this.

Make sure to catch the changes to pack() and parsePackFormat() and to some other packets... :O

=>

Quote from GeForz :

I already had done this.

Make sure to catch the changes to pack() and parsePackFormat() and to some other packets... :O

=>


<?php 
$pck = new IS_REO();
$pck->NumP = 5;
$pck->PLID = array(1,2,3,4,5);
?>



Ok. I'll look over that again to make sure that version is good. But not right now, I have to get some sleep.

For everyone, my current branch has a stable pre-alpha of 0.3.0 if anyone wants to take a look. Everything works except for the STDIN commands that I have to edit back over. As they are becoming apart of the plugin interface. However everything else is there.

I would so dive into this - developing - if it wasn't on GitHub =(


However - When my 'Natsume' is done - I woul consider creating an addon wrapper to allow this to be integrated into the page or blogging features?


Its an idea now - -- nothing more so far =/