Yes, definetly player name in addition to the unique username. How about also squad or team name. Additionally it'd be nice to show squad/team results too as I know LOTA has squad battles in each of its series plus other series have only team battles (i.e. IGTC, MoE, etc.).
Yes!! Although I'd say only really news and maybe race results and standings.
Otherwise I think people are wanting LFS to do things they should be doing.
Otherwise I think people are wanting LFS to do things they should be doing.
Avoid C++. Its the worst thing in the world to try and learn OOP programming on because its pretty much the lowest level high level language.
And you can do procedural programming in almost any language, C#, Java, Python, PHP, JavaScript, VBScript, etc.
Learning something about what a function is, what a procedure (or method) is, and when to use them are good starting points. Learning data structures (lists, linked lists, stacks, queues, trees, etc.) are another good exercise and is important when it comes down to manipulating data.
But one of the reasons that OOP came into being is almost any program boils down into data that has methods that act on that data. Classes are simply data with methods that act on them. There is not a huge jump between procedural to OOP (unlike say going from traditional OOP to doing IOC based OOP, etc). In fact the paradigms are usually taught in many data structure classes.
The real problem is not whether OOP is easy/hard, whether it should be learned before or after procedural, but rather that people do NOT how to design and structure programs. Or what data structures to use for different situations, or even what the hell a data structure is. And it can be quite apparent when looking at code.
What you should really not do is start with an RAD language and attempt to make programs that way. You won't learn anything of merit.
As an example, I recently ran into a client who was annoyed at their development partners (to put it mildly) and basically pulled the plug on them. We ended up looking at the codebase to determine what it'd be to complete changes and rebuild. What I saw shocked me. The codebase was obviously done by amateurs masquerading as professional developers. The did exactly what I described above; took a RAD language (this case VB.NET with an ASP.NET project) and slapped together things. Its quite apparent that they had no understanding of the fundamentals of programming (even procedural).
The "Learn X in 21 Days" is a complete load of crock.
If you are stuck on "C" then use something simplier like Pascal and learn the fundamentals, and then switch to C and become familiar with its syntax and issues (i.e. no procedures in C). Then move onto C++ and learning OOP.
There may be no right choices, but there are bad choices. There is a reason that most advanced languages (C++ being one) are offered as higher level courses at most colleges (at least the good ones). They are not good introductory level languages. That being said any of the modern high level languages in general should suffice although try and avoid the niche ones or the 'flavor of the day' languages.
I would also say learning some assembly (or at least an Intermediate Language such as those in .NET or Java) would be benefitial too. It helps you understand, at a very low level, what the computer is really trying to accomplish. Its actually quite fun.
Only 100ks of code? Lightweight.
But yes, otherwise I would agree fully. Far cry from doing things in vi/emacs. Or even some of the original GUI compilers.
And you can do procedural programming in almost any language, C#, Java, Python, PHP, JavaScript, VBScript, etc.
Learning something about what a function is, what a procedure (or method) is, and when to use them are good starting points. Learning data structures (lists, linked lists, stacks, queues, trees, etc.) are another good exercise and is important when it comes down to manipulating data.
But one of the reasons that OOP came into being is almost any program boils down into data that has methods that act on that data. Classes are simply data with methods that act on them. There is not a huge jump between procedural to OOP (unlike say going from traditional OOP to doing IOC based OOP, etc). In fact the paradigms are usually taught in many data structure classes.
The real problem is not whether OOP is easy/hard, whether it should be learned before or after procedural, but rather that people do NOT how to design and structure programs. Or what data structures to use for different situations, or even what the hell a data structure is. And it can be quite apparent when looking at code.
What you should really not do is start with an RAD language and attempt to make programs that way. You won't learn anything of merit.
As an example, I recently ran into a client who was annoyed at their development partners (to put it mildly) and basically pulled the plug on them. We ended up looking at the codebase to determine what it'd be to complete changes and rebuild. What I saw shocked me. The codebase was obviously done by amateurs masquerading as professional developers. The did exactly what I described above; took a RAD language (this case VB.NET with an ASP.NET project) and slapped together things. Its quite apparent that they had no understanding of the fundamentals of programming (even procedural).
The "Learn X in 21 Days" is a complete load of crock.
If you are stuck on "C" then use something simplier like Pascal and learn the fundamentals, and then switch to C and become familiar with its syntax and issues (i.e. no procedures in C). Then move onto C++ and learning OOP.
There may be no right choices, but there are bad choices. There is a reason that most advanced languages (C++ being one) are offered as higher level courses at most colleges (at least the good ones). They are not good introductory level languages. That being said any of the modern high level languages in general should suffice although try and avoid the niche ones or the 'flavor of the day' languages.
I would also say learning some assembly (or at least an Intermediate Language such as those in .NET or Java) would be benefitial too. It helps you understand, at a very low level, what the computer is really trying to accomplish. Its actually quite fun.
Only 100ks of code? Lightweight.
But yes, otherwise I would agree fully. Far cry from doing things in vi/emacs. Or even some of the original GUI compilers.Well there is LOTA ( http://lfs-lota.net )... you're on the wrong side of the pond most likely for most of the Thurs. night stuff, but w do have the XRT Stock Car Cup on Sundays starting up soon and is a bit more accessible timewise those across the pond. Here's the info on it...
-------------------------
The XRT Stock Car Cup is an XRT-only stock-car type racing series consisting of 4 oval events and 4 road course events. Series features include the traditional stock car racing features such as Safety Car regulated starts/restarts, Safety Car periods, the "Lucky Dog" rule for lapped cars, and required pit stops. Three events on the Kyoto Ring Oval including the special knock-out formated All-Star Challenge, two oval events on custom courses at the AutoCross Arena, and three road course events highlight the eight event schedule. Colorful skins, exciting drafting battles, and close, hard racing make the XRT Stock Car Cup the definitive stock car racing series in LFS.
The typical race day schedule is this:
-------------------------
-------------------------
The XRT Stock Car Cup is an XRT-only stock-car type racing series consisting of 4 oval events and 4 road course events. Series features include the traditional stock car racing features such as Safety Car regulated starts/restarts, Safety Car periods, the "Lucky Dog" rule for lapped cars, and required pit stops. Three events on the Kyoto Ring Oval including the special knock-out formated All-Star Challenge, two oval events on custom courses at the AutoCross Arena, and three road course events highlight the eight event schedule. Colorful skins, exciting drafting battles, and close, hard racing make the XRT Stock Car Cup the definitive stock car racing series in LFS.
The typical race day schedule is this:
- 7:45 PM UTC (2:45 pm EST) - Drivers are encouraged to join and prepare. Officials set race conditions.
- 8:00 PM UTC (3:00 pm EST) - Qualifying starts
- 8:30 PM UTC (3:30 pm EST) - Heats/Feature starts (earliest time)
-------------------------
We use a hacked up forum but are moving to a custom website with an attached forum (SMF gah).
Of course.
.CSV format?! With text data? Mmms.... better not use any commas.
With RSS you could do put whatever you wanted in it. Now you might have to make changes to your software package to accomplish it or setup specific forum, news area, etc. but I would tend to think the less work on Victor to setup the better for automation.
Seriously, C++ isn't a great place to learn to program (especially just for fun or hobby). Check out the programmers forum.. there is quite a bit of discussion threads on how to learn to program.
Try C#, Java, Python, etc. Plenty of info on those, they are easier to chew than C++, have available IDEs, etc, etc.
Try C#, Java, Python, etc. Plenty of info on those, they are easier to chew than C++, have available IDEs, etc, etc.
Cool... I like it!
Too bad it brings back bad memories of Delphi and COM.
Too bad it brings back bad memories of Delphi and COM.
Comments on Psyinsim Tutorial...
I didn't want to pollute an otherwise excellent threads with some comments, so I put them out separately.
That's the point of APIs. Just like Pyinsim, it is to gloss over the minute details and allow you to do things without need to know those things.
The beauty of folks like sdether is that they donated such APIs in open source format. So you can go and study their code, see how it works, learn not only InSim but in a lot of cases some new tricks and even how things differ between C#, Java, Python, etc. when attempting to do the same things.
Take for example (I use sdether's because I use it). I original built one of the first C# APIs when Scawen first rolled out InSim (see those discussions concerning new packets way back when). I did it one way (i.e. avoiding events) and sdether did it another way (using events), but he did have a nice trick of marshalling the structures for the InSim packets. I hadn't originally thought of that and was a nice trick to have learned by reviewing the codebase.
No sense doing the exact same thing over again and again for each app. And there is a fine line. Do you have the time to invest? Do you need to learn or want to learn? Or do you just want to write your app?
But on the flip side, if you want to truly learn, yes you need to do it yourself from scratch. With InSim that means learning something about programming network connections (dealing with sockets, ports, packets, etc.) and translating the InSim packets from/to the raw bytes of the structures.
Thats always a valuable idea. I do this constantly... PHP apps, ASP.NET MVC based apps, Linq based apps, various Java based stuff. If new (or aspiring programmers) take one thing to heart in the well written tutorial, it is to strike out on your own and experiment. Even if you don't complete an full InSim API (or whatever else you research, i.e graphics engines, networking libraries, etc.) you at least learn something whether it be new techniques, APIs, etc.
Point blank, no. There are several misleading comments in this block that really set my teeth on edge.
The only thing closer to the underlying architecture of InSim would be a C or C++ library.
Python is NOT far better suited to writing InSim apps. It is only one of a multitude different ways of doing things. Is it better than C# or Java (which are based on the C paradigm)? Not in general no. Is it for someone who is proficient with Python? Sure. Can Python be easier to learn? Maybe, but in a lot of ways its no different than .NET or Java programming either (same imports, same try/catch/fetch, same define functionality [i.e. methods, functions, procedures]).
The fact that you sullied an otherwise good article with opinions/comments such as these is really quite unfortunate.
That's the point of APIs. Just like Pyinsim, it is to gloss over the minute details and allow you to do things without need to know those things.
The beauty of folks like sdether is that they donated such APIs in open source format. So you can go and study their code, see how it works, learn not only InSim but in a lot of cases some new tricks and even how things differ between C#, Java, Python, etc. when attempting to do the same things.
Take for example (I use sdether's because I use it). I original built one of the first C# APIs when Scawen first rolled out InSim (see those discussions concerning new packets way back when). I did it one way (i.e. avoiding events) and sdether did it another way (using events), but he did have a nice trick of marshalling the structures for the InSim packets. I hadn't originally thought of that and was a nice trick to have learned by reviewing the codebase.
No sense doing the exact same thing over again and again for each app. And there is a fine line. Do you have the time to invest? Do you need to learn or want to learn? Or do you just want to write your app?
But on the flip side, if you want to truly learn, yes you need to do it yourself from scratch. With InSim that means learning something about programming network connections (dealing with sockets, ports, packets, etc.) and translating the InSim packets from/to the raw bytes of the structures.
Thats always a valuable idea. I do this constantly... PHP apps, ASP.NET MVC based apps, Linq based apps, various Java based stuff. If new (or aspiring programmers) take one thing to heart in the well written tutorial, it is to strike out on your own and experiment. Even if you don't complete an full InSim API (or whatever else you research, i.e graphics engines, networking libraries, etc.) you at least learn something whether it be new techniques, APIs, etc.
Point blank, no. There are several misleading comments in this block that really set my teeth on edge.
The only thing closer to the underlying architecture of InSim would be a C or C++ library.
Python is NOT far better suited to writing InSim apps. It is only one of a multitude different ways of doing things. Is it better than C# or Java (which are based on the C paradigm)? Not in general no. Is it for someone who is proficient with Python? Sure. Can Python be easier to learn? Maybe, but in a lot of ways its no different than .NET or Java programming either (same imports, same try/catch/fetch, same define functionality [i.e. methods, functions, procedures]).
The fact that you sullied an otherwise good article with opinions/comments such as these is really quite unfortunate.
Very nicely put together article; I reserve comments elsewhere though.
Being able to either upload news via a REST url or have you read an RSS feed sounds like the best ideas to me.
I would also agree with Brilwing, that really a centralized site should concentrate on overall items (top level news) rather than more in-depth stuff.
If we take a look at LOTA (and CTRA I suppose is similiar in a way too) we have a variety of different series going on within the context of the LOTA web presense (i.e. Formula GP/GT Challenge, not to mention our mini-series, the series formerly known as StormCup, Monday Night Random Combo Cup, etc.). Trying to get present detailed information on everything going on in LOTA in a centralized site could be problematic.
As it stands we generally spit out the most important information into a main news channel which is RSS'd, but things could be modified to send news clips to LFS too.
Actually on this topic what I know us at LOTA would love is for LFS to spit out the race results in some type of XML format. Yes, we know about the stat InSim programs and have our own, but this would really be nice touch to LFS.
That's too much; especially with regard to points system.
We at LOTA just want verbose stats on the race (i.e. what the spit and lap times and speeds were for each racer, positions at each lap and split, overall time and speed, final position, start position, when people made pit stops and what they did, etc.). As mentioned before we do have this with some InSim apps, but there are some hiccups (like tracking speeds at lap/splits) so not hugely important, but would be a nice touch.
Once people have the stats output from the race (or maybe they are embedded in the replay... but that seems like a more bulky option) they can do whatever they want, generate whatever point scheme they want to use, etc.
There is a fine line between something like this not doing enough (i.e. only reporting start/finish positions or so forth) and too much (i.e. having a point system, scripting, etc).
I would also agree with Brilwing, that really a centralized site should concentrate on overall items (top level news) rather than more in-depth stuff.
If we take a look at LOTA (and CTRA I suppose is similiar in a way too) we have a variety of different series going on within the context of the LOTA web presense (i.e. Formula GP/GT Challenge, not to mention our mini-series, the series formerly known as StormCup, Monday Night Random Combo Cup, etc.). Trying to get present detailed information on everything going on in LOTA in a centralized site could be problematic.
As it stands we generally spit out the most important information into a main news channel which is RSS'd, but things could be modified to send news clips to LFS too.
Actually on this topic what I know us at LOTA would love is for LFS to spit out the race results in some type of XML format. Yes, we know about the stat InSim programs and have our own, but this would really be nice touch to LFS.
That's too much; especially with regard to points system.
We at LOTA just want verbose stats on the race (i.e. what the spit and lap times and speeds were for each racer, positions at each lap and split, overall time and speed, final position, start position, when people made pit stops and what they did, etc.). As mentioned before we do have this with some InSim apps, but there are some hiccups (like tracking speeds at lap/splits) so not hugely important, but would be a nice touch.
Once people have the stats output from the race (or maybe they are embedded in the replay... but that seems like a more bulky option) they can do whatever they want, generate whatever point scheme they want to use, etc.
There is a fine line between something like this not doing enough (i.e. only reporting start/finish positions or so forth) and too much (i.e. having a point system, scripting, etc).
Last edited by Hollywood, .
Not this B.S. again... be inclusive, not exclusive. Sim racing is about having fun. Not all leagues, series, etc. may require the use of real names. Not all leagues may be drop-dead serious. Give play to all types. Worried about unpronounceable names? Um, yeah, there are tons of real names that are tongue twisters too.
Yes,
Do not build as InSim library from scratch, especially if you have no network expertise, rather if you are using C# see the libraries and use sdether's excellent .NET InSim library.
Also you could look at Gai-Lauran(sp?)'s take over of the LFS stats InSim app and see what is going on in there for generating the stats.
But yes, it essentially means tracking the race start packet, saving off the starting positions, and then waiting til you get the race end packets. You can then compute your points or whatever you want to do, and then with LFS buttons write that out to the screen or whatever.
Do not build as InSim library from scratch, especially if you have no network expertise, rather if you are using C# see the libraries and use sdether's excellent .NET InSim library.
Also you could look at Gai-Lauran(sp?)'s take over of the LFS stats InSim app and see what is going on in there for generating the stats.
But yes, it essentially means tracking the race start packet, saving off the starting positions, and then waiting til you get the race end packets. You can then compute your points or whatever you want to do, and then with LFS buttons write that out to the screen or whatever.
Not really. I've been around this "game" (not LFS, but the racing sim world, plus others) for way too long. Some people are very generous (i.e. sdsether, etc. Scawen goes into this boat too) and let their hard work be used by others to create cool things with. Others aren't always a generous, and yes sometimes they prefer to work "undisturbed" (I don't disagree... I've got several InSim apps that will see the light of day at some point). However that being said, one too many utilities end up having the original developer fade away (boredom, lack of interest, other things, life, death, etc.) and that application becoming unusable to the community.
Thats not the point. The point is that if you are making something available to the community for the community's enjoyment, then you should be generous enough to be able to drop it out there. Sure there are a lot of people who just take and use (how many phpnuke were forked off the same codebase?!). But the utilities that are a) done in a more complete and robust fashion and b) provide more features/options are the ones that are generally going to be used by the community.
Personally I am of the opinion that if you are going to be generous then you should force others to be just as generous if they are using your generously open code (i.e. the GPL). Yes, there are lots of ramifications of this, but nonetheless, it helps keeps down the #s of just rip-offs because then the code is visible and people can tell. It also allows people to contribute back and make the original application (once its been released in a stable fashion) more robust, more options, etc.
Thats all concerning APIs and utilities. "Applications" such as say the CTRA server application/utilities or the "Cruise" server applications can be a completely different matter. You are essentially providing a service and you don't really need to release that, but if you end up deciding to stop, making it available to the community to pick up where you left off, etc. would always be a positive. In this case I'd want to personally make sure that someone couldn't "close the door" on worthwhile modifications which means leanings towards GPL license as opposed to MIT, Apache, etc.
Then there are utilities or applications that use exploits. Things like that have surfaced for a long time now (aim-bots in FPS game, the old 'color the track' in NROS, etc). Those things should be just kept closed. Make people spend the time themselves to exploit, etc.
Sure thats fine, until the next patch of LFS breaks it and you aren't anywhere around to "fix" it, or just don't want to "fix" it. Then effectively the time you spent developing something for other people's enjoyment has been wasted because its no longer a viable application.
Thats not the point. The point is that if you are making something available to the community for the community's enjoyment, then you should be generous enough to be able to drop it out there. Sure there are a lot of people who just take and use (how many phpnuke were forked off the same codebase?!). But the utilities that are a) done in a more complete and robust fashion and b) provide more features/options are the ones that are generally going to be used by the community.
Personally I am of the opinion that if you are going to be generous then you should force others to be just as generous if they are using your generously open code (i.e. the GPL). Yes, there are lots of ramifications of this, but nonetheless, it helps keeps down the #s of just rip-offs because then the code is visible and people can tell. It also allows people to contribute back and make the original application (once its been released in a stable fashion) more robust, more options, etc.
Thats all concerning APIs and utilities. "Applications" such as say the CTRA server application/utilities or the "Cruise" server applications can be a completely different matter. You are essentially providing a service and you don't really need to release that, but if you end up deciding to stop, making it available to the community to pick up where you left off, etc. would always be a positive. In this case I'd want to personally make sure that someone couldn't "close the door" on worthwhile modifications which means leanings towards GPL license as opposed to MIT, Apache, etc.
Then there are utilities or applications that use exploits. Things like that have surfaced for a long time now (aim-bots in FPS game, the old 'color the track' in NROS, etc). Those things should be just kept closed. Make people spend the time themselves to exploit, etc.
Sure thats fine, until the next patch of LFS breaks it and you aren't anywhere around to "fix" it, or just don't want to "fix" it. Then effectively the time you spent developing something for other people's enjoyment has been wasted because its no longer a viable application.
More replay suggestions...
When clicking on the 'view' icon, you would get a list of the available views and be able to select a view you want rather than toggling through them. Potentially more useful if there end up being more views, and/or custom views, in the future.
When clicking on the 'car' icon, you would get a list of the drivers currently in the race and select the driver you are intested in viewing, rather than having to toggle through them. This would be a nice boon to league/series officials when dealing with 30 drivers or so in a replay.
When clicking on the 'car' icon, you would get a list of the drivers currently in the race and select the driver you are intested in viewing, rather than having to toggle through them. This would be a nice boon to league/series officials when dealing with 30 drivers or so in a replay.
Ok, but what about the FXR and FZR?! Those cars look out of place now in comparison to the XRR!!!
YUP! The Summer Formula GP Challenge series starts next Thurs. for both the GP (i.e. F08s) and GP2 (F08s with 20% IR). We're holding another practice session tomorrow night.
Last edited by Hollywood, .
With most utilities for games, such as LFS, its usually better that the utilities remain OPEN and the source available so if the original author goes away someone else can pick up the reigns.
I suspect you would be best served by getting a licensing agreement with Scawen, etc.
It'd have to be a heck of a InSim app to want to pay money for it anyways.
I suspect you would be best served by getting a licensing agreement with Scawen, etc.
It'd have to be a heck of a InSim app to want to pay money for it anyways.
That is not quite true. Lots of people still use C/C++. Yes, most of the "professional" grade engines and APIs (network, physics, sound, graphics, etc.) still done in C/C++. There are plenty of indie level stuff going on with C/C++ and the open source world. In fact, most of the open source APIs (OGRE being one, Torque Network Library another, OpenAL, ODE, etc.) are all done in C/C++. There are some Java and C# (and other languages) wrappers. That is not likely to change any time soon as its its about as close as you are going to get to machine code with a high-level language.
That being said, its really dependent on your game. There are plenty of other choices (C#, Java) that can be used quite comfortably depending on your game choice. I know GarageGames is working on a game engine similar to their high-end Torque product using the XNA framework (it's called TorqueX), and for Java there are several graphics engines (jMonkey) comes to mind. Outside of graphical games, you could use Java (via JEE or even just JSP), PHP, ASP.NET (or hopefully soon the MVC for ASP.NET instead of the brain dead WebForms), to do web style games. Or there is Silverlight or Flash for more interactive "fun" (whatever that may be... I just generally call them "annoying") games.
And speaking of "hacks", heck building mods in some of the high-end FPS games (Unreal, HalfLife, Cyrsis, etc) can be a "fun" way of learning to program in maybe a more "exciting" venue... depends on your perspective of course.
That being said, its really dependent on your game. There are plenty of other choices (C#, Java) that can be used quite comfortably depending on your game choice. I know GarageGames is working on a game engine similar to their high-end Torque product using the XNA framework (it's called TorqueX), and for Java there are several graphics engines (jMonkey) comes to mind. Outside of graphical games, you could use Java (via JEE or even just JSP), PHP, ASP.NET (or hopefully soon the MVC for ASP.NET instead of the brain dead WebForms), to do web style games. Or there is Silverlight or Flash for more interactive "fun" (whatever that may be... I just generally call them "annoying") games.
And speaking of "hacks", heck building mods in some of the high-end FPS games (Unreal, HalfLife, Cyrsis, etc) can be a "fun" way of learning to program in maybe a more "exciting" venue... depends on your perspective of course.
Sure, I'm in... however 90 degree look is configurable as an option.
Ah, yes, had missed that... been a bit too buried in other work that I haven't paid as much attention to XNA as I'd like. I'm sure now on the GarageGames forums there is a huge clammer on when their TorqueX will support the XNA networking. 
XNA is the latest MANAGED wrapper to DirectX plus some for the .NET platform.
C++.NET is managed code, so it runs in the same sandbox as any other .NET language once its compiled. The main benefit to managed C++ is port C++ code for easier integration (instead of dealing with interops, etc.) with other managed code. Or you are a hard-core C++ developer who needs to write managed code apps.
C++.NET is managed code, so it runs in the same sandbox as any other .NET language once its compiled. The main benefit to managed C++ is port C++ code for easier integration (instead of dealing with interops, etc.) with other managed code. Or you are a hard-core C++ developer who needs to write managed code apps.
Again, that is incorrect Gai. C# has actually been used in a few published box games. It is also highly dependent, as I mentioned before, on the *type* of game. High-end, triple-AAA, twitch games, its probably not as good of fit. Indie twitch, role-playing, puzzle, etc. games its just as good if not better and probably more productive. Same goes for Java.
Not about that, its about distributing misunderstanding.
Not about that, its about distributing misunderstanding.
You could potentially explore the possibility of writing a log4net appender. Not sure how well it'd work because the appender wouldn't know which textbox, etc. I have an appender for MessageBox.
Probably the best way would be something akin to what LFSLib's author post http://www.claassen.net/geek/b ... net-scrollingtextbox.html
Or potentially this http://www.mail-archive.com/lo ... .apache.org/msg00461.html
Probably the best way would be something akin to what LFSLib's author post http://www.claassen.net/geek/b ... net-scrollingtextbox.html
Or potentially this http://www.mail-archive.com/lo ... .apache.org/msg00461.html
FGED GREDG RDFGDR GSFDG