You still didn´t read that I think...
He must mean this because he also said, "At current hard disk sizes the extra 1 MB or so will not be a problem, I figure."
But yeah bad grammar *gg*
Hi, back again with 1.52.
Get it here http://www.liveforstats.de.vu/ and look at the changes.
It´s more intuitiv and better in use, because of for example three icons showing the status:
red for no LFS started
yellow for LFS started
green for InSim open
It runs good now, some problems in the realtime race were fixed, wich caused the lap positions to be wrong.
Also all icons were optimized for all windows versions (only a few colors for 98 and transparency for Vista)
Everything else is shown in the changelog and the news text.
I also created an account on sourceforge.net where I upload the source code in the next days http://www.sourceforge.net/projects/liveforstats/
Get it here http://www.liveforstats.de.vu/ and look at the changes.
It´s more intuitiv and better in use, because of for example three icons showing the status:
red for no LFS started
yellow for LFS started
green for InSim open
It runs good now, some problems in the realtime race were fixed, wich caused the lap positions to be wrong.
Also all icons were optimized for all windows versions (only a few colors for 98 and transparency for Vista)
Everything else is shown in the changelog and the news text.
I also created an account on sourceforge.net where I upload the source code in the next days http://www.sourceforge.net/projects/liveforstats/
Last edited by CLRS530, .
No only that you are informed over all systems you can use (not offensive)
Also if you get real fuel for the others, you don´t have really time to tab everything else in a race (ok maybe while pitting, but who would that do and what does it benefit because you don´t know wich strategy he uses
What ever, in the inSim packet it isn´t a right place in my opinion
(not offensive)Also if you get real fuel for the others, you don´t have really time to tab everything else in a race (ok maybe while pitting, but who would that do and what does it benefit because you don´t know wich strategy he uses
What ever, in the inSim packet it isn´t a right place in my opinion
Last edited by CLRS530, .
Sure thats only for your own car
@MonkOnHotTinRoof I thought you made some addons...
@MonkOnHotTinRoof I thought you made some addons...
You can only argument that you could see it because of the standing times but in case of that you can write a program and calculate that from the time (subtract a tyre change...)
The pit struct should be changed I think, because if there is no change you can´t see wich tyres are used yet.
So one for the tyre type and also a flag with
no change, changed and changed type
Also the tyre type have to be added into the new player (NPL) struct
The pit struct should be changed I think, because if there is no change you can´t see wich tyres are used yet.
So one for the tyre type and also a flag with
no change, changed and changed type
Also the tyre type have to be added into the new player (NPL) struct
I only don´t think that it is a good deal for someone to make a program for a team he isn´t part from and maybe no other one can use.
Strange request
Reads the same like you go to Ford and ask: "Could you create a car for me like I want it - surely for free?"
OK heavy example :P
Strange request
Reads the same like you go to Ford and ask: "Could you create a car for me like I want it - surely for free?"
OK heavy example :P
Last edited by CLRS530, .
Hmm, I didn´t do it because you could use that in a race against the other racers so I think its better to left it out.
One new packet I mentioned before in the InSim bugs post but write here again to have a full list.
One major problem for me in my stats tool is if a player finished and have a ? instead a number. In this case no package will be send.
But if he pits (and come back) before the result comes I have normally to reset him.
So I request an extra package (the package won´t be send often so no information have to be left out. Best would be also with pit and penalty...)
The second one I thought about are the flags if it would be better to have one package for beginning and the other one for end (with a duration time). Thats interesting especially for the blue flag, but for some addons also for yellow
Some discussion now here would be nice
One major problem for me in my stats tool is if a player finished and have a ? instead a number. In this case no package will be send.
But if he pits (and come back) before the result comes I have normally to reset him.
So I request an extra package (the package won´t be send often so no information have to be left out. Best would be also with pit and penalty...)
struct IS_PRS //Pre Result
{
char UName [24];
char PName [24];
byte UniqueId; // player's assigned unique id
byte PlyNum; // player's number (stays in list)
word VerifyId;
}
The second one I thought about are the flags if it would be better to have one package for beginning and the other one for end (with a duration time). Thats interesting especially for the blue flag, but for some addons also for yellow
Some discussion now here would be nice
Last edited by CLRS530, .
You are right, but for now it didn´t go out of control and not to many saying something to it.
Also it wasn´t a discussion about one idea against another. So I don´t think Scawen has problems to read it and see fast whats interesting.
But it would be nice if you (Scawen) could write something to my (finished) packets whats ok and what you don´t see so or isn´t possible to do.
That are all new packets I have a idea for and the others didn´t mentione new ones.
The new packets and the bugs are very important for me to be fixed, so Im happy that you finally see that its needed
Also it wasn´t a discussion about one idea against another. So I don´t think Scawen has problems to read it and see fast whats interesting.
But it would be nice if you (Scawen) could write something to my (finished) packets whats ok and what you don´t see so or isn´t possible to do.
That are all new packets I have a idea for and the others didn´t mentione new ones.
The new packets and the bugs are very important for me to be fixed, so Im happy that you finally see that its needed
Yes good that you mention that, this is one of the hardest design problems I had to work with. If a player finished and has no result but went to pit and back I have to reset him.
So it would be good if you send two result packets for this reason with a special flag set or the position to 255 (better would be a new packet for that reason to be compatible).
I meant a result packet for players wich finished before you joined the race with InSim.
Hi Scawen, nice to see.
I made a thread some time before, where I thought about some new packets
http://www.lfsforum.net/showthread.php?t=16290
Also I found some bugs wich are very annoying:
1. All packets you got early in race (MCI and STA) have information from the last race. That problem is surely only in the real race but not in a replay.
2. There were many other responses to the node bugs in the MCI packet.
The new lap don´t comes on a static time. Sometimes it comes before the finishline.
It would be good if you could be sure that it comes 1 node behind the finish line.
(3.) I´m not sure here, but in my Stats tool I send a MST packet if I save the stats or not, sometimes at the end of a race there comes a warning "Thats not a right MST packet" (the message is something similar). But I don´t know why it could appear from my side.
EDIT:
One thing wich gives you very hard work, is to make sure you get all information at a race in progress. It would be nice, if a new player gets a welcome packet or more welcome packets.
Important is the race start packet and there could be send all players and the results from players wich finished.
I made a thread some time before, where I thought about some new packets
http://www.lfsforum.net/showthread.php?t=16290
Also I found some bugs wich are very annoying:
1. All packets you got early in race (MCI and STA) have information from the last race. That problem is surely only in the real race but not in a replay.
2. There were many other responses to the node bugs in the MCI packet.
The new lap don´t comes on a static time. Sometimes it comes before the finishline.
It would be good if you could be sure that it comes 1 node behind the finish line.
(3.) I´m not sure here, but in my Stats tool I send a MST packet if I save the stats or not, sometimes at the end of a race there comes a warning "Thats not a right MST packet" (the message is something similar). But I don´t know why it could appear from my side.
EDIT:
One thing wich gives you very hard work, is to make sure you get all information at a race in progress. It would be nice, if a new player gets a welcome packet or more welcome packets.
Important is the race start packet and there could be send all players and the results from players wich finished.
Last edited by CLRS530, .
@Stuff that isn´t really a good answer at all, you are right, thats in the insim documentation, but do you thought where to get a result number? - Yes from a result and you get that only if a result has given.
@Frankmd interesting idea, never thought of that, but I´m not for those unsecure solutions and thinks you have do hardcoding (nodes). Also you often stop on the wrong place and accelerate and stop again.
But yes, at least you should get a good result with thing of all
@Frankmd interesting idea, never thought of that, but I´m not for those unsecure solutions and thinks you have do hardcoding (nodes). Also you often stop on the wrong place and accelerate and stop again.
But yes, at least you should get a good result with thing of all
No you can´t get both.
You are right for the penaltys, you can get it only with the result packet
Also there is no packet with pit information. Only the count in again the result packet.
The penalty in the result packet don´t says if you got a penalty ever in the race. It only says if you have a penalty at the end of the race.
There are many design problems and bugs in InSim, I wrote some threads but don´t got a reply from Scaven if he want to do something in the future
You are right for the penaltys, you can get it only with the result packet
Also there is no packet with pit information. Only the count in again the result packet.
The penalty in the result packet don´t says if you got a penalty ever in the race. It only says if you have a penalty at the end of the race.
There are many design problems and bugs in InSim, I wrote some threads but don´t got a reply from Scaven if he want to do something in the future
You can surely use insim on your local machine and send it to the same (only to the same)
Here is Release 1.42
News from http://www.liveforstats.de.vu
After a while, here is a new release. It provides many fixes and should work on a server over races and shouldn´t crash for some reason like the releases before that case was tested much.
Also the program runs on dedicated server with full support of an ip not 127.0.0.1 and parameters to start the server
The third part of the update is one of the biggest changes in the program I implemented but it don´t changes the normal way the program works. You can now change the value "noplayerreset" in the ini- file (only there not in settings) this affects that all players won´t be resetted for dissconnects (if they come back in game) or for flying to pit. It´s interesting mainly for longer races where the rules allowing dissconnecting and continue there.
Until now it wasn´t possible to get a good result, but with this release you get it. Critical things like the total time, lap count and positions (also the positions in lap and split) will be fixed. I tested it with a 25h race in germany some time ago 25h race There were many disconnects and the result is mainly how it should be.
For default noplayerreset is surely 0, you can set it to 1 (player won´t be reseted) and 2 is the same like 1, but if one player dissconnects and someone else connected for him with the same clanttag the result will be continued The detection of clan players is very basic because it is hard to do it and nearly unpossible to detect all. If you have problems there give me the names and I try to fix it (it was used also for the 25h race).
At least I added a command: you can test the connection of Live for Stats at any time with "/mso !test" if you get a reaction Live for Stats is active.
The new version is 1.42 you can get it in the download section.
The download is here http://www.liveforstats.de.vu/liveforstats-v142.zip
News from http://www.liveforstats.de.vu
After a while, here is a new release. It provides many fixes and should work on a server over races and shouldn´t crash for some reason like the releases before that case was tested much.
Also the program runs on dedicated server with full support of an ip not 127.0.0.1 and parameters to start the server
The third part of the update is one of the biggest changes in the program I implemented but it don´t changes the normal way the program works. You can now change the value "noplayerreset" in the ini- file (only there not in settings) this affects that all players won´t be resetted for dissconnects (if they come back in game) or for flying to pit. It´s interesting mainly for longer races where the rules allowing dissconnecting and continue there.
Until now it wasn´t possible to get a good result, but with this release you get it. Critical things like the total time, lap count and positions (also the positions in lap and split) will be fixed. I tested it with a 25h race in germany some time ago 25h race There were many disconnects and the result is mainly how it should be.
For default noplayerreset is surely 0, you can set it to 1 (player won´t be reseted) and 2 is the same like 1, but if one player dissconnects and someone else connected for him with the same clanttag the result will be continued The detection of clan players is very basic because it is hard to do it and nearly unpossible to detect all. If you have problems there give me the names and I try to fix it (it was used also for the 25h race).
At least I added a command: you can test the connection of Live for Stats at any time with "/mso !test" if you get a reaction Live for Stats is active.
The new version is 1.42 you can get it in the download section.
The download is here http://www.liveforstats.de.vu/liveforstats-v142.zip
I think writing a program working with another interface would be something more interesting.
With a plugin system as interface or a script language.
I don´t have the knowledges here
With a plugin system as interface or a script language.
I don´t have the knowledges here
There are a few librarys availible, you don´t have to search to long in this sub- forum...
Hmm, first I wanted to write that makes no sence, but at the time where all the problems with a black window were, I had NO ONE with a good old CRT.
But as I said, this wasnt a common situation.
Will try it normal with the TFT now or better "tomorrow"
But like you read it happened to me.
What you wrote makes no sence, if LFS gets a black screen surely its a LFS bug
illepall So please don´t write things like LFS is bugfree or I´m too stupid to setup my system.
So Scawen can easily read it and can fix this or decides that it isn´t important enough to give effort
EDIT: To make it clear: LFS gots a black window on laptops screen!
Again Black Screen in Patch V
Hi, I´m on the laptop of my parents at this time and got a new TFT oh christmas 
so I plugged it into the laptop.
Now I sized the output about both screens and had LFS windows, so no maximized in this buggy behaviour.
If I now switch it to the new tft and back it will be black (maybe I have to minimize the window in this procedure, didn´t test it again)
I read a similar bug report in the test patches around ~U20 where the bug was heavier in more situations.
I hope it now can really be fixed.
On the other hand its not really bad for me because I only tested the TFT.
so I plugged it into the laptop.Now I sized the output about both screens and had LFS windows, so no maximized in this buggy behaviour.
If I now switch it to the new tft and back it will be black (maybe I have to minimize the window in this procedure, didn´t test it again)
I read a similar bug report in the test patches around ~U20 where the bug was heavier in more situations.
I hope it now can really be fixed.
On the other hand its not really bad for me because I only tested the TFT.
Yes, my words.
While I was developing my InSim program I had the same 'problem' with the uniquue id.
On the other hand its easy to handle.
But I would prefer an id wich you get in one race and also get again if you reconnect.
In the next race/ session reget the ids.
But at all its ok and I can work with it
Also this will never come before S3, I suggest first new methods for one of the next patches because no other programs should have problems with them.
So wich additional packets do you want beside my or do you want to have another structure/ other values...
While I was developing my InSim program I had the same 'problem' with the uniquue id.
On the other hand its easy to handle.
But I would prefer an id wich you get in one race and also get again if you reconnect.
In the next race/ session reget the ids.
But at all its ok and I can work with it
Also this will never come before S3, I suggest first new methods for one of the next patches because no other programs should have problems with them.
So wich additional packets do you want beside my or do you want to have another structure/ other values...
Future New InSim packets discussion [V]
Hi, I spend some time to think over new packets wich build every new functionallity LFS gots in S2 in.
Thats whats the progress ATM, I don´t think it´s all and also I don´t think if every value is a good idea or if additional should be there.
But for that it´s a Discussion.
I hope some of the Addon developers help to get it to the ears of Scaven and maybe he could write here too, so that we can get a good system from the beginning wich provides everything for all possible parts of addons
Thats whats the progress ATM, I don´t think it´s all and also I don´t think if every value is a good idea or if additional should be there.
But for that it´s a Discussion.
I hope some of the Addon developers help to get it to the ears of Scaven and maybe he could write here too, so that we can get a good system from the beginning wich provides everything for all possible parts of addons
struct IS_PPS // Player Pit Stop (after the stop) (not so much information could be included because of multiplayer races)
{
char PPS [4];
char UName [24]; // username
char PName [24]; // nickname
char CName [32]; // car name (could be good here but no one would need it)
// functional
MSHT StopTime; // standing time
// information is save because everyone in a race could heare it from pit
byte Tyres; // 0 = no change; 1 = street normal..... n = r1 (not depending on the car)
word Damage; // damage points 0 = nothing; 1 = very little orange in graphic... (also save, who can do much with use of that in a multiplayer race)
byte UniqueId; // player's assigned unique id
byte PlyNum; // player's number (stays in list)
word VerifyId;
};
struct IS_PCC // Player Change Car
{
char PCC [4];
char UNameOP [24]; // username Old Player
char PNameOP [24]; // nickname Old Player
char UNameNP [24]; // username New Player
char PNameNP [24]; // nickname New Player
byte UniqueId; // player's assigned unique id
byte PlyNum; // player's number (stays in list)
word VerifyId;
};
stuct IS_PGP // Player Got Penalty
{
char PGP[4];
char UName [24]; // username
char PName [24]; // nickname
byte PenaltyFlag; // known Flag from Result
byte PenaltyBefore; // same Flag (only a active penalty; for Stop and Go to 30 seconds for example)
byte UniqueId; // player's assigned unique id
byte PlyNum; // player's number (stays in list)
word VerifyId;
};
struct IS_RYF // Race Yellow Flag
{
char RYF[4];
word Node; // where the yellow flag was caused
word VerifyId;
};
struct IS_PBF // Player Blue Flag
{
char PBF[4];
char UName [24]; // username
char PName [24]; // nickname
word Node // but not necessary cause of NLP and MCI
byte UniqueId; // player's assigned unique id
byte PlyNum; // player's number (stays in list)
word VerifyId;
};
No, nothing of this is possible, because InSim wasn´t touched again to implement the new features like Flags, Pit...
I linked version 1.35 now.
Didn´t fix the bug you posted (OldBloke) and the one I found too.
Also I don´t made a workaround cause that wouldn´t fix the main bug.
New in this official version is the working dedicated with server address....
And I integrated a minidump, so you should find everytime, if Live for Stats crashes a minidump called "liveforstats.exe-error.dmp".
This file will be overwritten everytime a new crash comes (I think and hope not often :P)
If you have a bug and no replay please send this dump to me.
Also the dump wouldn´t be wrong if you have a replay
Here the download link
http://www.liveforstats.de.vu/liveforstats-v135.zip
Didn´t fix the bug you posted (OldBloke) and the one I found too.
Also I don´t made a workaround cause that wouldn´t fix the main bug.
New in this official version is the working dedicated with server address....
And I integrated a minidump, so you should find everytime, if Live for Stats crashes a minidump called "liveforstats.exe-error.dmp".
This file will be overwritten everytime a new crash comes (I think and hope not often :P)
If you have a bug and no replay please send this dump to me.
Also the dump wouldn´t be wrong if you have a replay
Here the download link
http://www.liveforstats.de.vu/liveforstats-v135.zip
Last edited by CLRS530, .
FGED GREDG RDFGDR GSFDG