Quote from blackbird04217 :

Dygear; The files are far from complete, however, here I will share them in their current state. I added a little documentation where things were not yet implemented, but it should be enough to get you started.

Nice! Thank you, when I get some time in the next few years I'll translate that into PHP.

Quote from blackbird04217 :

Dygear - Not sure if you are familiar with C++ much or not, but once I finish my basic "Curve" object I will upload the class header and source and from there you, and others, can use it how they wish.

The class currently:

Makes a curve from a set of points along the curve.
Allows you to make a container of points from the given curve.
Estimates the total distance. (Estimation only because it is a curve and the more steps the more accurate the estimate but it will never be exact).

If you give me the source code, I'm sure I can translate it to PHP. Thank you for the assistance.

I want all of that! I've always hated the blocky nature of the PTH files and the CMX files. It would be nice to apply this to the pth parser, so that I can generate some higher quality images.

Since we have a little wait until the next patch should be ready, can we get a frame time tool built into LFS? "/fps 1" - Show's FPS, and "/fps_graph 1" shows a frame graph for when the rendered is presenting to the frame buffer. "/fps_save <filename>" allows you to store the time in milliseconds each frame takes to render.

I'd like to be able to do some benchmarks, like "Inside the Second".

Quote from Flame CZE :

It seems to throw some errors when I try to use it. But as I said, maybe it's just me.

Thread hi-jack, what's the errors you are getting, what version of PHP are you running, and what version of PRISM are you running?

Quote from the_angry_angel :

I'd like to say I'll be getting back into LFS soon but honestly I don't know if I will.

Story of my life. Barring a major patch, I don't see it happening any time soon.

As Coding Horror has moved over to Ghost as it's blogging platform, and Ghost uses NodeJS for it's interpreter I've looked more into NodeJS. I like the API, and I like that you can handle multiple connections at once because if you ever get into a blocking state with one query, you put it on the back burner and and handle another request while you wait.

As whole websites are being built on top of NodeJS, and with XI4N being available. You could have one instance of NodeJS that works as both an InSim Client, and WebServer. Making for communication between your website and your game servers VERY efficient. With being able to replace most of your stack with NodeJS I think everyone would be CRAZY not to look into it. (Yes, I'm a late bloomer) With NodeJS being able to act as a HTTP server, and also the code parser / interpreter, you shorten your LAMP [Linux Apache MySQL PHP] into LNS [Linux NodeJS SQL (MongoDB / SQLite / MySQL)].

No, it's Eric, and considering that he did this job many, many years ago now, I think they have done a pretty good job standing up to the test of time.

Quote from Scawen :

Thanks for the detailed debug info about that crash. I guess with that I should be able to sort it out. If needed, I'll come back to ask for more info. I wonder if anyone can enable DX9 debugging and get an error log with the Fraps crash?

What do we need to do in order to enable DX9 debugging? Aka, where do we download the debug version of DX9?

I found some instructions here ... Using Debug Version of DirectX 9

AMD supports potential DirectX ... ne Mantle's future at GDC

So AMD sees the movement in the industry around graphics APIs as validation of its own approach with Mantle. I'd say that's warranted.

Mantle no more? GDC sessions point to the next DirectX. Well, take a look at that.

OpenGL and DirectX to setup to Mantle's performance. Pretty sure you might as well just move to OpenGL now. They are not going anywhere.

11% of Windows XP Users Will Switch to Linux, Survey Claims

Although the source might be a little bias.

I remember the opening sequence of top gear back in 2002, with Jeremy Clarkson saying, "This is a car show", and it had a used car price segment with a presenter before James May that no one knows about. I think it changed around the time James was bought on for the second season, and then it changed again when they had their first challenge and it was received so well. Can you blame them for giving the audience what they want?

I'm pretty sure that the hosts command will give you all clients connected to all servers (that are not hidden servers).

Its the Star Trek Odd / Even rule applied to Windows Releases.

Quote from blackbird04217 :

I do completely understand that I am dealing with something very technical, and making my best attempts at explaining it so it is understandable by a not-so-technical mind.

I love the technical details. I like the insight to a world that I'm not interacting with yet. Exposing myself to the nitty-gritty is massively useful from an intellectual point of view as should you see it again, then you now have a frame of refrence to go back too.

Don't forget that quite a lot of us are programmers ourselves, so we have the technical experience to understand the scope of what you are dealing with. Don't be afraid of losing us.

I have some quiet optimism, emphasis on quiet.

So, I'm doing some restructing of PRISM's modules. That goal of this restructuring is that we make LFS's modules act as a 'Driver' that allows for communications between LFS's InSim interface and PRISM. Then I'd like to make HTTP, WebSockets, Telnet and SSH a driver as well. This takes the colors of the rainbow, and focuses them into a single white beam (a packet stream) that all "userland developers" can use. I'm just trying to come up with a simple interface for that, and a folder structure that makes sense.

Currently, I'm thinking that each driver should be it's own subdirectory within the modules directory. Or should it be that there is a driver top level directory within PRISM's directory and we use that for all of the different drivers we intend on supporting. Then more general modules go into the modules directory, in this case admins would be a general module, as well as the INI handler. Then we can expand on that so that plugins that use LFS' driver can simply add use a trait to get access to their packet information.

Then we have to think about a common interface for PRISM into it's drivers. The most common way that Victor handled that was to use initialise(), getSelectableSockets() & checkTraffic(). We would make a module for the drivers, and make these required functions to implement.

I hope this will make for clearer code, while allowing the programming with this dev team, and programmers within the "userland" to be able to use PRISM in a more concise manner. As such, I'm shooting for PHP 5.6.0 to be a REQUIREMENT for PRISM 0.5.0. All devs should start testing PRISM with PHP 5.6.0-Alpha1 as soon as possible. There are many great things to be seen in 5.5.0, and now 5.6.0.

Can anyone report if they are still having issues with the client / player state information?

Quote from Neilser :

Agreed, BUT (as I once suggested in the distant past) LFS could semi-trivially interpolate between the current position+time and the previous one to give much higher precision splits. This would free the physics clock to be run at whatever we want. (Probably same for everyone tho, or sync issues...)

But that would be a lie. Do you really want to lose a race because the game engine took a guess. I guess you could make the argument that everything is a lie.

Quote from Yisc[NL] :

1) Can PRISM do anything Lapper can?
2) In Lapper there seems to be a bug when checking tyretypes before/after pitstop, do you think that's working correctly in PRISM or is that an Insim bug?

1. Yes, you have total access to the InSim interface.
   
2. Yes, you have total access to the InSim interface.

PRISM makes it pretty easy to handle things like that. You just have to hook into the IS_PIT packet to get information about the Tyres. You can get original tyres by getting that information from when they joined the race from the IS_NPL packet. I also included the IS_PLA packet and IS_PSF packet as it gives you when they enter and exit the pits.

Lol, we live we learn. I kinda like that you put them all in this thread for their patch level. That's kinda nice.

I perfer to do 0.4.5.1 and then 0.4.5.2 as apposed to 0.4.5a, 0.4.5b. PRISM follows PHP's number scheme and the version number should be able to be parsed by version_compare.

Congrats on your first release T3!