I'm not sure when it is send when you are hotlapping. At an multiplayer race the NewConnectionResponse is send when a player connects (here you get the connection id). When the player leave the pits or the race is restarted, the NewPlayerResponse is send.
I think that the NewPlayerResonse is also send when you start hotlapping, but I have not tested it.
Just output all responses then you'll see what responses are send:
I think that the NewPlayerResonse is also send when you start hotlapping, but I have not tested it.
Just output all responses then you'll see what responses are send:
public void packetReceived(InSimResponse response) {
System.out.println(response);
}
With the NewPlayerResponse you get the playername, car name, plate, skin etc.
public void packetReceived(InSimResponse response) {
if (response instanceof NewConnectionResponse) {
// here you get the connection id
} else if (response instanceof NewPlayerResponse) {
// here you get the player id and the player name etc.
}
}
I think that the LFS player name is important, cause this name is unique. In my tool for the results the LFS player name is used as primary key to identify players.
On our website the results looks like this: http://liveforspeed.at/?q=en/league/results/102
In our league we have only one penalty and this could be disqualify or loss of championship points (we keep it simple). The easiest would that a driver result can be marked with a penalty and a description can be entered.
What about league standings?
Our league standings looks like this: http://liveforspeed.at/?q=en/league/standings/6
We have also multiple standings cause have an own standings for rookies and also a team standings:
http://liveforspeed.at/?q=en/league/teams/standings/6
http://liveforspeed.at/?q=en/league/standings/rookies/6
On our website the results looks like this: http://liveforspeed.at/?q=en/league/results/102
In our league we have only one penalty and this could be disqualify or loss of championship points (we keep it simple). The easiest would that a driver result can be marked with a penalty and a description can be entered.
What about league standings?
Our league standings looks like this: http://liveforspeed.at/?q=en/league/standings/6
We have also multiple standings cause have an own standings for rookies and also a team standings:
http://liveforspeed.at/?q=en/league/teams/standings/6
http://liveforspeed.at/?q=en/league/standings/rookies/6
I don't understand why a registration is needed. Only races results and standings etc. should be submitted to the centralized league system. With the lfsworld name it is possible to add an overview that displays in which league the driver has raced.
I have an self written software to manage our leagues (Austrian Championship, A-Cup and Summer-Challenge). Besides the race result and the stats it also calculates the standings.
I think that a XML based exchange format is the best option, and I think that it is not a very difficult task to update my tool to generate that xml with the proper data.
What about the transmission of this data file. Is it pull by the centralized league tool of has the admin an upload form at lfsworld?
Both ways are fine for me. (but I think the upload option is the better one)
I think that a XML based exchange format is the best option, and I think that it is not a very difficult task to update my tool to generate that xml with the proper data.
What about the transmission of this data file. Is it pull by the centralized league tool of has the admin an upload form at lfsworld?
Both ways are fine for me. (but I think the upload option is the better one)
A centralized site for leagues is a nice idea, but I think that it should contain only the important informations and should not go into detail. Like RSS feeds, they also contain only a summary of the news and you have to go to the website to read the whole story.
If a league has sponsors it is also important that the audience sees this sponsors. On a centralized website this is not possible, so the user should have to visit the leagues website if he wants more detailed informations and here also the sponsors are presented.
So I think the main goal for a centralized league site should be that leagues have a place for presentation like what kind of league it is, the race schedule, a brief race result. etc.
If a league has sponsors it is also important that the audience sees this sponsors. On a centralized website this is not possible, so the user should have to visit the leagues website if he wants more detailed informations and here also the sponsors are presented.
So I think the main goal for a centralized league site should be that leagues have a place for presentation like what kind of league it is, the race schedule, a brief race result. etc.
Very strange. I had a look in the logfile but I need to do some testing. I have an idea what can be wrong, but I don't know if im right.
It could take a while until I find time to investigate this issue.
Yes
Not really. I don't see lots of changes coming to JInSim in the near future, so I think CVS is fine for now. (If I'm wrong, I have no problems switching to SVN)
If you provide patches in the future for JInSim it is also very likely that you get access to the source control
:banghead:
Sorry, i though you want only one unique id for a driver (combine connection id and player id). I should read the posts more carefully
If you will create a patch that rename the getId methods and replaces it with a more readable getConnectionId or getPlayerId, then I'm on your site and will include the patch in JInSim.
(Note to me: first read, then think, then write an answer)
Sorry, i though you want only one unique id for a driver (combine connection id and player id). I should read the posts more carefully
If you will create a patch that rename the getId methods and replaces it with a more readable getConnectionId or getPlayerId, then I'm on your site and will include the patch in JInSim.
(Note to me: first read, then think, then write an answer)
JInSim is only the Java implementation of the LFS InSim interface, and I think it should work the same way as InSim is described in Scawens documentation.
I understand your problem, with the player id and the connection id, but I don't think that a solution should be part of JInSim.
It would be better to create a new project that is a higher level object oriented api to communicate with LFS and uses JInSim as basis.
For example: When you want the list of all drivers you call a 'List<Driver> getDrivers()' method that returns a list driver object.
I understand your problem, with the player id and the connection id, but I don't think that a solution should be part of JInSim.
It would be better to create a new project that is a higher level object oriented api to communicate with LFS and uses JInSim as basis.
For example: When you want the list of all drivers you call a 'List<Driver> getDrivers()' method that returns a list driver object.
I have not tested it, but I think a tiny request will do. e.g. extend the net.sf.jinsim.examples.console.Console example with:
client.send(new TinyRequest(Tiny.ALL_RESULTS));
But when you want to keep track of all players, you must also response when a player connects or leaves, also when he joins the race.
I have done a stats application that tracks the laps over every driver etc.
Here is the source, but I'm currently refactoring this app, so there will be lots of bugs:
https://openbakery.org/svn/repos/trunk/racecontrol/
client.send(new TinyRequest(Tiny.ALL_RESULTS));
But when you want to keep track of all players, you must also response when a player connects or leaves, also when he joins the race.
I have done a stats application that tracks the laps over every driver etc.
Here is the source, but I'm currently refactoring this app, so there will be lots of bugs:
https://openbakery.org/svn/repos/trunk/racecontrol/
I do the same for SIG (http://www.setupgrid.net/sig) and my solution also work in Vista. LFS is started with this command:
String command = "rundll32 SHELL32.DLL,ShellExec_RunDLL \"" + lfsHome + "LFS.exe\" /insim=" + port;
We have also the idea to do live broadcasts of our austrian championship. We have done some tests with one strong PC, where LFS runs and also the Windows Media Encoder, that capures the video and encodes it to a 300kbit/s VC-1 video stream. The video quality is not the best, but viewable.
When you have a second PC, that you should get a better video result, cause you have more CPU time for the encoding.
We have also googled some commercial hosts where you can by stream time, but for the first broadcasts we will use our root-server as relay and limit the users. (e.g. with Darwin Streaming Server or something similar as relay)
I hope we can provide broadcasts in the next season which starts in autumn this year.
When you have a second PC, that you should get a better video result, cause you have more CPU time for the encoding.
We have also googled some commercial hosts where you can by stream time, but for the first broadcasts we will use our root-server as relay and limit the users. (e.g. with Darwin Streaming Server or something similar as relay)
I hope we can provide broadcasts in the next season which starts in autumn this year.
Nevertheless i will run a test in the profile, just to make sure that everything is fine
I only used OutGauge in the Speedometer example and with the short tests I can remember any delays, but my tests were only very brief.
I will try to run some longer tests and do also so some profiling.
I will try to run some longer tests and do also so some profiling.
Here a new version 0.5rc5:
https://sourceforge.net/projec ... files.php?group_id=174994
Changes:
* added prefix for the init request
* fixed NodeLapInfoResponse
https://sourceforge.net/projec ... files.php?group_id=174994
Changes:
* added prefix for the init request
* fixed NodeLapInfoResponse
I was busy with other stuff, I try to create a version in the next days.
I did an example and the NodeLap works fine for me:
package net.sf.jinsim.examples.nodelap;
import java.io.IOException;
import net.sf.jinsim.Channel;
import net.sf.jinsim.SimpleClient;
import net.sf.jinsim.TCPChannel;
import net.sf.jinsim.Tiny;
import net.sf.jinsim.request.MessageExtendedRequest;
import net.sf.jinsim.request.TinyRequest;
import net.sf.jinsim.response.InSimListener;
import net.sf.jinsim.response.InSimResponse;
import net.sf.jinsim.response.NodeLapInfoResponse;
public class NodeLapExample implements InSimListener {
private SimpleClient client;
private String hostname;
private int port;
private String adminPassword;
public NodeLapExample(String[] args) {
hostname = args[0];
port = Integer.parseInt(args[1]);
if (args.length > 2) {
adminPassword = args[2];
}
}
public void run() {
try {
client = new SimpleClient();
Channel channel = new TCPChannel(hostname, port);
client.addListener(this);
client.connect(channel, adminPassword, "NodeLapExample");
MessageExtendedRequest msgRequest = new MessageExtendedRequest();
msgRequest.setMessage("NodeLapExample");
client.send(msgRequest);
int i = 0;
while(i<10) {
client.send(new TinyRequest(Tiny.NODE_LAP));
Thread.sleep(500);
i++;
}
} catch (Exception e) {
e.printStackTrace();
} finally {
try {
client.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
public void packetReceived(InSimResponse response) {
if (response instanceof NodeLapInfoResponse) {
NodeLapInfoResponse nodeLap = (NodeLapInfoResponse)response;
System.out.println(nodeLap);
}
}
static public void main(String[] args) {
if (args.length >= 2) {
NodeLapExample testConnect = new NodeLapExample(args);
testConnect.run();
} else {
System.out.println("usage: net.sf.insim.nodelap.NodeLapExample <hostname> <port> <admin password>");
}
}
}
Hmm, could be a bug in JInSim. Do you have a stack trace for the BufferUnderflowException?
I'll try to write an example program to verify if this is a JInSim bug (hopefully this week).
I have fixed one issue in rc3 or rc4 that could also fix this BufferUnderflowException, so you could also try the latest version:
http://www.lfsforum.net/showthread.php?p=708608#post708608
Ok I will add this in the next release
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
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.
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)
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.
A /i message is not seen by the others, so I use this on my host for commands. This is the ISP_III package.
FGED GREDG RDFGDR GSFDG