Perhaps we should move the GUI folder under the data directory, or config? It just hanging out there by it's self is freaking me out a little bit on the inside.
We also need a lang directory that should probably data directory, or config. Thoughts?
We also need a lang directory that should probably data directory, or config. Thoughts?
I don't disagree with you, regarding the best tool for the job.
I find that PHP is severely lacking in the WebSockets space and we can fill that void with something that doesn't suck.
I find that PHP is severely lacking in the WebSockets space and we can fill that void with something that doesn't suck.
I was thinking some thing along those lines, but I really don't have any idea where to start. To quote Steve Jobs, "Everything out there right now is shit." at least in PHP land. The require some odd choice to get Ratchet PHP to work and I really don't want that.
Anyway, I want to re-factor the PRISM code base so we can get too a point where it can be used with any protocol not just LFS connections from InSim, but also HTTP connections (already supported, thanks Vic), and Telnet connections (already supported, thanks Vic). I want to add WebSockets too that stack, and have all of these programs communicate through the PRISM.
Basically, the PSR-0 patch from T3 and Co would become the base for it, and we'd move all of the LFS / InSim stuff into the $PRISM/modules/lfs/ folder, and all of the HTTP, Telnet stuff into $PRISM/modules/HTTP & $PRISM/modules/Telnet. The last part would be the $PRISM/modules/WebSockets, that _might_ require the HTTP module to work, as it's an upgrade request.
From here plugins would be allowed to communicate on any protocol there was a module for. So you could have a plugin that would use the WebSocket connections and the LFS connection modules.
I honestly, don't even know where to start with that one. Because, I should really allow for multiple WebSocket connections. But I guess, that would be handled like multiple InSim connections, where it's agnostic too the plugin, and is a configuration setting.
Anyway, I want to re-factor the PRISM code base so we can get too a point where it can be used with any protocol not just LFS connections from InSim, but also HTTP connections (already supported, thanks Vic), and Telnet connections (already supported, thanks Vic). I want to add WebSockets too that stack, and have all of these programs communicate through the PRISM.
Basically, the PSR-0 patch from T3 and Co would become the base for it, and we'd move all of the LFS / InSim stuff into the $PRISM/modules/lfs/ folder, and all of the HTTP, Telnet stuff into $PRISM/modules/HTTP & $PRISM/modules/Telnet. The last part would be the $PRISM/modules/WebSockets, that _might_ require the HTTP module to work, as it's an upgrade request.
From here plugins would be allowed to communicate on any protocol there was a module for. So you could have a plugin that would use the WebSocket connections and the LFS connection modules.
Note: Importing rules are per file basis, meaning included files will NOT inherit the parent file's importing rules.
<?php
use modules\lfs\insim;
use modules\websockets;
class Multiplexing
{
const URL = 'http://lfsforum.net/forumdisplay.php?f=312';
const NAME = 'Multiplexing Example';
const AUTHOR = 'PRISM Dev Team';
const VERSION = PHPInSimMod::VERSION;
const DESCRIPTION = 'WebSockets and LFS InSim Connections Multiplexing';
public function __construct()
{
$this->registerPacket('onNewPlayer', ISP::NPL);
$this->registerPacket('onPlayerLeave', ISP::PLL);
}
public function onNewPlayer(ISP_NPL $NPL)
{
$this->webSocket(json_encode($NPL));
}
public function onPlayerLeave(ISP_PLL $PLL)
{
$this->webSocket(json_encode($PLL));
}
}
?>
That's gonna be a bitch. Put simply, there are 6 different ways to read that struct now based off the Index . Meaning the the UNPACK and PACK functions have to change slightly for it.
Where is AXO_CONCRETE_SLAB, ect defined? I'm not seeing them in my InSim.txt file for 0.6G18.
<?php
private function concrete_parse($index, $bits)
{
switch($index)
{
case AXO_CONCRETE_SLAB:
$name = 'Width/Length/Pitch';
break;
case AXO_CONCRETE_RAMP:
$name = 'Width/Length/Height';
break;
case AXO_CONCRETE_WALL:
$name = 'Color/Length/Height';
break;
case AXO_CONCRETE_PILLAR:
$name = 'SizeX/SizeY/Pitch';
break;
case AXO_CONCRETE_SLAB_WALL:
$name = 'Colour/Length/Pitch';
break;
case AXO_CONCRETE_RAMP_WALL:
$name = 'Colour/Length/Height';
break;
default:
// No idea why we would get here.
break;
}
foreach (explode('/', $name) as $name)
$packet[$name] = self::concret_bits($name, $bits);
}
private function concrete_bits($name, $bits)
{
switch ($name)
{ // Some of these will not return the correct value yet.
case 'Width':
return $bits & 0x03 >> 0; # 2, 4, 8, 16
case 'Length':
return $bits & 0x0c >> 2; # 2, 4, 8, 16
case 'SizeX':
return $bits & 0x03 >> 0; # 0.25, 0.5, 0.75, 1
case 'SizeY':
return $bits & 0x0c >> 2; # 0.25, 0.5, 0.75, 1
case 'Height':
return $bits & 0xf0 >> 4; # 0.25 to 4 in steps of 0.25
case 'Pitch':
return $bits & 0xf0 >> 4; # 0 to 90 in steps of 6 degrees
case 'Colour':
return $bits & 0x03 >> 0; # grey / red / blue / yellow
}
}
?>
I think I would stick it in with the onClientPacket. It adds too that information about the client, so for me that seems like the most apporiate area for it.
Don't forget to add NCI's definition too the ClientHandler class, as it falls in to that area as well.
WebSocket Support [RFC 6455]
I'd like to add WebSocket support as a module too PRISM.
The idea being that PRISM would be a WebSocket server and it's connections would be handled by the plugins as if they where packets from InSim. You'd do this by registering an endpoint, you can then give that end point to any plugin that wants to take part in that communication or sub-protocol. From there, parsing the packet down, it can be given too the plugin already part procssed by a module or raw as the prism_packets module would get an InSim packet.
These are some rough ideas, and I want to know what you guys would think would make this a robust but easy solution to use. I'd also love to take a peek at Victor's implementation for LFSWorld so I have some idea what I'm talking about.
The idea being that PRISM would be a WebSocket server and it's connections would be handled by the plugins as if they where packets from InSim. You'd do this by registering an endpoint, you can then give that end point to any plugin that wants to take part in that communication or sub-protocol. From there, parsing the packet down, it can be given too the plugin already part procssed by a module or raw as the prism_packets module would get an InSim packet.
These are some rough ideas, and I want to know what you guys would think would make this a robust but easy solution to use. I'd also love to take a peek at Victor's implementation for LFSWorld so I have some idea what I'm talking about.
[Feature Request] OAuth
Please let us use our LFS accounts elsewhere on other forms, or to confirm our identity with the authoritative servers here at lfs.net.
(It would be massive for PRISM and everywhere else too!)
(It would be massive for PRISM and everywhere else too!)
[Mod Tools] [Feature Request] Merge Posts
I'd like the open to merge multiple posts into one, so long as the posts are from the same author. You should be able to check muliple posts from the same person, and in the drop down for the dev tools, merge them, in much the same way that one could delete.
Post your hosts.ini file, or send it too me via PM. The part here Invalid socket type set for 127.0.0.1:29999 is your issue. PRISM should of gracefully shut down when it had no hosts to connect too because they were all invalid. The error is a bug, and one that we should handle, but the error started from an malformed hosts.ini file, or a miss-configured one.
The error starts here in PRISM's core and is not handled outside of that functions scope when there is no hosts too connect too.
Last edited by Dygear, .
LMAO, there is an epicly small bug in 0.4.6.0. When you start the welcome plugin it fails to start the server because there is no ; at the end of line 33. Quick fix has been posted too github. No need for a dot release for something as simple as that.
You can do that with delta. You define the group as starting at 0, 0 and built the .ini file to match that, then from there, you can move the cluster around the screen by moving the starting point simply by adding to each buttons Top and Left values. I guess the .ini files should have a default top and left value that should be over ridden when the user needs, or can be set on a per client basis from within PRISM's instance. And if the PRISM server is running across multiple instances then those settings can be remembered on multiple servers.
I think you nailed it from the diff that I could see. When I try to read the whole file as a diff on github the request fails. I think github is still getting DDoSed. But everything looks good right now too me.
Last edited by Dygear, .
Not having that issue myself and I'm rocking a 660 Ti.
Scawen, is there any chance that you can make the draw distance infinite? I'd like to be able to go too Shift+U mode and see every car on track. I've attached the screen shot below that blew my mind ... (I took the screen shot at UHD res, and it's insane.)
I'm hoping that Vic will pickup the WebSockets module for 0.5.0. *Hint, Hint, Nudge, Nudge*
I'll look over the changes tonight when I get home.
I'll look over the changes tonight when I get home.
You're my hero. Nice job man!
have you learned nothing from the past years!
Holy shit!
Vic, any chance of adding WebSocket support as a module to PRISM and making it available too the Plugins in the same way we offer the InSim Packets?
I'll keep the pitch forks handy, UNLESS you want to take a stab at adding WebSockets support to PRISM.
I understand that you have a solution that's awesome that you use here on this site.You are never going to get help if you're going to be a dick.
2015 FOM F1 Overlays & Website
Looking at the qualifying session for F1 this year, and it looks like the F1 overlays should be quite easy to recreate 1 for 1 in LFS using the InSim button system we already have. The F1 website has also done a pretty good job of making this information accessible in a HTML5 format, making it much more accessible then their previous Java effort.
Now that we are waiting for an incompatible patch, is there any chance we can get some InSim Changes implemented?
[RFC] InSim Language Information
[RFC] Insim - variable size IS_MSO
[RFC] Make IS_PLC Two Way
[RFC] IP Address Information In InSim
[RFC] InSim Language Information
[RFC] Insim - variable size IS_MSO
[RFC] Make IS_PLC Two Way
[RFC] IP Address Information In InSim
Error's happen, in transit, on disk, or in memory. Looks like it was one of the other two this time.
Odd bug that I can't reproduce. I choose SO6X, on the BF1 and start my lap. I get a false start of 30 seconds and do a whole lap with that (never going below 100FPS BTW, So nice work there). I get to the end of the lap and Ctrl + S, spectate. I then do not have my skin (The default BF1 skin of the BMW Sauber race car) is no longer there. I load back into the race, inside the cockpit I see the inside of the skin, outside of the cockpit, I change view to the race TV camera, and I don't have a skin it's just white. I Ctrl + S again, and the skin is back.
Tried to reproduce this, and I can't. Might of been a fluke.
Tried to reproduce this, and I can't. Might of been a fluke.
I have no idea, try it out and let us know! I would think it's in an alpha state, I seem to recall a conversation with DarkTimes about it from _quite_ a while ago.
FGED GREDG RDFGDR GSFDG