In my experience those get broken quite easily. It sounds very much like my 2 drives.
I have two DVD drives currently. One has stopped reading CDs and the other one DVDs. If I put a wrong kind of a disc into a wrong drive it just makes sssrrrr sounds and freezes.
I have two DVD drives currently. One has stopped reading CDs and the other one DVDs. If I put a wrong kind of a disc into a wrong drive it just makes sssrrrr sounds and freezes.
+1 for more dynamic weather.
But I think the wind direction changes a bit already. For example do donuts until your tyres starts to smoke, then watch the smoke trails changing direction with the wind.
But I think the wind direction changes a bit already. For example do donuts until your tyres starts to smoke, then watch the smoke trails changing direction with the wind.
I don't think you are supposted to print floats in hex.
In ancient history some computers tryed to use base10 numbers, today every computer uses base2(binary). Never heard base16(hex) computers.
Floats are 'floating point' numbers. I.e the length/accuracy for the integer and decimals parts are not fixed. E.g IEEE754 32bit float uses 1bit sign, 8bit exponent and 23bit significand (iirc).
I don't know what you mean by saving floats "as they are". Floats are just saved in memory as I told in the prev paragraph. You could theoretically save them as a string writing "0.35", but that would be really slow operation to convert them constantly back and forth between float and string.
In old 286-486 days it was sometimes common to 'emulate' decimal numbers with fixed point 16.16 numbers. Basicly they were 32bit integer split into 16bit integer and 16bit decimal parts. It gave some speed advantage in old computers. Definately not recommended to use these nowadays. Just mentioned because these you could print in hex.
In ancient history some computers tryed to use base10 numbers, today every computer uses base2(binary). Never heard base16(hex) computers.
Floats are 'floating point' numbers. I.e the length/accuracy for the integer and decimals parts are not fixed. E.g IEEE754 32bit float uses 1bit sign, 8bit exponent and 23bit significand (iirc).
I don't know what you mean by saving floats "as they are". Floats are just saved in memory as I told in the prev paragraph. You could theoretically save them as a string writing "0.35", but that would be really slow operation to convert them constantly back and forth between float and string.
In old 286-486 days it was sometimes common to 'emulate' decimal numbers with fixed point 16.16 numbers. Basicly they were 32bit integer split into 16bit integer and 16bit decimal parts. It gave some speed advantage in old computers. Definately not recommended to use these nowadays. Just mentioned because these you could print in hex.
Mmmm... I don't want to do anything with the byte... at least currently. But somebody might want to do.
Yes well that might help somewhat. Although it feels bit hacky and if I was playing with the byte I would feel safer if it was fixed after the race. Besides you might not know the finish line for certain. Maybe you know it is say 5 lap race and so the 5th lap must be the last one. But what about timed (1h, 2h,... 24h) races?
Yes, I understood it. Sorry, my post was bit unclear about that. Of course you rather trust the end position in RES than MCI.
The point is, however, that RES gives only confirmation what the end position is, not how it has changed during the race. So the problem I described in prev post is still there.
It wouldn't be good if it stops sending MCI after the race is over (I use it for number of other things too).
I'm not saying it's a very big thing if the position keep changing after the race. You can control it little bit yourself in Insim app. Just made an observation publicly known.
One suggestion was that you lock the position yourself if you get RES. It's just that I wouldn't trust, especially with UDP, that the RES is the first packet you get after the car crosses the finnish line. You could get a time line like this (I think)...
...
1) cars 1 and 2 cross the finnish line
2) car 2 overtakes car 1 (after the finnish line)
3) you get MCI which have the new positions
4) you get FIN and RES for cars 1 and 2
...
Now if you are doing something immediately after the position changes (like draw a chart of positions or what ever), the point 3 would generate erronous indication that car 2 overtook car 1 during the race.
I'm not saying it's a very big thing if the position keep changing after the race. You can control it little bit yourself in Insim app. Just made an observation publicly known.
One suggestion was that you lock the position yourself if you get RES. It's just that I wouldn't trust, especially with UDP, that the RES is the first packet you get after the car crosses the finnish line. You could get a time line like this (I think)...
...
1) cars 1 and 2 cross the finnish line
2) car 2 overtakes car 1 (after the finnish line)
3) you get MCI which have the new positions
4) you get FIN and RES for cars 1 and 2
...
Now if you are doing something immediately after the position changes (like draw a chart of positions or what ever), the point 3 would generate erronous indication that car 2 overtook car 1 during the race.
You could give core2 seti @ home? (joke)
I tested it too (W39). However i found one interesting 'feature' in it. Not sure if this is intentional...
The positions change even when the race is over. I tryed with few AIs and after the race I moved my car ahead and behind the AI cars and my and AI positions changed respectively.
I don't use this byte for anything (useful) yet, but maybe it could be frozen to the end standings after the race is over (and the result is confirmed)? This might get important when some of the cars have finished and some are still racing. So you would need to do tracking which cars have finished which are not, because the byte is nonsense after the finnish line.
Also in the beginning (at the start grid) the positions are 0 for some time.
I don't know if these are big things. At least the 0 at the start can be handled easily with a test.
I actually searched 'time' too, but didn't get anywhere near the correct answer. Besides I was sure it would be too clever if it were actually 'time' and not 'thyme'
This was really hard (especially when I don't know much about metal).Yes, I guess it would. That's pretty much the same I was thinking but I considered it too messy (=not 'nice') if there was some simple direct way. So I decided to ask before. I suppose I have to do it in that way now
Thanks anyway.
Thanks anyway.
Me neither.
My logic was...
"...parsley, sage, rosemary,..." -> Clearly "Scarborough fair" as in it they sing...
"...parsley, sage, rosemary and thyme.." -> "thyme" and then that dude is clearly trying to steal it (but 'not' succeeding). So I tryed to to google all thymes which match the pic.
Sandy Denny & Trevor Lucas - Let no man steal your thyme?
To detect if all have finished
Sorry if this have been asked/handled already...
Does anybody have a 100% sure way to detect that everybody in the race has finished? I mean those who are going to get a place in finishing table.
This is bit tricky I guess. You cannot compare players in race and finished in IS_STA, because the player count is the number currently on track. If a player who has finished spectates, the player count is reduced by 1, and it is increased by 1 if a new joins. That is not related to if racing is in progress or not (finished) or if the added/removed player is such that he could have finished.
If there is no such way, maybe it should be added? Maybe a new packet telling that the last player who can get a place in finishing table (has started before the 1st player finishes the race) has finished. Adding a count (etc) to IS_FIN packet (telling number of racers) doesn't help because somebody could spectate/pit before the end and never finishing. Same problem with a new confirmation flag (e.g. CONF_LAST_PLAYER) for IS_RES.
This could be used for qualifying too (time ended and nobody can improve time anymore).
This would be nice as I wanted my program to do something immediately and only after everybody has finished.
Does anybody have a 100% sure way to detect that everybody in the race has finished? I mean those who are going to get a place in finishing table.
This is bit tricky I guess. You cannot compare players in race and finished in IS_STA, because the player count is the number currently on track. If a player who has finished spectates, the player count is reduced by 1, and it is increased by 1 if a new joins. That is not related to if racing is in progress or not (finished) or if the added/removed player is such that he could have finished.
If there is no such way, maybe it should be added? Maybe a new packet telling that the last player who can get a place in finishing table (has started before the 1st player finishes the race) has finished. Adding a count (etc) to IS_FIN packet (telling number of racers) doesn't help because somebody could spectate/pit before the end and never finishing. Same problem with a new confirmation flag (e.g. CONF_LAST_PLAYER) for IS_RES.
This could be used for qualifying too (time ended and nobody can improve time anymore).
This would be nice as I wanted my program to do something immediately and only after everybody has finished.
Nope, nope.
Hint: Think it the 'other' way (or google all FYC songs :tilt
EDIT: I did make it with Paint... took c. 20 mins
Still not correct... must be because of my crappy figures on the right side
1/2 correct. Band is right (I said it was too easy
)Waiting for the song...
Ok. He can post a new one next.
The last pics have been so freaking hard that I tryed to make easier... maybe too easy... was pop in the old days
The last pics have been so freaking hard that I tryed to make easier... maybe too easy... was pop in the old days
How long? He isn't in active users anymore. Have to wait till tomorrow.
Mato got it probably, but does anybody outside Finland have chances to know it
(too bad 'cause I used 20 mins to paint a nice pic :tilt
EDIT: yes he did (?)
(too bad 'cause I used 20 mins to paint a nice pic :tilt
EDIT: yes he did (?)
Does that pic contain both the band and the song?
World is full of songs with black, white, gray, shade(s) etc in the name.
Oh, give a hint, pleez.
World is full of songs with black, white, gray, shade(s) etc in the name.
Oh, give a hint, pleez.
Never heard. Although I know Matrix games. It has published/made strategy games and it sells them only in the net. I had no idea they are now in full 3D games business.
You should try the demo from here.... at least I'm going to (only 86Meg)
http://www.starshatter.com/index.htm
You should try the demo from here.... at least I'm going to (only 86Meg)
http://www.starshatter.com/index.htm
Yes, I kind of talked bit about this in the previous (now locked) thread (or at least tryed to talk).
"Maybe a flag could be put into the MSO packet to tell if it came from the 'owner' of the LFS which is running this insim? Or even better if the connection (NCN) had an "IOwnYou" type flag for similar purpose. Or is there some other easy way to tell which connection owns this insim?
(in server use you could assume host is always the 1st connection, but not so in client tool)"
(by 'host' i mean the insim owner)
I think it should be in NCN. After all you don't necessarily have a car in use. If you know the UCID of the insim owner, you can compare it to UCID of the player (in NPL) and check that it is not AI. Of course it can be in NPL too, but in NCN it would be useful if you don't have a car out.
Right?
There are no tracks big enough for F1 class cars in Finland.
You need not just the track, but also all other facilities. Parking lots and public transport etc.
There was the Keimola circuit between 1966-78 and they drove e.g. F2 and F3 class races. It was used for international events too and some famous racers drove there. The track died partly because of insane traffic jams in and out of parking lots and nearby people complaining about noise.
And I thought this was about van Beethoven. You know, we used to call him just Ludwig among friends. Anyway he got deaf after playing LFS too loud with headphones and finally got sick and died when he ran out of unlocks.
FGED GREDG RDFGDR GSFDG