Raz0r

I started adding emotes yesterday. IRC and Skype are the only IMs I have access to. Will PM my details.

Not exactly. See my signature for a bunch of information on cvars and such.

Admin commands exist, most of them are the same as JA+ The banning system is more powerful than JA+ - it supports ban reasons and temporary bans. Instead of admin levels, JA++ has admin users, each with their own password, privileges, "rank", and login message. With this, you can create e.g. a Council user, Knight user, and Instructor user to mimic JA+ Grapple hook exists, and behaves exactly the same as JA+ Admin chat exists. Instead of clanchat, I have private channels. Essentially, you can join and messages as many channels as you want if you know the password. The JA++ client has a tabbed chatbox to manage messaging different channels. What part of the saber system is missing? I allow SP/MP damages, and added optional tweaks. I improved MP damages at low server framerate. There's a lot of logging in JA++, what's missing? I haven't yet added the IP matching, but this could be done with a lua plugin.

It would be the same process mentioned above. May as-well use JA++, with source available. =]

I believe @@redsaurus added it to SP for the gold pack. Zlyden also added it years ago, but it will only work on jasp.exe

Perhaps you could use this as a reference

Not easily, and the method used would be different on each version of JA+ It would be a server-side only change. You'd have to disassemble the code to find where clan-chat messages are sent, then hex-edit the colour it uses. It could use its own string, or point to strings used multiple times and concatenate them. Could be painful.

Just hasn't been updated in a while, and modifying it makes it a pain to merge in changes from OJK which modify that readme.

^ Good point, there's always been an influx when that happens. All two times.

And with the source released under GPLv2, if you were to add it to the engine source, you'd have to release that code, so you may as-well not bother. You're welcome to do it the JKG method, if you plan on only supporting jamp.exe and going through many hours of hell to write it.

Are you playing them on a laptop or something? I get the same issue when trying to play back at 1080p on my external monitor.

It already has attracted quite a few people after it was posted around Phoronix, Reddit and Occulus forums. There will be an official/stable release very soon, and will be advertised a lot more then.

It's an ~11 year old game. Activity is very slowly decreasing, with fluctuations based on the time of year and if there's a Steam sale or any other similar advertising.

Youtube only allows ~30fps videos, that'll be reducing the smoothness of it. h.264 cuts off the lower 3 bits of colour values when using "tv colours" setting. Look around for that setting, or anything related to gamma. It's a common issue.

Yep. Playing on LAN. Or time travel. Or quantum entanglement. I can only do 1 of those 3 =[

JA++ and OJK force a client update with falsified inputs every g_forceClientUpdateRate milliseconds to avoid those exploits/issues. Could also interpolate their path between frames and touch triggers.

JKA uses prediction heavily, that's why your saber swinging animation plays instantly instead of waiting for the server to acknowledge it. The problems I presented still stand. The technique they describe (target-relative shot information) will achieve the same result as the existing Unlagged.

Yeah, we're talking aimbots, wallhacks, ESPs, exploiting bugs through code modification, input automation (auto-kick, scripting attacks)

I've seen plenty of people using cheats/hacks, on almost every server. Giving the client full control over dealing damage would present the exact same problem in my first post. Major visual inconsistencies and odd timing behaviour with blocks. "Unlagged" effectively does the same thing. Each client movement command, the server saves the client's position up to ~1000ms in the past. When testing for a collision (e.g. when client A shoots the disruptor at client B) then client B is moved back to where their position was based on client A's ping, so they will be where client A was aiming when they sent the "fire" command. Collision is performed, damage is (potentially) dealt, and client B is moved back to where they were before unlagged kicked in. The end result is, that looks fine for client A...but let's look at it from client B's perspective. Client B may have moved around a corner within the past x milliseconds, where x is client A's ping Now there is a solid wall between them...yet client B gets hit and dies! This is because unlagged was triggered by client A's input (i.e. shooting the weapon) Another input to consider, is blocking with your saber - specifically client B parrying an attack from client A From client A's perspective, client B is right next to them, and their sabers are touching. In order for client B to parry, they would have to predict that client A's saber would be colliding with theirs x milliseconds into the future, where x is again client A's ping. Now going back to client B's perspective, pretend client A was standing still and swinging. Client B runs forward, and from their perspective, their saber collides with client A's saber, and they initiate a parry. Now client A was somehow parried by someone several meters away, with no way to predict that. That's just a simple example of what crazy things would happen in both scenarios (Using "Unlagged" with sabers, or letting the client decide what happens in combat) EDIT: Oh, hello, slight wall of text.

You can't predict the future, so this will only work to a degree. You can make it so your own slashes will hit your target, but from their perspective you might have hit them from several meters away, and they would have had no time to prepare. It would also screw over time with things like blocks. It's definitely been thought about, but it would introduce too many visual inconsistencies and weird behaviour. It's best to just compensate manually for latency in this case.

Yeah, use a font mod. The base ones are pretty small.

I'm not convinced

JA+ didn't patch it. It's patched in OpenJK.

Maybe don't go into specifics, it's kind of nasty.

Correct. Each client frame will generate a corresponding movement command, aka usercmd, thus you can not send more than 1 usercmd per frame. (cl_maxPackets <= com_maxFPS) If you were to set cl_maxPackets to 125, you would send 1 usercmd per packet. But with a non-modded jamp.exe, cl_maxPackets is limited to 100, which means sometimes you would send 1 usercmd per packet, and other times 2 usercmds per packet. In this case, it would be better to consistently send ~2 usercmds per packet, so long as you are sending at-least sv_fps packets per second. If you are sending at-least sv_fps packets per second, they will be queued and processed on the next server frame. The issue with having a lower cl_maxPackets/com_maxFPS value is the increased data-loss in situations with high packet-loss or latency, leading to warping as more usercmds are being processed (or skipped) each server frame. In general, com_maxFPS is best set to 125 (For physics and display reasons), so cl_maxPackets is best set to 63 (125/2)