• Welcome to MX Bikes Official Forum. Please login or sign up.
 
August 14, 2020, 10:39:02 AM

News:

MX Bikes beta14e available! :)


Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - HornetMaX

1
Plugins / Re: MaxHUD plugin
August 11, 2020, 08:58:23 PM
V2.2.1 out (2020/08/11)
  • Reduced by 50% the number of quads used by HUDMap: fps impact of MaxHUD should be lowered (especially on long tracks / low-spec systems).
  • All timings can now display longer times / gaps.
  • HUDLiveGapBar has now more options for its scale (can be longer, for veeery long tracks).
2
Plugins / Re: MaxHUD plugin
August 09, 2020, 03:07:46 PM
Quote from: iNsane | WW on July 05, 2020, 09:55:22 PMhey Max, while we are testing Erzberg which was the reason MXB got support for +50 Checkpoints, the plugin makes the game laggy as hell.
Someone with AMD setup got 15 fps, I had 30-40. Removing MaxHUD resolved the issue, AMD has 80 fps and I with everything maxed out suddenly have 80-100 fps.
OK, I had a look, here are my findings.

  • On my systems (i5-9600K, RTX 2070 super, 3440x1440, all MXB settings maxed out except AA at 8x) my fps at Kreken (start point) drop from ~170 (no plugin) to ~70 with the plugin. Ouch.
  • If I compile the plugin without the HUDMap widget, I get ~160fps so the problem, as expected, is in HUDMap due to the very long and twisty track.

The main reason is that HUDMap takes the track centerline (straights + arcs) and approximates it with straights only: in doing this, the number of centerline segments goes up, e.g. for Kraken the centerline has 1493 segments (469 straights and 1024 arcs) but after approximation I have 7041 straight segments.

Now for each segment I draw 4 quads: 1 rectangle for the "main segment" and 1 wider rectangle wider to have the track borders, plus 1 triangle joining two consecutive rectangles in a turn (and another "wider" triangle for the track border). Bottom line, that makes 28K quads and that maybe too much.

One thing you try immediately is edit the MaxHUD.ini file, find the [HUDMap] section in it. It should be as below:

[HUDMap]
_ini_version=2
_enabled={1,1,1}
_pos_x={0.721875,0.721875,0.721875}
_pos_Y={0.123611,0.123611,0.123611}
_pos_linked=1
_optlinked=1023
_color_back=[200,0,0,0]
_color_track=[255,0,0,0]
_color_trackborder=[255,230,230,230]
_color_me=[150,0,0,200]
_color_others=[150,0,128,205]
size={3,3,3}
rotate={0,0,0}
range={1,1,1}
show_racenums={1,1,1}
show_range={1,1,1}
track_width={5,5,5}
trackborder_width={1,1,1}
show_background={1,1,1}

In it, you can add these two lines:

_abserr = 0.500
_relerr = 0.002

The above values are the default ones. If I change _relerr to 0.020 (instead of 0.002) I get 120fps (instead of 70) for 3183 centerline segments (instead of 7041) and 12788 quads (instead of 28220). Of course in HUDMap, if you zoom a lot, the turns will be less smooth than before.

Explanations of the two parameters: the plugin needs to decide how many straight segments to use to approximate one arc. It picks the numebr of segs so that the error (distance between the "true" centerline arc and the sequence of approximating segments) is below a value. The value is dictated by the two parameters:
  • _abserr is absolute error, in meters (default - 0.5m).
  • _relerr is relative error: you multiply it by the arc radius and you get an absolute error (default = 0.002 means that for a turn with a radius of 4 meters, the allowed error is 4 * 0.002 = 8mm).
  • The min of the two errors is used.

So you can play with the values, that should help a bit.

On my side I can probaly cut the number of drawn quads by a factor 2, drawing a trapezoid instead of a rectangle + a triangle. That's on my todo list :)

Final word, I really think Piboso should have the HUDMap feature in MXB & co: surely he'd do it 10 times better and in a way more efficient manner.
3
Plugins / Re: MaxHUD plugin
August 07, 2020, 01:13:47 PM
Quote from: okwes on July 05, 2020, 03:59:06 PMWould it be possible to have the live timing go further than 9:59.99 for one lap? I'm wanting to use this for Enduro, where the lap time will be over 1hr
Yeah that's easy. Won't look very pretty in cases where one lap/split can be below/above 10min as it will show (example) 9:55.123 (below 10min) and 00h10:45 if above but guess that would be ok.
4
Plugins / Re: MaxHUD plugin
July 23, 2020, 09:31:12 PM
Hmm it's 40Km long, that's likely the reason. I'll have a look when I have the time.
5
Plugins / Re: MaxHUD plugin
July 23, 2020, 10:58:35 AM
Quote from: iNsane | WW on July 05, 2020, 09:55:22 PMhey Max, while we are testing Erzberg which was the reason MXB got support for +50 Checkpoints, the plugin makes the game laggy as hell.
Someone with AMD setup got 15 fps, I had 30-40. Removing MaxHUD resolved the issue, AMD has 80 fps and I with everything maxed out suddenly have 80-100 fps.

Is this anything you can resolve? I think it's due the amount of CPs. Erzberg has around 400ish.

Hi, sorry for the delay, I was on vacation (and I don't get any forum notification).

Not sure the number ofd CPs is the cause, the plugin doesn't even see them. Is there a place where I can download the track so that I can have a look ?

P.S.
I've PMed you my email, will be faster to communicate this way.
6
Plugins / Re: MaxHUD plugin
May 06, 2020, 11:08:39 PM
Quote from: 𝖙𝖋𝖈 on May 06, 2020, 07:17:07 PMOooh Max, thank you very much!

Can I make a request for the next release? Would it be possible to disable the helmet if in 3rd person? I frequently change from 1st to 3rd and keep having to turn the helmet on and off.

Thanks again!
Hi, no I cannot do that: the plugin has no idea if you're 1st or 3rd person.

But that's why I've created the profiles: you can have (for examples) one for 1st person and one for 3rd person.

It's harder to explain than to use :)
Each profile has the on/off status of each widget. Additionally, you can choose for each widget:
  • if its position is the same in each profile or not (the "pin" button)
  • if each widget parameter is the same in eah profile or not (the "link" button)
Bottom line: you can have 3 different setups of the widgets and switch between the 3 clicking on the "P1" / helmet button.
7
Plugins / Re: MaxHUD plugin
May 06, 2020, 04:40:36 PM
V2.2.0 out (2020/05/06)
  • Important: there are new files in the MaxHUD_data fodler: please copy the whole folder.
  • All the widgets that had the option to show or not a background can now also use a .tga file as background. Click on the menu option to know the file name each widget is expecting (in MaxHUD_data folder).
  • HUDMap: Improved track drawing. Now plots a border along the track. Width and color of track and border can be
    configured. Track width and track border width have a "fixed screen size" option. Warning: widget configuration will be
    reset.
  • HUDStandings: some cosmetic rework. Warning: widget configuration will be reset.
  • Fixed some scaling/aspect ratio bugs.
  • Some cosmetic changes all around.
8
Plugins / Re: MaxHUD plugin
March 15, 2020, 09:13:31 PM
Quote from: JNS47 on March 11, 2020, 07:41:50 PMI'm not sure if I have the latest version or if the bug got already reported, but live gap bar on testing keeps running when you pause (press escape). Or not exactly running, it freezes as it should and if you resume, the time you had it paused gets added.
This comes from the fact that MXB internal timing reported to the plugin has a bug(*): it has been reported a long time ago (years) but it is still unfixed. Due to that, in order to have reliable timing info in the plugin (what is used for the livegap stuff), I use Windows precise timer, which of course is unaware of the game being "paused".
Handling the pause state in the plugin would be a bit messy, so I didn't do it: the plugin livegap stuff will be off if you "pause" (as you reported).

All this won't happen if MXB timing was fixed.


(*)
The MXB (and GPB, RS, KRP) timing problem only affects the timing reported to the output plugin (i.e. the lap times MXB reports are correct). What happens is that the timing info in the calls to RunTelemetry tend to drift over time (multiple laps).
If I recall correctly, the problem may come from the way the integration time steps are summed (due to finite precision).
I think I even provided PiBoSo with a link to a more accurate way to do the summation (in case this was the origin of the issue).
9
Run the full profile a couple of times here, no issue.
10
Plugins / Re: MaxHUD plugin
January 23, 2020, 09:38:13 PM
V2.1.8 out (2020/01/23)
  • HUDTiming: LiveGap now shows only one livegap (the one from Windows timer, as the game's own timing passed to the output plugins drifts away over laps).
  • Change LiveTiming due to a bug discovered in MXB (see http://forum.mx-bikes.com/index.php?topic=3143.0). Should have no impact (aside mitigating the MXB bug).
11
Bug Reports / Re: Telemetry bug ? (+ bonus bug, maybe)
January 15, 2020, 02:00:29 AM
Quote from: PiBoSo on January 14, 2020, 07:04:04 PMThank you for the report.

Unfortunately it's not a simple bug, but rather a code design error, that also causes other issues, like the inability to reset the bike under a bridge.
The problem will be fixed as soon as possible.


Thx a lot for the info !
12
Plugins / Re: MaxHUD plugin
January 15, 2020, 01:59:48 AM
I guess you've seen PiBoSo comment in the bug thread so yeah ... let's wait for the fix.

To be honest I could try to put in place a workaround in my code, but it's such an ugly one I'd prefer to wait for the proper fix from PiBoSo.
13
Plugins / Re: Output Plugins
January 13, 2020, 10:59:13 PM
One small request: could you document what exactly is in the argument _pRaceData of TrackCenterline ?

__declspec(dllexport) void TrackCenterline(int _iNumSegments,SPluginsTrackSegment_t *_pasSegment,void *_pRaceData)
My understanding is that you have some floats indicating the position along the centerline of the start/finish line, then the split points and the speed trap.

Is it correct to assume (as not documented) that:
  • GPB has 1x start line, 3x splits, 1x speed trap
  • MXB has 1x start line, 2x splits, 0x speed trap
  • WRS has 1x start line, 2x splits, 1x speed trap
  • KRP has 1x start line, 2x splits, 1x speed trap
14
Plugins / Re: MaxHUD plugin
January 13, 2020, 10:42:43 PM
I had a look and, as far as I can see, the problem is not in my code.

I've found some weird data being passed by MXB to the output plugin: in a nutshell, the "position" of the bike along the centerline (what PiBoSo calls fPos in his plugin interface, a float between 0 and 1) has a very weird jump back (something like you're 1515m down the track and then for a few tenths of sec you go back to 196m and after that you're back to 1919m).
This confused my livetiming (well, no wonder :) ).

I've created a bug post for PiBoSo (here), let's wait for some feedback from him.

P.S.
I haven't received a forum notification (e.g. when somebody posts something in this thread) in ages, so I may not be super reactive answering this (guess it's something like gmail blacklisting the forum for whatever reason).
15
Bug Reports / Telemetry bug ? (+ bonus bug, maybe)
January 13, 2020, 10:37:29 PM
@PiBoSo:

In the thread of my MaxHUD plugin there's a report of a strange behavoiur of my LiveTiming (posts from tfc and teeds, from here).

What my LiveTiming does is to save the position (fPos) and time (fTime) in an array all along a lap (your best lap).
On subsequent laps I do the same in a different array and hence I can compute the time gap at the current point on the track, between the ongoing lap and the currently best one.

The RunTelemetry call of the output plugin seems to receive some weird data, here's an example (relevant part only):

@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.763742, fT:154767.734375
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.763926, fT:154788.375000
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154804.046875
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154825.359375
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154843.796875
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154867.578125
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154887.109375
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154907.015625
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154926.875000
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154945.796875
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154965.390625
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.099025, fT:154984.546875
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.765946, fT:155003.312500
@@@LiveGap Telemetry (WIN) step 1: iB:0, iC:1, fP:0.766131, fT:155022.921875

As you can see, fPos is 0.763742 on the 1st call (1st of the ones shown here), then 0.763926 on the 2nd but on the 3rd it goes back to 0.099025 and stays there for a few calls (10 in this case), before resuming with more normal values (0.765946 then 0.766131). This of course screws up my LiviTiming thing (and makes some weird telemetry graphs :) ).

Notice that the point at which this happens has nothing special (no crashed bike).

According to tfc and teeds, this seems to happen only on some tracks. I can reproduce it systematically on Ironman track: drive first lap out of pits and on the second lap (1st "real" lap) it happens always for me. So my LiveTiming of the 3rd lap is screwed.


P.S.
Another weird thing, likely unrelated.
On Ironman when you go to track from the paddock you don't cross the start/finish line, but the ghost of the 1st lap out of pits is recorded anyway. This is probably unwanted (the 1st lap out of pits is not considered as a valid lap by MXB anyway, in terms of timing).