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

That tells me that there's something wrong somewhere and it's not LFS related.

Anything above 0% packet loss is bad, as is 'jitter' that high.

Either the router is indeed to blame, or something's happening with your ISP, either overloaded or traffic shaping etc.

Looks like you're not getting any position updates until you join the track.

Random guess: perhaps UDP packets aren't being recieved properly by your system.
There's a key combination I hit by accident occasionally that forces TCP for position packets instead of UDP. No idea what it is though. Failing that, check firewall(s)/router settings etc.

I have replays for:
race 2 http://www.mediafire.com/download.php?jtkymzjnnjj
race 7 http://www.mediafire.com/download.php?mmnxktzwhdy

Quote from Postman Pat :

The thing you alter with the software in a sim, usually called FOV, would be GFOV (geometric field of view). Which according to tons of research - some in driving sims - very much affects accurate perception of speed and distance.

Yeah, that's pretty much what I was trying to say. You're only really going to get an accurate perception of speed when GFOV==DFOV and it's large enough to display what you'd see in your periferal vision.


The dynamic alteration of GFOV in games is used quite a lot, and can help when done properly (ie not like when you press the nitros in NFS). Curved/fishbowl GFOV (higher values on the edges of screen than the centre) is used in a few. Motion blur is often used as well (usually badly).

The problem is, all these tricks need to be subtle or the illusion fails completely. It's very hard to get a good balence between subtlety (sp?) while actually making enough difference to prepresent perception properly.


I've yet to find a game that achieves it, and I doubt it's even possible. Proper speed/distance perception is one of those things that only works for the few people who have the right hardware - for everyone else there must be compromise.

Field of View, by definition, is constant.

The 'correct' FOV depends on the overall width of the screen(s) and how far away from them your eyes are.

Unfortunately, the vast majority of people don't have 180+ degrees worth of screen coverage - most of the time, only 25-50 degrees or so.

Using the 'correct' FOV, you will not get an accurate sense of speed at such a small FOV, as you can't see peripheral movement. You also can't see anything of what's next to you for the same reasons. With such setups (low physical FOV) the ingame FOV is always a compromise between accuracy, sense of speed (for racing games anyway) and how much of what's around you you need to see.

In an ideal world, everyone would have at least 160 degrees of screen coverage - ideally 360 degrees - and then the 'correct' FOV can be used properly and you will get an accurate sense of speed.

Unfortunately, that'll probably never happen.

If you press shift + f4 in LFS, it will toggle fullscreen/windowed mode.

I've also had no problems with W7 64

Quote from tristancliffe :

I run Windows 7 64 bit, and had no problems. Well, actually, I did seem to struggle making a shortcut in the Games quicklist - when I loaded LFS from it it said it couldn't do something - but that was easily fixed with a couple of minutes fiddling.

For some reason, when dragging the .exe into the Games list, it doesn't include the "start in" path in the shortcut it creates. This means LFS has no idea where all the other files are, so gives an error.

If you right-click LFS.exe, create shortcut, rename the shortcut to whatever you want, then drag the shortcut into the games list, it'll work fine.