Messages

Normal riding the wheel speeds are reported as identical - i guess they must be 'normalised' somehow to allow for the variations in contact diameter. Difference only shows when braking.

You might not be aware of all the processes, how about this one 

http://www.infoworld.com/article/2612676/microsoft-windows/new-windows-7-feature-in-kb-2852386-reclaims-wasted-space-on-your-c--drive.html

Is it a SSD ? The drive will recover space during automated 'garbage collection' activities that occur when the PC is idle.

Thanks, i was wondering how it could occur without the bike tying itself in a knot. Strangely the default 990 does not seem to exhibit it to the same degree and seems to be about 1m/s difference with similar braking force.

Playing with my widget i can view front and rear wheel speed and the difference whilst riding.

With the default 125 i can observe that front braking with any useful but controlled degree of force (not locking the wheel) and the bike upright, straight and stable causes a difference of up to 3m/s difference in wheel speed with the front rotating slower than the rear. Not tried it with any of the more powerful bikes yet.

This seems to suggest either the front is always sliding to some degree or the rear is spinning up. Pretty sure i am not lifting the rear tyre and the throttle is shut, all braking assists are off.

Not sure it means anything, i am just wondering what causes this to happen, any ideas?

It just too extreme a difference, the 600 traveling straight in 6th gear will instantly just do a 360 back flip off the small bump. Its not even like its an overly developed wheelie, the bike just seems to rotate around its axis - very weird.

I think bike geometry issues are very likely playing with the Donnington track i was amazed at how easy it was to back flip the Yamaha 600 on the back straight but the default 990 just does a nice gentle 2 wheel off the ground jump at the same point under the bridge. The Yamaha geometry must provoke this response and is just not believable.

From my dabblings the biggest source of oscillations are on the bike lateral X axis. I was surprised at the magnitude of lateral vibrations compared to those on the vertical axis.

If you ask MaX very nicely he might be persuaded to add a bar meters to MaXHUD for X, Y and Z vibration magnitudes. I have them on my rig control widget and they are quite interesting to observe.

The numbers sound a lot like 32 bit restrictions, i believe this extends to page filed memory as well.

If you run 32 bit OS i think you need to enable Physical Address Extensions

How is the file written to disk? One big file or a series of files?

Is it stored in virtual memory before writing to disk or is it streamed direct to disk?

Does GPB have the old 32 bit file size limit of a bit less than 4GB maximum file size?

[Problem:]

Not sure this has been submitted as a "bug" even though it has been discussed elsewhere on  the forum.

But after tonight's race and the discussions there, I said I would submit it here:

Problem:
After a crash the probability of further crashes increases greatly.

Effect:
Many ruined/not fun races.

Possible Cause:
It seems to be tyre temperature related - during the crash/slide tyre temp increases too much causing further slides/crashes to compound the problem. But there may also be another reason.

Possible Fix:
Reset tyre temperature to optimum or tyre-warmer temperature when bike is reset to track / Don't allow tyres to overheat during crash / Don't crash(! not possible until physics improved) / Other reason

Temporary notice to riders:
After a crash, ride slower until temperatures come down it seems to help

Thank you. As always we are happy to assist with any testing that might be needed, to assist this, or any, fix.

I wonder if the tyre temp model is very simple and the localized temperature increase is applied to the whole tyre rather than averaged into the whole mass.

All good now  Acceleration outputs looking more like i was hoping for at 100Hz rate

Thanks, i will recompile,still getting to grip with C++

Bit confused, but am i right in understanding GPB should make the call to this function 'Startup' when the program starts?

FILE *g_hTestLog;

/* called when software is started */
__declspec(dllexport) int Startup(char *_szSavePath)
{
   g_hTestLog = fopen("gpbikes_log.txt","wt");
   if (g_hTestLog)
   {
      fprintf(g_hTestLog,"Startup\n");
   }

   /*
   return value is requested rate
   0 = 100hz; 1 = 50hz; 2 = 20hz; 3 = 10hz; -1 = disable
   */
   return 3;
}

I cannot see the file 'gpbikes_log.txt' on my system which suggest this never executes. As it also sets the data rate for GPB output i cannot see any reason to call it from my host.
Where would the default path for log file be?

Am i right jn assuming the rate the is how often the shared memory area information is refreshed?

Thanks

I don't understand why PiBoSo doesn't release an update every month. Even if it's only 1 little fix it would be amazing. Just to show that he's still working on the game and to motivate all the players/customers...

I have thought this too as a good idea for developers, it gives the community something new to play with and discuss and feedback so they keep keen and interested, but more than that it shows development is progressing and is a means of communication just on its own.
"ooh I wonder what update we will get this month!"

It might be an idea to use the model adopted by the opensource community; an official supported beta release with unsupported 'test builds' released more frequently for testing and bug reporting only.
This would allow the community to contribute by detecting bugs and gameplay issues before they are released in the next official beta release saving PB a lot of time testing and reducing disappointment in the official releases.