It would be insanely great to have a UNIX version on the dedi one day, but I guess it would mean a complete rewrite of the current implementation. Supporting the myriad of *NIX systems out there would itself be a massive undertake
I for one think it's perfect that we can run the dedi on X-less machines and still get the output.These are some awesome news, perhaps I'll finally be able to host a LFS server I gave it a brief test on my headless openSUSE server and it worked like a charm, so it definitely doesn't need a running X server.
I gave it a brief test on my headless openSUSE server and it worked like a charm, so it definitely doesn't need a running X server.I've been asked how to get the mod working with 0.6E. I'm working on a bigger update with some extra features and more user friednly interface which will work with all versions of LFS. Unfortunately some other aspects of my life demand a lot of my time so I'm not progressing as fast as I'd like to.
In the meantime, you can still use v1.05 with 0.6E through G27LEDsHelper (still bit buggy, but it should work in most cases). If you have some programming experience, you can use CheatEngine to find the memory addresses which hold car type and RPM and update the mod yourselves. RPM is of float type and car type is stored as char[4]. Feel free to upload such an updated version.
I'll release an updated version as soon as possible, but I can't give you any sensible estimate ATM.
In the meantime, you can still use v1.05 with 0.6E through G27LEDsHelper (still bit buggy, but it should work in most cases). If you have some programming experience, you can use CheatEngine to find the memory addresses which hold car type and RPM and update the mod yourselves. RPM is of float type and car type is stored as char[4]. Feel free to upload such an updated version.
I'll release an updated version as soon as possible, but I can't give you any sensible estimate ATM.
Timer bounding is a double edged sword. It fixes problems where the reported time value suddenly jumps when it shouldn't (WINE bug). On the other hand it creates a new problem when the time jump actually happens (rocklan's problem). I guess that only time will show if LFS should keep this workaround.
I'm uncertain how big a problem it would be to implement, but perhaps a server-side option to switch this workaround on/off might be considered for a future update?
Depending on the type of dashboard you will be using, you might be successful with Arduino microcontroller, but there is no universal solution.
My money is on the Intel driver, it's very unlikely that an application would cause a total freeze on Windows with an NT kernel.
Are the unloadable cars from S1 or S2 pack? IIRC this happens when you have a race set up with licensed cars on a demo track and your LFS gets locked for some reason (like an update).
Are you trying to send way too many InSim packets at once by a chance?
Does this help? (the code is obviously not PHP, I just like the syntax highlighting)
Point is a class or struct that contains X and Y coordinates and _vertices is a set of points making a polygon. The algorithm above returns true if the point "p" is inside the polygon and false if it is not.
<?php
/** Casts a ray from the tested point onwards
* along the X axis to determine if the point
* is inside or outside the area.
* Odd number of intersections means the point is inside the area.
*/
bool Area::contains(const Point& p)
{
int pX = p.x();
int pY = p.y();
bool inside = false;
/* Start with the segment made of last vertex (j = SIZE - 1) and first vertex (i = 0) of the polygon */
for (unsigned int j = 0, i = _vertices.size() - 1; j < _vertices.size(); j++) {
if (pY > _vertices[i].y() != pY > _vertices[j].y()) { /* Can the segment cross the ray vertically? If it cannot, skip it. */
/* WARNING: Magic ahead.
* If anybody wonders why this works, imagine that the formula below is nothing but an inverse linear function equation X = K*Y + Q
* where K = dX / dY and Q is the X coordinate of the starting point of the segment (note that the segments are created backwards).
* By solving this equation and comparing the result to pX we can tell whether the segment is "ahead of" or "behind" the tested point on the X axis
* at a given pY coordinate. If it is behind, the cast ray does not intersect the segment.
* (It's better to grab a piece of paper and visualise the whole solution) */
float shift = ((float)(_vertices[i].x() - _vertices[j].x()) / (float)(_vertices[i].y() - _vertices[j].y())) * (pY - _vertices[j].y()) + _vertices[j].x();
if (pX < shift)
inside = !inside;
}
i = j;
}
return inside;
}
?>
Are you trying to use track nodes to get a car's location on the circuit? There are no track nodes in open configs so it obviously doesn't work. You can define areas on the track using X,Y coordinates. This is very easy for rectangular areas and a bit more complex for areas in a shape of an arbitrary polygon. Sample code for both approaches is available on the forum.
You'd probably have to use other tool than FRAPS to capture the screen.
I have to concur. Windows is a bit of a mess when it comes to storing applications' configuration and there is nothing you could easily backup to store just the configuration. Putting Windows and your apps on a separate partition and creating an image of it might be the only reasonable solution.
I don't think there is any way you can do this without some serious hacking. Unless you have some programming experience, I'm afraid it's just not worth the effort.
The intake restriction option was added to help balance the performance of cars, particularly in the GTR class. Intake restrictors are actually used in various racing series to limit engine power so it makes perfect sense to have this in LFS. The passengers are sort of silly, but it's been like that since S1.
I don't believe this is in any way InSim.NET's fault. When a track is changed, LFS just sends a packet to notify InSim applications of the change. Assuming you wrote your application in C# or VB.NET you should get an exception which can help you track the problem down.
When a car is "turned off", RPM and speed is exactly zero and no dashboard lights are lit (maybe with exception of hazard lights and beam, I didn't check that). I can't think of any other condition under which you'd get the same readings. Except for the situation when a driver switches ignition off while the car is moving it's fairly easy to approximate the "on/off" status of a car.
Plus the open configs like the second most suggested thing for years (right after the engine tuning and exchangeable body kits). Open configs can serve to a wide variety of purposes, most of which have something to do with racing. LFS is not an MMO version of GTA.
You might want to check out this guide: http://en.lfsmanual.net/wiki/H ... rwarding_.2F_Home_Routers
A note about the almighty autoconfigration. I learned not to trust it. For instance, I've come across a few RAM modules which required a slightly higher voltage to work properly. Unless I specifically set that in BIOS, the modules worked fine until I put the system under some load or tried to overclock - even a little bit. Once I set the correct voltage manually, everything started to work just fine. The modules of course had an SPD chip with correct info programmed in. I'm not saying this is the cause of the odd beeping, but if there's any chance something could have misautoconfigured itself, it's worth checking it out.
Yet another option would be to expand the IS_NCN as needed but send the appended data only when an InSim app asks for it in IS_ISI flags. That would maintain binary compatibility with older InSim apps and eliminate the need for a special packet. OutGauge already uses similar solution to send OutGauge ID.
Breaking InSim binary compatibility without a really good reason is obviously not the way to go. I guess that supplying the locale info in a new optional packet would be the best solution. I for once agree that it could be quite useful.
I guess I should have mentioned that. "Official" support is still for 0.6B only, but you should be able to get it working with any test patch through G27LEDsHelper. I'll release a bigger update once 0.6C is out.
I've made what appears to be a mistake of updating my Windows development environment to Windows 8 and MSVS 2012. There've been some changes to the compiler so I'd like to know if it there are any problems when the mod is bulit with MSVS 2012 toolchain. Apart from being bulit with MSVS2012 this version is identical to 1.05D.
See the first post in this thread for download.
See the first post in this thread for download.
Isn't this just a limitation of the FPS limiter implementation rather than the game engine itself? If the entire game loop recalculates every 1000/limit milliseconds when the FPS limiter is set, it's logical that you see pings only as multiples of the delay between two iterations of the loop. For instance, if you set the limiter to 35 FPS, the only ping values you'll get are 28, 56, 84, 112 ms.
Here's a friendly suggestion from a hobbyist programmer. Programmers won't usually beg you let them work for you, unless can offer them some interesting and new problems to solve. You seem to be creating yet another cruise server and I'm afraid you won't attract a lot of people with something that's been done million times before.
If you have ideas for some actually innovative game concepts that no cruise server has done before, bring them on or you might end up doing all the work yourselves. Good luck!
If you have ideas for some actually innovative game concepts that no cruise server has done before, bring them on or you might end up doing all the work yourselves. Good luck!
FGED GREDG RDFGDR GSFDG