Movement/Wall Detection for Variable sizes

[DustyPorViva]

A small script I threw together to show how you can create a movement system with various speeds(without skipping over walls), and more importantly: various sizes. This means you can shrink your player down to 1 tile and squeeze through cracks, or apply a better wall detection to larger players. What it is lacking is detail to anything else but those two things. It initially started as an experiment with onwall2 for a solid wall detection(instead of lots of onwall()'s), and I decided to add size support later. Lacks important things like sliding around corners, but that's not what this is focused on.

PHP Code:

function onCreated() {
  clientr.movementSpeed = .5;
  clientr.movementSize = 2;
}
//#CLIENTSIDE
function onCreated() {
  showstats(1024);
  disabledefmovement();
  clientr.movementSpeed = .5;
  clientr.movementSize = 2;
  player.x = int(player.x)+.5;
  player.y = int(player.y);

  setTimer(0.05);
}

function onTimeout() {
  temp.speed = clientr.movementSpeed;
  temp.size = clientr.movementSize;
  player.zoom = size/2;
  for (temp.k=0;k<4;k++) {
    if (keydown(k)) {
      player.dir = k;

      temp.cx = (player.x+.5)-((size - 2)/2);
      temp.cy = (player.y+1)-((size - 2)/2);

      temp.horizontalwall = onwall2(cx + vecx(k)*speed,cy,size-1/16,size-1/16);
      temp.verticalwall = onwall2(cx,cy + vecy(k)*speed,size-1/16,size-1/16);

      if (horizontalwall == 0) player.x += vecx(k)*speed;
      else {
        for (i=0;i<(speed > client.size ? speed : size);i+=1/16) {
          if (onwall2(cx+vecx(k)*i,cy,size-1/16,size-1/16)) {
            player.x += vecx(k)*i;
            player.x = int(playerx+((size%2 == 1)*.5))+((size%2 == 0)*.5);
            break;
          }
        }
      }
      if (verticalwall == 0) player.y += vecy(k)*speed;
      else {
        for (i=0;i<(speed > size ? speed : size);i+=1/16) {
          if (onwall2(cx,cy+vecy(k)*i,size-1/16,size-1/16)) {
            player.y += vecy(k)*i;
            player.y = int(playery+((size%2 == 0)*.5))+((size%2 == 1)*.5);
            break;
          }
        }
      }
    }
  }
  showpoly 200,{
    (player.x+.5)-((size - 2)/2),(player.y+1)-((size - 2)/2),
    (player.x+.5)-((size - 2)/2)+size,(player.y+1)-((size-2)/2),
    (player.x+.5)-((size - 2)/2)+size,(player.y+1)-((size-2)/2)+size,
    (player.x+.5)-((size - 2)/2),(player.y+1)-((size - 2)/2)+size,
    (player.x+.5)-((size - 2)/2),(player.y+1)-((size - 2)/2),
    (player.x+.5)-((size - 2)/2),(player.y+1)-((size - 2)/2)+(1/16),
    (player.x+.5)-((size - 2)/2)+size-(1/16),(player.y+1)-((size - 2)/2)+(1/16),
    (player.x+.5)-((size - 2)/2)+size-(1/16),(player.y+1)-((size - 2)/2)+size-(1/16),
    (player.x+.5)-((size - 2)/2)+(1/16),(player.y+1)-((size - 2)/2)+size-(1/16),
    (player.x+.5)-((size - 2)/2)+(1/16),(player.y+1)-((size - 2)/2)+(1/16)
  };
  setTimer(0.05);
}

function onPlayerChats() {
  if (player.chat.starts("size")) {
    temp.newsize = player.chat.substring(5);
    if (newsize >= 1 && newsize <= 20) clientr.movementSize = newsize;
    else if (newsize > 20) player.chat = "Seriously, are you nuts?";
    else player.chat = "Not a compatible size!";
  } else if (player.chat.starts("speed")) {
    temp.newspeed = player.chat.substring(6);
    if (newspeed > 0) clientr.movementSpeed = newspeed;
  }
} 


Video as soon as I can get it uploaded without my internet timing out.

[Imperialistic]

please donate this script to UN, they need it.

Anyways great job dusty, I'm loving the work lately.

[Chompy]

Originally Posted by Imperialistic

please donate this script to UN, they need it.

Anyways great job dusty, I'm loving the work lately.

Why just UN? Placing this in the code gallery would help many, instead of just one server. UN can just get the script from the code gallery, so that's not a problem if they need it.

Great script Dusty, could have an awesome use for server having interesting quests, like drinking an elixir to become smaller or something like that.

[DustyPorViva]

Oh, this should be moved to the code gallery, my bad!

[WhiteDragon]

How I did the movement on Classic was by having a function that works a long a "primary axis". That could be x-axis, y-axis, or say 45deg.

Then it moves along that access, then when it encounters a wall in its path, it will slide perpendicular to the primary axis.

I made it even more complex (for the sake of efficiency), by doing a conquer-and-divide algorithm along the movement path. With built-in onwall() and onwall2() it literally had 0% impact on CPU. With our scripted onwall (i.e., loop through every player, npc, blocking tile and check if they are blocking & intersect), it matched default performance.

Getting it pixel perfect was a little annoying, but the script came out nicely in the end (probably about 200 lines if all the extra documentation and lines were removed). It supports variable speeds and sizes as well.

I might release it in Code Gallery at some point, but it'd require some cleaning up so it wouldn't rely on some of the other systems we have on Classic, so that is a project for when I have free time.

[DustyPorViva]

Well making sliding isn't that hard, especially in GS2 since I can use passing parameters to simply make a function that checks for a wall in a given direction, making it much simpler to do accurate wall sliding. Maybe I'll add that later.

[Twinny]

I <3 you Dusty....saved me a hell of alot of effort.

p.s.

PHP Code:

     else if (newsize > 20) player.chat = "Seriously, are you nuts?" 


needs a semicolon

p.p.s

If you do add sliding, I will love you even more =)

p.p.p.s

On further usage, it doesn't seem very smooth. I also found it suffered the same problem I had whereby faster speeds can cause you to jump obstacles... it was this problem that caused me to delay working on it since it was either efficiency or accuracy

[DustyPorViva]

Originally Posted by Twinny

I <3 you Dusty....saved me a hell of alot of effort.

p.s.

PHP Code:

     else if (newsize > 20) player.chat = "Seriously, are you nuts?" 


needs a semicolon

p.p.s

If you do add sliding, I will love you even more =)

p.p.p.s

On further usage, it doesn't seem very smooth. I also found it suffered the same problem I had whereby faster speeds can cause you to jump obstacles... it was this problem that caused me to delay working on it since it was either efficiency or accuracy

I just tested it at size 2, speed 5 and didn't even jump over a 1 tile thick wall. Though I suppose circumstance has a lot to do with it. The wall check is checking the desired position, instead of the space BETWEEN the player and the desired position. So at the speed of 10, at the size of 2, the new position is ahead 10 spaces, and the size is 2 so that's 8 tiles not being checked.

It's a fairly easy fix though, which just involves adding the speed to the size of the onwall2.

[Twinny]

Originally Posted by DustyPorViva

I just tested it at size 2, speed 5 and didn't even jump over a 1 tile thick wall. Though I suppose circumstance has a lot to do with it. The wall check is checking the desired position, instead of the space BETWEEN the player and the desired position. So at the speed of 10, at the size of 2, the new position is ahead 10 spaces, and the size is 2 so that's 8 tiles not being checked.

It's a fairly easy fix though, which just involves adding the speed to the size of the onwall2.

I found I was able to jump over a tree line whilst moving diagonally but yeah it's exactly the same problem I've had before...I eventually went insane trying to create a method which would check for a wall within your speed, move you right before that wall but still allow for the other axis movement and sliding....it's beyond me

[12171217]

Originally Posted by Twinny

I found I was able to jump over a tree line whilst moving diagonally but yeah it's exactly the same problem I've had before...I eventually went insane trying to create a method which would check for a wall within your speed, move you right before that wall but still allow for the other axis movement and sliding....it's beyond me

Perhaps you're going so fast that you slide under and around the tree in a single frame?

[Twinny]

Originally Posted by 12171217

Perhaps you're going so fast that you slide under and around the tree in a single frame?

The area I eventually got into was enclosed

[DustyPorViva]

I'm rescripting this from scratch right now. I'm instead breaking the wall detection into 4 quadrants and basing wall collisions off of that. This will make it easier to implement sliding, and easier to handle the wall data.

[scriptless]

Must say, very impressed. Tho size doesn't show for other players, so I came up with this. Maybe you could impliment something to show size properly in your next rescript?

PHP Code:

function onActionServerside() {
  if ( params[0] == "size" ) {
    clientr.movementSpeed = .5;
    clientr.movementSize = 2;
  }
  if ( params[0] == "getsize" ) {
    temp.var = findplayerbycommunityname(params[1]).clientr.movementSize;
    triggerClient("gui", this.name, "gotsize", params[1], temp.var);
  }
}
//#CLIENTSIDE
function onCreated() {
  player.x = int(player.x)+.5;
  player.y = int(player.y);
  triggerserver( "gui", this.name, "size", null );
  setTimer(0.05);
}

function onActionClientSide() {
  if ( params[0] == "gotsize" ) {
    findplayerbycommunityname(params[1]).zoom = params[2]/2;
  }
}

function onTimeout() {
  temp.speed = clientr.movementSpeed;
  temp.size = clientr.movementSize;
  triggerserver( "gui", this.name, "getsize" );
  for( temp.pl : allplayers ) {
    triggerserver( "gui", this.name, "getsize", pl.communityname );
  }
  player.zoom = temp.size/2;
  for (temp.k=0;k<4;k++) {
    if (keydown(k)) {
      player.dir = k;

      temp.cx = (player.x+.5)-((size - 2)/2);
      temp.cy = (player.y+1)-((size - 2)/2);

      temp.horizontalwall = onwall2(cx + vecx(k)*speed,cy,size-1/16,size-1/16);
      temp.verticalwall = onwall2(cx,cy + vecy(k)*speed,size-1/16,size-1/16);

      if (horizontalwall == 0) player.x += vecx(k)*speed;
      else {
        for (i=0;i<(speed > client.size ? speed : size);i+=1/16) {
          if (onwall2(cx+vecx(k)*i,cy,size-1/16,size-1/16)) {
            player.x += vecx(k)*i;
            player.x = int(playerx+((size%2 == 1)*.5))+((size%2 == 0)*.5);
            break;
          }
        }
      }
      if (verticalwall == 0) player.y += vecy(k)*speed;
      else {
        for (i=0;i<(speed > size ? speed : size);i+=1/16) {
          if (onwall2(cx,cy+vecy(k)*i,size-1/16,size-1/16)) {
            player.y += vecy(k)*i;
            player.y = int(playery+((size%2 == 0)*.5))+((size%2 == 1)*.5);
            break;
          }
        }
      }
    }
  }
  setTimer(0.05);
} 


Would love to see some updates/addons to this

[Twinny]

Originally Posted by scriptless

Must say, very impressed. Tho size doesn't show for other players, so I came up with this. Maybe you could impliment something to show size properly in your next rescript?

PHP Code:

 triggerserver( "gui", this.name, "getsize" ); 
  for( temp.pl : allplayers ) { 
    triggerserver( "gui", this.name, "getsize", pl.communityname ); 
  } 


Would love to see some updates/addons to this

You have suggested that the weapon should trigger the server every 0.05 seconds for the size of allplayers clientside... Imagine Zodiac with 100 people on the server. You would be triggering the server 1 + 100 + amount of people on your buddy list every 0.05 seconds.... bad....

A better way would be to put the players size in an attr[] and simply update the local (someone in a different gmap won't care how the player is being drawn afterall) player's size via some method clientside script (weapon/gani)....

[DustyPorViva]

Typically you will use a gani as an attr, with ganiscript in it to handle zoom. You set the script in to one attr, then the size of your player(and other visual aspects like alpha and such, if you'd like) to another attr. Use the ganiscript to parse the other attr and then set the player's effects.

However, it was not my responsibility to do this, as that's not what the script was about

[scriptless]

I normally stay AWAY from ganiscripts. Most people dont fully understand, ganis are downloaded from the server. If you have the gani it usually ignores it (or has in the past). And you can use scripts in ganis maliciously. I saw people do it on N-Pulse, UN, and gk. =/

Yah I really don't recoment doing it the way I showed but I was just showing a example of something that worked. o_o

It would be alot easier if we could just use findplayer("player").clientr.value =/ but that doesnt work clientside. and I thought cleintr. was readable by client and server?

[DustyPorViva]

Originally Posted by scriptless

I normally stay AWAY from ganiscripts. Most people dont fully understand, ganis are downloaded from the server. If you have the gani it usually ignores it (or has in the past). And you can use scripts in ganis maliciously. I saw people do it on N-Pulse, UN, and gk. =/

Yah I really don't recoment doing it the way I showed but I was just showing a example of something that worked. o_o

It would be alot easier if we could just use findplayer("player").clientr.value =/ but that doesnt work clientside. and I thought cleintr. was readable by client and server?

Err... what? Ganiscripts haven't been abused since they were first released. That was quickly patched up. Gani's with scripts downloaded don't even use the gani files, they use encrypted .code files.

If they were that dangerous, all you'd have to do is input ganiscript into any gani like idle or walk, and have it run. Whether or not you have a ganiscript has no bearing on how available the function is.

Also, client vars are readable by server/client, but it's not data sent to other players. Data shared between players is a very specific set of vars, as to not chew up a lot of bandwidth.

[scriptless]

If they were that dangerous, all you'd have to do is input ganiscript into any gani like idle or walk, and have it run. Whether or not you have a ganiscript has no bearing on how available the function is.

That is what I ment. Foogles showed me this a few years back. It seems to work for a very long time, so long that I was unaware it was even patched. And I assume the .code files are the .code files I see on my computer? Wonder how long it takes for someone to break the encryption :o Graal v2-5 have already had there packet encryption broken (several times).

Thanks for informing me on the client vars. so player.attr[] vars would be the best way? I was just wondering cuz if a noob opened a memory editing tool and changed there attr, would this effect show for all other players? seems unfair if 1 player changes his size to 20+ and just stomps you to peices.

[DustyPorViva]

Originally Posted by scriptless

That is what I ment. Foogles showed me this a few years back. It seems to work for a very long time, so long that I was unaware it was even patched. And I assume the .code files are the .code files I see on my computer? Wonder how long it takes for someone to break the encryption :o Graal v2-5 have already had there packet encryption broken (several times).

Thanks for informing me on the client vars. so player.attr[] vars would be the best way? I was just wondering cuz if a noob opened a memory editing tool and changed there attr, would this effect show for all other players? seems unfair if 1 player changes his size to 20+ and just stomps you to peices.

I doubt the encryption is the only form of security backing them up. It probably checks modification time as well.

As for player.attr[]'s, even if a hacker were to change the attr of another player it'd all be clientside. That means the only person who would see the change is the player doing the hacking. Also, there's a reason my system is not dependent on zoom. I use a separate, more secure(ideally, though I mainly leave that up to whomever uses it to implement) variables and zoom is only a visual representation. In fact, the zoom was the last thing I added.

[scriptless]

Originally Posted by DustyPorViva

I doubt the encryption is the only form of security backing them up. It probably checks modification time as well.

As for player.attr[]'s, even if a hacker were to change the attr of another player it'd all be clientside. That means the only person who would see the change is the player doing the hacking. Also, there's a reason my system is not dependent on zoom. I use a separate, more secure(ideally, though I mainly leave that up to whomever uses it to implement) variables and zoom is only a visual representation. In fact, the zoom was the last thing I added.

Correct me if im wrong but you set your clientr. variables twice on the oncreated() for serverside and clientside. I thought only client. variables could be set clientside, and clientr. was read-only on clientside.

This is all good information to know then. We should all hope that graal checks other forums of security. Altho modification time would be useless as I can modify those dates from Borland Delphi 2005 (yes i use outdated version).

Checksum of the files might work. Tho collisions are easy to generate now

[WhiteDragon]

Originally Posted by scriptless

Checksum of the files might work. Tho collisions are easy to generate now

I'd like to see you generate a collision on any random given file without a large array of GPUs and serious programming knowledge. Also, why in the world would anyone go to those lengths for Graal?

Also, sorry for derailing. :P

[coreys]

Scriptless, I think you're over analyzing security a bit lol

[scriptless]

Originally Posted by WhiteDragon

I'd like to see you generate a collision on any random given file without a large array of GPUs and serious programming knowledge. Also, why in the world would anyone go to those lengths for Graal?

Also, sorry for derailing. :P

Sure? I recommend google tho. There are freely available programs to do so. There is a good example (if you have source) to make 2 programs (1 good, and 1 malicious) and they bot have the same filezise, checksum, and what not but do completly different tasks. And this information was easily avalible in 2007 when I tested it. Work has been done with standards and I believe a new SHA algorihtm is already in production to address the flaws in the current hashing algorithms.

Erm, I am not overanyalising security at all. I will fully admit, I am iwir3d. I have been playing graal since 2002 and I have been responsible for several trainers being released. My best trainer I made allowed 2.220 and priror to go form offline mode to online mode and inject scripts onto a server. Here I will link you to some damage I did on GK back in 2005.

http://forums.graalonline.com/forums...light=bloodpet (pictures at bottom and top of 2nd page)

I have since then tried to move my abilities to more productive things but having this knowledge that allows me to do this helps me acheive a greater understanding on BOTH sides of scripting in the efforts for better security.

If you guys want you can do a full search on me
Here are my other names I have gone by: mewtoo18, toybox, dbug, shadow_deathstorm, bloodpet, scriptless, nibnub. And I think that may be it. Oh and ofcourse "iwir3d".

I once read in a book that you should never assume that a bug will not be exploited and you should never assume that any small bug does not esculate into a even bigger bug (as my unethical work has clearly shown).

*sorry for going off topic a little (needed to show how critical security can be).

[WhiteDragon]

Originally Posted by scriptless

There is a good example (if you have source) to make 2 programs (1 good, and 1 malicious) and they bot have the same filezise, checksum, and what not but do completly different tasks.

Sure, if you have the source you can compile the program down with junk data to match the MD5 checksum, but the point in this case is that would be entirely impossible with format that is binary-encoded and can't be easily reverse-engineered.

The complexity of an MD5 collision is still 2^32, and with the added complexity of the format you are trying to engineer a hack into, I stand by my original statement.