It's interesting to play with at any rate. The code for the RaceEventClient in 0.2 is brand new and I've already found a number of bugs in it. I'm using it for a JInSim based add-on I'm toying around with, so I should shake out the obvious bugs pretty quickly. I'll be making a 0.3 release relatively soon. If I find out that any bugs are holding someone up I'll release more often.
I've tried to include plenty of documentation so that even Java beginners can get some use out of it. It's a lot easier to learn something when you're using it for something else you're interested in.
As always, let me know if you're stuck and I can point you in the right direction.
You're always using $Podium[0], $Podium[1] and $Podium[2] but you're assigning past that since $ii increments without bound. Since you're the first person whose stats are read, everyone ends up getting your stats.
OK, I guess it does work. I wonder what I was doing before. If I run across it again and it doesn't seem right I'll say something 
. It eliminates the need for those helper methods, anyway. Bear with me as I ask a few stupid questions
. It eliminates the need for those helper methods, anyway. Bear with me as I ask a few stupid questions Are you certain? If I send an MST packet with the string "^1red^0black", I get "^^1red^^0black". So, the carets are escaped by LFS when they're sent. There is no way to send control character literals through the MST packet that I can see.
--
Rob
Looking at it again, I should've been more precise.
In JInSim, I've created a helper class that helps an add-on creator do common things easily. One that I've implemented is the ability to send a multi-colored message. There are some interesting issues related to which type of LFS application you're connected to, but that's for a future thread The multi-colored message is send as a String with escape sequences to change colors. I've just used a caret (^) and the number that corresponds to the color when you're typing it in. So for instance:
helper.sendMultiColoredMessage("^1Red and ^4Blue");
will send the message "Red and Blue" where "Red and" will be red and "Blue" will be blue. You get the picture.
To implement this, I iterate through the String character by character and test for the escape sequences, then send the appropriate character out using the "SCH" type packets.
In my test program, I send out an MST packet, then the SCH packets in quick succession. The SCH packets don't get sent correctly unless I have a 500ms delay before I start sending them. There are some other technicalities, but that's the gist of it. Victor, I think what you've said fits my scenario. The MST and SCH packets I send are all done through the "talk" interface of the client. In other words, before I start sending the messages, I send an SCH packet that types the letter "T" beforehand.
--
Rob
In JInSim, I've created a helper class that helps an add-on creator do common things easily. One that I've implemented is the ability to send a multi-colored message. There are some interesting issues related to which type of LFS application you're connected to, but that's for a future thread
The multi-colored message is send as a String with escape sequences to change colors. I've just used a caret (^) and the number that corresponds to the color when you're typing it in. So for instance:helper.sendMultiColoredMessage("^1Red and ^4Blue");
will send the message "Red and Blue" where "Red and" will be red and "Blue" will be blue. You get the picture.
To implement this, I iterate through the String character by character and test for the escape sequences, then send the appropriate character out using the "SCH" type packets.
In my test program, I send out an MST packet, then the SCH packets in quick succession. The SCH packets don't get sent correctly unless I have a 500ms delay before I start sending them. There are some other technicalities, but that's the gist of it. Victor, I think what you've said fits my scenario. The MST and SCH packets I send are all done through the "talk" interface of the client. In other words, before I start sending the messages, I send an SCH packet that types the letter "T" beforehand.
--
Rob
Message packet throttle?
In one of my tests, I send a couple messages in quick succession. The second message wasn't making it through correctly until I waited about 500ms between messages. Is there a message throttle to prevent message floods?
--
Rob
The Java InSim library (JInSim)
http://jinsim.sourceforge.net
--
Rob
The Java InSim library (JInSim)
http://jinsim.sourceforge.net
JInSim v0.2 released
The Java InSim library v0.2 has been released.
See http://jinsim.sourceforge.net
v0.2 includes:
Rob
The Java InSim library (JInSim)
http://jinsim.sourceforge.net
See http://jinsim.sourceforge.net
v0.2 includes:
- org.kerf.jinsim.RaceEventClient is a class that gathers interesting race events as they happen. Extending this class will allow you to easily reaspond to certain race events easily. Currently it will tell you when a car is losing control and may be crashing (or drifting?), and also reports on the closest current race between two cars.
- org.kerf.jinsim.InSimHelper is a new helper class that is a handy place to look for commonly needed tasks. There are plans for a number of new methods. Right now you can get a taste for what will go in there. A lot of the requests will have an easy to use helper so you don't have to create them and send them. There is a "sendColoredMessage()" helper right now that makes it much easier to send a message in any color you'd like. Eventually there will be a "sendMultiColoredMessage()" helper that will allow you to mix colors within a message easily.
- New example: A working speedometer. This example shows how you might use OutGauge data to drive an external GUI (or real gauges?)
- Some of the code has been improved for performance. Particularly when creating OutSim and OutGauge packets, since the information contained in them is only accurate for a short amount of time.
- More javadoc was added and will continue to be added.
Rob
The Java InSim library (JInSim)
http://jinsim.sourceforge.net
Uh...yeah...those...
I can't see anything in the code you've shown us. It sure looks like a spurious message is being sent after the "ISC" packet though.
--
Rob
What do your InSimInit and InSimPack classes look like?
--
Rob
--
Rob
1. Make sure you have java installed. You can download a JDK from http://java.sun.com if you don't. If you can type "java -version" at a command line and get version information, you're on your way.
2. Download JInSim from SourceForge. Go to http://sourceforge.net/projects/jinsim/ and click the big green Download button to download the zip file. The current one is jinsim-0.1.zip
3. Unzip jinsim-0.1.zip somewhere on your hard drive that's handy.
4. Look at the README file inside the newly unzipped directory. There's some information there on how to run the "Hello World!" example. Once you have that working, you're well on your way.
To start off with, you may just want to edit simple java files with your favorite text editor, figure out how to compile them with javac and run them. Once you're comfortable with that, you can download one of the freely available Java IDEs like Eclipse or NetBeans. I use Eclipse, because that's what I use at work. I actually prefer IntelliJ, but that's a (spendy) commercial package. If you have any questions, let me know.
--
Rob
2. Download JInSim from SourceForge. Go to http://sourceforge.net/projects/jinsim/ and click the big green Download button to download the zip file. The current one is jinsim-0.1.zip
3. Unzip jinsim-0.1.zip somewhere on your hard drive that's handy.
4. Look at the README file inside the newly unzipped directory. There's some information there on how to run the "Hello World!" example. Once you have that working, you're well on your way.
To start off with, you may just want to edit simple java files with your favorite text editor, figure out how to compile them with javac and run them. Once you're comfortable with that, you can download one of the freely available Java IDEs like Eclipse or NetBeans. I use Eclipse, because that's what I use at work. I actually prefer IntelliJ, but that's a (spendy) commercial package. If you have any questions, let me know.
--
Rob
Java - JInSim - a Java InSim library
JInSim is an easy to use Java library for communicating with InSim, OutSim and OutGauge. It's currently in pre-alpha form, but I've created a few small examples that work correctly to get you started. The examples are well commented and straightforward, so if you have any Java knowledge at all, you should be able to understand them and move on to creating your own clients.
Right now, the core communication with InSim is done and I'm starting to create specialized classes for common use scenarios. The first one is a "RaceEventClient" that will notify you about crashes in progress and the closest race on the track. What I really would like is some feedback from people who are interested in using a library like this.
I've created a SourceForge project where you can get the code through anonymous CVS. If you aren't familiar with CVS and want JInSim, let me know. You can find the project at http://jinsim.sourceforge.net
Thanks,
--
Rob
Right now, the core communication with InSim is done and I'm starting to create specialized classes for common use scenarios. The first one is a "RaceEventClient" that will notify you about crashes in progress and the closest race on the track. What I really would like is some feedback from people who are interested in using a library like this.
I've created a SourceForge project where you can get the code through anonymous CVS. If you aren't familiar with CVS and want JInSim, let me know. You can find the project at http://jinsim.sourceforge.net
Thanks,
--
Rob
You two were, of course, correct. I had a bug. You gotta admit, it would've been a great improvement suggestion if it wasn't already there, though! 
--
Rob
--
Rob
AI info in InSim race tracking packets
I should start off with a "thank you!" to the devs for including anything like InSim/OutSim/OutGauge. On to my request...
Right now, it looks like information about AI drivers in the race tracking packets for InSim is limited to the NPL and RES packets. I'd like to see AI reported more consistently. I'd especially like to see them included in the NLP/MCI packets that are sent.
--
Rob
Right now, it looks like information about AI drivers in the race tracking packets for InSim is limited to the NPL and RES packets. I'd like to see AI reported more consistently. I'd especially like to see them included in the NLP/MCI packets that are sent.
--
Rob
I think this request just deals with fullscreen mode, where "height" and "width" are really the display resolution unless you set them both to "0". Then it puts LFS in windowed mode, but doesn't give you control over window bounds or placement.
--
Rob
OK, I've answered my own question; yes InSim, OutSim and OutGuage all send from different ports. So, I got it working for all the above
The results are encouraging too. With OutSim or OutGuage packets coming every 100ms, and a text representation of them being printed to stdout, I'm seeing a small ding in my fps. If I redirect stdout to /dev/null, I'm hardly seeing a dip at all.
I now have the beginnings of a simple to use library that allows you to register for notification of any Insim, OutSim or OutGuage packet. It also allows you send any of the InSim request packets to the server. I've only written tests for part of the library, so haven't verified all of my packet parsing, but so far it looks pretty good. Here's an example of a simple program that requests the version from the server and prints out the response when it gets it:
The code is similar for any InSim packet, just register for notification then send the request and handle it in the InSimListener implementation. All of the Initialization, ACKs and networking is taken care of for you. Let me know if you're interested in trying it out.
--
Rob
The results are encouraging too. With OutSim or OutGuage packets coming every 100ms, and a text representation of them being printed to stdout, I'm seeing a small ding in my fps. If I redirect stdout to /dev/null, I'm hardly seeing a dip at all.
I now have the beginnings of a simple to use library that allows you to register for notification of any Insim, OutSim or OutGuage packet. It also allows you send any of the InSim request packets to the server. I've only written tests for part of the library, so haven't verified all of my packet parsing, but so far it looks pretty good. Here's an example of a simple program that requests the version from the server and prints out the response when it gets it:
import org.kerf.insim.Client;
public class Main implements InSimListener {
private Client client;
public void run() {
try {
String toAddress = "localhost"; // Address of server
int toPort = 33333; // Port on which server is listening for InSim requests.
String adminPassword = "password"; // Administration password for server (if applicable)
client = new Client(toAddress, toPort, adminPassword);
client.addListener("VER", this); // Listen for Version packets
client.connect();
VersionRequest versionRequest = new VersionRequest();
client.send(versionRequest);
} catch (Exception e) {
e.printStackTrace();
client.close();
}
}
// InSimListener implementation
public void packetReceived(InSimResponse response) {
if(response instanceof VersionResponse) {
VersionResponse versResponse = (VersionResponse)response;
System.out.println("Product: " + versResponse.getProduct());
System.out.println("Version: " + versResponse.getVersion());
System.out.println("Network version: " + versResponse.getNetVersion());
}
}
static public void main(String[] args) {
Main testConnect = new Main();
testConnect.run();
}
}
The code is similar for any InSim packet, just register for notification then send the request and handle it in the InSimListener implementation. All of the Initialization, ACKs and networking is taken care of for you. Let me know if you're interested in trying it out.
--
Rob
Ports used by InSim, OutSim and OutGauge
In the program I'm writing I'm not receiving OutSim or OutGuage packets, although I am receiving InSim packets correctly. To make matters more confusing, at one point I was using a different method of connecting UDP sockets and was receiving OutSim and OutGauge packets. I think the problem may lie in a technicality with the new method.
Here is a blind question, that perhaps only Scawen can answer: Does LFS send all InSim, OutSim and OutGauge packets from the same port on the server?
A little more info for the curious: I'm writing the code in Java. Initially I was using the DatagramSocket and DatagramPacket classes from the java.net package. I switched to using a DatagramChannel from the java.nio.channels package because of the cleaner architecure and the speed. To use the DatagramChannel, it has to be bound to an address on the server side, where "address" means "IP address and port number". It will only accept datagrams from the address it's bound to. So, my belief is that if a datagram comes from a different port on the same machine it won't be accepted. If that's the case, and LFS is sending using different ports, I need to rethink things. I would use something like Ethereal to sniff packets, but it doesn't see packets on the loopback address because Windows shortcuts that special case and doesn't go through the network stack Anyway, thanks for any help!
--
Rob
Here is a blind question, that perhaps only Scawen can answer: Does LFS send all InSim, OutSim and OutGauge packets from the same port on the server?
A little more info for the curious: I'm writing the code in Java. Initially I was using the DatagramSocket and DatagramPacket classes from the java.net package. I switched to using a DatagramChannel from the java.nio.channels package because of the cleaner architecure and the speed. To use the DatagramChannel, it has to be bound to an address on the server side, where "address" means "IP address and port number". It will only accept datagrams from the address it's bound to. So, my belief is that if a datagram comes from a different port on the same machine it won't be accepted. If that's the case, and LFS is sending using different ports, I need to rethink things. I would use something like Ethereal to sniff packets, but it doesn't see packets on the loopback address because Windows shortcuts that special case and doesn't go through the network stack
Anyway, thanks for any help!--
Rob
Demo vs. Licensed vs. Dedicated server capabilities
Is there a list of the API capabilities in each of the different products? Specifically, does OutGuage work in the demo?
--
Rob
--
Rob
Ah! That makes sense. Thank you.
--
Rob
--
Rob
My reading of the InSim documentation agrees with your suggestion that I just send a MST type packet with "/ai <name>" in the Msg field. It may be a problem with my understanding of the dedicated server itself. If I'm running it and type "/end" that should put me in the setup screen where commands like "/ai <name>" work, right? It doesn't seem to work that way for me. So, maybe if I understand administration of the dedicated server better, I can answer my own question.
Now, assuming I just want to do it through InSim and disregard any other ways of accomplishing the same thing. I am using MST successfully to send other commands. What packet(s) would I need to send for adding AI?
Something like this?:
MST "/end"
MST "/ai <name>"
Which doesn't seem to work. Am I missing any flags that I need to set in the config script or ISI packet? Thanks for any help.
--
Rob
Now, assuming I just want to do it through InSim and disregard any other ways of accomplishing the same thing. I am using MST successfully to send other commands. What packet(s) would I need to send for adding AI?
Something like this?:
MST "/end"
MST "/ai <name>"
Which doesn't seem to work. Am I missing any flags that I need to set in the config script or ISI packet? Thanks for any help.
--
Rob
Adding AI from InSim
How would I go about adding AI to a race using InSim? In other words, what type of packet(s) would I send?
It's worth noting that (apparently) because of the algorithm LFS uses to determine whether a driver is shown the blue flag or not, a lapped driver can be shown one right after he passes a slower driver in front of him. This does not mean he must yield if he continues to drive faster.
I just mention this because an incident like this happened to me where the slower driver complained after I passed him that I had a blue flag.
--
Rob
I just mention this because an incident like this happened to me where the slower driver complained after I passed him that I had a blue flag.
--
Rob
...and on cue here comes the wrecker. In the absence of desire or ability to make it fun and interesting for anyone, he tries to ruin it for everyone.
--
Rob
Preach on, Brother Slarty!
Good post. It touches on some of the points brought up in the "Overtaking" thread. This "hotlapping" mentality is largely a product of the sprint races run in most (all?) public servers, I believe. I think the answer is joining a well run league, if you don't want to deal with the inherent problems of public servers. Maybe we can develop some kind of Evolutionary Theory of Online Racing:
Demo servers -> Public servers -> Leagues -> ? (Professional sim racing?)
Now I just need to find a grumpy old farts' league.
--
Rob
Good post. It touches on some of the points brought up in the "Overtaking" thread. This "hotlapping" mentality is largely a product of the sprint races run in most (all?) public servers, I believe. I think the answer is joining a well run league, if you don't want to deal with the inherent problems of public servers. Maybe we can develop some kind of Evolutionary Theory of Online Racing:
Demo servers -> Public servers -> Leagues -> ? (Professional sim racing?)
Now I just need to find a grumpy old farts' league.
--
Rob
You own the half of the track you're on. While you're side by side, no one owns the ideal line. The general tenor of conversations about racing incidents online (and this thread) seems to be about "assigning blame". Everyone knows the pithy quotes about the first secret to winning is surviving, but most people don't drive like that. I'm including myself here, when the red mist takes over. If you drive with the first intent being to survive the race, the skill to survive closer racing will come with experience. The biggest problem with the wide range of skills on a server at any given time is that there isn't enough "racing" going on to help people develop racing skills, especially with the 5-10 lap sprints that dominate. If you are the one doing the passing on the public servers, it might be in your best interest to also consider it your responsibility to help less experience drivers learn how to be better drivers.
Wow, how did I get on this soapbox?
--
Rob
Back to overtaking in the world of sims, though...
The general rule has always been: "While there's overlap, hold your line". This is especially important in sims where most drivers have an impaired field of view, and skill levels vary from "first time in a multiplayer race" to "Greger Huttu".
--
Rob
The general rule has always been: "While there's overlap, hold your line". This is especially important in sims where most drivers have an impaired field of view, and skill levels vary from "first time in a multiplayer race" to "Greger Huttu".
--
Rob
FGED GREDG RDFGDR GSFDG