It actually was an issue with our DNS-server (no idea though what it was that let it go into tilt) ... Our hoster switched us over to another one and now everything is fine again.
Thanks guys and sorry for initially blaming lfsw
Thanks guys and sorry for initially blaming lfsw
Yes!
No!
Just testet it ... wget is extraordinarily slow too.
As a matter of fact, I realized later, that other scripts using file_get_contents() (not getting files from lfsworld) are going into timeout too, so it obviously is NOT a lfsw-problem.
Strangely enough, I didn't change anything to my configuration ... I already contacted my hoster for further investigations.
@morpha: Thanks for testing ... I'd have expected similar values before ... by now it takes nearly half a minute to resolve hostname and send http-request (in wget) ... so there's definitely something very wrong ...
Last edited by avetere, .
Hey folks!
I've been using this recently using file_get_contents() in my scripts.
Up to yesterday it all went very smooth, but now it is extremely "laggy" and takes about 10-25 seconds to display a result, whereas directly opening the link returns a result instantly (as ist was before within the script) ...
So ... what happened?
I've been using this recently using file_get_contents() in my scripts.
Up to yesterday it all went very smooth, but now it is extremely "laggy" and takes about 10-25 seconds to display a result, whereas directly opening the link returns a result instantly (as ist was before within the script) ...
So ... what happened?
You might also want to close insim-apps as some of them do overlay the menu, so that you don't see the buttons even if you hit spacebar 'til you're old and grey 
I just recognized, that this service is down at the moment.
Have you suspended it, Victor, or will it be on again?
Thanks,
AV
*ouch* Are you sure about that one? I think 5.2 is a de facto standard nowadays since a lot of hosters do not use 5.3 yet ...
splittime passed twice by same car
Hey folks!
Here's a weird bug I whitnessed today when looking at the results of a replay.
As it is a 7MB replay and I cannot zip it so much that I can upload it here, I please you to download it yourself from this location:
http://cl.racemore.de/mpres/XI/4/2/r1/
(right above the track image there is a link to the replay)
Now the bug:
In lap 9 62-zGAreo gets split 1 two times:
After 37.38 seconds of his lap (replay timecode: 10:47.67) he passes split 1 regularly.
About 9 seconds after that (replay timecode: 10:55.37), his split time is "updated" to 46.70 seconds way after he passes the split and strangely enough: At that point his lap is just about 45 seconds "old".
After quite a bit of examination, I figuered out, that the "impulse to update" is given just at the time !ce.Pusherx8x passes split 1 (although the paket arrives 0.20 seconds later it seems to be exactly that moment)
There seems to be some minor lagging, but nothing serious, so it is at least not obviously a "lag bug" ...
To make irritations perfect: The effect does even show in insim, as it is visible in Relax, though LFSStats gives the correct splittimes (probably it does reject the "update" as there already exists split 1 for that car and lap).
There actually are two timeframe pakets associated with Aero's car within the replay, thus making him pass the split twice ... but there is no obvious reason as to why they are there ...
Here's a weird bug I whitnessed today when looking at the results of a replay.
As it is a 7MB replay and I cannot zip it so much that I can upload it here, I please you to download it yourself from this location:
http://cl.racemore.de/mpres/XI/4/2/r1/
(right above the track image there is a link to the replay)
Now the bug:
In lap 9 62-zGAreo gets split 1 two times:
After 37.38 seconds of his lap (replay timecode: 10:47.67) he passes split 1 regularly.
About 9 seconds after that (replay timecode: 10:55.37), his split time is "updated" to 46.70 seconds way after he passes the split and strangely enough: At that point his lap is just about 45 seconds "old".
After quite a bit of examination, I figuered out, that the "impulse to update" is given just at the time !ce.Pusherx8x passes split 1 (although the paket arrives 0.20 seconds later it seems to be exactly that moment)
There seems to be some minor lagging, but nothing serious, so it is at least not obviously a "lag bug" ...
To make irritations perfect: The effect does even show in insim, as it is visible in Relax, though LFSStats gives the correct splittimes (probably it does reject the "update" as there already exists split 1 for that car and lap).
There actually are two timeframe pakets associated with Aero's car within the replay, thus making him pass the split twice ... but there is no obvious reason as to why they are there ...
This is one of the rare occasions (do you call it this way in english?! not sure ...), where you have to be corrected:
-----------
?action=pst
-----------
(online statistics of one racer)
requires: &racer=<racer>
optional: -
returns: distance in metres
fuel burnt in cl
laps
hosts joined
wins
second
third
finished
quals
pole
drags
drag wins
[B]country[/B]
online status (0 = offline, 1 = spectating, 2 = pits, 3 = in-race)
current / last hostname (or blank line if not online or on hidden host)
last_activity_time(*) (Unix timestamp (UTC))
current / last known track(*)
current / last known car(*)additionally, there is such thing as:
http://www.lfsworld.net/highlight_countries/highlights_<Country_Name>.txt
(not as useful though)
Actually I use colorconversion only after codepage-conversion (In fact I use the one posted here) ... so, to some extend, I may find it useful, to combine both of them into one ...
Currently I use this on converted names:
<?php
### define colors for HTML-output ###
function getColorCode($col) {
switch ($col) {
case 0 : return "#000000";
case 1 : return "#ff0000";
case 2 : return "#00ff00";
case 3 : return "#ffff00";
case 4 : return "#0000ff";
case 5 : return "#ff00ff";
case 6 : return "#00ffff";
case 7 : return "#ffffff";
case 8 : return "#000000";
case 9 : return "#000000";
default : return $col;
}
}
### strip colors from names ###
function nameblank($name) {
return stripslashes(preg_replace("/\^[0-9]/","",htmlspecialchars($name)));
}
### get colored names for HTML-output ###
function namecolored($name) {
return stripslashes(preg_replace("/\^([0-9])(.[^\^]*)/e",'"<span style=\"color:".getColorCode($1).";\">$2</span>"',htmlspecialchars($name)));
}
?>
Not at this end of the line :snail:
Yeah, he didn't seem to realize that ...
The error there is the same: byte order ...
to enforce it, use "V" (upper case) instead of "i" or "I" ... and for those 2-byte things (words: laps, pflags, penalties) use "v" (lower case)
I'm afraid not only those are wrong, but laps too (and i assume even pflags ...)
Here's my own readout of the replay:
flags is your pflags ... my values result in: CustomView, AutoClutch, LeftHand and Wheel ...
done with this unpack:
Edit:
1: too slow
2: just doublechecked: little-endian enforcment is the key ... so do what morpha said ... you seem to have a "big-endian-machine"
Here's my own readout of the replay:
[1] => Array
(
[nick] => per.Domi K
[numberplate] =>
[car] => FZR
[lfsw] => Dominic123
[lapsdone] => 6
[flags] => 8705
[confirm] => 2
[numstops] => 1
[penalty] => 0
[totaltime] => 642700
[bestlap] => 102510
[null] => 0
[startpos] => 4
[handicap] => 0
[restrictor] => 0
)
flags is your pflags ... my values result in: CustomView, AutoClutch, LeftHand and Wheel ...
done with this unpack:
<?php
unpack("@0/a24nick/a8numberplate/a4car/a24lfsw/Slapsdone/Sflags/Cconfirm/Cnumstops/Spenalty/Ltotaltime/Lbestlap/Cnull/Cstartpos/Chandicap/Crestrictor",$string);
?>
1: too slow
2: just doublechecked: little-endian enforcment is the key ... so do what morpha said ... you seem to have a "big-endian-machine"
Last edited by avetere, .
Here "integer" standy for exactly that: an integer value, in difference to a floating number. There is no direct correspondence with what "character-type" the pack (or unpack) function assumes.
Actually, you would like to use:
char: a
byte: C (c for signed ones)
word: S (s for signed ones)
int: L (l for signed ones)
Actually, you would like to use:
char: a
byte: C (c for signed ones)
word: S (s for signed ones)
int: L (l for signed ones)
actually i (or I) don't require a size-value (nor are they supported, if I'm not wrong).
My guess is: Your machine does not(!) interpret i as an 32bit integer (4byte), as the parameter i (or I) is machine-depentent in it's size.
I'd recommend the use of "L" instead, as this one is always 32bit ... or "l" for a signed integer which is useless here of course
edit:
btw: "i" is for signed integers, so use of "I" was - out of those two - the right choice
My guess is: Your machine does not(!) interpret i as an 32bit integer (4byte), as the parameter i (or I) is machine-depentent in it's size.
I'd recommend the use of "L" instead, as this one is always 32bit ... or "l" for a signed integer which is useless here of course
edit:
btw: "i" is for signed integers, so use of "I" was - out of those two - the right choice
Last edited by avetere, .
You want to execute scripts on somebody else's computer?!
Neither schould that be possible (via insim), nor would I want it to be ...
Neither schould that be possible (via insim), nor would I want it to be ...
seeing that color-table for the first time, the question arrises:
Why did the devs decide to swap the codes for red/blue and yellow/cyan ? The rest seems to be done in quite analogy to that table ...
Now ... where did I say that?!
I only disagreed with your opinion, that the old system was more practical than the new one (for the reasons Android already gave). As this is just opinions and/or personal use/behaviour there obviously is not right or wrong, not even speaking of thruth ...
I can't remember me saying "Listen people, here comes the truth" nor something similar ...
I just cannot see, why - even with your example - the old system is more practical, since I regard the gain of the new one (more flexibility in general) more important than the loss (more "overfueling" in some occasions) ...
Not less but neither more ...
I only disagreed with your opinion, that the old system was more practical than the new one (for the reasons Android already gave). As this is just opinions and/or personal use/behaviour there obviously is not right or wrong, not even speaking of thruth ...
I can't remember me saying "Listen people, here comes the truth" nor something similar ...
I just cannot see, why - even with your example - the old system is more practical, since I regard the gain of the new one (more flexibility in general) more important than the loss (more "overfueling" in some occasions) ...
Not less but neither more ...
But that calculation is only correct in one(!) specific situation: When you pit exactly in the forsought lap ... an earlier pitstop will leave you without fuel, a later one with even more fuel ... Besides, what would be the maximum "fuel-overload", you'd carry that way? Say 2-3 % ... neglectable in my opinion ... but well ... if you thought it more practical before, do so, I can't see that ...
For kicking and banning that's plain right ... I was thinking of such things as penalties ...
Not more practical either, as Android stated perfectly just above you
Yeah, that's right. Nevertheless it would be very much easier in a lot of occasions, if you were able to do it in another way. be that a playerid or connectionid (which are already present) or even the lfsw-name. Espescially in leagues you do know that one quite often. so it would already a great improvement, if a lfsw-name would be accepted as input (also since many people don't know the right-klick-thing)
If you read my post carefully, you'll realize, that I made the exeption "every car but your own".
And as I understood, naza wanted some thing, that could reproduce fuel usage of other cars?!
FGED GREDG RDFGDR GSFDG