This
, should really be sanitized down to
that should be Zsooti. The way I read it, the first two colors should have no effect.

Pretty much what avetere just said.

Quote from scipy :

Forgive me for my observation (especially if I'm wrong) but, is it just me or is this thread kind of going into the direction of "let's do everything other than the (now) simple original idea"?

As with any project there must be a planning stage. That and no one has said that they are actually going to do this. I've expressed an interest, and that's why I keep on replying to this thread. Anyway what's wrong with having ideas and sharing them?

Quote from Bean0 :

Just displaying the gaps to the car in front and the car behind would be enough (or maybe 2 cars each way).

DoP have a HUD like this, so it must be possible.

DoP? It's defiantly possible, but each car's driver would have to be known to the InSim application, so that when a new driver comes in they can take over that car's position and continue to move the race forward for that car.

Quote from misiek08 :

And 1 thing more. What do you think about overriding LFS GUI with tracker data? After TO, LFS will show last position and will count laps from 0.

I think that the only way to do the properly is by setting the server into practice mode, and allowing the InSim application to take over race control completely. This would allow for example things like a warm up lap, and a cool down lap.

Quote from Krammeh :

Will be releasing it under my secondary S2 licence though, don't want the race linked to cruise :P

LAMO, funny, it's normally the other way 'round.

The first one is by far the better choice.

I had an all McLaren setup, except my drivers so I did quite well this weekend. Pretty happy.

The Black Screen AA bug is a known issue that seems to happen on more then just Intel IGPs. I have the same problem with my i3-2100T using a HD 1000. Not sure if the bug lays with LFS or with Intel Drivers, but I've heard this problem also be reported on some nVidia chips as well. I'm about to get an AMD 6950 and I'll let you know if the AA problems happen on AMD GPUs.

Quote from Dygear :

FOM Overlays & Timing and Scoring Plugin.

So, I've started work on this plugin, and I've got the basic timing parts down on your own car and it looks pretty good. But this is using some features of 0.4.2, and some updates that I've not released yet. But it's a good starting point of code to see how I'm programming this, and I hope people can use this to learn.

Figures ... Something had to screw up a good thing.

Quote from ivantod :

@ avetere

Be nice.

No, there is no command, or combinations of commands, that allows for the player to exit the pits.

Oil + Rain = Skid Pad Fun!

Rain brings the oil on the tarmac to the surface, so it gets even worse then just being wet. This often happens at intersections as all cars will travel that section of road so it can get, 2 times or even 3 times the normal amount of oil.

There was a patch of road where I live that once I got wet you could do donuts in a 4 cylinder giving it only half throttle. It was great fun if you knew about it, scary if you did not.

Quote from ATC Quicksilver :

I bet he wishes he was Italian, after watching Valentino Rossi for so many years I know the Italian anthem better than the British one.

I know the Italian anthem better then the British only because of one M.Schumacher and his Ferrari days.

I'm pretty sure that PRISM can handle the extra load, even if the update was say, 1 time a second, times 32 players.

So MCI packets unformat string would look like this would look like this.

bSize/bType/bReqI/bNumC/[NumC]Info{SNode/sLap/bPLID/bPosition/bInfo(tBlue/tYellow/t3/tLag/tFirst/tLast)/bSp3/lX/lY/lZ/sSpeed/sDirection/sHeading/sAngVel}

The only limitation is that back references, and in references would have to be same level only to avoid ambiguity. If I knew C++ better, and I had the PHP SDK, I would make this function and add it to PHP myself. I think this it a worth wild project. I also think that JavaScript should have these functions as well with the upcoming WebSocket support for binary data.

Last edited by Dygear, Tue 27 Sep 2011, 07:52.

I'm not so sure about that, I think that every driver would have to setup OutGuage, and then provide the connection details to PRISM some how, so that PRISM could listen for the OutGuage packet from their client. But there should only be the need for one instance of PRISM, and that's on the server side. But I don't know if OutGuage packet's will route outside of a local network, I've never tried it.

The AI thing was obviously out of the scope of this right now, it would be something that Scawen would have to work on. But as far as getting information about the engine we can get that from OutSim or OutGuage. PRISM could handle this without any problems at all if I add the OutSim packet to PRISM. This way we can monitor the engine temps of each of the car.

Version 1.9.7 includes full support for what was added in Version 1.5 of Victor's LFS World Pub Stats. Even more show case pages where updated, but not all of them are done.

Changed my mind, here is 1.9.6 with support for LFS Pub stats version 1.5 and so all of the things that come with it. All showcase pages are present, some have been updated, some have not.

Ok, I'll merge that in as well.

[Edit] The next version will be 1.9.9, and it will be the last version of this branch.

I'll be sure to update that when I get home, expect a fix in the next 12 hours.

Quote from T3charmy :

Although this is nice, it brings me to worry about some things... How exactly are servers that have multi-LFS dedi's going to use PRISM? will we still be able to set up manually?

Most people will only want to use PRISM with just one server, I see that being the greatest use set. But the people like you, who have jumped on right now, are really power users, and so of course there will still be options available to you to setup multiple servers. Something along the lines of a question on if you want to load the settings from the detected LFS instance, or use them and add more, or ignore the detected LFS instance and setup a whole thing on your own.

As I have said before, PRISM really is meant to be installed under the LFS directory, in a sub directory called addons. This is so that PRISM can make use of configuration files that LFS has, and to make use of any assets that LFS uses (Like the path files, or AutoX layouts.) The point of this being not only to make addons clearer, where things like Airo would be installed to $LFS/addons/Airo/ and PRISM would be installed to $LFS/addons/PRISM, it also give us access to LFS directly.

Knowing where LFS.exe is very helpful to PRISM when used on the same computer as the LFS instance. It give us direct access to the configuration files, allowing us to read and parse this data. This means that, as long as PRISM is installed correctly into the $LFS/addons/PRISM directory, PRISM, in the coming versions, will not require any configuration at all. It will simply work with LFS. You don't need to give it any passwords, or anything of that nature, as it has access to that already in the config files. You don't need to setup the hostname, or tell it the InSim port, because it also has that information already. It will just work. I think in many cases, this will get around any problems that people might have with installing PRISM on their computers and servers.

The only draw backs is that it will not configure the HTTP interface, or the telnet interface. But for people that don't use it, I don't see it being a problem. If I do add the HTTP interface to PRISM as apart of the NCN setup, then it would be on port 8080 as to get around the permission problem with Windows Vista / 7.