mdd client proxymod 0.0.1.0

[dqopb]

Another thing is the annoying window which pops up when I change the map.
Didn't notice it in the first test.

MddCgameProxyModv0.0.1.0.png

[<hk>]

Another thing is the annoying window which pops up when I change the map.

Yes, that is client dependant. As far as I know only the original quake3 client and dfengine pop up that warning. However you can get rid of that messagebox by setting
com_blindlyLoadDLLs to 1

+1 to oranje's advice.
Numeric values for recent jumps would be very useful.

Actually it used to be a delay graph that moves in from the side. I can add the old code back in and make it optional.

I'd like to have the jump delay values in frames, rather then ms.
It seems the jump delay works wrong in demos recorded with sv_fps different from 125.

Weird, as I recall the timestamps the server hands me are in milliseconds since server start. I can divide by the current framerate to get frames per second.

Also, the label 0ms is drawn in the centre of the screen when a demo is being loaded.

Since I draw after defrag I can only put things on top of everything. The dll is loaded when the maploading starts. I could hide the hud until I see the client actually enter the game.

khetti's boted dfwc2012-0 demo showed 0 ms jump delay in some jumps.
On the other hand, gaz's famous demo 'apparently cpm is for bots' showed jump delay more than 2000 ms in one of the rocket jumps.
I'm just telling the demos that reveal this couple of bugs.

The hud does _not_ use defrags internal predicted playerstate. That's why it might miss the frame the player hits th ground. At one frame jumps this can lead to broken output. I can rewrite it to use the predicted playerstate but I don't feel comfortable hooking defrag.

[TittenIgnition]

Both MS and frame-time are sent to the client every snapshot, so grabbing that should be possible, rather than dividing the MS by 8 (or whatever the sv_fps is).

Also, com_blindlyloaddlls doesn't exist.

[dqopb]

The dll is loaded when the maploading starts.

Can you load it when the maploading ENDS? Will it be the same as you proposed above?

[<hk>]

Quake3 does the loading not the proxymod.
I cannot control the "client"(dfengine/iodfe/quake3/...)
The proxymod is loaded INSTEAD of "game". This means the proxymod is loaded when the map screen with that progressbar appears.
It is unloaded the moment the map ends.

[<hk>]

I am gathering feature requests for the next version:

• Readme-file with explanation of the cvars
• Jump delay history (list of x last jumps)
• Use predicted playerstate
• Option to have ammo hud horizontal
• Use 'frames' instead of milliseconds as time unit.
• Hide hud until player finished loading a map

Would you like to add to the list?

Also BUMP

[TittenIgnition]

explanation

[<hk>]

Also, com_blindlyloaddlls doesn't exist.

Sure it does. You are probably just using an engine that doesn't have that dialog box anyway.
https://github.com/id-Software/Quake-II ... ain.c#L551

explanation

Well thanks, I corrected it.

[dqopb]

I discussed with <hk> and asked for a timegraph, similar to native lagometer.

JumpDelayHud_TimeGraph_Proposal.png

Sorry for the uggly pic, I didn't have a proper editor when drawing it.

I also propose to make the numeric values show the distribution of delay pressed before and after the very jump (like blue/red bars of the graph). As an alternative additional mode, of course.
So if it shows 30/70 ms in average instead of simple 100, I'd know that I usually keep the jump key pressed for too long AFTER the jump. On the opposite, if it usually shows 70/30, it means I usually press the jump key too early BEFORE the very jump.

Of course, in order not to make it annoying/confusing, it should look properly. Maybe custom small font size (in brackets?), or custom font color (e.g. grey/transparent by default)..

Same proposal can go to the jump history. Duuno if it is reasonable though. And no idea how to lay out the values properly. Maybe brackets will suite again. For instance, a history for 3 jumps can look like: 120(68/52) 100(58/42) 80(32/48).

[dqopb]

.. Maybe add +attack hold time? No idea how to display it well.