I'm not even going to debate languages/VM/etc. merits because as sd points out it'd be a flame fest, and usually because people are misinformed.
Java/C#/etc. are OO, but you can do tons of procedural programming in them. And spaghetti code is completely possible (I've seen bizarre stuff in huge corporate systems that makes you shake your head). However, scripting languages are a bane because they are generally used incorrectly and they tend to make it very easy to end up with spaghetti code which ends up teaching only bad practices.
As far as languages, personally I think everyone should have to do some assembly (especially mainframe assembly), some Fortran, heck do some oddball stuff like learning Forth. Anything to stretch your mind and be able to look at programming problem solving in a different light. Be exclusionary (just as its bad for the LFS community) is bad because it doesn't allow you to approach problems with new, potentially innovative, manners.
Java/C#/etc. are OO, but you can do tons of procedural programming in them. And spaghetti code is completely possible (I've seen bizarre stuff in huge corporate systems that makes you shake your head). However, scripting languages are a bane because they are generally used incorrectly and they tend to make it very easy to end up with spaghetti code which ends up teaching only bad practices.
As far as languages, personally I think everyone should have to do some assembly (especially mainframe assembly), some Fortran, heck do some oddball stuff like learning Forth. Anything to stretch your mind and be able to look at programming problem solving in a different light. Be exclusionary (just as its bad for the LFS community) is bad because it doesn't allow you to approach problems with new, potentially innovative, manners.
You are right, I don't like exclusionary practices (and I don't mean race practices). The point was that licensing systems (and by no means am I pointing fingers at CTRA just in and of itself), tons of mods (re: rFactor), tends to divide the community up into insular pockets. Or let's take another case; drifting or drag racing. Most folks look down on drifting and dragging. I'm not a fan of the drifting myself, but as long as drifters aren't trying to drift on a race server and visa versa, they are positives to the community. Trying to exclude them in some ways is harmful. In regards to licensing, or at least creating "special servers" (whether licensing or other systems are involved), also decreases the number of good drivers out in the public domain that can help set good examples for newer drivers. Or even help them out (as long as requests are politely done).
As for your league, if um your drivers drivers need practice time without interruption, then the use of a private server is ideal.
I never said CTRA was a bad thing, all I am saying is the creating too many subdivions without the community based on exclusionary ideas is bad. Providing different ways of using LFS is good; such as the CTRA ladder (aka licensing) system, Cruise Servers, drifting servers and competitions, drag competitions, etc. All good.
P.S. Since you made the point to someone else about remembering the "old days", I was racing back before S1 days and got S1 on 05/30/2007. So I have been around for some time and seen LFS community ebb and flow.
As for your league, if um your drivers drivers need practice time without interruption, then the use of a private server is ideal.
I never said CTRA was a bad thing, all I am saying is the creating too many subdivions without the community based on exclusionary ideas is bad. Providing different ways of using LFS is good; such as the CTRA ladder (aka licensing) system, Cruise Servers, drifting servers and competitions, drag competitions, etc. All good.
P.S. Since you made the point to someone else about remembering the "old days", I was racing back before S1 days and got S1 on 05/30/2007. So I have been around for some time and seen LFS community ebb and flow.
I'll beg to differ. I'm not sure that it's done anymore or less than any other licensing or league system. Those that want to be clean will, those that don't... well nothing is going to persuade them otherwise. Are there those that eventually see the benefits to racing cleanly when presented with quality racing (or getting their knuckles cracked a few times via protests), absolutely. However, what I have seen is a new layer of stratification apart from track and car preference. Exclusionary practice is bad for the LFS online racing community.
Well that's going to be problem #1. If you expect to learn to do something, as fairly complex as computer programming (which in and of itself is not that complex next to say chemical engineering, medicine, etc.), and you aren't able/willing/etc. to do the legwork required to figure out where to look for information, or how to look for information, then it will cause you no limit to the amount of frustration.
So step one is really to learn how to learn.
Step two would be to learn the basics of programming design and not attempt to code up applications without knowing what you may or may not be doing. The reason a lot of software(especially the hobby stuff, but also commercial stuff too) sucks? Because things are hacked together and not thought through with good design philosophies employed. Lack of understanding about data structures, design patterns, etc. generally lead to poor execution, poor performance, issues with maintainability, etc.
Step three is to do a lot of problem solving. Outside of just the general basics of how to structure a program (which has nothing to do with languages or IDEs, etc.), programming is pretty much like everything else thats remotely scientific... it's about problem solving. Sure its grammar is less rigorous than say mathematical formulas, but if you can excel at geometry proofs or problem solving with algebra or calculus (I realize at 15 and change you wouldn't have been exposed to calculus yet, but the other two you should be), then you should have no problems with solving problems via programming.
The 8 queens or the traveling salesman problems are classic problems to be solved. If you can solve those, programmatically, while employing good design, use of data structures, and design practices you'll know you are on a track in your learning of "how to develop software".
No one ever was successful at learning by delegating responsibility
So step one is really to learn how to learn.
Step two would be to learn the basics of programming design and not attempt to code up applications without knowing what you may or may not be doing. The reason a lot of software(especially the hobby stuff, but also commercial stuff too) sucks? Because things are hacked together and not thought through with good design philosophies employed. Lack of understanding about data structures, design patterns, etc. generally lead to poor execution, poor performance, issues with maintainability, etc.
Step three is to do a lot of problem solving. Outside of just the general basics of how to structure a program (which has nothing to do with languages or IDEs, etc.), programming is pretty much like everything else thats remotely scientific... it's about problem solving. Sure its grammar is less rigorous than say mathematical formulas, but if you can excel at geometry proofs or problem solving with algebra or calculus (I realize at 15 and change you wouldn't have been exposed to calculus yet, but the other two you should be), then you should have no problems with solving problems via programming.
The 8 queens or the traveling salesman problems are classic problems to be solved. If you can solve those, programmatically, while employing good design, use of data structures, and design practices you'll know you are on a track in your learning of "how to develop software".
No one ever was successful at learning by delegating responsibility
Yes, its called the pick-up race mentality. And its concetrated on those servers because as someone mentioned its usually a lot of the newer drivers (and drivers who don't bother to race on CTRA servers except every blue moon). In a way it's good, because maybe it'll draw more of the problem folks to those lower CTRA server and leave cleaner pick-up racing elsewhere. It's bad because it frustrates people who are attempting to legitimately move their way up the CTRA ladder system. And of course it has its downside in the segregation of the community.
Hehehe, a bit of tongue-n-cheek in my post there. 
That's why a couple of Western Hemisphere teams banded together and started LOTA. That and a distinct lack of league based racing available in our time "window" in the new world. Doesn't matter how slow or fast you are, as long as you can demonstrate that you, as a new world driver, have good car control and have some race craft, you are more than welcome to participate. There are about 50 drivers signed up for the Grand Touring Cup with a variety of experience and speed throughout the ranks; all are welcome and all are treated as equals.
Even then, the cream still rises to the top. I believe it was Peter Windsor who mentioned, on an F1 broadcast a couple years ago, that teams generally expect an F1 driver to be able to be up to speed in about 5 to 10 laps.
But anyways, there are those guys (and gals) who just have that gift of figuring out the right line and lack of practice IMO, and I'm one who takes lots of laps to get ahold of nuisances in a track, isn't that much of an equalizer as it might initially appear to be.
It's one reason we don't limit practice (not that we could mind you) in the LOTA premier series... usually the fast guys get smaller increments of improvements even with lots of practice, where those, like myself, often can make much larger improvements.
But anyways, there are those guys (and gals) who just have that gift of figuring out the right line and lack of practice IMO, and I'm one who takes lots of laps to get ahold of nuisances in a track, isn't that much of an equalizer as it might initially appear to be.
It's one reason we don't limit practice (not that we could mind you) in the LOTA premier series... usually the fast guys get smaller increments of improvements even with lots of practice, where those, like myself, often can make much larger improvements.
Not really. Scawen's a smart cookie; he's probably got a really nice codebase with good code seperation. Unlike some of the "dire pronouncements" made, its not a case of a complete code rewrite, but multithreaded applications (doesn't matter if its even one processor) does have additional considerations that take more work to support and then to rigorously test.
Most games tend to work on a single game loop that listens and processes OS messages, rendering the current graphics frame, does physics and AI calcuations, polls network, and polls controllers (not necessarily in that order). In fact the min. sleep in the LFS options is probably inside the game loop; essentially it means that the current thread (i.e. the LFS app) does not use up any processor time slices for X amout of time which allows other applications, the OS, etc. to process messages, etc. Anyways, a decent, high-level overview (with code) of a game loop can be found http://www.mvps.org/directx/ar ... writing_the_game_loop.htm. And in LFS case, you are also dealing with a constant rate physics heartbeat which adds a bit of a wrinkle to the game loop.
Back to the topic of multi-threaded support in games, here's a quote snippet from Tim Sweeny (of Unreal fame; he and John Carmack are very good at what they do... plenty of others could be mentioned in the same breath too) has to say:
If Epic Games finds this difficult, and they have a very good and large staff, hopefully it impresses on folks the non-trivial nature of the task with Scawen being pretty much the sole programmer on the LFS codebase.
Here's another article http://www.gamasutra.com/featu ... 060906/monkkonen_01.shtml that's a good discussion on the pro's and con's of several different types of multi-threaded approaches with regards to games (and actually any type of interactive application).
Most games tend to work on a single game loop that listens and processes OS messages, rendering the current graphics frame, does physics and AI calcuations, polls network, and polls controllers (not necessarily in that order). In fact the min. sleep in the LFS options is probably inside the game loop; essentially it means that the current thread (i.e. the LFS app) does not use up any processor time slices for X amout of time which allows other applications, the OS, etc. to process messages, etc. Anyways, a decent, high-level overview (with code) of a game loop can be found http://www.mvps.org/directx/ar ... writing_the_game_loop.htm. And in LFS case, you are also dealing with a constant rate physics heartbeat which adds a bit of a wrinkle to the game loop.
Back to the topic of multi-threaded support in games, here's a quote snippet from Tim Sweeny (of Unreal fame; he and John Carmack are very good at what they do... plenty of others could be mentioned in the same breath too) has to say:
If Epic Games finds this difficult, and they have a very good and large staff, hopefully it impresses on folks the non-trivial nature of the task with Scawen being pretty much the sole programmer on the LFS codebase.
Here's another article http://www.gamasutra.com/featu ... 060906/monkkonen_01.shtml that's a good discussion on the pro's and con's of several different types of multi-threaded approaches with regards to games (and actually any type of interactive application).
Great! Then do it yourself, if its not so difficult.
Sure, I'll be willing to do it. Here's some standard boilerplate for you to consider.
We estimate that our solution approach would take 650 man hours to implement. We are quoting a blended billing rate of $300.00 per hour for this project. Our total professional services quotation is $195,000.00 on a time and materials basis. We do not expect to incur any travel related expenses.
Since the detailed functional requirements have not been defined, we would prefer to work on a time and materials basis to implement the project. We have found that our clients achieve the best value through this approach since they have some control over the ultimate cost of the solution.
However, we are able and willing to provide a fixed-bid quotation for professional services for this project. Our fixed-bid quotation would be $225,000.00, with 50% paid at the start of the project, 10% to be paid upon completion of all project deliverables, and the remaining 40% to be paid upon the completion of interim project deliverables. The specific details of what deliverables would be tied to the payments of interim deliverables will be determined at the time the contract is signed.
We estimate that our solution approach would take 650 man hours to implement. We are quoting a blended billing rate of $300.00 per hour for this project. Our total professional services quotation is $195,000.00 on a time and materials basis. We do not expect to incur any travel related expenses.
Since the detailed functional requirements have not been defined, we would prefer to work on a time and materials basis to implement the project. We have found that our clients achieve the best value through this approach since they have some control over the ultimate cost of the solution.
However, we are able and willing to provide a fixed-bid quotation for professional services for this project. Our fixed-bid quotation would be $225,000.00, with 50% paid at the start of the project, 10% to be paid upon completion of all project deliverables, and the remaining 40% to be paid upon the completion of interim project deliverables. The specific details of what deliverables would be tied to the payments of interim deliverables will be determined at the time the contract is signed.
Last edited by Hollywood, .
Could be simply that no one is interested.
Yes, it'd be nice to have the forum moderated to get rid of the nonsense posts that are just requests, combine "how to program" topics into one, mark the "how to program" as sticky, etc.
Yes. Here is my advice:
Go to school and take classes in computer programming. School could be a brick-and-mortar or it could be online; there are plenty of options available.
Go to school and take classes in computer programming. School could be a brick-and-mortar or it could be online; there are plenty of options available.
Yes, you can do speedtraps in InSim. Examining the MCI packet is necessary to do that, but only the MCI packet for the split nodes and starting line node.
If you are running your InSim app locally, no it won't mess up server based InSim apps. The only issue might be button placement.
My suggestion would be either use the LFSLib for .NET or the Java InSim library. .NET is a pretty easy in that you can download a free development studio (VB or C#) from MS and are pretty much ready to start in on things. The author of LFSLib has also posted some simple examples on his blog website to help start you out.
Java its pretty much the same with Eclipse, but Eclipse might not be quite as "user friendly" for newbies.
You could also try playing with luaLFS too. Those are probably the most up-to-date libraries for LFS.
If you are running your InSim app locally, no it won't mess up server based InSim apps. The only issue might be button placement.
My suggestion would be either use the LFSLib for .NET or the Java InSim library. .NET is a pretty easy in that you can download a free development studio (VB or C#) from MS and are pretty much ready to start in on things. The author of LFSLib has also posted some simple examples on his blog website to help start you out.
Java its pretty much the same with Eclipse, but Eclipse might not be quite as "user friendly" for newbies.
You could also try playing with luaLFS too. Those are probably the most up-to-date libraries for LFS.
It may not have been updated for the InSim changes in patch X.
As a note; the old Papyrus games you couldn't edit tracks (or create new tracks either). However, some really dedicated folks figured out the various formats, and created their own track editor. While that was happening, others were creating new tracks for the older Papy sims and definetly a slew for GPL.
Anything is possible. However, it may need to be something that is discussed, etc. outside of these forums.
Anything is possible. However, it may need to be something that is discussed, etc. outside of these forums.
School. We've talked about this in another thread.
Yes, thats what I said. You also get one when you leave the pits/garage.
Yes, I noticed. I wasn't really asking for help, I was making a note that the PLP packet was not being sent when someone enters the pits/garage while the game is at the multiplayer lobby screen. This is the issue.
Uh, you know that LFSLib, which is a .NET LFS library, has been around for quite some time? 
Hate to see duplicated work (unless of course for learning purposes).
Hate to see duplicated work (unless of course for learning purposes).If you are spectated you do not have a player, so that makes sense. However, once you join (whether or not you are in the lobby or not) you have a player id. Therefore not getting the IS_NLP is a bug especially since when you do leave the pits/garage you get the IS_NPL packet (with of course the same player id).
ISS_FRONT_END is the main screen of the game, not the multiplayer lobby screen. It'd be nice if the status had a bool on it that let you know you were in the lobby screen.
And no, that doesn't work. Because the lobby screen is really when I want the scripts running so that when a player joins they get car and handicapped checked. That way when everyone is ready and the race starts, we know that everyone is in the right car with the right handicaps.
ISS_FRONT_END is the main screen of the game, not the multiplayer lobby screen. It'd be nice if the status had a bool on it that let you know you were in the lobby screen.
And no, that doesn't work. Because the lobby screen is really when I want the scripts running so that when a player joins they get car and handicapped checked. That way when everyone is ready and the race starts, we know that everyone is in the right car with the right handicaps.
No nikka, it can't.
Not having a PLP packet in the lobby screen is a InSim bug, period. All other connection packets, i.e. connection enter/leave, player enter/leave work as expected. The IS_PLP does not, therefore it is a bug.
Not having a PLP packet in the lobby screen is a InSim bug, period. All other connection packets, i.e. connection enter/leave, player enter/leave work as expected. The IS_PLP does not, therefore it is a bug.
Because I don't want the script running while they are in the pits/garage menu... simple enough.
The NPL does not get fired until they leave the garage so that does not do any good as far as stopping scripts. Its the event that is used to start the scripts up.
And GeForz, it does not matter if they are driving or not; they still entered the pits/garage menu.
The NPL does not get fired until they leave the garage so that does not do any good as far as stopping scripts. Its the event that is used to start the scripts up.
And GeForz, it does not matter if they are driving or not; they still entered the pits/garage menu.
FGED GREDG RDFGDR GSFDG