forum.fpsclassico.com

ok, the thing with the local server/single player is that I preferred it to stay as close to the "mainstream" servers as possible (it's what makes the most sense in my opinion) but I also understand what you mean, so I uploaded the local server/single player (the qagames files) with a new variable "\g_floatvectors 0" (defaults to one for consistency) that should now give you a canonical vq3 local server. so please check it out and let me know if with that you can now do that bridge to rail jump. the files you need are qagame-intel.dll and qagame-lowend.dll (in case you test both though I guess that you can just stick for the intel build probably) re-download and re-place as necessary.

four.pk3 still does not work. I put the file in those folders:
- c:\Users\tar\AppData\Roaming\Quake3\baseq3\demos\four.pk3
- c:\Users\tar\AppData\Roaming\Quake3\unfreeze\demos\four.pk3

I also deleted the four.pk3 from the baseq3\demos subfolder (to ensure he uses the one from the unfreeze\demos subfolder) but it still does not work.

I tested the timedemo again with my wtf.pk3 (see attached, it is in the unfreeze\demos subfolder). The results are as follows:
- r_smp = 0: intel.exe: 1215 FPS, lowend.exe: 1217 FPS
- r_smp = 1: intel.exe: 780 FPS, lowend.exe: 790 FPS

It fluctuates a bit when I repeat the test (around 20 FPS) - so I would say, it is identical between intel.exe and lowend.exe but its about 35 % performance loss when r_smp is enabled.

By the way, when I disable r_smp the whole starting process hangs on the "awaiting..." screen. Then I need to change to windowed mode (ALT+ENTER) and it loads the game. After a second start (still with r_smp disabled) everything works fine.

Mh, now you confuse me even more. You say that most of the players are not able to handle exact 125 FPS all the time but you fixed the "mainstream server" FPS to 200 which is, as far as I remember maths, much higher than 125.

Ah, I forgot in_mouse -1 - put it back in there and it seems to fix my issue. Thanks!

I also tried out your new .dll-files but /g_floatvectors is an unknown command.

easy, delete c:\Users\tar\AppData\Roaming\Quake3\baseq3\demos\four.pk3 and c:\Users\tar\AppData\Roaming\Quake3\unfreeze\demos\four.pk3 and install instead c:\Users\tar\AppData\Roaming\Quake3\unfreeze\four.pk3. you're installing a pk3 file not a dm_68 file, pk3 files goes at the root of the mod folder not in the demo sub folder.

mmm that's a interesting finding, so no only r_smp does nothing for you that it even makes thing worse, good to know, thanks about that.

ok, ok, you've got a point there however you're overlooking that that would be precisely the issue on plain vq3, support different client frame rates, which is what would lead to large differences between players (in addition to coarser movement/display), which is at the end the root of the discussion.

that's my fault, turned out I had re-uploaded the previous version of those files, sorry about. just re-uploaded now the correct versions, give them a try (qagame-intel.dll and qagame-lowend.dll). in addition I also updated now the unfreeze1-dev-client.pk3 with a new "\cg_drawspeed 1" functionality to display your current in-game speed (pretty much a "standard" feature of most mods) to help you debug/test that bridge to rail jump (as well as to anyone else to learn about the game physics). analysis over the last miro games shows that he generates about 500 u/s on the first jump and nearly 600 u/s on the second to complete that trick, so make sure you're around those numbers when trying it (beside the proper trajectories also of course). anyways, that's it, check them out and let me know.

It does not work with v1.33a but worked instantly with v1.36, see demos attached.

No idea what I am doing wrong. I've set g_floatvectors to "0".

mmmm that's good material there, thank you for that. yes I have the impression that your third jump should have landed and the values are correct so I'll have to look deeper into that. it's interesting because the 1.36 there apparently it's just the regular standard 1.36 (not some other crazy modded version) and baseq3 so it's "canon" and it's quite frustrating because the difference is very small. anyways whatever the case is I have the impression that that would have landed at the server, the server has those (infamous) physics corrections that I didn't include on the local server. I'm not happy with that "solution" (I miss calculated somewhere, it should have landed) but I updated the dll files now with that correction, please give them a try, I believe that now it should land, if so it would be cool to try with and without g_floatvectors and see if there's some tangible difference.

Results attached... seems to work now but harder as in v1.36

awesome, looks solid consistently hitting those 500 and +570 and landing right on the spot, great job man, that's what I was talking about, thanks for testing that out for me and the material, much appreciated.

I know, that correction is evil too much of it and the server would just become a "random noob shit" so that's why I only added just enough of it for this stuff to work.

and by looking at your demos now is way clear where I miss calculated before, the canon vq3 settings weren't taking effect (the results in your demos was the same). the thing is that I recklessly assumed that the server (canon vq3) should overrule the client (UnFreeZe mod), this is generally believed to be so (though I hadn't personally verified it, that was my mistake) but I don't know if it's because is a local server that has some special rules but it wasn't being the case. I don't feel like dealing with the client by now (for the reasons I explained, I don't feel like putting at risk the integrity of the servers just for the sake of this) so one way to work around this at the moment is just to enable "\cg_nopredict 1" and that should force the canon vq3 settings accessed by "\g_floatvectors 0" (though it will feel rough, it's just a work around).

so I think I finished with the local server/single player by now (yes those same dlls again), I added a few minor corrections based on the data you provided then if you still feel like giving them a try another cool physics test for this can be the classic strafe to the red armor in hub3aeroq3. reference values taken from last miro game are around 470 first jump and 550 second jump although I've seen him land at lower speeds too. I attach you a couple of screens, looks easier than what it is. a cool test would be "standard" UnFreeZe (g_floatvectors 1 cg_nopredict 0 are the defaults but just saying) and then if so for reference check if the canon vq3 via g_floatvectors 0 with cg_nopredict 1 works as expected this time (and if both land of course and even if not identical that they never will at least reasonably close).

Did not know this move but it works on both settings. I got some FPS lag... but I think because of another task I had open.

great job man

beautiful, consistently hitting 470-490 and 520-550 with proper trajectories (which is the hard part), smooth landing, both versions as close as it gets (or as reasonably gets). the correction now definitively looks on point (looked cleaner/more natural on the float demo than on the normal) then I guess that this should finally close this issue, thank you for the hard work, now let's see if on the next days I arrange a bit the thread about it and organize this a little better on the forum, update posts and so.

Would fps be any issue when others connect I lag, although I know my connection has problems just wondering how to deal with it

I don't really think so, you can try different fps settings on the new 64 bits package that it's unlocked (\com_maxfps <anything> is the command) but very likely isn't gonna change anything.