o Add a packet that allows for adjusting the voluntary handicaps, such as:

struct IS_RSX // Adjust player Restrictions
{
byte Size; // 8
byte Type; // IS_RSX
byte ReqI; // 0
byte PLID; // player's unique id

byte H_Mass; // mass (kg) to be added
byte H_TRes; // intake restriction

byte Sp0;
byte Sp1;
};

There are plenty of examples of C# apps already around. Check out the LFSLib.NET posts as sdether has already posted a bunch of example applications.

Quote from revolucio :

the app that I am doing is with C# language.

I dind't want to send more information of that.

Thanks in advance

I agree.

Stop fixating on GPL so much. It was great sim for its time. However, its issues have been talked about over and over for years. It is *not* the end all be all of racing sims. Nor is anything, including LFS, at this point in time.

Accept LFS for what it is, and that means the online community if you plan to race online, or don't.

Quote from BlueFlame :

Now that proves you have never played it, your the true meaning of 'spitting the dummy out'.

Quote from MAGGOT :

There is no such series as 'Indy Car' any more. It split into the IRL and CART many years ago. IRL is now something else (forget the name) and CART is now Champ Car.

It really helps to know what you are talking about.

IRL == Indycar Racing League. And it didn't split from CART, rather Tony George (owner of Indy) started a rival racing series, the IRL which was formed to race solely on American ovals with mostly American drivers.

And yes CART has transitioned, through many business transactions, into ChampCar.

So the original poster was spot on about his comments concerning which American series represents the typical types of racing.

Quote from joelbarton1987 :

is there any one out there that would be willing to teach me how to program ..... PLEASE XXXXXX

Yes, its called "school".

I don't think IS_STA packet is connection or player based, its server based rather.

Can you request a single player's info?

In my testing whenever a player spectates, an IS_PLL packet is sent. If the connection has not received an IS_CPL packet then its still connected to the server, so therefore is spectating.

Perhaps an IS_SPC packet that says when a connection spectates could be sent?

Quote from Shotglass :

it will teach you a lot of the fundamental things you need to know about programming from a higher level point of view

Yeah, it's good to understand at a 50,000' view of it.

Quote from sdether :

Unless you are talking in the sub-millisecond response time-frame, C# is going to be fast enough. If you want to write a competitor to LFS, you probably need to get into C++ (but XNA may go a long way).

There are already one or two published high-end games (I'm drawing a blank right now) that used C#. There is GarageGames upcoming (it's still in beta) Torque X, the .NET version of a game platform for their Torque Game Builder for 2d games (GarageGames is at the core the guys who originally wrote Tribes and Tribes 2). Biggest drawback right now to XNA is that there isn't a quality network stack. There are several in the C/C++ world (such a TorqueNetworkLibrary, RakNet, etc) but the .NET and Java landscape is pretty barren (and I don't count Sun's "Sun Games Server" as such). Also, I know that that NCSoft has a few key developers working on a Java 3D engine (available to the community as the JMonkey) and was recently.

Unfortunately, with XNA (and same with ASP.NET too), there is too much emphasis on making things "easy" for the "drag-n-drop" coder with less regard to professional and enterprise quality level programming. But another topic, as I could rant on that for hours.

And as another point-in-case, J2EE (although its not called JEE) has been used for nearly 10 years as an application stack for building enterprise level web applications and back-ends.

The .NET platform is very fast, especially with today's computing power. Same with Java, although Java on the client is hampered by Swing (which is poor, better to base GUI apps off the Eclipse model). Both virtual machines are highly optimized and fast. Go check google for speed comparison results. As for the memory management, its really immaterial in both cases, but if you have an overwhelming desire to know, you'd have to go check out the ECMA specifications for the .NET platform. Sun also has the Java specs available too.

I re-iterate it again, starting to play with programming by creating GUIs in drag-n-drop designers, or using any sort of RAD tools, is *not* the way to actually learn to program. You gotta learn the basics first. Sure exceptional individuals (John Carmack, Scawen, and a host of people throughout the software development world) can get away with being self-taught; but usually they aren't the type that ask "how do I program" to start with anyways.

Quote from mikey_G :

Well ofcourse i know that, i was saying that i dont know what memory management technique c# .net uses ( like in copying between 2 areas, mark and sweep, ref count).

Do yourself a big favor and go take some programming classes from a local university or continuing education. This way you learn about programming and not just how to code in a specific language. And preferrably the classes should start without dealing with any language, but rather you should be only dealing with psuedo-code at best. Once you actually know the ins and outs of programming, data structures, etc. the languages are nothing but frosting on the cake.

Don't forget 16 on the AutoX.

Are you using VB6 or VB.NET? Because your code snippet is not syntaxically correct for VB.NET with .NET 2.0. As far as I know, you can't use .NET libraries with VB6...

Anyways, here's a code snippet of a working VB.NET program that does what yours is attempting to do:


[/COLOR][/SIZE]

Quote from tronicgr :

I spend 800 euro making it (all PVC pipes, metal dexion parts, motors and electronics, bucket seat). Now I said 30 times assuming the cost of the 301 is around 30k, If I'm wrong correct me...

You should put together a parts list and a basic "how-to" guide.. I'm sure others would love to try it themselves after seeing your awesome results.

Ok, here is a list of suggestions I've compiled while working on a Live for Stats replacement.

o IS_TOC needs more information about the player that is taking over. As it stands now, after the IS_TOC gets sent a IS_PFL packet is sent, but we are still missing some of the information (i.e. Plate[8], PType). It'd be nice, instead of the IS_PFL being sent, that a IS_NPL is sent instead. Or the IS_TOC to include the PType, Flags, PName, Plate information fromt he IS_NPL. The latter would probably be preferrable as shown below As it stands in order to get the Plate and PType, we'd have to request, via the IS_NPL, all of the player info packets to be sent which seems a bit in-efficient if we're only interested in one player.

Relavent forum posting is http://www.lfsforum.net/showthread.php?t=27991.

struct IS_TOC // Take Over Car
{
byte Size; // 44
byte Type; // ISP_TOC
byte ReqI; // 0
byte PLID; // player's unique id
byte OldUCID; // old connection's unique id
byte NewUCID; // new connection's unique id

byte PType; // bit 0 : female / bit 1 : AI / bit 2 : remote
word Flags; // player flags

char PName[24]; // nickname
char Plate[8]; // number plate - NO ZERO AT END!

byte Sp2;
};

o Especially in replays running at greater than x2 speeds, we are not able to reliably receive every IS_NLP node packet, so this makes pulling statistically information that is not provided in the IS_LAP and IS_SPX packets. Specifically the information missing is the race position of the player and the current speed. From the IS_SPX packet, the lap number is also missing. Sure it can be inferred, but its better to be certain in the case of out of order packets with UDP. Adding these would give the following packets:

struct IS_LAP // LAP time
{
byte Size; // 28
byte Type; // ISP_LAP
byte ReqI; // 0
byte PLID; // player's unique id
unsigned LTime; // lap time (ms)
unsigned ETime; // total time (ms)
word LapsDone; // laps completed
word Flags; // player flags
byte Sp0;
byte Penalty; // current penalty value (see below)
byte NumStops; // number of pit stops
byte Sp3;

byte Position; // current race position : 0 = unknown, 1 = leader, etc...
word Speed; // speed (32768 = 100 m/s)

byte Sp4;
byte Sp5;
byte Sp6;
};

struct IS_SPX // SPlit X time
{
byte Size; // 28
byte Type; // ISP_SPX
byte ReqI; // 0
byte PLID; // player's unique id
unsigned STime; // split time (ms)
unsigned ETime; // total time (ms)
byte Split; // split number 1, 2, 3
byte Penalty; // current penalty value (see below)
byte NumStops; // number of pit stops
byte Sp3;

byte Position; // current race position : 0 = unknown, 1 = leader, etc...
word Speed; // speed (32768 = 100 m/s)
word LapsDone; // laps completed

byte Sp4;
byte Sp5;
byte Sp6;
};

Alternatively, it would be nice to have a CompCar packet available in the IS_LAP and IS_SPX.

struct IS_LAP // LAP time
{
byte Size; // 48
byte Type; // ISP_LAP
byte ReqI; // 0
byte PLID; // player's unique id
unsigned LTime; // lap time (ms)
unsigned ETime; // total time (ms)
word LapsDone; // laps completed
word Flags; // player flags
byte Sp0;
byte Penalty; // current penalty value (see below)
byte NumStops; // number of pit stops
byte Sp3;

CompCar Info; // car info for the player
};

struct IS_SPX // SPlit X time
{
byte Size; // 48
byte Type; // ISP_SPX
byte ReqI; // 0
byte PLID; // player's unique id
unsigned STime; // split time (ms)
unsigned ETime; // total time (ms)
byte Split; // split number 1, 2, 3
byte Penalty; // current penalty value (see below)
byte NumStops; // number of pit stops
byte Sp3;

word LapsDone; // laps completed

CompCar Info; // car info for the player
};

In either case, although I'd prefer the second, effeciency is increased because we aren't having to collect repeatedly collect the IS_MCI at a 100ms interval (for realtime and x1 replay speeds) or 50ms interval (for x2 replay speeds) in an attempt to collect information. This is especially true if we don't really need the position, etc. of the car at every node.

Relavent forum postings are http://www.lfsforum.net/showthread.php?t=27714 and http://www.lfsforum.net/showthread.php?p=482370#post482370.

o Add the connection Id to the IS_PFL packet as shown below. The player flags are really more connection based than they are player based. In terms of "taking control", the new connection that takes over the player object may have different player flags so when we track this information for statistical purposes we'll have a player information object that contains one to many connection information objects, which stores things related to the connection. This way we know what flags each "connection" used during the race.

struct IS_PFL // Player FLags (help flags changed)
{
byte Size; // 12
byte Type; // ISP_PFL
byte ReqI; // 0
byte UCID; // connection's unique id
byte PLID; // player's unique id
word Flags; // player flags (see below)

byte sp0;
byte sp1;
byte sp2;
};

o It'd be nice to have an SMALL_NPL that has a SMALL_NPL enum and the UVal would be the playerId. This SMALL_NPL packet would send a single IS_NPL packet for the requested playerId.

Relavent forum posting is http://www.lfsforum.net/showthread.php?t=27991.

Thanos, very cool. You might want to try damping the forces since the cockpit seems to be moving more than it should.

Ok, I totally misread my output, it does send down the player flags with the player flag change packet (IS_PFL). But in terms of efficiency, it'd make sense to send an IS_NPL packet immediately following the IS_TOC or just make the IS_TOC basically equivalent to an IS_NPL packet.

Otherwise you have to do, as you suggested, send a TINY_NPL which means you receive all the players info again. Not to mention it'd be nice to be able to request just one player's info, and not all of them.

Quote from sdether :

I suppose it's meant to be optional. I.e. if you care about the details of the new driver after a takeover, you can always request the player info again with an IS_TINY/TINT_NPL.

Yes, I suppose that's true... guess will have to do that. Thanks for the tip... should have seen it myself.

Am I missing something, or when another racer takes over for the first, is a IS_NPL not sent along with the IS_TOC packet?

Below is a snipet of the event log output... as you can see, 6 seconds past after the RaceTrackPlayerChange (i.e. IS_TOC) packet was sent, but no further packets as I sent sorta idle in the pits after taking control.

Without the IS_NPL packet, you don't know what the user's plates, player flags, etc. are.

Last edited by Hollywood, Tue 17 Jul 2007, 14:52.

Truly uncalled for.

Quote from dawesdust_12 :

Oh wait, you're an American. It all makes sense now.

Quote from birder :

I agree 99%, but progammers are a breed apart as us normal folks just can't understand what they do and how they do it.

In the past i had a programmer work for my company and at one board meeting he told me what i was asking was impossible to do in a million years, but 10 minutes after the meeting he had done it.

Not really any different than any other engineer.

Quote from birder :

i have yet to find one who will obey an order, simply ask politly.

That pretty much goes for anyone, not just programmers (unless of course they program for the military). :|

And no, programmers aren't a breed a part, they, just like a engineers of any other stripe, prefer to be given a full set of requirements for a project to cut down on the number of interpretations that have to be made. It makes it far easier to design and then implement a project if you know precisely what the client wants.

Would be nice if we had some commands that went to particular screens, like a "/front" which would take you to the front screen, etc.

Scawen,

Have some InSim node issues. All these tests were performed with an MPR replay using single AI driver, on Blackwood, with MCI turned on and running at a 50ms interval.

First issue is that the node indexs for the finish line and splits that are given in the IS_RST packet don't seem to match up with emperical evidence. For Blackwood, the node indexes are as follows:

NodeFinishIndex: 431
NodeSplit1Index: 113
NodeSplit2Index: 288
NodeSplit3Index: 65535 (of course means there isn't a 3rd split)

When running MCI, it produces the following output: http://www.thzero.com/racing/nodesx1.log

The first lap, we can see that the node that was received immediately afterward the Split 1 packet (denoted by Lap 1, Split 1 <<<<<<<<<<<<<<<) is index 110, instead of 113. Second lap it was index 111. For the second split it was indexes 287 and 285 instead of index 288. And for the finish line it was 429 and 428 instead of 431. So we're off a couple of nodes.

So thats a minor issue. Although at the rate the AI driver was running laps (79seconds) and the 50ms interval, I would have expected about 3 MCI packets per node, but I was only getting a smattering of MCI packets that had the same node. I am assuming, as I haven't had chance to examine the path information to determine distances between nodes, that not all nodes are equidistant.

The second issue is what happens when you increase the replay speed. The following log outputs show the nodes at x8 and x16 speeds, respectively.

http://www.thzero.com/racing/nodesx8.log
http://www.thzero.com/racing/nodesx16.log

We see a dramatic drop-off in the number of MCI packets received due to the engine running at x8 and x16 speeds. The AI guy is running at 79 seconds a lap which consists of 476, thats 6.03 nodes per second. So any interval under 166ms, we should get all the nodes via the MCI packets. Once we hit the x4 replay speed, we are would need to below 41ms intervals in order to attempt to capture every node packet.

So in order to capture position and speed statistics, reliably, with replays you either need to run the replay at most x2 speeds unless we are able to get the race position and speed included in the IS_LAP and IS_SPX, as mentioned in the Urgent InSim requests thread.

Why the need for pulling stats off replays as opposed to "live"? Well, one could say its a backup mechanism in case the "live" stat collection fails. It also may be perferable because of the server hosting situation. Or something else. But in a situation where you are collecting stats offline, and you are dealing with needing to wade through several hours of racing, on multiple servers, running the replay at the x8/x16 range is quite beneficial.

Thanks.

Sure TCP is guarenteed order of delivery, however since both TCP and UDP protocols are supported, it does matter.

Quote from Dygear :

Don't quote me on this one, and I'd like to be told I'm wrong if I am, but the TCP connection should not allow for that exception. All packets are ordered.