Quote from Dygear :

Bullshit. That reeks of GT4, look at the fence detail, look at the tirewall detail. It does not have the texture level that GT5 has and it has no anti aliasing. It's just GT4 on the PS2 in 1080i or 720p and someone is passing it off as a GT5 screen shot. I think that proves that GT4 had some great graphics for it's time.

Supported by the fact that the image is missing 300px in width, quite possibly the bit that reads "GRAN TURISMO 4 / ©SCEI"

Quote from dawesdust_12 :

This is Forza model of a Nascar:
[img]http://www.vidgames.com/ps/screens/dderby7.jpg[/img*]

You can tell that's no NASCAR game due to the fact that it permits the car to rotate clockwise, which allows for a right turn. We all know there's no such thing in NASCAR
Do I get bonus points for recognizing the Psygnosis owl?

My nickname is easily tied to my real name, which is in the phone book. No point in trying to hide, /b/ would find me if they wanted to

Quote from Boris Lozac :

With samples, yeah, it's WOW to someone sitting next to you, not actually while driving it, no? I can't believe that on LFS forums, people don't think syntethic engine sound is better then samples..

Yes, in theory synthetic sounds will reproduce the actual engine sound with higher accuracy, in relation to the listener position, the sound deadening between the source and the listener, the environment and so on, or in short: occlusion, reverberation and obstruction. LFS's (and GT5's for that matter) synthetic engine sounds, however, are a joke. I'll take samples any day, thank you.

Quote from danthebangerboy :

Its BBcode, not vBcode.

For as long as I can remember, it's been called vBCode in vBulletin.
They seem to have changed it now, but it's still listed in the manual.

Quote :

BB Code (or vB Code) is a method by which your members can format their messages. Its syntax is similar to HTML, but it has the benefit that you (the administrator) can define exactly what codes are allowable in order to prevent unwanted formatting or malicious use. It is also less prone to break the layout of your forums than raw HTML.

Edit: Have a look at the FAQ, it's almost exclusively called vB code there.

Quote from dawesdust_12 :

I did not know that VB code existed.. although then you decide to bold one of the brackets, instead of using *!4828493!*

Not one bracket, all of it, because I wanted it bold and noparse would have caused that not to be parsed as well... although now it occurs to me, I could have just... [thread][/thread] nested it that way

Haven't posted here in a while, can't seem to produce any good material for some reason. Some "meh" stuff:

The plural of photo is photos. Also, we already have a thread for this.
€: I'm so slow -.- However, I am the only one making use of the correct vB-Code, [thread][/thread]

Quote from Matthewrobinson :

I put my ip in and my port of my insim and my adminpass but it dont work can some 1 and an image showing me how to do it but with out ur detail and just put words in the boxs please some 1 please help

No. It's all there right in front of you, you just need to carefully read the instructions and follow them precisely.

Good stuff

That's called circular dependency and you've already figured out the solution

Click here, click the "Insim relay" tab and add your host. If the connection is established successfully (you may have to open your InSim port for incoming traffic if you're behind a FW/router), the host will show up in the LFS Remote hostlist and marked with "R" in the LFSW hostlist.

I'm not quite sure I understand your problem, but if you're talking about what I think you're talking about, #include guards or the #pragma once preprocessor directive should help. The latter is faster but non-standard, so only use it if you're not terribly concerned with portability.

Quote from brandons48 :

Thank God i'm capable of getting real girls

Are you absolutely certain they're real?

LFS doesn't use any kind of complex send -> acknowledge -> confirm system, meaning the client doesn't have to wait for the server's response to execute the issued actions. All clients continuously send position updates, at a fixed interval but also when input changes, whichever applies at any given step. The receiving end (the server) will always re-distribute the most recent update it has available, possibly flagged as lagging if the packet exceeds a certain age.

As a result, your local simulation is always running at 100Hz (tyres at 2000Hz) and your input is as "real time" as this stepping allows, regardless of network latency.

Of course, only Scawen can explain the exact inner workings, but that's basically how it is (or how I think it is and am reasonably certain of).

Hard to believe, no NAT settings page? Perhaps via telnet/ssh?
What about your friend's router?

Quote from MattsterGT :

donate at:http://www.amazon.co.uk/Sennhe ... qid=1289924766&sr=1-2

Pretty sure Amazon and Sennheiser will survive without donations
I believe you meant to post http://www.bbc.co.uk/pudsey/donate/

UPnP doesn't take care of the forwarding, it allows applications to take care of it, which LFS does not. Manually configure the forwarding, both UDP and TCP, to the relevant port (default is 63392 IIRC) and you should be good to go

Hmm I don't remember Turok selling too well, any of them really... and they had plenty dinos

That's up to you, the documentation leaves plenty of room for various interpretations and the client will happily display buttons sent, even if the user just hit Shift+I. Basically it's:
Buttons visible: Shift+I -> BFN_USER_CLEAR
No buttons visible: Shift+I -> BFN_REQUEST

That also means it is possible for an InSim app to receive a USER_CLEAR and a REQUEST in such quick succession that the USER_CLEAR will not have finished processing by the time the REQUEST is received, because the client does not wait for acknowledgement of the receiving InSim app.

I believe Lapper brings up a menu when it receives a USER_CLEAR, but as I said, I wanted to stick to what my interpretation of the documentation tells me it was intended for, simply clearing or requesting buttons.

Quote from Dygear :

Oh come on morpha! You where one of the guys that where so happy to be pushing PHP to it's limits! Where did that enthusiasm go? What happed to it?

It just suddenly faded, could return just as quickly, who knows

Quote from Dygear :

Yes, again your correct. I should be capturing the Shift+I event and I ignore it completely. That will also be fixed in 0.3.2 as it's an unacceptable oversight. The idea behind the zero width & height button detail is that you could update the button without knowing where it was on screen. Not sure how useful that is any more come to think of it.

Even if you account for Shift+I the invalid dimensions issue is not completely resolved. The client clears the buttons immediately, but the server could (and in my case did quite frequently) still send buttons before the BFN_USER_CLEAR reaches it, resulting in invalid dimensions. The only bulletproof solution is to always send the dimensions, which PRISM can maintain a list of so that the plugin does not have to.

How to handle this properly depends on what you want Shift+I to do of course, in my case I wanted to preserve the original meaning, i.e. clear all buttons and keep them turned off until Shift+I'd again (sending a BFN_REQUEST), translates to $user->receive_buttons == false if you will. To make sure this works, I do this (essentially):

• receive BFN_USER_CLEAR
• set $user->receive_buttons to false, stopping the button manager from sending buttons to that connection.
• send a BFN_CLEAR to clear any buttons that might have been sent between the client side clear and the arrival of the BFN_USER_CLEAR, or more accurately the $user->receive_buttons = false.

Quote from Dygear :

Fixed the way text is sent to the screen when you go past the limit of the packet, now smartly spans muliple messages where available.

I wouldn't say smartly, it doesn't preserve colours, escape sequences and charsets. You'll have lines ending in '^' followed by a line starting with [0-9vacdsqtlrLGCJETBHSK], multi-byte characters could be cut up mid-sequence and even if not, will be output as complete garbage in subsequent lines due to the assumed latin-1 charset. I cannot offer a solution, but it shouldn't be too difficult

Quote from Dygear :

From there, I set it's width and hight to zero to tell LFS to ignore all details of the packet except the Text field and the ClickID, so that I update only the text in that button.

Bad idea, always send the dimensions or you will have "Invalid dimensions" errors popping up eventually, I guarantee it. Just takes someone to Shift+I, or in rare cases just to join at the wrong time, or to join when the connection queue is desynchronising (you'll find a discussion about this bug somewhere in the InSim improvement suggestions thread I think) or some other bug, it just happens, trust me.

Overall though I'm very impressed with the progress PRISM has made and still appears to be making

Quote from jibber :

That's what i mean... who wants to drive a freaking Mercedes AMG? All the wrong cars are premium cars... (with some exceptions).

If it sounds the part, I certainly do... although I wouldn't actually have to drive, I could just rev it standing still

Shift+U -> D
Your virtual measuring tape, if you need even more precision you'll have to work with the track meshes.

Last edited by morpha, Sun, 14 Nov 2010 21:23. Reason : typo