ok thanks but new error : error = in dedi host screen when trying to load insim : = " insim: first byte in packet does not match size "
PLEASE HELP!!!!!
ok thanks but new error : error = in dedi host screen when trying to load insim : = " insim: first byte in packet does not match size "
PLEASE HELP!!!!!
Hmm, I have tested this example only with LFS not with the dedi, so I don't know if the example works with a dedi, because it only sends a chat message. But you error message look like that you are using an older dedi version. Are you using the latest dedi version patch X?
@Eclipse: download this: http://www.eclipse.org/downloads/moreinfo/java.php
Ok I've managed to run the Hello World thingy, and it does what it's supposed to do in LFS, but in the console I get this over and over (nonstop):
java.nio.channels.ClosedChannelException
at sun.nio.ch.DatagramChannelImpl.ensureOpen(DatagramChannelImpl.java:107)
at sun.nio.ch.DatagramChannelImpl.read(DatagramChannelImpl.java:313)
at org.kerf.jinsim.UDPChannel.receive(UDPChannel.java:120)
at org.kerf.jinsim.AbstractChannel.run(AbstractChannel.java:57)
at java.lang.Thread.run(Thread.java:619)Hmm I don't have this exception when I run the hello world example. Nevertheless, I have updated jinsim that this exception is handled, cause it indicates that the jinsim connection is closed.
here you find the update: http://liveforspeed.at/download/jinsim-0.4.96.zip
here you find the update: http://liveforspeed.at/download/jinsim-0.4.96.zip
yep using the latest release 0.5 X10 ......
I have created new package of jinsim with the latest fixes:
http://liveforspeed.at/download/jinsim-0.4.97.zip
* Some fixes at the button requests
* added java.lang.String to LFS codepages encoding
* fixed a synchronizing issue when sending lots of insim requests
* and maybe some more that I can't remember
http://liveforspeed.at/download/jinsim-0.4.97.zip
* Some fixes at the button requests
* added java.lang.String to LFS codepages encoding
* fixed a synchronizing issue when sending lots of insim requests
* and maybe some more that I can't remember
I updated jinsim with the minor X30 changes:
http://liveforspeed.at/download/jinsim-0.4.99.zip
Also changed:
* InSim relay support is now included + example program
* Fixes at the comp car and MCI requests
* Fixes a the set camera request
* Added a Track enum so that track codes like 100 or BL1 can be converted in an enum value and then to the real trackname.
I have tested this version only with a X30 Dedi, but it should also work with X10.
http://liveforspeed.at/download/jinsim-0.4.99.zip
Also changed:
* InSim relay support is now included + example program
* Fixes at the comp car and MCI requests
* Fixes a the set camera request
* Added a Track enum so that track codes like 100 or BL1 can be converted in an enum value and then to the real trackname.
I have tested this version only with a X30 Dedi, but it should also work with X10.
Are the examples shipped within the zip file for older versions or are they just not working? ^^
The raceclient example throws a nullpointer exception
The raceclient example throws a nullpointer exception
Yes some examples do not work, cause I haven't updated all by now. If everything is stable the version number whould be 0.5 
The UDPChannel has some bugs, and I will fix this soon, until then try the examples using the TCPChannel.
The UDPChannel has some bugs, and I will fix this soon, until then try the examples using the TCPChannel.
oh btw your NodeLap type is missing the position byte (and remember to change it in the CompCar, too when you change the NodeLap 
)
and in the Client class the bit flag with value 16 is not for new players but for node lap packets
)and in the Client class the bit flag with value 16 is not for new players but for node lap packets
Thx, fixed this in my version.
I will post a new version as soon as I have fixed the UDP issue.
I will post a new version as soon as I have fixed the UDP issue.
It won't compile for me. I'm really not sure what the problem is:
insimApplication.java:6: unreported exception java.io.IOException; must be caught or declared to be thrown
Client insimConnection1 = new Client("localhost", 6699, "adminpass");
You just have to catch the exception? ^^
That Client class isn't the one in the library, right?
That Client class isn't the one in the library, right?
Yes, the connect throws an IOException.
Thnx for the update Brilwing!
There's a little mistake in SetCarCameraRequest, line 55:
super(PacketType.CAMERA_POSITION, 8);it should be:
super(PacketType.SET_CAR_CAMERA, 8);Thanks again for all your work
Starblue
new version: http://liveforspeed.at/download/jinsim-0.5rc1.zip
Changes:
* Renamed packages from org.kerf to net.sf
* Fixed camera packet (thx. Starblue)
* UDP communication works now again
* OutGauge and OutSim also works again
* Fixed the not working examples, and all should work now fine.
All I wanted in version 0.5 is now included so this is the first release candidate.
Changes:
* Renamed packages from org.kerf to net.sf
* Fixed camera packet (thx. Starblue)
* UDP communication works now again
* OutGauge and OutSim also works again
* Fixed the not working examples, and all should work now fine.
All I wanted in version 0.5 is now included so this is the first release candidate.
Hi Brilwing,
I get a "page not found" on that link
Two more things I fixed on my local version of 0.4.99:
SetCarCameraRequest: uniqueId and cameraType were inverted, the correct order is:
data.put(uniqueId);
data.put(cameraType);
NodeLap: the Position byte (after PlayerId byte) was not implemented. I added the getter/setter for position and setPosition(buffer.get()); after setPlayerId(buffer.get()); in the constuctor.
Starblue
Ups, was a typo in the Url...
So here we go: http://liveforspeed.at/download/jinsim-0.5.rc2.zip
Changes:
* fixed SetCarCameraRequest (thx Starblue)
* added Car enum
(set position is already in 0.5rc1 at the NodeLap)
Thanks for the update
I'm currently using 0.5.rc2 for a project and I noticed the following behaviour, while connecting with the SimpleClient class:
if an unchecked exception is thrown in the registered listener, the jvm will start increasing its memory without limits, until.... I had to terminate it because my pc was freezing
That happened me twice, once for a mistaken object cast and once because I received a string of unexpected size and went out of bound doing a substring
If I had enabled logging, I guess I would have seen the "Something went wrong!" message of AbstractChannel.java line 122, as I think the exception got caught there.
As it's not nice to have an application crash everything by stealing all the available memory, you may want to change that behaviour..
Maybe you could have a dedicated try/catch around the notify action, like this:
try {
client.notifyListeners(packetData);
}
catch (Exception e) {
log.error("Something went wrong!", e);
}This way the custom listeners can be wrong and throw whatever they like but it won't crash the whole InSim connection & program.
It's probably not the best way to handle the situation, but I think it may be worth to change it.
Starblue
Sorry I haven't got the time to test this problem, but I read the code and I have an idea to solve this problem without using an extra try-catch. I hope I find time this week to fix this.
Hi Brilwing,
I've found a problem with the MessageResponse class.
I wanted to check what users said so I used getTextStart() to make a substring of the getMessage() and filter their name to get only the actual text they typed.
However, it didn't work for people with "^" in their name.. that's because LFS encodes it with "^^" and getMessage() returns it to just "^"..
So basically the number of characters in getMessage() is not the original one and so the position returned by getTextStart() becomes wrong.
I changed my local copy of MessageResponse constructor like this:
After this change, it became safe to get the typed message like this:
Starblue
I've found a problem with the MessageResponse class.
I wanted to check what users said so I used getTextStart() to make a substring of the getMessage() and filter their name to get only the actual text they typed.
However, it didn't work for people with "^" in their name.. that's because LFS encodes it with "^^" and getMessage() returns it to just "^"..
So basically the number of characters in getMessage() is not the original one and so the position returned by getTextStart() becomes wrong.
I changed my local copy of MessageResponse constructor like this:
public void construct(ByteBuffer buffer) throws BufferUnderflowException {
super.construct(buffer);
buffer.position(buffer.position()+1);
connectionId = buffer.get();
playerId = buffer.get();
typedByUser = buffer.get();
textStart = buffer.get();
message = getString(buffer, 128);
// Starblue 04/01/2008
// Rewind the buffer and check how long the "pre-message" part really is:
int pos = buffer.position();
buffer.position(pos-128);
String preMessage = getString(buffer,textStart);
textStart = (byte)(preMessage.length()+1);
buffer.position(pos);
}
After this change, it became safe to get the typed message like this:
String typedMessage = response.getMessage().substring(response.getTextStart());Starblue
Hi Brilwing,
I found another problem related to the try/catch in AbstractChannel: sometimes I get this exception:
The description "Connessione interrotta dal software del computer host" (which means "connection interrupted by computer host software") makes me think that this a particular implementation of an event similar to the ClosedChannelException, for which you had already provided a try/catch:
Unfortunately, this time it's an IOException so it does not get caught into the ClosedChannelException catch and it goes on to be catched by the generic try/catch you've put at the end of the loop:
As there is no action in the catch to solve the problem, the thread keeps looping and logging the same error, eventually filling up all the space available on the disk and crashing the program...
(I think this explains my previous problem where I had not enabled logging on disk, so it filled up memory instead of disk space).
I'm going to put a return statement in the generic Exception catch, so that if something "unexpected" happens, the thread stops working (since it is not supposed to be able to "fix" an unexpected event anyway).
Starblue
I found another problem related to the try/catch in AbstractChannel: sometimes I get this exception:
15:13:58,890 ERROR - Something went wrong!
java.io.IOException: Connessione interrotta dal software del computer host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(Unknown Source)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at sun.nio.ch.IOUtil.read(Unknown Source)
at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at net.sf.jinsim.TCPChannel.receive(TCPChannel.java:36)
at net.sf.jinsim.AbstractChannel.run(AbstractChannel.java:60)The description "Connessione interrotta dal software del computer host" (which means "connection interrupted by computer host software") makes me think that this a particular implementation of an event similar to the ClosedChannelException, for which you had already provided a try/catch:
try {
numberRead = receive(sizeBuffer);
} catch (ClosedChannelException ex) {
// do nothing chase numberRead is already -1
}
Unfortunately, this time it's an IOException so it does not get caught into the ClosedChannelException catch and it goes on to be catched by the generic try/catch you've put at the end of the loop:
while (running) {
try {
[...]
} catch (Exception e) {
log.error("Something went wrong!", e);
}
}As there is no action in the catch to solve the problem, the thread keeps looping and logging the same error, eventually filling up all the space available on the disk and crashing the program...
(I think this explains my previous problem where I had not enabled logging on disk, so it filled up memory instead of disk space).
I'm going to put a return statement in the generic Exception catch, so that if something "unexpected" happens, the thread stops working (since it is not supposed to be able to "fix" an unexpected event anyway).
Starblue
Here is a new jinsim release 0.5.rc4: http://downloads.sourceforge.n ... 5.rc4.zip?use_mirror=osdn
Changes:
Changes:
- Fixed the bugs Starblue reported:
- fixed the endless loop when the ResponseListener throws an exception
- The MessageResponse getMessage only returns the message without the driver name. For the driver name use the getDriverName() method
- Changed the ChannelCloseException to an IOException so that the Channel is closed when an error happened.
- fixed the endless loop when the ResponseListener throws an exception
- minor fixes at the buttons
Thank you Brilwing
Starblue
Starblue
Hi Brilwing,
I wanted to use the prefix variable in the ISP_ISI packet, but the Client class generates its InitRequest inside the connect method and it's not possible to set a prefix from outside. Could you add a prefix parameter in the next release?
Starblue
I wanted to use the prefix variable in the ISP_ISI packet, but the Client class generates its InitRequest inside the connect method and it's not possible to set a prefix from outside. Could you add a prefix parameter in the next release?
Starblue
Java - JInSim - a Java InSim library
(240 posts, started )
FGED GREDG RDFGDR GSFDG