It does not use PHP 5.5 yet, but you should still get it, it makes the code run faster, and it uses less memory. The next version of PRISM (0.5.0) will use PHP 5.5.
All you need to do is make a logs folder underneath the PRISM folder and that error will go away.
Oh yes, I forgot about the in between states. I gues that means 4 bits then! 1000 for far left, 0100 for mid left, 0000 for center, 0010 for mid right, and 0001 for far right.
I've not dissected the network packs, so I have no idea of how head movements are sent to the client, but as I see it right now, they have 3 states, Left, Right and Center. That's 2 bits at least. If you bump that up to a whole byte (8 bits) you can get 256 different values. If you use that for just X, that's plenty of room for a fairly good amount fluidity. Or you could use 4 bits (upper nibble) for X, and the 4 lower bits (lower nibble) for Y, giving you 8 states that you can kinda tween between. The nibble with tween idea might make more sense given the expected number of packets a second for updates (3 - 6 Packets Per Second).
That would be amazing!
Vettle gets #1, it's automatic. Everyone else get's to pick from 2 - 99.
Can someone post a reply of a packed server, with as many people as possible (I'd like to see a full server, with every car racing that is possible.) So I can run benchmarks against the same data set.
The problem is speed of the algorithm. One car (C), on one track (T), on one node (N) using one point is one calculation, and that's what we offer with the MCI packets, with the official tracks, as we get node information (C * N). When we don't get node information, we have One car, on one track, times by the number of points on the track (C^N). Because now we have to test for each node within the pth file. Now when your talking about multiple cars, and multiple points the problem is compounded again. You have to check every car against every point. This quickly becomes an expensive operation for just one server, yet alone a few that PRISM could be installed on, effectively becoming multiple cars, on multiple tracks, using all of the nodes. It's a question of speed, what the fastest way to get this done without having the node information for each client.
To this end, I'm designing PRISM to be fast first. It's going thorough a whole redesign for PHP 5.5, and that upgrade with the same code base alone is a 20% - 40% speed improvement without any code changes (Cool, free performance.) Using SPL, on top of that it should be 25% faster then native arrays when writing data, and use 40% of the memory size, but there is hardly any difference in iteration speed. So my last hope is implementation of R* Trees. It would be odd if an SQLite query would be faster then native memory because of the underlying C structure, but who knows! It's worth a shot for speed.
To this end, I'm designing PRISM to be fast first. It's going thorough a whole redesign for PHP 5.5, and that upgrade with the same code base alone is a 20% - 40% speed improvement without any code changes (Cool, free performance.) Using SPL, on top of that it should be 25% faster then native arrays when writing data, and use 40% of the memory size, but there is hardly any difference in iteration speed. So my last hope is implementation of R* Trees. It would be odd if an SQLite query would be faster then native memory because of the underlying C structure, but who knows! It's worth a shot for speed.
Lap Verification System (LVS)
Cargame has been poking and prodding me for literally years now over the LVS plugin. The plugin verifies that each player's vehicle is on the track at all times. It currently only supports official tracks, using Node information within the packet. The next step is to enhance it to use custom pth files. To make sure this is as fast as possible, as we are talking potentially about doing this over 250 times a second, I've been looking up some solutions. The slowest solution in theory should be the standard PHP array. Then comes SPL (Standard PHP Library) Fixed Arrays and R* Tree using SQLite databases. These two are what I'm going to be testing to see what is faster ... let the battle commence!
So, part of the rewrite that I'm doing for PHP 5.5, is the InSim, HTTP and Telnet interfaces are no longer going to be hard coded into the core of PRISM. I want to be able to implement any type of interface that uses sockets, simply by importing it with a configuration file.
This means a few things, for the core devs. Each interface has to promise to provide a checkTraffic() method and a getSelectableSockets() method. It can also implement a maintenance() method if the interface requires it (InSim Did).
The cool part about doing it this way, is that PRISM becomes quite a bit more general purpose and can be suited to interact with many different types of interfaces quite easily and because of the plugin system attached to it, it can cross pollinate the information from one interface (InSim for Example) with another (WebSockets, Telnet, Ect).
There is another thing, that I wanted to discuss. The deprecation of the HTTP module. I'd like to use the built in PHP server as it should in theory make it easier for people to program for ... if we give them some boilerplate WebSocket interface for them to use. Basically, I wanted to replace the HTTP module with a WebSocket module, and fork anything that we did for HTTP and move that into a separate (but equal) project.
This means a few things, for the core devs. Each interface has to promise to provide a checkTraffic() method and a getSelectableSockets() method. It can also implement a maintenance() method if the interface requires it (InSim Did).
The cool part about doing it this way, is that PRISM becomes quite a bit more general purpose and can be suited to interact with many different types of interfaces quite easily and because of the plugin system attached to it, it can cross pollinate the information from one interface (InSim for Example) with another (WebSockets, Telnet, Ect).
There is another thing, that I wanted to discuss. The deprecation of the HTTP module. I'd like to use the built in PHP server as it should in theory make it easier for people to program for ... if we give them some boilerplate WebSocket interface for them to use. Basically, I wanted to replace the HTTP module with a WebSocket module, and fork anything that we did for HTTP and move that into a separate (but equal) project.
Well, NT was kinda like the hybrid of OS/2 and Win32. In fact, NT was built to be 32bit from the ground up, they kinda just bolted on Win16 just to keep everything running in the background. "Hey look, you can upgrade to this, and still use your old applications! When you want to move forward, the infrastructure will be there to support you." Some of OS/2 and some of NT came from Steve Jobs, because they licensed some tech from NeXTSTEP.
And OS 9 was kinda killed in a day, because when Apple bought out NeXT, they pretty much knew that they where buying it because they wanted a new OS, and they wanted Steve back and this one company had both.
And Intel to PPC happend in the back room over many, many years because Macs have always been compatible with x86, and PPC, and ARM. iOS is OSX distilled and boiled down, and compiled for ARM chips.
Big Corporations are doing that every day, I still still "Patient Care Registration" running DOS emulators! It's INSANE, but that's because they spend money in the wrong areas.
From my understanding of the SMX and PTH files, there are 65536 units in 1 game meter, that's a pretty good level of fidelity already. That is millimeter precision in the game.
Ok but why? If some can see it, then why throw away information?
Quick notice for everyone. There is an change in PHP 5.5 that breaks some string parsing in the packets module. It's an interesting "gotcha" that you should all be aware of. I noticed this problem in the LVS plugin when parsing the AXI packets the LName was filled with white space at the end. For now you'll want to trim() any string you get from the PRISM packet system until a core patch is applied.
The parsing error that you are listing was fixed in the last patch that I applied to PRISM on github. Now if you use that link again it will give you a zip file with all of the patches that I've applied for this thread in it. So to make it easy, click here and download. After you've downloaded that, you can simply extract it to the C:/modas directory and it will replace what it needs and update all of the files.
As far as the startup procedure text, it should be lowercase only.
Your doing a direct connection, if its on your local machine. I don't know if you have a listen server or dedicated server. It's a listen server if you start the host and can play at the same time. It's a dedicated host, if you have to start the client to connect to your host, but one does not depend on the other. It's the same nomenclature of Half-Life servers. And it does not matter, PRISM works on Mac, Linux, Windows ... just answer the questions based on the type of server you are connecting too in the fashion you are connecting to it.
As far as the startup procedure text, it should be lowercase only.
Your doing a direct connection, if its on your local machine. I don't know if you have a listen server or dedicated server. It's a listen server if you start the host and can play at the same time. It's a dedicated host, if you have to start the client to connect to your host, but one does not depend on the other. It's the same nomenclature of Half-Life servers. And it does not matter, PRISM works on Mac, Linux, Windows ... just answer the questions based on the type of server you are connecting too in the fashion you are connecting to it.
Last edited by Dygear, .
Thanks for the update T3, good luck and god speed.
Some say rendering too twice the size and then reducing the image by 50% is the best way to do AA.
One can dream right?
If only, if only. OpenGL seems like a good idea all around at this point. You decouple yourself from Micrsoft's upgrade cycle and you can lunch the game on Linux (SteamOS), Mac OSX, and Windows all at the same time. That in turns brings up your market share, you'll be one of the first true racing games to be cross platform that people really want to play.
Use that link above again and you'll get a working version of PRISM. I just did a quick run through with the patch that I just applied. From there you should click on the PRISM.bat script and it will start PRISM for you and you just have the answer questions to get it up and running.
Exactly this. You should redownload PRISM and start fresh.
This link includes that fix fr ... o you should use this one.
From there I would follow cargame's advice and extract it to a root directory in your C:/ drive.
Last edited by Dygear, .
Yes you can write stuff to your home directory, and any sub-directory but that's not the point. The point is he just made a hard code articulation when he should of done it in the config file. Let's try to keep a good single to noise ratio please gentlemen.
That's because you should not be doing that at all.
Don't edit the code, it gets this information from the configuration file. You need to put that path in there.
<?php
!file_exists($logPath['C:\Users\Deividas\Desktop\insim']))
?>
Ok, simple fix for that one is ...
Change that line to that and it should work. I've also patched it on github.
You'll also want to fix the error it's reporting by making a log folder for PRISM to use.
console('The path to your log folder does not exist : '.$logPath['dirname']);Change that line to that and it should work. I've also patched it on github.
You'll also want to fix the error it's reporting by making a log folder for PRISM to use.
FGED GREDG RDFGDR GSFDG