OrionTF beta

[ceriux]

btw i know im a lil late, but this looks sexy wish i had the chance to play.

[scar3crow]

Tried it again, with the teamplay settings on. Pretty fun, though it seems like some bots are exceptionally better than others. A single soldier killed me four times in a row, along with three of my teammates, multiple times. I would think it was just me sucking, but none of my bot teammates could stand up to him. He just racked up the frags outside of a spawn room in 2fort5.

Also, I got kicked out of the game for cheating, due to my speed? I don't know, I entered a respawn room, grabbed, some ammo, and was exiting the respawn room when I got kicked from my own game.

[Orion]

@scar3crow This also happened to me. Often. Mainly if I'm a Scout.
At that time I didn't figure out how to fix that, but I realized that I just needed to change some numbers on the cheat checking function. That function is to prevent players changing their cl_forwardspeed and so to values higher than the class' default speed.

Also, on PlayerPostThink() I added some lines that prevents a player to bunnyhop. Sure he can bunnyhop normally, but it he reaches a certain speed, when he hits the ground, will result in a complete stop, giving him a major disadvantage, depending on the case. The criteria is if he reaches the class' speed + 200 units (say soldier's speed is 240, so the maximum is 440) while bunnyhopping, he'll have a complete stop when landing on the floor. But this won't kick a player out of the server. Also, you may notice some "stops" when you try to wallhug.

I also let the bot's aim a bit less botlike, but I'm waypointing some more maps, and I'll then release a patch.

[Sajt]

These Satanic hacks are where (vanilla) Quake shows its age (and inexplicability of some of the programmer's decisions)... The sensible thing to do is to send movement values in the 0-1 range and send the status of the run key, rather than multiplying to get the desired player speed on the client-side. And the equally abominable "anti-bunnyhop" hacks wouldn't be necessary if SV_PlayerPhysics were modified. If you are intending this mod for vanilla engines, it's like the outbreak of world war... senseless and horrifying but there's not much I can do about it. I would like to just run away and pretend this world doesn't exist.

[Pulseczar]

Just tried to run this in WinQuake. When I spawn a bot, the game crashes with i >= cl.maxclients. I tried setting 'maxclients' but discovered that it doesn't exist in NetQuake.

[Orion]

Try -listen 16 on the command line.
Then set deathmatch to a value other than zero, teamplay to 1 or 2, and maxplayers to 16. On NQ the command is maxplayers, not maxclients.

[Dr. Shadowborg]

Forgot to mention it in my earlier post, but scar3crow's post reminded me, I too got kicked for speed cheating a few times (even though I wasn't), seemed to happen on any class.

[Spike]

SV_PlayerPhysics? DIE! DIE HORRIBLY! SERIOUSLY, DIE!!!

That extension is an abomination that mucks up prediction big time.

If you want to prevent QW-style acceleration in zquake/mvdsv/fte just set pm_bunnyspeedcap 1
Same physics, no bunnyhop acceleration.
Note that you can still propel yourself quickly using rockets, but you'll slow down again if you turn... At least I think you will.

Speedcheating in QuakeWorld is detected by checking the duration of the movement frame which the client sends to the server. Its not due to your actual speed (as that would break as soon as you bunny).
In other words: lower your client's framerate (or packetrate in clients that support that).
If you're running the mod in DP, you need to reduce the server's ticrate down to no more than 77 tics per second, I assume.

[Orion]

If you want to prevent QW-style acceleration in zquake/mvdsv/fte just set pm_bunnyspeedcap 1
Same physics, no bunnyhop acceleration.
Note that you can still propel yourself quickly using rockets, but you'll slow down again if you turn... At least I think you will.

OMG! *facepalm*
The mod is NQ-only, but if I host it on an FTE dedicated server, any QW client can join. And this command is also on FTE.
So I'm gonna take out my server-side bunny limiter. But the speed cheat check will be still there. I raised some numbers a bit, and when I played, at least I didn't get kicked on a 15-minute match, but I gotta test it again to guarantee. Because anyone can change their cl_forwardspeed and so to values higher than their class' speed, and this function will reset the commands to the class' original speed and if that happen repeatedly, that player is kicked from the server.

At least when I play on DP or FTE, these commands are latched, as they're stuffcmd()'d.

EDIT: Forget to mention that the speed cheat is checked every 2 seconds. It's not checked every frame, otherwise you'd be kicked in a matter of seconds. I just made the function less sensible.

[Spike]

How do you measure speed?
Does this also consider rocket impacts on people running? Gravity?

[Orion]

Actually I didn't made the code, I taken it from TF source code and adapted it to my mod.

Code: Select all

void() CheckSpeedHack =
{
   local float tf, pf;
   local vector vplf, vf, ang;
   
   self.nextthink = time + 2;
   
   if (self.owner.deadflag)
      return;
   
   if (!(self.owner.flags & FL_ONGROUND) || self.velocity_z != 0)
      return;
   
   vplf = self.owner.velocity;
   
   ang = self.owner.v_angle;
   ang_x = ang_z = 0;
   makevectors (ang);
   
   vf = v_forward;
   vf_z = 0;
   
   vf = normalize(vf);
   
   tf = (vplf_x * vf_x) + (vplf_y * vf_y);
   
   pf = self.owner.speed + 200;
   
   if (tf > pf)
   {
      pf = pf + 200;
      
      if (tf > pf)
      {
         dprint (self.owner.netname);
         dprint (" had his speeds reset\n");
         self.nextthink = time + 2;
         self.owner.cheat_lev = self.owner.cheat_lev + 300;
      }
      else
      {
         dprint (self.owner.netname);
         dprint (" had his speeds cautiously reset\n");
         self.nextthink = time + 3;
         self.owner.cheat_lev = self.owner.cheat_lev + 150;
      }
      
      SetSpeed (self.owner, self.owner.speed);
   }
   
   if (self.owner.cheat_lev > 1200)
   {
      self.owner.cheat_lev = 0;
      
      bprint (self.owner.netname);
      bprint (" has been kicked for cheating\n");
      sprint (self.owner, "You have been kicked for cheating, because of your speed.\n");
      stuffcmd (self.owner, "disconnect\n");
   }
};


It only works if you're on the ground. You can still move quickly via a rocket-jump, grenade-jump, gun knockbacks and such.

[Orion]

OK I finally decided to update this.
There are now 18 waypointed maps in total, and that visible weapon bug was fixed. It's now handled by 'temp1' cvar.
Also detpacks will now destroy walls, grates etc.

File (10mb):
http://www.quaketastic.com/upload/files/multiplayer/mods/oriontf_beta2.zip

[Team Xlink]

OK I finally decided to update this.
There are now 18 waypointed maps in total, and that visible weapon bug was fixed. It's now handled by 'temp1' cvar.
Also detpacks will now destroy walls, grates etc.

File (10mb):
http://www.quaketastic.com/upload/files/multiplayer/mods/oriontf_beta2.zip

So does this mean the DP_SV's aren't required anymore?

Or is DP_CHECKEXTENSIONS, used?

Or am I just talking non sense and none of what I typed is relevant to it at all?

[Orion]

It uses DP_CHECKEXTENSIONS.
You can run it on practically any engine, except regular WinQuake (you'll get skin taller than 300 errors), but WQPro will run fine.

If you run it on DarkPlaces or FTE, the only thing that changes is visible weapons support, just set 'temp1' to 1.

[r00k]

The mod also features visible weapons, which are separate weapon models from the player. Unfortunately, if don't play on DarkPlaces or FTE you'll get a bug like this in 1st person view

Can't you just stuffcmd to all clients r_drawviewmodel 0 ?