I search for solutions in this order: Past Code, Unreal Source, Wiki, BUF, groups.yahoo, google, screaming at monitor. – RegularX
Difference between revisions of "Legacy:JumpSpot (UT)"
(LiftCenter links now point to UT version) |
m |
||
Line 1: | Line 1: | ||
− | {{classbox|[[Legacy:UT|UT]] :: [[Legacy:Actor (UT)|Actor (UT)]] >> [[Legacy:NavigationPoint (UT)|NavigationPoint (UT)]] >> [[Legacy:LiftCenter | + | {{classbox|[[Legacy:UT|UT]] :: [[Legacy:Actor (UT)|Actor (UT)]] >> [[Legacy:NavigationPoint (UT)|NavigationPoint (UT)]] >> [[Legacy:LiftCenter|LiftCenter]] >> JumpSpot}} |
− | '''Tarquin:''' DM-Morpheus places the JS at the TOP of the jump – where the bot should land. This is similar bahaviour to the use of [[Legacy:TranslocDest|TranslocDest]], and since both TD and JS are subclasses of [[Legacy:LiftCenter | + | '''Tarquin:''' DM-Morpheus places the JS at the TOP of the jump – where the bot should land. This is similar bahaviour to the use of [[Legacy:TranslocDest|TranslocDest]], and since both TD and JS are subclasses of [[Legacy:LiftCenter|LiftCenter]], I'm inclined to say that what is written below is incorrect. |
Also, on Morpheus the bots don't have boots: they jump plain, but travel far with the gravity. can JS be used in normal gravity to specify an accomplaishable jump? Stay tuned... | Also, on Morpheus the bots don't have boots: they jump plain, but travel far with the gravity. can JS be used in normal gravity to specify an accomplaishable jump? Stay tuned... | ||
− | Then again, Morph uses LE - JS - LE for the top towers, where a bot has to go up. For jumps ''across'' gaps, Morph uses LE - [[Legacy:LiftCenter | + | Then again, Morph uses LE - JS - LE for the top towers, where a bot has to go up. For jumps ''across'' gaps, Morph uses LE - [[Legacy:LiftCenter|LiftCenter]] - LE. Hmmm. |
A JumpSpot actor is used to tell the bots where to perform an impact hammer or anti-gravity (typically with the boots) jump. Place the actor where the bot should begin the jump and set bHammerJump to <tt>True</tt> if you want the bots to use the impact hammer for the jump if boots are not available. Note that this should not be used for places like bots jumping a small gap or lip - if a player can make the jump normally (preferably with a bit of room to spare), then simply use [[Legacy:PathNode|PathNode]]s above/below or before/after the lip/gap. | A JumpSpot actor is used to tell the bots where to perform an impact hammer or anti-gravity (typically with the boots) jump. Place the actor where the bot should begin the jump and set bHammerJump to <tt>True</tt> if you want the bots to use the impact hammer for the jump if boots are not available. Note that this should not be used for places like bots jumping a small gap or lip - if a player can make the jump normally (preferably with a bit of room to spare), then simply use [[Legacy:PathNode|PathNode]]s above/below or before/after the lip/gap. | ||
'''EntropicLqd:''' My understanding of jump spots is that they can be used to tell the bots about all jumps that they can make that could lead to a shortcut through the level, or ones which the normal AI can't figure out for itself, including impact hammer jumps and low-grav short cuts. The AI will calculate some jumps, but not all possible ones (it seems to be distance based with the Z component having more significance. I've always had most luck setting up jump spots that are short cuts through the level (or pathnoding kickers) as one way paths with the jumpspot pretty much next to its associated lift exit. From the experimentation I've done bi-directional jumpspots required the jumpspot to be at the apex of the jump that is to be made. However, I found the failure rate of this sort of path to be unnaceptable. Oddly, the AI only requires that the lift-exits are travelled through, not the jumpspot. | '''EntropicLqd:''' My understanding of jump spots is that they can be used to tell the bots about all jumps that they can make that could lead to a shortcut through the level, or ones which the normal AI can't figure out for itself, including impact hammer jumps and low-grav short cuts. The AI will calculate some jumps, but not all possible ones (it seems to be distance based with the Z component having more significance. I've always had most luck setting up jump spots that are short cuts through the level (or pathnoding kickers) as one way paths with the jumpspot pretty much next to its associated lift exit. From the experimentation I've done bi-directional jumpspots required the jumpspot to be at the apex of the jump that is to be made. However, I found the failure rate of this sort of path to be unnaceptable. Oddly, the AI only requires that the lift-exits are travelled through, not the jumpspot. |
Revision as of 21:03, 2 January 2003
Tarquin: DM-Morpheus places the JS at the TOP of the jump – where the bot should land. This is similar bahaviour to the use of TranslocDest, and since both TD and JS are subclasses of LiftCenter, I'm inclined to say that what is written below is incorrect.
Also, on Morpheus the bots don't have boots: they jump plain, but travel far with the gravity. can JS be used in normal gravity to specify an accomplaishable jump? Stay tuned...
Then again, Morph uses LE - JS - LE for the top towers, where a bot has to go up. For jumps across gaps, Morph uses LE - LiftCenter - LE. Hmmm.
A JumpSpot actor is used to tell the bots where to perform an impact hammer or anti-gravity (typically with the boots) jump. Place the actor where the bot should begin the jump and set bHammerJump to True if you want the bots to use the impact hammer for the jump if boots are not available. Note that this should not be used for places like bots jumping a small gap or lip - if a player can make the jump normally (preferably with a bit of room to spare), then simply use PathNodes above/below or before/after the lip/gap.
EntropicLqd: My understanding of jump spots is that they can be used to tell the bots about all jumps that they can make that could lead to a shortcut through the level, or ones which the normal AI can't figure out for itself, including impact hammer jumps and low-grav short cuts. The AI will calculate some jumps, but not all possible ones (it seems to be distance based with the Z component having more significance. I've always had most luck setting up jump spots that are short cuts through the level (or pathnoding kickers) as one way paths with the jumpspot pretty much next to its associated lift exit. From the experimentation I've done bi-directional jumpspots required the jumpspot to be at the apex of the jump that is to be made. However, I found the failure rate of this sort of path to be unnaceptable. Oddly, the AI only requires that the lift-exits are travelled through, not the jumpspot.