Name:
GRAVITY CONTROL MUTATOR for UT2004
Description:
Provides granular control of gravity (vs the stock 'LowGrav' mutator, which is hardcoded to a fixed value of 300).
Set a negative value and players will float to the ceiling (or up into the sky!)
Version Number/Status:
hmm, call it v2010_1
Compatibility:
tested with UT2004 v3369
================
Additional details:
during PostBeginPlay(), the mutator sets Level.DefaultGravity equal to your specified gravity_control value
Note: the mutator ALSO utilizes CheckReplacement() and overrides the gravity for any LOCAL physics volumes the mapper may have placed
The mutator ALSO performs CheckReplacement() on each JumpPad and sets kick force proportional to the adjusted gravity.
Q: Can I set a negative value for the gravity_control var?
How about a SUPER high grav value, like 99999 ?
A: The mut code does (does not) perform error-checking of any value you manually place in the ini...
...and the GUI will accept values in the range of -2000 to 3000.
Really, though, values outside the range of -1200:2000 are virtually unplayable, and IMO, values between 3 and -3 are "annoying" (takes too long to settle against a surface).
NOTE: Technically, a player standing/walking on the ground isn't subject to any PHYS_Falling induced by the local PhysicsVolume/gravity.
(usually not noticeable unless gravity is near zero) PHYS_Falling can "kick in" or "take over" as soon as a player jumps, gets bumped slightly upward,
or (occasionally) seemingly inexplicably, it can occur when the pawn is in mid-step... or has just raised himself from a crouched position.
The above is mentioned here a disclaimer, so that if you notice any 'wierdness' while running the mutator you'll understand that you're seeing a quirk/bug in the
game's physics engine, not a bug in the mutator. Probably the most noticeable / frequent effect is "confused, non-engaging bots which have been "taken over by"
Phys_Falling, caught in mid-step and hovering just above the ground. You can counter this by using a bot roster -- you'll see "confused" bots much less often if you
choose the more aggressive and higher-ability bots for your roster.
May want to select -1 rather than zero for "zero grav"
(this isn't calibrated EXACTLY to zero... at 0 you do wind up drifting back to the floor... at -1 you eventually drift to the ceiling)
=================
devnotes:
TODO: add a settings toggle (y/n) which provides the option to affect ONLY the defaultPhysicsVolume.
REASON: As-is, the mut may spoil gameplay for maps which contain localized PVs used as 'lift tubes'.
Perhaps revise mut to create RELATIVE (to normal) Zgravity, rather than a fixed number
(a neg Z for a lift tube could remain neg, if the overall default PV receives low/high positive grav)
TODO: Per map, how can we can pass in the gravity_control value via the commandline?
It would be preferable to set a different value for each map (not disturbing some maps, period). I would like to retain 'bAddToServerPackages=True' and enumerate mapname=grav_value pairs, one per line, within the ini. Gameplay for only the listed mapfiles would be affected.
Against human opponents, zero/negative gravity may be "fun"... but bots will often behave as though they are "stumped" (they think they are in a state of falling) and may ignore their opponents.
(Higher ability bots tend to "handle" low grav situations better, as well as bots which have higher aggressiveness assigned in their *.upl record)
(As an alternative to messing with *.upl values [which will lead to being barred from netplay when you try to join a netserver] run the MoodyBots mutator to crank up the bot aggressiveness)
Under conditions of extremely low // zero // negative gravity, you CANNOT count on the "Jump" (or "Crouch" for that matter) key to work as expected!
(sometimes it does, at start of match... but will stop working after you've bounced around a while)
(those native "movement" commands could be overwritten so that they behave differently under neg grav... but that's beyond the scope of this mutator)
==================
Installation:
copy these files to your UT2004/System directory:
Mut_GravityControl.u
Mut_GravityControl.ucl
Mut_GravityControl.int
Mut_GravityControl.ini
Although it isn't necessary to distribute an ini file with this mutator
(the ini will be written if/when user visits GUI ConfigureMutators page and selects a value)
this distribution pkg DOES include a sample Mut_GravityControl.ini file, containing the single line gravity_control=400
so that a server admin doesn't need to locally generate an ini prior to placing on a net gameserver.
You may edit the mutator ini file via text editor, or via the UT2004 GUI ConfigureMutators screen.
If you do the latter, bear in mind that the game doesn't (re)write the ini until you click the "OK" button on the ConfigureMutators screen
As compiled, the mutator's defaultProperties includes the line
bAddToServerPackages=True
so that an admin won't need to specify the mutator as a maplist commandline argument or edit the UT2004.ini ServerPackages when adding this mut to a netserver
The source code is provided ( Mut_GravityControl.uc )
If you would prefer to apply the gravityControl mutator only to select maps in your rotation via commandline argument, remove the bAddToServerPackages line and recompile.
FileFront download:
http://www.filefront.com/17268587/Mu...ityControl.zip
GRAVITY CONTROL MUTATOR for UT2004
Description:
Provides granular control of gravity (vs the stock 'LowGrav' mutator, which is hardcoded to a fixed value of 300).
Set a negative value and players will float to the ceiling (or up into the sky!)
Version Number/Status:
hmm, call it v2010_1
Compatibility:
tested with UT2004 v3369
================
Additional details:
during PostBeginPlay(), the mutator sets Level.DefaultGravity equal to your specified gravity_control value
Note: the mutator ALSO utilizes CheckReplacement() and overrides the gravity for any LOCAL physics volumes the mapper may have placed
The mutator ALSO performs CheckReplacement() on each JumpPad and sets kick force proportional to the adjusted gravity.
Q: Can I set a negative value for the gravity_control var?
How about a SUPER high grav value, like 99999 ?
A: The mut code does (does not) perform error-checking of any value you manually place in the ini...
...and the GUI will accept values in the range of -2000 to 3000.
Really, though, values outside the range of -1200:2000 are virtually unplayable, and IMO, values between 3 and -3 are "annoying" (takes too long to settle against a surface).
NOTE: Technically, a player standing/walking on the ground isn't subject to any PHYS_Falling induced by the local PhysicsVolume/gravity.
(usually not noticeable unless gravity is near zero) PHYS_Falling can "kick in" or "take over" as soon as a player jumps, gets bumped slightly upward,
or (occasionally) seemingly inexplicably, it can occur when the pawn is in mid-step... or has just raised himself from a crouched position.
The above is mentioned here a disclaimer, so that if you notice any 'wierdness' while running the mutator you'll understand that you're seeing a quirk/bug in the
game's physics engine, not a bug in the mutator. Probably the most noticeable / frequent effect is "confused, non-engaging bots which have been "taken over by"
Phys_Falling, caught in mid-step and hovering just above the ground. You can counter this by using a bot roster -- you'll see "confused" bots much less often if you
choose the more aggressive and higher-ability bots for your roster.
May want to select -1 rather than zero for "zero grav"
(this isn't calibrated EXACTLY to zero... at 0 you do wind up drifting back to the floor... at -1 you eventually drift to the ceiling)
=================
devnotes:
TODO: add a settings toggle (y/n) which provides the option to affect ONLY the defaultPhysicsVolume.
REASON: As-is, the mut may spoil gameplay for maps which contain localized PVs used as 'lift tubes'.
Perhaps revise mut to create RELATIVE (to normal) Zgravity, rather than a fixed number
(a neg Z for a lift tube could remain neg, if the overall default PV receives low/high positive grav)
TODO: Per map, how can we can pass in the gravity_control value via the commandline?
It would be preferable to set a different value for each map (not disturbing some maps, period). I would like to retain 'bAddToServerPackages=True' and enumerate mapname=grav_value pairs, one per line, within the ini. Gameplay for only the listed mapfiles would be affected.
Against human opponents, zero/negative gravity may be "fun"... but bots will often behave as though they are "stumped" (they think they are in a state of falling) and may ignore their opponents.
(Higher ability bots tend to "handle" low grav situations better, as well as bots which have higher aggressiveness assigned in their *.upl record)
(As an alternative to messing with *.upl values [which will lead to being barred from netplay when you try to join a netserver] run the MoodyBots mutator to crank up the bot aggressiveness)
Under conditions of extremely low // zero // negative gravity, you CANNOT count on the "Jump" (or "Crouch" for that matter) key to work as expected!
(sometimes it does, at start of match... but will stop working after you've bounced around a while)
(those native "movement" commands could be overwritten so that they behave differently under neg grav... but that's beyond the scope of this mutator)
==================
Installation:
copy these files to your UT2004/System directory:
Mut_GravityControl.u
Mut_GravityControl.ucl
Mut_GravityControl.int
Mut_GravityControl.ini
Although it isn't necessary to distribute an ini file with this mutator
(the ini will be written if/when user visits GUI ConfigureMutators page and selects a value)
this distribution pkg DOES include a sample Mut_GravityControl.ini file, containing the single line gravity_control=400
so that a server admin doesn't need to locally generate an ini prior to placing on a net gameserver.
You may edit the mutator ini file via text editor, or via the UT2004 GUI ConfigureMutators screen.
If you do the latter, bear in mind that the game doesn't (re)write the ini until you click the "OK" button on the ConfigureMutators screen
As compiled, the mutator's defaultProperties includes the line
bAddToServerPackages=True
so that an admin won't need to specify the mutator as a maplist commandline argument or edit the UT2004.ini ServerPackages when adding this mut to a netserver
The source code is provided ( Mut_GravityControl.uc )
If you would prefer to apply the gravityControl mutator only to select maps in your rotation via commandline argument, remove the bAddToServerPackages line and recompile.
FileFront download:
http://www.filefront.com/17268587/Mu...ityControl.zip
All about putting content together. If someone is already doign that, there is no need for me to do the same
Comment