Quote from the_angry_angel :

Personally I blame perl for making it "popular".

Tim Toady is both perl's greatest asset and the reason many consider it a "write only" language. Before people accuse me of flaming perl, I should say I am a perl code and, ahem, some of my best friends are perl coders.

Quote from Mako. :

May I please ask just what you guys are talking about???

I was trying to write some InSim code that could tell me whether my current client was in the race or spectating, which can be done if you know your connectionID and you look to see if you find yourself (and not as an AI) in the player roster. I just couldn't figure out how to get my connectionId until GeForz reminded me about the remote flag in IS_NCN.

Quote from GeForz :

struct IS_NPL // New PLayer joining race (if PLID already exists, then leaving pits)
{
...
byte PType; // bit 0 : female / [B]bit 1 : AI / bit 2 : remote[/B]
...
};

Said that. You know your connection ID (and player/username!) by looking at the NCN Packets which you can request and which also have a remote-flag

Doh. I completely forgot about that flag, and yes it works exactly as advertised. Thanks!

I have a scenario in which LFS will close my InSim connection without warning, regardless of whether it's TCP or UDP. Basically, if i connect to an LFS client and it connects to a server that has a layout for the current track, InSim shuts down as soon as LFS connects. I can reconnect to LFS after i get disconnected and all is fine, so it's only on connect, not while running on a server with a layout. If anyone could confirm this behavior, I'd appreciate it.

just was posting about the /pitlane bug.. a little late to the party.

Last edited by sdether, Thu 26 Jul 2007, 04:39. Reason : Didn't see the message already confirming this as a bug.

Quote from DarkTimes :

Yeah, but in my view you should play to the strengths of whatever language you're working with, and OOP is not one of those for C.

Totally. I spent several years doing OOP in perl. Perl is amazingly versatile and OO was grafted onto it via some clever tricks, but at the end I was trying to write perl as if it was java and it was just getting too painful. You just gotta write code in the way most natural to your language of choice.

Now I do mostly procedural stuff in perl with limited OO here and there, and leave the heavy OOP to other languages. If I had to venture back into dynamic language land for something more than admin scripting, I'd probably go for php5. It's the object model most closely resembling what I'm used to. I know lots of people swear by python but I've never been able to get over the "white space is significant" barrier.

I just discovered that /mp doesn't work in the multiplayer connection screen. So after i join a server, I cannot join a server again without killing and respawning LFS. It would be nice /leave would drop back to the front for all screens.

Quote from Hollywood :

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?

IS_STA is LFS instance based, which could be either a server or a client. All tracking packages are sent by all LFS instances, i.e. if i start up lfs, connect to it locally and then connect to the server, i still get all race tracking packages, so i can't tell if that IS_PLL is me or someone else

An IS_SPC wouldn't help, since i still wouldn't know my connection Id.

I'm trying to determine whether my client is spectating or not and all I figure out is a roundabout way of tracking connections and players and it still requires non-insim knowledge about the client. This goes hand in hand that State doesn't just tell you your playerId or connectionId either.

Basically, all I can figure is that if I know my playername, i can request all playerinfo and also listen for players joining. If i see myself listed or joining, that's my playerId and i'm not spectating. If i see that playerId leaving, I know i'm spectating now.

Of course, there's the catch-22, that i can't find out my playername without knowing my playerId or connectionId.

Is there some information I'm overlooking?

If no one else has a solution, I'd would like to request that IS_STA uses one of it's Spare's to report the connectionId and/or playerId

Last edited by sdether, Fri 27 Jul 2007, 18:57. Reason : problem solved

Quote from Shotglass :

True but how are you going to teach those without establishing at least some kind of pseudo code?

I don't think there's a problem with learning the concepts of conditionals, iteration, inheritance, polymorphism, encapsulation, etc. without code.

Quote from Shotglass :

(btw on a side note I don´t think data representation is something you should put that much emphasis on when you begin to learn about coding).

I think this statement illustrates our differences in approach and our respective stance on OO. After all, the essence of Object oriented programming is that you are defining a model in which data is grouped and has data domain specific functionality attached to it. I.e. data representation precedes function in design.

Quote from Shotglass :

You´re both making it sound like OOP is _the_ holy grail of programming and that you should teach it first before you get to the point of teaching someone how to actually do something with it.

OO is not the holy grail, but currently it is the predominant paradigm in programming today, so understanding it is definitely beneficial, no matter what your goals are.

And I do believe that code structure, data structure and control flow are language independent concepts that should be learned prior to figuring out any particular languages specific syntax for printing out a line of text. You can find the commands the perform specific actions in your reference documentation, but it won't tell you what's a good or bad way of structuring your code.

Quote from Shotglass :

darktimes' example is exactly the reason why no one should start out with java or anything .net
i havent dug into either one yet but from what ive seen they appear to require you to put a lot of essentially useless overhead around the actual code to make it do anything in the first place

I'd claim the opposite. Anyone can learn the essence of calling a command that executes some intrinsic part of the language. But for any decent size program (not some one of script), structure of the code becomes absolutely vital for the extendability and maintainability of the application over its lifetime. A object oriented language forces a lot of boilerplate that for Hello World and it's ilk appears to be significant effort, but for any real program become negligible. Meanwhile some basic structure has been instilled in the program logic.

Mind you, OO doesn't mean you can't write crap. You can over- or under-design your model and getting it right is not deterministic. Only more reason to start with design fundamentals before learning the syntactic nitty-gritty of a particular language.

Quote from Hollywood :

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.

I can't begin to express how much I agree with this. While life without Visual Studio would be painful, hiring programmers that learned all they know in Visual Studio makes me want to cry. I've interviewed programmers with "10 years of ASP and ASP.NET experience" that don't know what an object model is.

If you want to be self-taught, steer clear of the "<insert language here> in 21 days" variety and learn the concepts of object orientation and data structures before learning the syntax of a specific language. I'd even say start with this wikipedia page (and those linked) just go learn the concepts involved. Then pick your language and find a book that talks about design for that language.

I know dynamic languages are often easier to start with and especially if they aren't type-safe, they are a lot more forgiving. At the same time, that ease can also lead to some bad habits being formed in the way you write your code. Which is why I think there are strong benefits of starting with a type-safe language that does not burden you with memory management, i.e. C# or Java. I think that Visual C# Express is significantly easier to get started with than Eclipse, so I'd say of the two C# is easier to get into (again my bias is showing).

Speed is funny. Lots of people bag on java or .net languages for speed, but then write code in javascript, perl, php, whatever. Byte-code compiled languages are generally an order of magnitude or two faster than interpreted, and native compiled languages can get you another order or 2. But all this is completely dependent on the domain and the programmer. If you're processing text and are ok in perl and in C++, you are likely to generate faster code in perl, for example.

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). If you need a web application or need to talk to insim, you gain nothing by the speed of C++, unless it's what you are best at, and neither is C#'s speed going to be an advantage over a dynamic language like php. I.e. in the domain that we are talking about in the forum, the full spectrum of languages should do just fine.

I've switched to running all my servers as vmware images (will try Xen on my new server). Aside from being able to run multiple servers on one machine, I can easily back up each server and even bring it up on another machine, should the host machine die on me. It's made my life so much easier.

Mikey_G found a bug while sending IS_SCH using my lib. I've confirmed the behavior and stepped through the code to check on the actual packet and I'm fairly certain that it's not a bug in my lib, but one on the LFS side.

Basically, if you send a keypress of 'g' (char 103) and you have a text entry open, it'll type out g. But if you do not, then the left turn indicator turns on. Mikey_G noticed that the hex for g is 0x67, so the the question was whether it someone saw the trailing 7 (which is bound to left indicator) and used that as the keypress instead of the char 'g'.

Can anyone not using LFSLib confirm this behavior?

thanks,
sdether

Quote from DarkTimes :

The resulting RaceTrackRaceEnd parameter appears to have only the base object methods, E.G. ToString(), Equals() etc... Maybe I'm doing something wrong, but I tried it in a couple of different ways. Unless of course that class is supposed to have no properties or methods.

That is actually correct. The Race end packet is really an IS_TINY with TINY_REN type, i.e. it carries no extra information. Creating an eventargs for that event was kind of redundant. I could have just used EventArgs.Empty, but wanted to have an EventArgs object in case that there might be information in the packet in the future.

Quote from Mojo1987 :

The gaps of the car in Front of me and behind where so much great.
Your Tool is great for hotlaps, but for race, the gaps are important

I agree that the gaps are important, but the actual request from Trekkerfahrer that this thread is about is for hotlap, or qualifying style time monitoring. Although I get the feeling, he has since moved on

You are a victim of this little insidious statement from the release notes:
Some events lost or gained information as the underlying data structures changed

Basically, as I did the various clean-ups necessary for going to patch X, I also brought all events into line the standard .NET event syntax, so that any event could get handled with a plain EventHandler delegate. So since 0.12b all events now always have a sender and eventargs that inherit EventArgs.

You need to change your eventhandler from

PrivateSub InSimHandler_Updated(ByVal InS As InSim.Events.State) Handles InSimHandler.LFSState


to

PrivateSub InSimHandler_Updated(ByVal sender As InSimHandler,
ByVal InS As FullMotion.LiveForSpeed.InSim.Events.State) Handles InSimHandler.LFSState


That should do the trick

Last edited by sdether, Thu 19 Jul 2007, 13:56. Reason : code markup hid the changes offscreen

I did some work a while back doing a blindspot checker, which created an overlap of the cars around you. Of course it had to be a lot less accurate since it was really trying prevent collisions not detect them. I just dealt with a collision circle around the car rather than a rectangle, but even with this, the different sizes of different cars had effects on accuracy.

One thing i'm playing with is doing collision by looking at large changes in velocity and direction. This will probably not show small bumps, but should be a cheap and easy way to detect a vehicle that crashed. And once you have made that detection, you can check cars in its proximity so see if they were involved in the crash.

vic.lfs.net:47474 works for me. At least I can telnet to it and open the channel. Haven't tried sending packets

Victor,

I'll be implementing Relay support into my library, but I probably won't have anything ready for testing until next week. I'll PM you once I have something I can test with.

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.

How about this? Attached is a screen shot i took on a random server running the timemonitor locally. More information and a link to the code is here. It's fully functional as is, but really meant as a code sample for someone else to build on. (I.e. it needs a way to configure where on the screen to display the HUD, etc.).

Last edited by sdether, Mon 16 Jul 2007, 21:55. Reason : Code has been released

Quote from birder :

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.

A corollary to that experience is that the best way to get something done is to tell the programmer that it's impossible.

Note, this motivator is not a substitute for a spec, in case anyone was thinking to use that statement in their next request on this board.