Limiting Player Movement on Screen?

[legacy-kyawesker]

Hello, I have a rather hard problem. At least, I think it's hard. I made a top down view camera for an online mod and it's my hope to some how limit the player movement so that the player can only move within a certain radius of the other player.. I guess I want almost a scrolling effect. Does this make sense to anyone? Here's a picture

|-------|
| x|
|o___|

x can't move beyond whats on screen until the o comes closer to him..

Thank you

[legacy-bushbomb]

well, I guess that's possible, maybe in a tick function have it check the distance between the two and if the distance is > somedistance, set their momentum to 0. With a tick, if the O is slowly approaching the X anyways, it would then allow the person to move in a fraction of a second, provided they are not still trying to move too far away.

[legacy-kyawesker]

thank you for your reply. That seems like the only way I could do this. Do you have a suggestion as to what class I should extend from to make this possible?

What if I didn't effect the player movement but instead do something with hitwall?

Thank you for your reply

[legacy-bushbomb]

well, I created a freeze object in their inventory for freezing certain players when I type in a command. It goes in their inventory and it counts for 30 seconds, then destroys itself. You could simply make an object extend the inventory class, give it to them, and inside it will have a tick that does the distance/momentum checking.

[legacy-kyawesker]

Hello again, I came up with this today and I'm not sure if it will work or not.. I don't think I quite understand pawns and any advice that I can get would be wonderful. I did all this inside my custom playercontroller class.


first thing I did was made two new pawn var's which extend my custom pawn.. (playerone and playertwo)

 function Tick(float DeltaTime)

{
local float Dist;


  Dist = vSize(PlayerOne.Location - PlayerTwo.Location)-PlayerOne.CollisionRadius - PlayerTwo.CollisionRadius;
  if( Dist == (MaxDist - 10))
  {
       LocationPlayerOne = PlayerOne.location;
       LocationPlayerTwo = PlayerTwo.Location;
  }
  if( Dist >= MaxDist)
    {
      PlayerTwo.SetLocation(LocationPlayerTwo);
      PlayerOne.SetLocation(LocationPlayerOne);
      }
    }

[legacy-Slinky730]

I believe pawns have a movespeed variable that you can drop to 0 to limit movement.

[legacy-kyawesker]

I don't really want to make the move speed to 0 though.. I want almost an invisible wall effect and the only way I can do that I believe is if I save the location of a pawn at X location then if the two players are so far apart each pawn would be set to location X

[legacy-Slinky730]

Oh! I see- you're trying to do something like, say, crystal chronicles? It might be cleaner to create a volume- the volume is the size of the camera bounds, sort of and the camera is locked to point to the center of the volume. When the player moves outside the volume (use the volume's untouch event to process this), the volume will either adjust its location so that all players are inside it (if possible) or pull the player back in. Rather than setting a specific location to pull back in, though, do it by axes, pulling the player back across the bound he left the volume through. Also, remember to set this new volume class's bIsStatic and bNoDelete both equal to false.

[legacy-kyawesker]

Yes that is exactly what I am trying to do.. Volumes eh? I have no experience with these but it looks like you have given me a very good solution.. I just need to learn some new things.. Do you have any advice or some kind of setup that will point me in the right direction?

Thank you very much

[legacy-Slinky730]

I've never done any specific work with cameras, but I take it if you can handle the top-down view to begin with, you can do work in this department.

I actually know a bit about volumes, because I just had an annoyingly-difficult problem getting arrays of beasts to spawn within a volume (and this problem is exacerbated by the problem that I think I overcomplicated it). Anyway!

It seems that volumes are just an empty area with collision bounds that can be defined by a brush or whatever. The bounds can be used for whatever- there are a lot of premade volumes- blocking volumes (invisible wall of the most basic sort) and physics volumes (used for lava, water, walk-upside-down thingies, whatever) are the two more basically used, but the parent Volume class has a couple neat features: first of all, it's a brush, so you can have an invisible, non-solid brush with a touch() and untouch() function (so you have areas of any shape you want tell you when someone enters or leaves them), and also you can define a tag that it should send all its touch/untouch events to, which is pretty neat.

Anyway, you'll be making a new Volume class and setting up its collision to be a big box- this is the area the characters are allowed in. Alex usually handles the collision stuff on Killing Floor, so I'm not really familiar with how to set that up, but the wiki should lead you aright. Shouldn't be too difficult. You might even go as far as to set up the volume you want in the map editor, place it around the playestarts, and give it a recognizable tag so you can grab it in the code. This would be easier, but less reliable. If you don't do this, you'll have to set up its collision in code, spawn it in the correct location, and orient it how you want, but if you want any community mapping for your gametype, code-handling of the volume-creation might be the way to go.

By the way, volumes by nature are bIsStatic=true and bNoDelete=true. This is great when you just want to place a volume and have it do something. You, however, will be moving, interacting with, and possibly even creating and destroying volumes in the code. Set both those values to false to make your life easier.

Anyway, in the volume, set up a new untouch function. (Make sure to call the super, plz). Basically, you'll be moving around this thing rather often, so make sure you're not paying attention to anything but players who have to be bound within the box (stuff will be entering and exiting the volume as you walk past it on a regular basis). As far as moving the volume goes, I actually change my mind. Rather than doing camera-movement code AND object-movement-limiting code in the volume, and locking the camera (where you've already done a ton of work) to the volume, it might be a better idea to have the camera move the volume around whenever it moves and just dedicate the volume to limiting players. This is especially important since it's always annoying to have to press up against the side of the screen to move around. It's much better if the camera tries to stay in a geometrical center of the players when possible, so put separate code in the camera trying to get a good angle (and making sure all players are looking through the same camera view), and then just put something like this in the untouch:

//I'm not sure how you'd get the world X/Y sizes from the volume
//and you might have to put them into a const or something
//so just pretend VOL_WID and VOL_HEI are those values

//if the distance of the pawn from the center of the 
//volume in either the X or Y direction is more than
//the distance of the edge, sanction the player
local int XDif,YDif;
local vector tLocation;

tLocation = Pawn.Location;
XDif = tLocation.X-Location.X;
YDif = tLocation.Y-Location.Y;

//Sanction the player by getting his direction with
//reference to the center (XDif/abs(XDif)), multiplying
//that by the edge's distance from the center,
//adding that to the center's location, and setting the
//player's position to that.
if(abs(XDif) > VOL_WID/2)
     tLocation.X = (XDif/abs(XDif)*VOL_WID/2)+Location.X;
if(abs(YDif) > VOL_HEI/2)
     tLocation.Y = (YDif/abs(YDif)*VOL_HEI/2)+Location.Y;

Pawn.SetLocation(tLocation);

The cool thing about that code is it also holds the player's Z location standard, so they can jump against the invisble wall and what have you. Don't worry if you totally didn't see those last few lines coming (with all that XDif stuff)- I'm just obsessed with compressing my code down to the fewest lines possible, which sometimes makes it hard to read.