PRISM's Birthday (Aug 22nd, 2010)
PRISM's birthday is in about a month (1 month, 11 days) from now. Anyone want to do anything at all for this event? Small server party, maybe a feature showcase of what can be done with PRISM?
I've been meaning to get to work on some of the Dirt2 style game play modes that I liked when I was playing that. Things like owning a sector time, and stuff like that. So I hope to get that done before PRIMS's birthday so I can show that off to you all. The other 'killer app' plugin that I have planned is FOM overlays. Where it shows stats about who is in what place on screen with buttons. That another one that I hope to have finished before PRISM's birthday. I feel they are both obtainable goals.
So, does anyone else wish to 'show case' a plugin for PRISM's birthday?
I've been meaning to get to work on some of the Dirt2 style game play modes that I liked when I was playing that. Things like owning a sector time, and stuff like that. So I hope to get that done before PRIMS's birthday so I can show that off to you all. The other 'killer app' plugin that I have planned is FOM overlays. Where it shows stats about who is in what place on screen with buttons. That another one that I hope to have finished before PRISM's birthday. I feel they are both obtainable goals.
So, does anyone else wish to 'show case' a plugin for PRISM's birthday?
With any luck, this will only add about 100 lines of code to PRISM to keep it nice and simple. I just hope this is not too confusing for new programmers to deal with.
Making TINY & SMALL Sub Type's Directly Bindable from the registerPacket method.
As I have said, I'm making TINY & SMALL sub types bind-able directly from the registerPacket method. But this requires me to do something strange because the TINY_* & SMALL_* namespace is already taken by the numeric defines. So I was thinking of making a TINY and SMALL object, and for the sake of consistancey making an ISP object as well. So instead of doing this ...
We could do this ...
This way it leaves the current name spaces in tact for their intended targets, and we can directly bind to these packet subtypes without having to worry about getting a TINY or SMALL that we did not want.
How I plan on doing this is also simple. Where ISP are the whole packet, TINY and SMALL have subtypes and as such could be looked at as fractions of the whole picture. So we define them as such fractions ... In terms a floating point numbers.
So when the registerPacket function sees a float, it knows that we are talking about the subtype of a particular packet. Thus that function will only get that registered subtype of that packet, not every TINY or every SMALL.
---
My question to you guys is, do you think you would use it?
$this->registerPacket('onVoteStatus', ISP_VTN, ISP_TINY, ISP_SMALL);
// And then checking the SubT for the TINY & SMALL,
// packet to make sure it's the type we want.We could do this ...
$this->registerPacket('onVoteStatus', ISP::VTN, TINY::VTC, SMALL::VTA);This way it leaves the current name spaces in tact for their intended targets, and we can directly bind to these packet subtypes without having to worry about getting a TINY or SMALL that we did not want.
How I plan on doing this is also simple. Where ISP are the whole packet, TINY and SMALL have subtypes and as such could be looked at as fractions of the whole picture. So we define them as such fractions ... In terms a floating point numbers.
class ISP {
const NONE = 0;
const ISI = 1;
const VER = 2;
const TINY = 3;
const SMALL = 4;
// ect.
};
class TINY {
const NONE = 3.0;
const VER = 3.1;
const CLOSE = 3.2;
const PING = 3.3;
const REPLY = 3.4;
// ect.
};
class SMALL {
const NONE = 4.0;
const SSP = 4.1;
const SSG = 4.2;
const VTA = 4.3;
const TMS = 4.4;
// ect.
};So when the registerPacket function sees a float, it knows that we are talking about the subtype of a particular packet. Thus that function will only get that registered subtype of that packet, not every TINY or every SMALL.
---
My question to you guys is, do you think you would use it?
Last edited by Dygear, .
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.
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.
Last edited by Dygear, .
What kind of bullshit was that? "Maintain the gap" is just as bad as "Is faster then you." **** that shit.
Gutted! Feel so bad for JB.
You both beat me to it by like 7 minutes. Nice, should be a good Ep then, along with the McLaren MC-Hammer 
.
.Unless you give me a source, I'm just going to assume that you made it up.
[edit]Never mind, I did the research for you ...
http://www.topgear.com/uk/phot ... ttel-2011-07-07?imageNo=0
Source: Final Gear Forums.
Last edited by Dygear, .
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.
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.
insim:// Web-based Protocol Handler
On the subject of JavaScript as a InSim parser, I also found that you can make a web-protocol handler. Submitting a JavaScript InSim client to the Chrome store or to Mozilla's store could be quite interesting. If we also register a protocol handler, it would be quite easy for someone to see what is going on in a game at any given time from any web browser.
Are you talking to me / victor or to the plugin developers?
Yeah, just send them my way, I'll take a look.
That's funny you should say that, because I was thinking that if I made a php like pack, unpack function for JavaScript that I would be able to do this quite easily. Now that it's right in front of me, it's kinda hard to say no to this.
Any notes would be appreciated.
This is why I release all of my stuff under the MIT license.
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.
Before we get to 0.5.0 I want to have support for WebSockets and include a MetaSim plugin.
Last edited by Dygear, .
Yeah, but it might be interesting for like a web client ... Even if the max concurrent is 8, it still would be pretty cool to see. I don't really see there being more then 8 admins on a server at a time anyway.
Consider this C structure:
You can access a buffer containing data in this format like this:
In the case of say, the ISP_TINY packet, that looks like this:
struct someStruct {
unsigned long id;
char username[16];
float amountDue;
};You can access a buffer containing data in this format like this:
var buffer = new ArrayBuffer(24);
// ... read the data into the buffer ...
var idView = new Uint32Array(buffer, 0, 1);
var usernameView = new Uint8Array(buffer, 4, 16);
var amountDueView = new Float32Array(buffer, 20, 1);In the case of say, the ISP_TINY packet, that looks like this:
struct ISP_TINY {
byte Size = 4;
byte Type = ISP_TINY;
byte SubT = NULL;
byte ReqI = NULL;
};var Packet = new ArrayBuffer(256);
var Size = new UInt8Array(Packet, 0, 1);
var Type = new UInt8Array(Packet, 1, 1);
var SubT = new UInt8Array(Packet, 2, 1);
var ReqI = new UInt8Array(Packet, 3, 1);A pure JavaScript InSim Application?
It seems that this is now possible with the new WebSockets API object, and use of JavaScript Typed Arrays. We should be able to send Binary over the wire to say ... Connect to InSim. I'm interested to see where this could go, it could offer a live view of any game that can't be matched by any server side option.
Last edited by Dygear, .
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.
Last edited by Dygear, .
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.
Yeah, I need to refractor that slightly also.
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.
<?php
public function getUsers() {
global $users;
$users->query('SELECT * FROM `users`;');
}
?>
Yeah, I need to refractor that slightly also.
Last edited by Dygear, .
:fence:, you win this round, but there will be others!
<?php
function isFileType(fileName, fileType) {
return (fileName.split('.').pop() == fileType);
}
?>
As you said, PHP, I'll also chime in with ...
PHP 5 also has built in support for SQLite, and can also be used very simply with the functions available to you.
PHP 5 also has built in support for SQLite, and can also be used very simply with the functions available to you.
<?php
function isFileType(fileName, fileType) {
return (fileName.substr(fileName.lastIndexOf('.')) == fileType);
}
function isSetupFile(fileName) {
return isFileType(fileName, '.set');
}
echo ((isSetupFile(file)) ? 'Is' : 'Not') + ' a setup file.';
?>
I'm sure this will be helpful to someone, thanks!
FGED GREDG RDFGDR GSFDG