I strongly recommend that you backup your current version of prism, before upgrading to this version!
Please let me know of any bugs you should find, as I'm sure that they are going to be a few with the statehandler, and I know of one already with the LVS plugin, but it's more to do with the pth parser. Anyway, thank you for your continued support!
Please let me know of any bugs you should find, as I'm sure that they are going to be a few with the statehandler, and I know of one already with the LVS plugin, but it's more to do with the pth parser. Anyway, thank you for your continued support!
PHPInSimMod - PRISM 0.4.3 Discussion
You can download PHPInSimMod - PRISM 0.4.3 from that link. Please use this thread to talk about this release.
Thank you.
PHPInSimMod (PRISM) 0.4.3
Thank you.
PHPInSimMod (PRISM) 0.4.3
- Updated to Version 0.4.3.
Updates to support PHP 5.4.0.- Fixed parse error when used with PHP 5.4 RC1.
- Fixed fatal error when used with PHP 5.4 RC1.
- Fixed STRICT warning when calling the interactive query method in a static context on PHP 5.4.0.
- Massive update to state handler, the classes are now much better devided into their roles, lots of redundant code removed, still need to check TOC packet, and for 5.3.x compatability.
- Added some functions to the Client & Player Hanlder.
- ISP_TOC handling done.
- Added the Data Directory, that includes the PTH files used for the LVS plugin, and by the PTH module.
- Moved the inPoly method into the pth parser, and added some new methods to use that can be found in the LVS example plugin.
- Completly rewrote the PTH parer (twice).
- Fixed PTH parser, was using l, but needed V because some numbers where too large.
- Fixed small errors in the pth parser.
- Completly rewrote the SMX parer.
- Fixed SMX parser, was using l, but needed V because some numbers where too large.
- First draft of OutGauge support. Has config and network facilities and parses packet. Needs a method to actually do something with it.
- Added OSP & OGP consts, and added their ID's to the TYPEs array.
- Updates the OutSimPack's & OutGuagePack's PACK, UNPACK and added LENGTH and added a special unpack method to both.
- Made OutGuage code cross refrence the information from the OutGuagePack class. That also made the code much more concise.
- Fixed crash on player pitting.
- Made the dedicated or listen server, answer choices make sense.
- Slight Change for T3, to allow for plugin defined parameters to be received by the onClick handler.
- Changed the string type for the Plate's from a NULL Padded (a) string to a SPACE Padded string (A), in response to a bug report 29 by PoVo. This effects, CPR, NPL and RES packets.
- Fixes issue 26, reported by PoVo, where a client presses Shift + I PRISM would crash.
- PoVo confirmed fix for the button interface, un-commented ButtonManager::buttonsForHost();
- Fixed bug when pitting due to the handling of the Tyres.
- Added some questions to the interactive start for the hosts, so we can find out what flags to set. I've also added default ports to both HTTP and Telnet.
- Fixed bug where no plugins are loaded when PRISM_DEBUG_CORE is not set.
- Fixed duplicate port-check.
- Fixed data types for ints in the packests, where their signed long machine byte order variant, now they all are unsigned long little endian byte order as they should be.
- Fixed PACK/UNPACK in IS_RST
- Fixed PACK string of IS_MTC, so that sound does work.
- Fixed a capital K in parent::unpack in the IS_HLV class.
- Fixed missing semi-colon after class for IS_TINY.
- Added iTunes control plugin (Works only on Windows)
- Added Timing & Scoring plugin.
- Removed some testing plugins that are no longer needed. (AutoX, Button Test, Color Buttons, Contact, Distance, Gap Monitor & GapMon, and Pylons.
- Fixed a bug with the PLL, CNL & CPR packets going to the state handler first, removing inforemoving information from the plugin's scope before they have had a chance to use it.
- Added IS_CPR (Client Player Rename) to list of packets that are sent to the plugin before they are handled by the State Handler.
- Fixed parse error when used with PHP 5.4 RC1.
Last edited by Dygear, .
PHPInSimMod (PRISM) 0.4.3
PHPInSimMod (PRISM) 0.4.3
- Updated to Version 0.4.3.
Updates to support PHP 5.4.0.- Fixed parse error when used with PHP 5.4 RC1.
- Fixed fatal error when used with PHP 5.4 RC1.
- Fixed STRICT warning when calling the interactive query method in a static context on PHP 5.4.0.
- Massive update to state handler, the classes are now much better devided into their roles, lots of redundant code removed, still need to check TOC packet, and for 5.3.x compatability.
- Added some functions to the Client & Player Hanlder.
- ISP_TOC handling done.
- Added the Data Directory, that includes the PTH files used for the LVS plugin, and by the PTH module.
- Moved the inPoly method into the pth parser, and added some new methods to use that can be found in the LVS example plugin.
- Completly rewrote the PTH parer (twice).
- Fixed PTH parser, was using l, but needed V because some numbers where too large.
- Fixed small errors in the pth parser.
- Completly rewrote the SMX parer.
- Fixed SMX parser, was using l, but needed V because some numbers where too large.
- First draft of OutGauge support. Has config and network facilities and parses packet. Needs a method to actually do something with it.
- Added OSP & OGP consts, and added their ID's to the TYPEs array.
- Updates the OutSimPack's & OutGuagePack's PACK, UNPACK and added LENGTH and added a special unpack method to both.
- Made OutGuage code cross refrence the information from the OutGuagePack class. That also made the code much more concise.
- Fixed crash on player pitting.
- Made the dedicated or listen server, answer choices make sense.
- Slight Change for T3, to allow for plugin defined parameters to be received by the onClick handler.
- Changed the string type for the Plate's from a NULL Padded (a) string to a SPACE Padded string (A), in response to a bug report 29 by PoVo. This effects, CPR, NPL and RES packets.
- Fixes issue 26, reported by PoVo, where a client presses Shift + I PRISM would crash.
- PoVo confirmed fix for the button interface, un-commented ButtonManager::buttonsForHost();
- Fixed bug when pitting due to the handling of the Tyres.
- Added some questions to the interactive start for the hosts, so we can find out what flags to set. I've also added default ports to both HTTP and Telnet.
- Fixed bug where no plugins are loaded when PRISM_DEBUG_CORE is not set.
- Fixed duplicate port-check.
- Fixed data types for ints in the packests, where their signed long machine byte order variant, now they all are unsigned long little endian byte order as they should be.
- Fixed PACK/UNPACK in IS_RST
- Fixed PACK string of IS_MTC, so that sound does work.
- Fixed a capital K in parent::unpack in the IS_HLV class.
- Fixed missing semi-colon after class for IS_TINY.
- Added iTunes control plugin (Works only on Windows)
- Added Timing & Scoring plugin.
- Removed some testing plugins that are no longer needed. (AutoX, Button Test, Color Buttons, Contact, Distance, Gap Monitor & GapMon, and Pylons.
- Fixed a bug with the PLL, CNL & CPR packets going to the state handler first, removing inforemoving information from the plugin's scope before they have had a chance to use it.
- Added IS_CPR (Client Player Rename) to list of packets that are sent to the plugin before they are handled by the State Handler.
- Fixed parse error when used with PHP 5.4 RC1.
Last edited by Dygear, .
From pth.txt found on the lfs website.
From the CompCar struct found in the InSim.txt, found in LFS 0.6B.
So they are directly compatible from a datatype stand point. No conversion needed on our end. What you get from the packet should be, there for directly compatible with what you get from the pth file.
Don't worry, I'm working on the LVS plugin right now.
1) X,Y,Z int : 32-bit fixed point world coordinates (1 metre = 65536)
X and Y are ground coordinates, Z is up.From the CompCar struct found in the InSim.txt, found in LFS 0.6B.
int X; // X map (65536 = 1 metre)
int Y; // Y map (65536 = 1 metre)
int Z; // Z alt (65536 = 1 metre)
So they are directly compatible from a datatype stand point. No conversion needed on our end. What you get from the packet should be, there for directly compatible with what you get from the pth file.
Don't worry, I'm working on the LVS plugin right now.
That's what I'm thinking. PHP 6 pretty much became PHP 5.4, as PHP 6 was all but abandoned in name, mainly due to it's requirement of UTF-16 being used everywhere. So short term we do get some of the cool things that where meant to be in PHP 6, but we just get them in PHP 5.4 instead. This works out quite well for us I think!
Did I mention that the <?= syntax is always available? Regardless of the short tag setting? I like that!
Did I mention that the <?= syntax is always available? Regardless of the short tag setting? I like that!
Last edited by Dygear, .
PHP 5.4.0 is a pretty massive upgrade that will make some thing in PRISM much easier, such as the use of the web interface, that can be pretty much completely taken out and replaced with a native alternative that is much more in line with what other PHP programmers handle on the front end of the web sites every day. Vic did a great job, but it's very confusing to people who are no as adept to PHP as some of the devs are.
That would result in some huge changes to the code base, and the interfaces that you're all given. The trait support would be front and center in the modules, and you'll fell that right away with the plugin class, should use decide to use it. But it also allows for the different paradigms to work as one with the plugins, even all in one if someone so desired. Would you still want to do it, knowing that it would be incompatible with anything you might of already programmed?
It's on the repo, I forgot that you stick to official updates. As far as multiplying by a the size of a small int, I'll get into it.
I've wanted to do a rewrite of PRISMs core for a while now, and this have given me a pretty good reason to do that. The 0.4.3 release will fix some bugs that happen with PHP 5.4.0 that don't happen otherwise, but will works with PHP 5.3.x. This may end up being the last release the supports PHP 5.3.x before we move on to PRISM 0.5.x that will only support PHP 5.4.0 and greater. If you have any questions, comments or concerns, please do voice them now. I would love to hear what the community thinks.
Copy the PTH files from your LFS directory into the pth files that PRISM has. If they are not the same file you're going to have this problem.
vB Setting 'Prevent Shouting'
Admincp > vBulletin Options > Message Posting and Editing Options > Prevent 'SHOUTING'
I'm guessing this was just enabled, because, when I try to type like PHP in a title, it turns int Php. When I write PRISM it turns into Prism.
Kind of annoying, can we turn it back to 0 please?
I'm guessing this was just enabled, because, when I try to type like PHP in a title, it turns int Php. When I write PRISM it turns into Prism.
Kind of annoying, can we turn it back to 0 please?
Prism & php 5.4.0
There are a few things to keep in mind if your planning on running PRISM with PHP 5.4.0, you can find where the list of incompatible changes they have made from 5.3.x to 5.4.x. But there are also some new features that should be keep in mind as things that might not be supported by all platforms as right now PRISM only requires 5.3.0 and above. There are currently no plans to require a change to 5.4.0, however should you have custom plugins that you alone are going to use, it is safe to use these new features. I also have not tired to run PRISM with 5.4.0 yet, but I don't see anything that would be a show stopper.
I do think that the web server built into 5.4.0 is pretty cool, so I'll for sure take a look at that.
[EDIT1]
PHP 5.4.0 Traits
This is why I would LOVE to make PHP 5.4.0 a requirement for the next versions of PRISM. This would make my modules work together so much better. Currently, the Plugins module is a bastard child of many different classes that it extends from. With this, we can just have a clean defined class, and it can use the traits of the timer and button traits without having to worry about having to extend those classes into it.
[EDIT2]
Ok, after just trying PRISM with 5.4.0, we do have some issues, but they are pretty small. We get an E_STRICT warning with trying to call a Interactive::Query method in a static context, as of 5.4.0 that's a no no, we'll have to fix that. That's the only thing I've seen so far, but I'm still going through the setup from scratch, so we'll see.
I do think that the web server built into 5.4.0 is pretty cool, so I'll for sure take a look at that.
[EDIT1]
PHP 5.4.0 Traits
This is why I would LOVE to make PHP 5.4.0 a requirement for the next versions of PRISM. This would make my modules work together so much better. Currently, the Plugins module is a bastard child of many different classes that it extends from. With this, we can just have a clean defined class, and it can use the traits of the timer and button traits without having to worry about having to extend those classes into it.
[EDIT2]
Ok, after just trying PRISM with 5.4.0, we do have some issues, but they are pretty small. We get an E_STRICT warning with trying to call a Interactive::Query method in a static context, as of 5.4.0 that's a no no, we'll have to fix that. That's the only thing I've seen so far, but I'm still going through the setup from scratch, so we'll see.
Last edited by Dygear, .
Sorry, I'll fix that when I get home.
What do you mean by that? Do you mean only the first MCI packets information is given, or do you mean that the packet's Info only has one member, and that's the only thing that your getting?
First off, you might only get one Info item in that array because that is the last packet of the set to be sent, or there is only one client on the server. Secondly, the MCI function you defined will be fired one time for each packet in an MCI set, some times there is only 1 packet if there is less then 1 client.
As a US Citizen, I have no direct problem with anything he is saying. Being exposed to more then one point of view is not a disadvantage.
How about ...
PRISM/modules/prism_button.php L39-L59
Let me know if that works out better for you.
If after you update this breaks anything let me know, because I'll have to change it on the commit too.
PRISM/modules/prism_button.php L39-L59
<?php
public function registerOnClick(Plugins $plugin, $methodName, $params = NULL)
{
$this->onClick = array($plugin, $methodName, $params);
$this->BStyle |= ISB_CLICK;
}
public function click(IS_BTC $BTC)
{
if (!is_array($this->onClick))
return;
switch (count($this->onClick))
{
case 3:
call_user_func_array(array($this->onClick[0], $this->onClick[1]), $this->onClick[2]);
break;
case 2:
default:
call_user_func($this->onClick, $BTC, $this);
break;
}
}
?>
<?php
$this->registerOnClick($this, 'ChaseClient', array($UName, $CliUName));
?>
Last edited by Dygear, .
Really? Why? Why are you handling NCN packets anyway?
Wide Area Network Emulator, for testing packet quirkiness.
WANEM: The Wide Area Network Emulator. WANem allows the application development team to setup a transparent application gateway which can be used to simulate WAN characteristics like Network delay, Packet loss, Packet corruption, Disconnections, Packet re-ordering, Jitter, etc.
I've just found this project today, about 10 minutes ago, and was thinking that this could be useful for other InSim devs out there to check their code against to see how robust their network code is within a lab environment that can simulate the quirky WAN characteristics can may only be found on the fringe.
I've just found this project today, about 10 minutes ago, and was thinking that this could be useful for other InSim devs out there to check their code against to see how robust their network code is within a lab environment that can simulate the quirky WAN characteristics can may only be found on the fringe.
It's really best if you leave PRISM's core alone, everything is programmed in a way for a reason, even the error handler. It's very hard for me to support code that I can't see, and even more so when your reporting bugs in code that is no longer mine because of the modifications that you've made.
As for the Indirect modification error, that's because of somewhere in your code you have modified UName some how. Check your plugins, and I'll need the whole error message next time so I can tell you where it's coming from, hopefully.
Yeah, that's a known bug. Not really sure how I am going to fix that yet. I ask for the connections in the case of PRISM starting while there is already a session in progress and I don't have their information yet. The request is needed so that I can populate their information within the state module. I'll probably check to see if there is a session in progress before I request an NCN packet.
Last edited by Dygear, .
No, although it has been asked for many times.
Oh here we go again. This is why Open Sourcing your code makes sure you get the kudos.
Did you modify PRISM's error handler?
When do you get this error?
When do you get this error?
Just to be sure, we should really make that recursive, but really good catch. I was pretty sure that I used microsecends, so even if you added two timers, it should of given you a unique value for each of them.
Anyway, the fix should look something like this, just added a recursive call to create timer, and the simple recursive call should offset it enough not to bounce into another timer.
<?php
// Registers a callback method.
protected function createTimer($callback, $interval = 1.0, $flags = Timer::CLOSE, $args = array())
{
# This will be the time when this timer is to trigger
$mtime = microtime(TRUE);
$timestamp = $mtime + $interval;
# Check to make sure that another timer with same timestamp doesn't exist
if (isset($this->timers["$timestamp"]))
{
$this->createTimer($callback, $interval, $flags, $args)
}
# Adds our timer to the array.
$this->timers["$timestamp"] = new Timer($this, $callback, $interval, $flags, $args);
}
?>
Like you have shown, there is a time where two or more timers want to execute at the same time, and for that we need a real solution. I think having the current timestamp keyed array is a good solution, but also it's value should be allowed to be an array as well. So if there is a collision with time stamps, then the other timer is simply added to it's array. Something like this is the real solution.
<?php
// Registers a callback method.
protected function createTimer($callback, $interval = 1.0, $flags = Timer::CLOSE, $args = array())
{
# This will be the time when this timer is to trigger
$timestamp = microtime(TRUE) + $interval;
# Adds our timer to the array.
$this->timers["$timestamp"][] = new Timer($this, $callback, $interval, $flags, $args);
}
?>
I pretty much only watch the Superbowls, or some of the local team games if it's on and I have nothing else to do. Other wise, I'm programming or working. I did enjoy the game last night, the team where I live won, so I'm pretty happy and I do get quite into it. Just like I got into watching real football when I lived in England ...
What about just shipping the PTH files with the application? Would that not just solve your second problem out right? Or is it that you want an always available fall back mechanism, should a third part connect to a server they don't own? Like how your using XI4N on the cargame server.
So, going with the calculation of 32 clients on the server and getting closing speed of all of them even just 1 time a second is not really feasible. So that's out of the question. (For those wondering, it's like 26313083700000000000000000000000000 calculations to get the information for every player vs every other player.) I think that, using each MCI cords, finding the number of client's within a 25 meter radius of each player and prioritizing by the group the has the most amount of players in each area. Then from there, you only have to find the closing distances of the players within these radius giving you the a much less to calculate. However, if you find that there is more then say 10 clients in a single 25 meter radius of a single client, then you should just look at that group. Closing distances are not really needed, and would become problematic to calculate. But making that a 'threshold' variable might be a good idea so that you can play with it while you develop it. Doing the same for the radius search would be good too.
So, going with the calculation of 32 clients on the server and getting closing speed of all of them even just 1 time a second is not really feasible. So that's out of the question. (For those wondering, it's like 26313083700000000000000000000000000 calculations to get the information for every player vs every other player.) I think that, using each MCI cords, finding the number of client's within a 25 meter radius of each player and prioritizing by the group the has the most amount of players in each area. Then from there, you only have to find the closing distances of the players within these radius giving you the a much less to calculate. However, if you find that there is more then say 10 clients in a single 25 meter radius of a single client, then you should just look at that group. Closing distances are not really needed, and would become problematic to calculate. But making that a 'threshold' variable might be a good idea so that you can play with it while you develop it. Doing the same for the radius search would be good too.
PRISM can do it with iTunes, but not winamp. If winamp had a COM api, it would of been possible.
It was not. If anything the changes posted where the main points of the update. I don't have anything new but what you can find on the GitHub repo. I've had zero time to do anything with prism since this update, but that's why this is open source. Anyone can take what I've done and continue the work. Thank you for the bug reports, if I get some time, I'll fix to the level you have here and I'll update as needed. I'm pretty sure that I'm not done with the base class for PTH and that's why I've not really done anything with the LVS plugin.
FGED GREDG RDFGDR GSFDG