Messages

The reflections' resolution was kept low on purpose, to cheaply simulate the "blurriness" of reflections.

I think that's smart. Maybe worth seeing if a resolution a bit higher (for the reflection) is a better trade off.

One thing I noticed on the video (not sure if it's a problem of the track or of the engine): between 0:00s and 0:04s you can see the reflection and the shadow.
But from 0:04.5s, the shadow disappears (there seems to be a change in the track surface)..

Also, when we do see the shadow, should the shadow be blurred too ? It looks a bit strange to have the reflection blurred but not the shadow.

BTW, which KRP track is that one ?

Rye House.
Sorry for using KRP screenshots in a GPB discussion, but this track is the one with the best reflections.

New screen with quadrupled resolution.
Probably a better compromise, as you suggested.

The asphalt is obviously better with puddles and a nice bump map, but I mean the real-time reflections, I think in any surfaces you can notice the pixels effect.

The reflections' resolution was kept low on purpose, to cheaply simulate the "blurriness" of reflections.

Is possible with some hidden option to improve the quality of the reflection in the wet? As seen in this clip are really ugly. 

The main problem is that the asphalt shouldn't be a smooth mirror.
It should have puddles and a normal map, too.

With proper art reflections look more realistic.

day off


http://www.youtube.com/v/-jB_QM73Slk

* GPB / WRS / KRP / MXB: synced them all to the latest codebase

* GPB / WRS / KRP / MXB: added the yaw angle to the plugins track position

* WRS / KRP: added the steer input to the plugins vehicle data

* GPB / MXB: added the lean angle to the plugins vehicle data

* GPB / WRS: added support for gear shift and pit limiter flashing rpm lights

* GPB / WRS: ported from KRP support for the RPM sensor resolution


http://www.youtube.com/v/g4flAZEgtjs

Had some discussion with DD and i am very confused.

As i understood it direct lean OFF places the virtual rider in control of the bike and he rides the bike for you based on the limits of the physics model and your steer vector request.

Direct lean 100% overrides the virtual rider steer input and allows you to input whatever you like directly as a steer vector, the physics responding to this possibly exaggerated input.

The bike handling/physics response is very different between these 2 extremes.

I do not want to discuss the merits of each, but what is the 'correct' model for the bike control? I seem to remember from the very early alpha(1?) that direct lean was not an option so i assumed 0% direct lean with full virtual rider control is the full simulation mode. DD assures me that 100% direct lean is the full simulation mode.

Very, very confused as i can only ever see the physics being a compromise to satisfy the controller mode at the moment.

Help.....
h106frp

The direct lean slider only adds an input filter, even at 100%. The physics is exactly the same.

* GPB: added support for multiple displays


http://www.youtube.com/v/_uyRgcRSU9o

Sorry 

The tail light (not the rear brake XD )

It is already supported.
"brakelights" under the "chassis" section of the gfx file.
http://forum.piboso.com/index.php?topic=1279.msg38343#msg38343

Sorry H for the little semi-OT 

@Piboso In the beta 9 will be possible add a texture for the rear brake lights?

How does the rear brake light work?

Is it possible to declare more that one LCD texture (w_texture) in the gfx.cfg file?

I would like to create separate displays for gear position and lap time

Thank you

It is not possible, unlike WRS.
Support will be added in Beta9.

* GPB / WRS / KRP / MXB: a little improvement for mouse and resolution debug

* WRS / MXB: improved terrain rendering: http://forum.mx-bikes.com/index.php?topic=1118

* KRP: recorded and published a new video: https://www.youtube.com/watch?v=GFYakoZ-u64


http://www.youtube.com/v/O3pz4eDrm7Q

* KRP: data tuning


http://www.youtube.com/v/rrZytaHypR4

Cool

How does the game handle it when using different bikes? (assuming a gp125 isn't going the be the same race distance as a gp1000)

The lower race distance is used, to allow every bike to finish the race.

Proposal - would it be possible to make the servers auto-save the replays PER SESSION rather than PER EVENT? (More often than not the replay is split anyway before being provided for others to download - so some labour saved there too). This would make replay files smaller, more easy to locate sessions, more likely to record full sessions and more chance of being successful on a wider variety of server specifications.

Added to the TODO list.

[defaulteventlaps=28]

In the tracks .ini

[race]
defaulteventlaps=28
reflaptime=121

That data is not used anymore and can be removed from track INI files.