Scripts for Trick Jumps

(ARES) #1

Can scripts help for trick jumps?

If yes, are there examples?

I mean a script like: run half a second, jump, left

(Loffy) #2

Hi!
I do not think so. I am not an expert scripter though, but convinced that scripts cannot help you, in terms of jumping, in clan matches or similar high stake, fast-paced matches.
// Loffy

(Fusen) #3

umm only trickjump script i use is one to turn off pmove_fixed and turn it no again which sickboy made it can be found in this forum havnt seen any others

Tiger Blood

(ARES) #4

What is pmove_fixed good for?

(Bludd) #5

http://www.xfire.be/content/show/index.php?show=18

there’s a detailed explanation

and here is what id says about it:

/pmove_fixed - Typically the player physics advances in small time steps. When this option is enabled all players will use fixed frequency player physics, the time between two advances of the physics will be the same for all players. The actual time between two advances of the player physics can be set with the pmove_msec variable. Enabling this option will make the player physics the same for all players independent from their framerate. [Enforced Server side]

/pmove_msec <milli-seconds> - Sets the time in milliseconds between two advances of the player physics. [Server side]

(ARES) #6

I read it before that framerate affects jumping height.

This is a very strange thing and only a techie will understand why. It is no common sense, except to Carmack maybe.

I read that Idsoftware wants to limit Doom 3 to 60 FPS. It seems that in the new engine the framerate has the some unlogical effect on jumping height. Why Carmack doesn’t remove this strange effect on jumping instead of limiting frame rate to 60?

Can a non-modder and non techie understand this? I’m just of flesh and blood made.

And about this option you wrote, pmove_fixed: Is it a server side thing? Why setting and unsetting it in a script?

(Fusen) #7

it simple terms enable it to jump further… thats basically what you want to know? and using the script to activate / deactivate means i dont have to type it out all the time I can just press a button and you need tosometimes deactivate it, to get better shots on mg42’s or to fix the leaning bug

NO2 VAPORIZER

(Kendle) #8

There are scripts that can be used for jumping. I used to have one which gave a little bit of sprint before jumping, and it works fine on flat surfaces and when running in a straight line. I used it a lot when I used to play RTCW.

The trouble is ET has a lot of un-even surfaces, plus it’s frame-rate dependent, which means there’s a slight (and often variable) delay between pressing the key and actually jumping. This makes it virtually impossible to use for trick-jumping, and a pain in the ass for most other occassions as well.

About 10 months ago I got rid of almost all the scripts I used to use, including the sprint-jump script. It meant having to learn proper strafe-jumping, which I’m still pretty useless at, but it has improved my game dramatically. Scripts are all very well, but there’s really no subsititute for doing things the “proper” way, even if it means practise, practise, practise.

(Rain) #9

I wrote a very simplified explination in this thread, both explaining why framerate affects physics and briefly mentioning pmove_fixed’s involvement.

(Kendle) #10

Thanks for the “idiots guide” to jumping / frame-rate dependency Rain :clap: I must’ve missed that first time round.

However, that begs a few other questions which maybe you or someone can answer.

[ol]
[li]I can’t get 125FPS, indeed I cap at 43 as that’s the highest I can consistently maintain. If I were to create my own listen server, and specify other values for pmove_msec, could I get as good an effect as pmove_fixed 1 and 125FPS?
[/li]
For example:-

At 43FPS set pmove_msec to 23 (.2558 if it takes a decimal value)
At 76FPS set pmove_msec to 13 (.1579 if it takes a decimal value)

[li]What would the implications of doing so be to people who can get higher frame-rates?
[/li]
[li]Does pmove_msec have any effect anyway unless pmove_fixed 1 is set on the server?
[/li][/ol]

(ARES) #11

I read that the rounding loss is because modern CPUs are still rounding with the same precision like 30 years ago. Today it would be no problem to have CPUs round floating point numbers with a precision of 512 bit or more there was written. For comparison, Java’s Double uses 64 bit precision.

Its very interesting which problems it causes. There are other problems with financial software for example. And all because they don’t increase rounding precision in modern CPUs…

Tell me please if this pmove_fixed stuff needs to be set to the server as well in order to work. If yes, how can I check if on a server it is set or not?

I experienced something strange. I set pmove_fixet to 1. When the next map is loaded, pmove_fixed is 0! I have to set it again. Why? And is there a way to automate this?

(Fusen) #12

it can be locked by the server just type /pmove_fixed 1 if it doesnt say anyting its fien and it changed otheriwse it will say this is write protected which means server locked it, also it will reset on each server you go to just put it in an autoexec.cfg or use a script to turn it on each map

TAUNUS V4 ENGINE

(Rain) #13

Well, pmove_msec is only honored if pmove_fixed is 1, and the default of 8ms is 125fps. Basically, pmove_fixed means ‘always run physics every X ms, regardless of framerate.’ If pmove_fixed is 1 and pmove_msec is 8, you should always achieve the same effect as running at 125 fps.

If you set pmove_msec to these values while pmove_fixed was enabled, the physics would run at (about) 43 or 76 fps, respectively. The code only takes integer values, and is capped to 8 ≤ pmove_msec ≤ 33 (where ≤ is the ‘less-than or equal to’ symbol should your browser not want to display it.)

I’m not sure what you mean here… If I didn’t answer this question with my other answers, could you please rephrase?

pmove_msec doesn’t have any effect unless pmove_fixed is 1, but the ‘on the server bit’ is a little tricky. In Q3 and RtCW, it can be enabled on the client, which will communicate its wish to use pmove_fixed to the server (who will match the physics behavior.) Unfortunately, ET doesn’t properly send this information to the server, so this doesn’t work right in ET–pmove_fixed only works properly if set on the server. In etpro, you can currently only change pmove_fixed on the server side (to keep people from really mucking up their clients), although I am planning to fix this Real Soon Now. (One bit of weirdness is that the client’s value for pmove_fixed and pmove_msec will be reset to the values on the server when the map restarts/changes.)

The other caveat to pmove_fixed is that it doesn’t work quite right in RtCW or ET. Leaning is the most obvious example of weirdness, but I recall the existence of some others (although I can’t remember what they are at the moment.)

It’s a little trickier than that.

ANSI C dictates that, when casting from a floating point number to an integer, the floating point number is to be rounded towards zero. To make things worse, integer calculations are required to be rounded to nearest (I say ‘worse’ because it’s a) slightly more confusing, and b) relatively slow for the CPU to change rounding modes.)

On precision, integer multiplies and divides are done with full 64-bit (IEEE double) precision before rounding on any x86 processor with an internal FPU (i.e. everything since and including the 486DX, and quite probably the 486SX.) There are means to use IEEE floats (32-bit) and IEEE doubles (64-bit) in ANSI C, and IEEE long doubles (80-bit precision) are specified in ISO C99 (the most recent official C language specification) (although support for them has been around for even longer in some compilers.)

(Lekdevil.NL) #14

I think we can all safely conclude now that Rain is a bot! :smiley:

(Sick Boy) #15

Too bad, would be nice to see what’s possible at pmove_msec 3 (333fps) :disgust: Especially for that jump-map where you need 333fps to finish it.

Any other ways of simulating this ? (in RTCW you could use g_synchronousclients and sv_fps 333, but g_synchronousclients is removed in ET)

I’m glad to hear it :slight_smile:
Was this the reason for write-protecting pmove_fixed? To keep people from mucking up? :frowning:

Other problems: not being able to aim with mounted guns, panzer shooting/reloading problems, crosshair jumping to the sky at mapstart,airstrike cannisters won’t always throw,…

So if you plan to use pmove_fixed make sure to bind it to a toggle key so you can enable it when you need it and disable afterwards so you won’t run into these problems.

You can do this with this script:

set fixed "pmove_fixed 1; echo "pmove_fixed 1"; set pmovetoggle vstr notfixed" 
set notfixed "pmove_fixed 0; echo "pmove_fixed 0"; set pmovetoggle vstr fixed" 

set pmovetoggle "vstr notfixed" 

bind p "vstr pmovetoggle"

or just

bind p "toggle pmove_fixed"
(Kendle) #16

I’m not sure what you mean here… If I didn’t answer this question with my other answers, could you please rephrase?
[/quote]
You have answered my question in as much as I didn’t fully understand what this all does in the first place. If I understand you correctly what you’re saying is that pmove_fixed 1 (both client and server in ET) makes everything work as if you had 125FPS, regardless of whether you do or not (in my case not).

In which case there’s nothing to be gained from using pmove_fixed 1 plus pmove_msec xx to emulate lower frame-rates, as jumping would be less due to the lower frame-rates anyway!

Rain, you’re a God. What an infinitely poorer place ET would be without you and Bani. :notworthy:

(KP-Homer) #17

Scripts are not needed and will hurt you in the long run. No scripts are used by the trickjumpers i know.

2 Things will make you jump higher and farther:

  1. an Upgrade
  2. Practice.

KP-Homer
#kernel

(IPvD) #18

I bow down before your enormous repository of knowledge, Rain!

(Loffy) #19

I agree. The jumps are hard, if not impossible on a slow computer. And they take time to master (months/years).
// L.

(Rain) #20

Shhh! :smiley:

These endcaps are kind of dated–I’ll give some consideration to changing it. You might be able to get similar behavior by enabling cg_nopredict on the client (although it’s cheat-protected, and you can crash the client with it in etmain while prone.)

Well, it’s less important now that we cap cg_errordecay in etpro, but it used to be possible to more your viewpoint away from your player (through walls, even) by using a high cg_errordecay and then causing a lot of prediction errors (which is as simple as several consecutive jumps in etmain.) The problem is, like I said, that the client currently doesn’t notify the server that it’s using pmove_fixed (so the physics on the client and server won’t match–lots of opportunity for prediction errors.) You can still enable pmove_fixed on the server (which will automatically enable it on the clients as well), but because of the problems with it, it’s probably not a good idea to leave a server running that way. :bored:

That’s correct (aside from the bug I just mentioned–but that is exactly the intended behavior.)