Topics

[@Piboso:]

@Piboso: random questions on fields in racedata stuff. What do these mean/indicate ?

• m_iSessionState in SPluginsRaceSession_t / SPluginsRaceSessionState_t / SPluginsRaceClassification_t
• m_iState in SPluginsRaceClassificationEntry_t / SPluginsRaceCommunication_t
• m_iPit in SPluginsRaceClassificationEntry_t
• m_iActive in SPluginsRaceVehicleData_t

Can we have some information about how to create a .fnt that we can use in GPB ?

Or, if that's not possible/too long, can we have a monospaced font to use (the current main.fnt is not monospaced) ?

That would save me quite a lot of hassle

From the daily dev:

* WRS / MXB: started work to support extra centerlines

What's this ?

[@PiboSo:]

@PiboSo: having the vehicle attitude (Roll/Pitch/Yaw are probably enough) in the SPluginsRaceTrackPosition_t structure could be useful.

Unless you're using it for "serious gaming"

http://techreport.com/news/30185/crytek-releases-cryengine-source-code-on-github

Quite a demo video though:

https://www.youtube.com/v/vF1zjDSqPoo

I really hate the far mountains in NC Mugello: their color is weird.

It's due to the fog (in the track .amb file): the way it is implemented in GPB means that if you push it too high, the objects far away will have horrible colors.

It's an old problem (see http://forum.piboso.com/index.php?topic=1174.msg14042#msg14042) and it affects other tracks too if I recall correctly (e.g. http://forum.piboso.com/index.php?topic=958.msg14312;topicseen#msg14312, not sure it has been fixed).



Rant over

P.S.
Yeah, I was testing some plugin stuff

Many RaceData structures reference a vehicle via its m_iRaceNum. Data relative to a vehicle is kept into an array of SPluginsRaceAddEntry_t.

So a plugin must keep track of all the entries (i.e. duplicate the SPluginsRaceAddEntry_t structures and keep them in sync with the one in the game every time  RaceAddEntry() and RaceRemoveEntry() happen) and each time it has to "search" for the m_iRaceNum in the stored structures, which is bad.

Wouldn't it be easier if referencing was done directly, like this (I take SPluginsRaceVehicleData_t as an example):

Code Select Expand


typedef struct
{
/* int m_iRaceNum; */
        const SPluginsRaceAddEntry_t  *m_psRaceEntry;                 /* pointer to const SPluginsRaceAddEntry_t structure */
int m_iActive;
float m_fRPM; /* engine RPM */
int m_iGear; /* 0 = Neutral */
float m_fSpeedometer; /* meters/second */
float m_fThrottle; /* 0 to 1 */
float m_fFrontBrake; /* 0 to 1 */
} SPluginsRaceVehicleData_t;


The same could be done for SPluginsRaceLap_t, SPluginsRaceSplit_t, SPluginsRaceSpeed_t, SPluginsRaceCommunication_t, SPluginsRaceClassificationEntry_t and SPluginsRaceTrackPosition_t.

In fact, I think you could even get rid of RaceAddEntry() and RaceRemoveEntry() calls completely if referencing was done as I suggest.

http://speedandengines.com/2016/04/10/some-harley-motorcycles-plagued-by-death-wobble-video/

While riding in 1st person view, when one looks left/right the camera gently turn left/right, that's good.
But when one looks back, the camera instantly switches to the back view.

Would it be possible to have it do something like when looking left/right (i.e. gently turning back) instead ?

Also, it shouldn't look "fully back" (180deg with respect to the forward direction), but something less.
In fact I'd be much in favor of the following: no look-back button at all, just look left and look right buttons.
The more you hold the look left button down, the more the head turns left (up to a max of, let's say 90-120 deg, or whatever makes sense).

http://www.cycleworld.com/tamburini-t12-massimo-superbike-first-look-motorcycle-review

I compared the 1st person view with the same settings (fov=75, pitch = 50) and to me there's too much difference between the murasama and, for example, the 916 and the nr750, see below.





I see only two possible solutions:

• Modders try to harmonize their 1st person point of view to be similar (not necessarily identical) to the murasama.
• PiBoSo allows us to have the pitch setting tied to a bike (i.e. the pitch is saved per bike).

I'm not sure we'll ever get solution 2 (there may be good practical reasons for that), so ...

Or if we're convinced the murasama 1st person point of view is "bad", then we should try to harmonize across our mods.

I print out the value of _iState in each Draw() call,  whenever it changes from one call to the other. The documentation for _iState says:

_iState: 0 = on track; 1 = spectate; 2 = replay.

(except for KRP, which only mentions values 0 and 1 for on track and replay, strange).

I start GPB and start a testing session (offline):

• When I go to track, state is 0 (OK to me).
• If while on track I press ESC and click on "Replay", state is 2: seems wrong. Should it be 1 ?
• If I go back to the pits and press ESC, state is 1 (OK to me).

Online the problem doesn't exist, as you can't press ESC and then click on replay (you have to go back to the pits).

If from GPB main menu I load a saved replay, state is 2 (which is OK).

Didn't check the other sims, I'm getting old and lazy.

Hi all,

out of curiosity, is there anybody with a 21:9 screen and using it with GPB/WRS ?

Can you say which model you have and if it works fine with GPB/WRS ?

https://ideas.lego.com/projects/137977

https://www.youtube.com/v/fO3XCtK4Fdo

http://www.popularmechanics.com/science/energy/a20406/single-atom-engine-works/

And it's a 4 strokes !! 

@track modders: have a look at this: http://forum.mx-bikes.com/index.php?topic=888.msg14944#msg14944

I'm not sure if you're (all) already aware, but you should

Current Aragon for example has mountains far away that are not in the background model: this means that they are rendered only if they are below the drawdistance which, by default, is 1Km (max value in game). So they appear and disappear as you goL: very bad looking. A workaround is to manually increase the drawdistance in the profile.ini, but it's very annoying as as soon as you enter the GPB settings page/menu it will overwrite it (like the fov thing).

[tyres]

@Piboso:

why do we now have, in the bike's .cfg file:

• A (new) tyres section, referencing a new .cfg file (e.g. m_gp1000_03.cfg for the 990)
• A wheel0 and a wheel1 section containing tyre0, tyre1 etc sections, each referencing a tyre via its ID (and adding to it a name and a numsets value)

And in the m_gp1000_03.cfg file:

• A wheel0 and a wheel1 section containing tyre0, tyre1 etc with an ID and a params file (.tyre)

It seems over-complicated, I really don't see the need for the m_gp1000_03.cfg file: the tyre0, tyre1 sections in the bike's .cfg file could simply reference a .tyre file, no ?

Fiddling around tonight I've found this:

• I start GPB, the current bike is the default 990 (default skin, default helmet and helmet paint, default rider suit paint).
• If I have 100 paints or less for the 990, then everything goes fine.
• If I have more than 100 paints for the 990, then as soon as I switch bike to the gp500 category, GPB crashes.

Which paints are in the 100 doesn't seem to matter: whichever paint I add as 101th paint, GPB crashes.

I can't recall exactly but I think somebody reported something similar a while ago.

https://www.youtube.com/v/S7yeV2B8Iv8

[@PiBoSo:]

@PiBoSo: would it make sense for a single track to work in any of the sims (GPB, WRS, MXB, KRP) ?

I'm under the impression that today we need to duplicate the track and change some minor details (race data) to adapt it to this or that sim specificities.
It's bad as we end up downloading and storing 2 times 140MB, where the two copies are essentially identical.

A smart mechanism could also be put in place so that all the sims take the tracks from the same common folder (or one can hack this with a hard link).

I'm asking as with pitbikes in MXB, SM bikes in GPB etc we see more and more common tracks ...