Topics

[RunLap()]

Hi Piboso,

I've found something I can't really explain: I take two tracks (Victoria and Paul Ricard Legend) and I do the exact same thing on the two, but I get different things out.

• Both tracks are such that the pit position (when only 1 rider is on the track) is before the finish line: exiting the pits the bike crosses the finish line (before the end of the pit lane).
• I join a testing session (offline), go to track, start from the pits and soon after having crossed the finish line (still in the pitlane) I crash the bike intentionally.
• The "respawn" sends the bike back to the pits position (i.e. before the finish line).
• Now moving again, I cross the finish line a second time.

Doing the above on both Victoria and Paul Ricard gives me two different behaviors:

• On Victoria, when I cross the finish line the 1st time, no RunLap() event is sent to the plugin (this is normal) while when I cross it for the 2nd time (after the crash and respawn at pit) I do get a RunLap() event.
• On Paul Ricard Legend, I don' t get any RunLap() event.

Any idea ?

MaX.

P.S.
In the default .csv telemetry files (I can send them if needed) two beacons are present in both cases (not a surprise that, just to confirm).

Hi Piboso,

I'm working on a telemetry software for GPB/WRS. The GUI part is mostly nailed: initially I went with wxWidgets but after a while I realized that the features I needed in terms of plotting graphs were simply not available and creating them would be too much for me. So I switched to Qt where a nice plotting package (QCustomPlot) seems just OK for my needs.

One thing is bothering me though: an output plugin is in charge to dump the telemetry data. That's not hard, except trying to slice all the data into laps.
The hard part is to slice in the same way as GPB/WRS do it, i.e. in such a way that the lap times recorded by GPB/WRS do match the ones in the telemetry data.

I've seen in the output of GPB default telemetry plugin that there's a bit of information that I do not have in the plugin interface: the beacon markers.

Code Select Expand

"Beacon Markers","106.444, 183.347, 268.056, 347.946, 485.568, 567.314"

These indicate the exact time at which a finish line crossing was recorded by GPB/WRS, leading to a lap being completed.

Is there a way to obtain this info ?

Because if I have to compute it from the telemetry data it's a bit of a mess: detection of finish line crossing can't be done properly without the finish line end points, some logic has to be implemented to handle multiple crossings in case of fall, etc...

MaX.

P.S.
Bonus question: how many splits are we supposed to have on a GPB/WRS track ? I was under the impression we had 3 splits for GPB and 2 for WRS (leading to 3 4 sectors for GPB and 3 for WRS), but I think I've seen a GPB track with only 3 sectors ... is this number fixed or not ?

Taken from here: 2014 KTM 1290 Super Duke R Review



OMG !

MaX.

http://www.youtube.com/v/1mqSCwLCs6I

MaX.

[In the .geom file, what is rear_length = 0.06 ?]

Hi all,

I put here a few questions I have no answer for (and nobody I've been in touch with neither). Would be nice if Piboso could provide answers (or others too, if they are really really sure)

• In the .geom file, what is rear_length = 0.06 ? Most seems to think it is the rear shock length (from fully compressed to fully extended), but it seems to have no effect at all. Also it would be not clear to me what this would be used for, given that we don't know where the shock is linked to the swingarm and chassis. I feel stupid.
• In the bike.cfg file, what are Damper and DamperPower in the steer section ? Probably related to some sort of steering damper, but how should we interpret them ?
• In the bike.cfg file, what are spg0, spg1  etc and KYaw, KDamping0, KDamping1 in the steer section ?



• In the bike.cfg file, what is ThrottleMapping0/1/2/3 in the ecu section ? Anybody seems to say "Easy, it's the throttle mapping". But nobody knows how to interpret the rpm0/1/2/3 and throttle params.

Plenty of unclear stuff on tires too, but I'll leave that for later

MaX.

Hi all,

when I run a command line like this:

Code Select Expand

"C:\Program Files (x86)\GP Bikes beta4b\core.exe" -mod gpbikes/gpbikes -testing

or like this:

Code Select Expand

"C:\Program Files (x86)\GP Bikes beta4b\core.exe" -mod gpbikes/gpbikes -testing -set params testing.ini

having this in my testing.ini:

Code Select Expand

[bike]
bikeid=varese_v594
paint=
helmet=default
helmet_paint=
riding_style=blend

[track]
track_id=victoria
[settings]
weather_realistic=0
weather_conditions=0
temperature=30
wind_direction=0
wind_speed=0
track_conditions=0


I still get the murasama (or whichever bike is in my profile.ini).

MaX.

Hi Piboso,

we used to have random's Telemetry Analysis software and it was good enough for our needs. But random is no longer here and his work is now useless, as no longer compatible with beta4 and future releases.

I think I've read on KRP forums that you were discussing possible alliances with some pro-grade telemetry analysis makers. Any news on that ?

I'm tempted to start something in terms of telemetry analysis but my dev skills are surely not enough to obtain something half-decent.
I started something in Python, but it's very limited in terms of features and a real mess to package and distribute.

MaX.

Hi Piboso,

GPB/WRS (as per beta4) make the track centerline available in the plugin interface.

Playing around with TrackEd I noticed that it seems to "automatically" generate the track limits, i.e. the two lines describing the track's "left" and "right" border (the white squares plotted when you generate the surface).

Would it make sense to make the two lines available in the plugin interface too ?
Probably it's not a big deal for an "HUD" style plugin, but they may be useful the day we have a decent telemetry analysis software.

MaX.

Just noticed, probably is irrelevant but ...
In the level0 section of chassis.hrc of the murasama, the name field is missing.

Code Select Expand


level0
{
scene = rc990.edf
switch = 0
}
level1
{
scene = rc990.edf
name = chassisb
switch = 5
}
level2
{
scene = rc990.edf
name = chassisc
switch = 10
}


MaX.

[@Track creators:]

Hi all,
I was wondering if it would make sense to be able to modify a track in a non significant manner (e.g. changing a texture) without having to publish/register a new version of the track.

Said otherwise: some track files are under a checksum to verify the track corresponds to the registered track. I'm under the impression that today, almost any possible change to a track leads to a new "version" of that track.

It may make sense to have only the "core" parts of the track (track surface, .rdf file, maybe something else) under the checksum, so that the rest could be changed wwithout creating a "new" track (a new track version).

For example, a track creator could focus on the track surface (and do minimal artwork on texture and environment) and release a v1 of the track: after some iterations the track surface is considered OK and we are at v5. Each version v1 .. v5 would be a different version for GPB. After that however, subsequent versions of the track will differ only in texture/environment, so that they would be considered as "same" version. Big advantages:

• Track creators can work on track surface first, nail that, and then tackle texture and environment.
• No need for stats reset for each version after v5 (in my example), unless some "core' part is changed, of course.
• A player with track v5 could connect to a server using v6 or v7 (as they only differ in "cosmetic" stuff).

It's more or less what happens with bikes and paints.

@Track creators: What do you think ? Is it interesting ?

@Piboso: reasonably doable ?

MaX.

Hi all,
this topic is for GPB images made more beautiful by your own talent with Photoshop and similar.

MaX.

[raw screenshots]

Hi all,
this topic is for raw screenshots: no retouching, no photoshopping, nothing except GPB own beauty.
OK, we may tolerate a little watermark in a corner, if you really want to.

MaX.

[[Thx to whoever created this section !]]

[Thx to whoever created this section !]

Hi all,
recently I was wondering about the rider positioning stuff and after thinking about what is in point 1 below, I went a bit further with what is in point 2.
Mostly it is something for Piboso to think about.

1. Split rider position from bike physics
As we have different bike mods on the same physics, today the rider is badly positioned most of the times.
Would it be possible to have rider positioning stuff (in the .geom file, rider, footpeg_lef/right, grip_leftpos/dir, grip_rightpos/dir and maybe even t-cam) in a separate file ?
This would allow different bikes to share the same physics but have the rider correctly positioned.

I know it's a minor abuse (cause the rider position influences the CoG and inertia tensor) but doesn't seem to be absoutely critical: I mean you could still compute them properly, but then allow bikes with different rider position to be considered as "same physics".

2. A step further
It is my understanding that today, when you create a new bike you have two possibilities:

• Use the 990 physics (for example), in which case you have to "stretch" the 3d model of the new bike to fit (as much as possible) the one of the 990
• Use your own physics, in which case you can create a true 3d model of your bike, but then you'll have to reflect the bike's geometry in the .geom file

If the above is wrong/incomplete, we can probably trash the rest of this post
Assuming it's OK, then here's the thing: it is clear that option 2 is the one closer to reality. However, option 1 has some interest IMO too: you could have visually different bikes (that's nice) using the same physics (so same bike performance). Also, you don't have to mess with the physics (and it's fairly long validation). Problem is, option 1 has that deformed bike ... bad ! So I was wondering if we could have something that allows us to have visually different bikes using the exact same physics.

I'm not 100% sure it is possible (that's where Piboso can shed light), but here's the idea.

For simplicity, let's imagine we want to create a bike that is identical to the murasama, but with a longer swingarm. We want the difference to be visual only: the bike behavior (physics) has to be the same. Today, the position of the rear wheel on the swingarm (which more or less define the swingarm length) is a parameter of the .geom file: if we change it to have the visual effevct we want, then we also change the bike's physics.
Let's say (values are not real ones) that the murasama rear wheel is positioned between min/max (0.0, 0.0, -0.5) - (0.0, 0.0, -0.6) while we want our new bike (the sukuzi ?) with the rear wheel between min/max (0.0, 0.0, -0.6) - (0.0, 0.0, -0.7).
The idea would then be to have 2 sets of parameters: one for the physics and one for the "assembling" of the 3d model. So the physics set would be identical as the 990 (i.e. (0.0, 0.0, -0.5) - (0.0, 0.0, -0.6)) while the "3d" set would be as we want (i.e. (0.0, 0.0, -0.6) - (0.0, 0.0, -0.7)).

This means that the bike will behave just like the murasama, but it will be rendered differently (as we want). The difference is purely visual, nothing else.
GPB would have to "map" the state of the bike physics (e.g. rear wheel at -0.55) to the corresponding value in the 3d world (i.e -0.65 in our example).
Notice that the gap between min/max does not have to be identical (0.10 here): it's just a linear map.

Just to give a simpler exmaple, imagine we want a bike that is just like the murasama, but 2 times bigger (scale X, Y and Z direction x2) and we want it to have the exact same physics.
This is trivially doable (when you render, render "twice as big"). Doing what I suggest is a bit more complex, but no too much.

I'm under the impression that this could be done for all the parameters that describe the bike's geometry today and that, at the same time, dictate the 3d assembly (so essentially all the purely geometrical parameters: no masses, CoG positions etc).

Notice that there's at least another parameter that has this double role (phjysics + 3d stuff): it's the wheel+tire radius, in the .tyre files (*).

Again, I'm not 100% sure it is doable, but if it is the case it could be interesting.

MaX.

(*)
You can make a funny test: take the murasama folder and edit the .tire file (quali front, for example), changing the radius to something much bigger (e.g 0.295--> 0.600) or smaller (-> 0.100), the go on track (select the right tire, of course) and see what happens

Hey you Mr.bean fans, any rugby follower here ?

I'll be at Murrayfield tomorrow hoping that the locals will spank you good, in case the defeat against France wasn't enough

Could be a 1st step towards an independent Scotland 

MaX.

[Real life -> GPB:]

Hi all,
there's some confusion on how GPB models the tire sizes, so let's try to write here what (I think) we know. Would be nice to have a confirmation all this is correct.
I won't discuss all the other parameters as many of them I do not have a 100% accurate idea of what they do, so here we'll look only at the ones at the end of the .tyre file (here from the 990 rear) and related to the tire dimensions:

Code Select Expand

Radius = 0.325
TorusRadius = 0.13
Width = 60

Radius is the overall radius (from rim center to radially farthest point on the tire tread), in meters. It's not the rim radius.
It is measured with the wheel suspended (otherwise the weight will compress the tire) and not rotating (at high speeds, the tire tends to "balloon" due to centrifugal forces, increasing the radius).

Torus radius: GPB describes the tire shape (or profile) as a torus (donut, for our american friends). This means that you can't have any profile you want (more or less V shaped), it's just a torus. It indicates the torus radius in meters. On this page (http://en.wikipedia.org/wiki/Torus) it would be the "r" (lowercase r) in the 3 equations under the Geometry paragraph.

Width = this is in degrees and it's the unusual thing. It defines the circle sector that describes the tire tread. In this image you have the cross section (one of the two, actually) of our torus/donut:

r is our TorusRadius, Theta is 2 x Width. For Width = 0 you have ... hmm ... a thin tire (just a conceptual thing), for Width = 90 (Theta is 180) you have the whole semicircle.

Usually tire dimensions are presented as 195/55ZR-17: 195 is the tire width in mm (the length of the horizontal line in the figure above), 55 is the relative height of the tire shoulder (55 means the shoulder is 55% of the width, in this case the shoulder is .55*195 = 107.25mm), Z is the speed rating (we don't care), R for Radial (we don't care) and 17 is the rim diameter in inches (hello, non-metric people !).

So how do we go from GPB parameters (Radius, TorusRadius and Width in degrees) to "real life" parameters (e.g. 195/55ZR-17) and vice versa ?

Real life -> GPB:

• 17 inches = 43.18cm = 431.8mm rim diameter ==> rim radius = 215.9mm
• Tire shoulder = 0.55 * 195 = 107.25mm
• Total (rim + tire) radius = rim radius + tire shoulder = 215.9 + 107.25 = 323.15 : that's GPB's Radius.
• For TorusRadius and Width (in degrees) we have to find two values such that 2 * TorusRadius * sin(Width) = 195mm. There're multiple solutions but, unless you can measure these from a real tire, you can assume Width to be 60 and hence compute TorusRadius as 195mm / (2 * sin(60)) = 113mm = 0.113 in GPB

GPB -> real life for the 990:

• The Width in m is given by 2 * TorusRadius * sin(Width in degrees) = 2 * 0.13 * sin(60) = 0.225m = 225mm (that's my kind of rear tire !)
• The rim diameter and tire shoulder are not really used by GPB. If you assume the relative height of the shoulder to be 50, then you have the shoulder as 0.50 * 225 = 112.5mm, hence the rim radius will be 325 - 112.5= 212.5mm, so diameter is 425mm or 16.7 inches.

@neoraptor: your .ggb file here (http://gpbikes-mods.wikia.com/wiki/Tyres) is hence probably wrong, as it says that Radius in GPB is the rim radius.

MaX.

Hi all,

just noticed this: all the bikes, including the default ones, except Juju's GSVR, have the bike stand badly positioned and/or not appropriate to the bike (i.e. they all use the default one which, surprisingly, does not fit even on the default bikes).

You can see it in the showroom (main menu) or when you select the bike.

I know, it's just a minor detail: I'm saying it just so that people know (not sure others have noticed).

MaX.

P.S.
Juju wins !

Hi all,
some info I was about to PM to some users and may be of interest to others here.

The noise of an engine has typically a "main frequency" (in Hz) equal to (Ncyl * RPM / 120).
That's for a 4-stroke engine, for a 2-stroke it's /60 instead of /120.

This frequency corresponds to the frequency of the detonations in the engine.

If you have a sample of an engine, throttle open at a fairly constant RPM, to get the main frequency (and hence the RPMs at which the sample has been taken), you need to plot the spectrum of the signal and find it's peak value. For example, you can use Audacity (free), Analyse/Plot Spectrum.

There are tons of technical parameters that require some knowledge in signal processing (don't ask, I will not try to explain, way too long).
Also, it gets a bit more complicate for sample with throttle OFF, as ... there are no detonations

MaX.

[NOT]

Hi all,
just to be sure I'm on the right path in my sound ramblings, I've taken some car samples ( ) and used them for the 990.

https://drive.google.com/uc?export=download&id=0BzmU7Qoo77i1Y0szcDhuVTRJQ0k

Download the .zip and put its content in the bike folder (any bike based on the 990 will do): it will NOT override any file.

The edit the sfx.cfg file of the bike and replace the engine.scl with engine.maxcar.scl:

Code Select Expand

engine
{
scl = engine.scl


Reload GPB and test (the Oval track is perfect for that).

OK, overall it sounds like shit, but that's probably because the samples are for a car and I used the just as they were.

Notice however that you hear almost no overlapping between samples: the transition from one to the other is nearly perfect (also the samples were perfectly loopable).

It is even more clear when you use the (also provided) engine.maxcar-nooff.scl, in which all the samples of the OFF layer are muted (so there's no ON/OFF blending or mixing).

That's because the Pitch computations were done correctly.

That's how they should sound. Now we need good samples (but that's not easy).

MaX.

[@Piboso: YOU.RULE.MAN.]

Easy, because no other game can do that:

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

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

Obtaining the above behaviors without any canned animation (e.g. the high-sides in MotoGP 13) is just freakin' amazing !

@Piboso: YOU.RULE.MAN.     (yeah, no big news here)

And now, a quiz for physics modders: somebody able to explain why, in the 2nd video (where I intentionally keep the throttle open while braking with the front) the rear wheel hops ?

You get it wrong and you'll only be allowed to mod scooters and choppers

MaX.

HI all,

when I watch replays I'm often in a situation where I use one of the trackside or spectator cameras, but I'd like to roam/move/zoom it a bit.
Today if I want to do that I have to use the Free-Roam camera, but that obliges me to "fly" all the way from the finish line to the spot I like.

Wouldn't it be better if, whichever cemera we are looking at, selecting the Free-Roam camera will automagically put its initial position (and direction) exactly where the current camera is ?

MaX.