Raz0r

It looks too flashy, but it's fairly cheap. A lot of "gaming" hardware that sells itself as gaming hardware, is often just for looks/novelty.

Try using OpenJK or have JA installed somewhere outside of Program Files

Wired. I could only expect most wireless devices to introduce latency. I know some are good, but wired is always good/safe.

I just went back to Logitech G500 after trying out WMO and Steelseries Kinzu v2 Pro. Never been happier with a mouse, it's the only one that feels responsive/doesn't skip, precise af, no negative accel, 1000hz polling through its own driver) For (mechanical) keyboards, I alternate between Tesoro Tizona and CoolerMaster Storm QF, I recommend both depending on the amount of action you want. For monitors, I absolutely can't recommend anything other than 120hz/144hz - current using BenQ XL2411t, but the colour reproduction definitely off. I'm looking to replace it. Mice are cheap. Keyboards get pricier because you'll want mechanical. Monitors you're going to want to splash out, it's worth getting that refresh rate. Ping has it right.

I'm not talking shit about SAC :< jdolan's method relies on hand-shaking with cryptographically-secure public/private key exchange paired with a cryptographically-secure one time pad (misnomer to call it a GUID) If that part is implemented correctly, it is not feasible to hack or bypass. The "one time" requirement means that message does not persist, you can not use it again. Because you can't forge that one time pad, you must be running the secure agent and generate the correct tokens. Once the connection is trusted (i.e. a trust boundary is established) then further checks can be performed reliably. This doesn't cover the threat model, though. This only ensures a trusted client on a small set of data (i.e. verify a certain piece of code is running, not verify a certain piece of code is NOT running) In other words, it's only step 1 of a particular "anti-cheat" method. There are still many more steps to take to prevent any actions you consider "cheating" as part of your threat model. Most people identify these wrongly, and this is one way false positives can be introduced. That's not a requirement, and I wasn't acting like an arrogant dick @_@ The more complex methods used in an anti-cheat system, the less it makes sense to hide the source code. Not providing source does not improve security, which was your claim. You already know about disassembly and the weaknesses of packers, which means you already know hiding the source does not hide the code that executes. The best method is of course to assume the environment is not secure, and design around that. That's information theory 101.

Sounds like it's due to using new compilers for newer language features (> VS2010 with C++11) - not sure how feasible it is to reintroduce XP support. It's 12 years old, hasn't received support for years.

How are you confirming they are 64 bits? What error are you getting when trying to run it? I haven't tried using OpenJK on Windows in months, but I'm not aware of any decisions to make it 64 bit only. I'm getting someone to confirm it at the moment. EDIT: Downloaded the files, they all seem to be 32 bit. @@mrwonko just checked the PE header, they're 32 bit binaries. Are you not talking about Windows?

OpenJK is 32 bit on Windows (which runs on 64 bit Windows), 32 + 64 bit on Mac and Linux.

Consistency and ease of development. But are vital to competitive CTF. Hi there. The assumption that only closed-source programs can effectively implement security is "security through obscurity", widely known to be wrong. The less people auditing your code, the less reputable it is. But again, as I said, jumping the gun WRT anti-cheat is not the way to go. You can't properly identify your threat model with an incomplete product. You can guess at it, but it will be constantly changing and any implementation of "anti-cheat" or "security" (extremely varying terms) will be invalidated. Security is something I'm passionate about and it's often done so incredibly fucking wrong because of simple assumptions/lack of knowledge.

Most of your suggestions assume security facts that are not true, mostly related to crossing trust boundaries. As someone with experience in gamedev + engine programming, security and competitive play, the only real options are heavily modified OpenJK (See: CompJA on GitHub), or an entirely new engine. Trying to graft JA onto another engine will result in a game that feels terrible, especially if you don't understand the very intricate parts of iD tech 3's design and implementation (network model, frames and snapshots, rendering, input) Trying to stick to gamecode changes won't bring the improvements needed for a successful competitive JA. Jumping the gun with "anti-cheat" is never a good idea. I've seen countless attempts that get all core assumptions on security wrong, and are almost entirely ineffective. But really, the main flaw with this is a lack of experienced coders who are available and willing to put time into it. If I ever do get time again, it'll go into CompJA again.

Does it actually crash, or does an "assertion failed" message come up?

Run it under a debugger, you'll see exactly where it's crashing and why. Then you figure out the logical steps to fix it.

Sounds like the IDE theme wars between coders. And themselves. Some of change theme/layout on a daily basis. 3/10/14 16/12/14 2/6/15 8/6/15 27/6/15 6/7/15

The field of view is the same. The point of view changes. Third person only moves the camera backwards and up.

They're the same thing. If it's a command-line interface to git, it will work.

You need to use BSP entity modding. There are a few tutorials, I'm sure there's one on this site.

Why you mad though?

Easiest way is to just run through terminal.

Only light entities should be disappearing.

Didn't sithcouncilv2 do that? at-least for a light-saber. Might have been an ICARUS scriptrunner to give the weapon and move the weapon model somehow.

git checkout <branch-name>

Depending on the mod, probably no one will receive the message. Maybe "123 Alpha" will, and it probably depends on who connected to the server first. It would be best to use JA+'s clanchat system for this.

Cvar. You can set it at startup, or during runtime followed by a vid_restart command.

Try r_ext_compress_textures 0, texture compression tends to have some issues with various Linux drivers.

Remember,