Quote from tristancliffe :

It does seem a tiny bit fishy that the change over isn't seamless, as it would be with a pure relocation. But who knows... We'll just have to wait and see

Wouldn't a datacentre relocation usually involve unplugging the servers, packing them in a van and plugging in at the new place?

I know it's possible to do a seamless relocation, but it's much more expensive (you need 2 of everything) and much more complicated to do.

pingtest.net

Connection speed/low ping is irrelevant if the ping time is still bouncing all over the place. Problems in LFS are generally caused by inconsistent ping (which makes position prediction useless) rather than high ping.

Sounds like it could be overheating.

Servers with a lot of players and a lot of autocross objects (like busy cruise servers) will tax CPU and Graphics more than other servers.

Try cleaning dust out of any heatsinks etc and see if that improves things.

You could also try HWMonitor from CPUID to see how hot things are getting.

You will also have to upgrade to S3 before you can drive Rockingham after it is released.

Quote from BenjiMC :

HA! Turns out the fuse had blown in the plug

That's still not a good thing Under normal conditions, fuses should never blow.
Anywho, make sure you replace it with the exact same type+size of fuse. Don't go sticking a 13A in there

The reproduction of mp3 depends quite a lot on the type of music (and how well it's mastered, but that's another matter).

High symbols sound crap on mp3 regardless of bitrate - it filters and/or distorts the very high frequencies too much. The lower the bitrate, the more noticeable it is, but it is still distinguishable at the higher rates.

Mids/high mids tend to be reproduced fairly well by mp3 >128k, although it goes downhill from there.

As a general rule: 128k absolute minimum. OK for el cheapo speakers.
192k seems to be good for the vast majority of people.

Encoders can make a difference - LAME is supposedly one of the better ones.

Depending on the genre of music, I can tell the difference between mp3 and lossless - yes, in blind tests in as much as I think "why does this sound so nasty?", then look at the bitrate/format and my question is answered.


Regarding speakers, I used to have a set of 5.1 Genius speakers (I forget the model) which sounded pretty good for the power (27.5w RMS). I now have a set of Creative 7.1 speakers, which are noticeably better.
An ex housemate has a set of Z-5500s, which are better, but not worth the extra cost quality wise. They keep the quality up to painful volumes, and the sub is no less than brutal, so probably worth it if you like that sort of thing.


If you have a good amplifier, don't ruin it by using a mini-jack to phono cable and relying on the analog preamp in your sound card. Run digital signal, or you're wasting your money.


The quality of the power cable is completely irrelevant as long as it's not arcing somewhere. If you really care when using an expensive high end system, use a signal rectifier for the AC.


*Disclaimer: I am far from an audiophile, but I have been into fairly regular contact with high quality, high power FOH sound-systems so I know quality when I hear it.
Perhaps I can tell the difference between mp3 more than many other people, because I don't like the compression artefacts and others like the 'smoother' mp3 sound. Who knows.

The multiple of 4 is stated in insim.h and is presumably either because of some networking limitation or just that 4 bytes conveniently fits in 32bits of memory.

I had forgotten that in the original insim.h, the text portion of the button packets is commented out. Presumably then, one way to create the packet would be to extend the struct or append the text somehow before sending? (calloc()/malloc()/realloc() ? )

ed: DarkTimes and Stuff posted while I was writing the above - I'll have a play in a day or two when I get the time

Quote from DarkTimes :

TEXT_SIZE = ceil(TEXT_LEN / 4.0) * 4;

The limitation as I understand it (I'm OK with C, but not fluent by any means) is that, in the header, you have to define a constant/fixed size for the text string when defining the struct.

What would be the best (or at least a good) way of implementing a variable length struct/packet/whatever?
Should the text field be defined in insim.h at all or is there a way of trimming the size of the struct/packet later when it's sent or is there a better way than either?

Quote from Ger Roady :

Yes . Scawen

I doubt even Scawen knows

It would probably be easier for Scawen to program in the soft stops himself, rather than work out how to communicate with every version of every profiler from every manufacturer.

The only limitation with that, would be that the soft stop strength would probably be limited by the max strength setting in the profiler, but that's not a major issue.

Quote from z-ro 8 :

you can also listen. many people don't.

I find wearing a pair of headphones helps a lot to hear where other cars are. It's surprising how easy it is to hear exactly where they are when close.
It also gives you a good idea of how your car is moving around through tyre noise etc.

Speakers just don't cut it - you can get them loud, but you tend to loose the subtleties of the sound. I imagine it'll be a whole different story once LFS gets surround sound.

LFS can only show the cars enabled on the server by the /cars command.

If you want the host list to display all the cars that are available ever on your server, you'll have to set /cars to what you want to be displayed on the host list and limit the allowable cars at the time via InSim.

Ed: By 'limit via InSim' I mean that the InSim app would /spec anyone who's in a disallowed car instead of using the /cars command.

In pseudo-ish code: (not in any particular language, so the syntax is probably wrong and will likely need to be tweaked to make work with whatever InSim API/Library you're using)


Almost all my knowledge of InSim is just from reading insim.txt - reading it all through gives a very good idea of how it all works. The nitty gritty of how to actually do useful things with it is all in the particular implementation


I should probably take a proper look at the C# InSim library at some point, but I actually find C/C++ simpler for my needs.

In exactly the same way as all the ISP_ and TINY_ constants are defined in the insim.txt (insim.h) file.

You would define BID_WHATEVER = 10 somewhere at the start of your code (not entirely sure in C#, but I would guess that the start of the main thread would work) then use

or similar, which uses the human readable BID_WHATEVER to refer to 10

How it works:
Constants are purely to make things readable (and easier to use and edit) to the programmer. When compiled, the compiler simply replaces every instance of "BID_WHATEVER" with "10".

Yes, MCI's are sent at regular intervals (if you enable MCI packets when initialising the InSim - you also specify the interval at the same time). You can also request a batch of MCI packets at any time.

You'll want to retrieve the data from the packet (or local array depending on the implementation of the library you're using) then convert it to either mph or km/h and send it in a button to screen.

I'm sorry I can't be more specific, I know very little C# as you know

Quote from drew555 :

I'd like to be able to use letters in there too

Create some constant variables to use for button IDs (BID_WHATEVER = 10) then you can call them what you like and make the code much easier to read.

Regarding the TM - this isn't very elegant, but may be the only way of doing it.
Create a char variable, set it to 153, then use the variable as part of the string in the same way $NickName is used.

If that still doesn't work, then maybe someone who knows anything about C# (ie not me) will step in

You have to actually tell it to add a character of ascii value whatever to the string, rather than putting ™ in the code.
Can't really help you on how to do that, because my experience in C# is practically nill, but I'll have a quick search.

edit:

this may work...
openPrivButton( "welc",25,50,150,15,12,-1,16,"^1Welcome " . $NickName . " ^1to [" . new string((Char)153,1) . "Pirate] server!&^0Type ^7!help ^0after leaving garage to see commands." );

Last edited by Degats, Sat 19 Dec 2009, 15:09.

Ascii 153

1. You could try pasting ™ in the code - there isn't an escape character when lfs saves a .ply file.

2. The IS_NPL packet is sent when a player joins the race/leaves the pits. I don't know how you'd find out when one is received using LFSLapper though, because I've never played with the code.

3.

Quote from R5Rider :

I have kind of a problem running LFS in my notebook.
It's an AMD Turion 64bits 2.0GHz single core, 1,5Gb DDR-2 and a shared memory ATI X1100 256Mb. It runs slow, but very very slow.
Running on XP, haven't tested yet with Win7.

EDIT:
When I meant that it runs slow, it is in single player with NO AI

That's your problem.
My 1.6GHz Turion (albeit an x2 - LFS isn't parallel threaded though so it won't make much difference) is more than enough for LFS, but the X1300 struggles a little. It's just about playable at 2xAA, but any more and it kills it.

Edit:
W7 is unlikely to give you any performance improvements, as you're graphics limited. Vista/W7 can help a lot when CPU limited.

Chances are, the frequencies made at ~3500rpm are matching the crossover frequency of your speakers. Frequencies on and around the crossover often sound much louder than others on many (usually cheaper) x.1 systems.

My speakers do the same thing with a few cars (although most prominently in the XRG/XRT). The crossover on mine is ~125Hz and that's pretty much the frequency range of the XRG @3500rpm, particularly when coasting.

There's not a lot you can do about it, other than tweaking the crossover in your audio driver's settings (if it has that option), or finding a system wide Equaliser (good luck - if you find one that works, let me know ) and reducing some frequencies at around 110-170Hz.

Raw stats are interesting and often revealing.

Intepretations/evaluations of stats are pulled out of the arse of whoever has an opinion to prove.

IMO, a third 'middle ground' setup option would be good.

This would give:
- Stock: Showroom spec, with only tyre pressures etc adjustable (as Scawen described as the limited option)
- Sane/Race: Some components can be changed (suspension, brakes, gear ratios, diffs etc) but not infinitely variable and with sensible limits. This should make adjustments similar to most racing series possible.
- Extreme: As it is now, with unrealistic limits and fine adjustments.

Personally, I'd be happy with just the first two (stock + sane), but I know a lot of people like taking things to the limits to see what can be done.

Quote from Shadowww :

It >could< be repack of debian too. :P

Or just about any base distro running the Gnome desktop environment.

After scanning the website, it's actually based on slackware

/offtopic