I know this is kind of off-topic, but as i watch this thread grow, I'm wondering if the whole script effort might not be better served by moving the external control subsystem into a DLL. I.e. take the existing commands and the existing abilities of insim and expose them to a DLL that happens to also implement the Insim code.
Once all the control and monitoring systems are exposed in this DLL, people can either use Insim to control LFS, or another DLL implementing the same signature can replace the Insim DLL and provide the control mechanism. At that point the community could build a DLL that embeds any of free scripting languages and exposes the control and monitoring methods.
Scawen, I don't know what the exact motivation for the scripting system is, but it seems like at least a partial duplication of what's possible via insim. And writing a scripting language these days seems to be better addressed by adopting one that exists.
I'm not trying to criticize the effort, just thinking there might be a more efficient path that has bigger pay-offs for everyone down the line.
Once all the control and monitoring systems are exposed in this DLL, people can either use Insim to control LFS, or another DLL implementing the same signature can replace the Insim DLL and provide the control mechanism. At that point the community could build a DLL that embeds any of free scripting languages and exposes the control and monitoring methods.
Scawen, I don't know what the exact motivation for the scripting system is, but it seems like at least a partial duplication of what's possible via insim. And writing a scripting language these days seems to be better addressed by adopting one that exists.
I'm not trying to criticize the effort, just thinking there might be a more efficient path that has bigger pay-offs for everyone down the line.
I like the idea of being able to tweak cars via these simple scripts. Makes a lot of sense and it's more flexible than having per car configs for the controls.
The one thing I would like to request that if there are new events created that are used to trigger the scripts, can the events also be sent to insim, so that insim could be used for these things as well? And will /echo make it out to insim?
Kegetys:
While having a built in scripting language in LFS would be cool, I think that could be more efficiently addressed by the community in creating an insim program that embeds python, lua or something similar. It would just pass the events onto the scripting engine and expos the lfs commands that can be issued as native scripting commands.
The one thing I would like to request that if there are new events created that are used to trigger the scripts, can the events also be sent to insim, so that insim could be used for these things as well? And will /echo make it out to insim?
Kegetys:
While having a built in scripting language in LFS would be cool, I think that could be more efficiently addressed by the community in creating an insim program that embeds python, lua or something similar. It would just pass the events onto the scripting engine and expos the lfs commands that can be issued as native scripting commands.
Wow, that's a well worn groove you've got on Kyoto.
It's definitely more tiring than doing it on the PC. The pedals are stiffer, everything moves, so you have to maintain a good grip on the wheel lest you let the g-forces affect your steering and it does rattle you around a good bit. But it's also so much more satisfying. I did 20 laps in the FZR on Kyoto National the other day to test out some new parts of our management systems and it was great.
I've been online once or twice, but mostly we do internal testing, so we're using our two machines and the AI. Since I only have two buttons, no keyboard, mouse, etc, within reach, it's hard to properly participate in an online race. If i want to vote 'start race' and I don't have someone at the office do it, chances are, my car will be dead on the grid with me voting, then trying to get back in and set up.
Well, beyond a public standard and independent implementations of a language, I can't help you any more to believe in it. You may not believe it, but it is an open standard, what MS decides to do with it in the future notwithstanding.
We rent a truck with a rail lift when we do events. Each 301 always stays fully assembled and weighs about 800lbs. We have a special palette jack to move them around. It still is a bit scary getting it on the lift, since it just fits.
You're looking at $35k+ by the time you have one sitting in your--err... where you can manage to fit one. They're a bit cumbersome to put places
I started Full Motion Racing. What we're doing is building a racing simulation center business. We are using Live For Speed and the Force Dynamics 301 as our platform. For the time being, we're localized to San Diego, CA only. We're still in our development phase, and so we've set up the site mostly for people who have seen our demos locally. We've tried not get the hype going too early, hence no plugs for it with the LFS community so far.
We don't have a facility open yet, but are just doing a couple of events here and there to get feedback from people. We're doing this mostly so that we have it properly dialed in by the time we open the doors to the general public. You can find details on past and upcoming events at http://www.fullmotionracing.com/Events.aspx
I can say with some conviction that the LFS/301 combination is an incredible combination. I prefer it to taking my car to autocross or the track at this time.
Just to avoid any rumors starting, the devs are aware of what we are doing. And yes, the rally crash did shake me about quite nicely, no less than i deserved.
We don't have a facility open yet, but are just doing a couple of events here and there to get feedback from people. We're doing this mostly so that we have it properly dialed in by the time we open the doors to the general public. You can find details on past and upcoming events at http://www.fullmotionracing.com/Events.aspx
I can say with some conviction that the LFS/301 combination is an incredible combination. I prefer it to taking my car to autocross or the track at this time.
Just to avoid any rumors starting, the devs are aware of what we are doing. And yes, the rally crash did shake me about quite nicely, no less than i deserved.
Last edited by sdether, .
Considering LFS is still very much under development and likely to get an engine change (DX9 or 10) before S3 is done, my bet is that they don't want to have to deal with dealing with incompatibilities they will create in the process. I mean, most of the file formats have changed in some way with every release, so releasing tools that writes things like maps just means they'll be breaking those tools constantly and instead of just supporting Eric in the changes having to support an entire community. Plus there's the complications on how to handle it in LFSW.
Of course, they might just keep it closed to keep quality control in place. But I hope that's not the case. If you look at most of the shooters, the good content has a habit of bubbling to the top.
Neither one will. The first because it doesn't have an entrance into the pits and the second because it has neither entrance nor exit. Both could be alleviated with alternate entrance/exit, kind of like the main pit is handled in some South City combos.
Really, I want a track that gets access to the straight from the second pit all the way to the back 180. But there is no config that would allow that and give access to either pits.
I really like long tracks, but that's because I'd rather be out on open roads than a track. But I agree that shorter combos are best for races. The shorter the laptime the more you are likely to get into overtaking and such. The one thing that would be useful would be some more tracks that are both short but still have fast sections.
Idle thoughts about Aston
I love any version of Aston that includes the Eau Rougeish Hill, so looking at the track, i came up with two configs that I'd love to try. Both have a good dose of fast and technical sections. Of course, neither is possible because of pit locations. Oh well.
The first one is Cadet Sprint. Basically Cadet with the long sweeper added to the mix.
The second is Cadet National. This one skips the switchback for a sweeping straight all the way to to the back. This one i especially like because it opens up that back stretch in a way unavailable in any other combo.
The first one is Cadet Sprint. Basically Cadet with the long sweeper added to the mix.
The second is Cadet National. This one skips the switchback for a sweeping straight all the way to to the back. This one i especially like because it opens up that back stretch in a way unavailable in any other combo.
Then maybe you should do your research first. Have you seen mono? C# is goverened by ECMA, as is the CLR. Sure MS can (and will) fork, but there is a open standard for the language and runtime, which is more than can be said for Java.
And while talking standards, most of the open source languages aren't goverend by any standards either. Generally they're each goverened by a benevolent cabal and you are free to fork if you don't like it.
Wow, can't get any more clear in throwing out a challenge for the never-ending and never to be resolved "language wars". I'll just say that disagree with you almost fundamentally.
EDIT: I should have some on-topic content...
Java is easy once you get your mind around OO principles. It's got a bit more base knowledge that you need to get under your belt before jumping in than your average scripting or procedural language. If you don't like the OO paradigm, you'll hate java and you'll find it annoying to program.
Last edited by sdether, .
I agree with everything you say, but doubt the last will come to pass. The issue being that until you reg, the content is encrypoted, or at least otherwise not accessible. That's why demo racers can't watch replays of races with cars and tracks they don't have (ok, i admit, i don't know for sure this is true.. is it?)
The question with the data stream is, how active a role does a "spectate" client have in the server communication. If it's simply listening, then you could set up a proxy that multi-plexes the spectate packets to any number of listeners, a la HLTV.
If the spectate client still has to do a lot of handshaking, but that handshaking is deterministic (i.e. it's the same each time), the proxy connects with its first client and it's all that the server really sees and voila you get your handshaking. All clients beyond that would connect to the proxy, and get the duplicate server data stream, but their responses would be thrown away, since they'd be the same as the responses from the initial client that's really talking to the server.
If the chatter is non-deterministic, then we're probably screwed and only dev involvement (by either creating the proxy or changing the spectate data stream) could help.
In the end, i think that LFS TV needs to be in-simulator, not a video feed, but I think that's generally agreed on anyhow.
If the spectate client still has to do a lot of handshaking, but that handshaking is deterministic (i.e. it's the same each time), the proxy connects with its first client and it's all that the server really sees and voila you get your handshaking. All clients beyond that would connect to the proxy, and get the duplicate server data stream, but their responses would be thrown away, since they'd be the same as the responses from the initial client that's really talking to the server.
If the chatter is non-deterministic, then we're probably screwed and only dev involvement (by either creating the proxy or changing the spectate data stream) could help.
In the end, i think that LFS TV needs to be in-simulator, not a video feed, but I think that's generally agreed on anyhow.
Determining Qualifying time
Maybe I'm just not looking at the right packets, but i can't seem to find any way via insim to determine how much time is left in a qualifying session or even if qualifying is over. My best hope was that IS_RES TotalTime would do it, but it seems to be 0 all the way through qualifying.
Right now the only thing i can think off is catch the IS_RST and then count down time from QualMins. Obviously that's not ideal.
Right now the only thing i can think off is catch the IS_RST and then count down time from QualMins. Obviously that's not ideal.
Can't say I do. I've seen Visual Studio get very hungry in debug mode, but haven't had it happen with the Library tester. I can see it happening if you are limited in RAM. Mind you, the Tester is by no means a best practices approach to writing Windows Forms. Best suggestion I have is try out the lib in a console application and see if the same happens. I certainly wouldn't build your own application based on the GUI code in the Tester, it's just a harness that was thrown together with total disregard for design.
Basically that means something else is already bound to that port. I know I had some trouble on one of my machines that if the Tester didn't shut down properly, it wouldn't release the port. See if the problem continues if you reboot. And make sure you don't have your LFS insim bound to 30003 as well.
The OutSim and OutGauge testers are both meant for standalone mode. I think port 30002 and 30003 respectively, using 127.0.0.1 as IP.
That rocks. How much do those screens run and are they simple RS-232 connectors or do you have to build a board to connect the display?
Also, did you build the LED rev indicator yourself or where did you find that board?
I suggest you take a look at www.mono-project.com before you reject C# for non-portable and MS evilness. My lib runs great under RedHat and Mac OS X using mono.
Of course your first reason is perfectly valid, so good luck with java. Building a lib for insim in java would be something useful to the community, since there are plenty of people using it. And surely there'd be more if someone went through the exercise of wrapping insim with a lib for java.
Not wanting to start a language preference war, but any reason you can't do it in .NET or mono? If you know java, C# isn't much of a stretch. As for porting my lib to java, a lot of things would probably port over fairly simply, but i do use properties, events/delegates and structs a lot, which are fairly .NET specific in syntax.
What about handicaps? I know this would completely screw World stats and maybe this would only work for servers not reporting stats, but if you want "realism" than handicaps is how all the governing bodies handle class differences. Cars in the real world classes aren't the same, and that's realism, but in order to have racing that's even handed (and yeah, commercially viable), rules are set to undo any particular advantages one manufacturer eeks out of the specs.
If a server could dial in weight additions and in-take restrictors, servers could even out classes per track per race. Otherwise you'll never get "even" cars. Because what makes one car have the advantage on one track is it's handicap on another.
If a server could dial in weight additions and in-take restrictors, servers could even out classes per track per race. Otherwise you'll never get "even" cars. Because what makes one car have the advantage on one track is it's handicap on another.
http://www.claassen.net/geek/lfs/doc-0.11b.zip
I've also linked it on the project page and will keep having a download of the current version from now on
I've also linked it on the project page and will keep having a download of the current version from now on
FGED GREDG RDFGDR GSFDG