x0nic

"only focus on single saber dueling" Actually, the raw concept of JKA's dual/staff sabers is awesome. A decent staff player needs a whole lot more movement/footwork and timing skills than the common poke/wiggle/crouch-addicted single guy. The thing is that the actual saber collision detection and netcode calculations usually suck when it comes to non-single; I guess that's what you were refering to? "We were also limiting it by focusing on maybe three maps and one player model." Why? There are tons of free community-made .bsp and .mdl (was that the correct suffix? I forgot) files out there which are quite HQ and available for free. "Awful for new players" - "interactive tutorial." Indeed, good idea. I play it since release (with several breaks), and nowadays, if one ain't able to air-kill a passively jumping staffer with a one-hit poke, you can consider him a noob. And naturally, being a noob is rather discouraging. I always feel kinda sorry for all the poor and clueless newcomers.... and then I kill them. So yeah you're right, a decent tutorial is vital. "We were also aiming to make it not 'star wars' themed." Avoiding copyright issues, clever. Simply rename the swords to plasma sabers and force powers are too imba for comp gaming anyway, EXCEPT for the high jumps. But we could simply put the arenas on planets with low gravity, explaining it that way, haha "However, even that never got off the ground." "a whole new game, so that maybe a new audience is attracted." You got the point. JK's gameplay is absolutely cool and unique. There's a lot of potential, but it needs a proper implementation, i.e. NOT idTech3 And I would consider myself as talented, but lack knowledge & experience in this specific field. I am only an autodidact who had his biggest projects in cryptography, and thus serious game programming is rather new to me (although I wrote several unlockers for Q3 games and created some unplayable maps with radiant, lol). But I love learning new cool stuff and am quite interested gonna try my best ---------------------------- I've just read the interview with Damian Scott, who says that he already ported certain parts of Jedi Outcast to the Unreal 4 engine for his movie project. Great news, actually! Plus, he's speaking about two mysterious game projects his company is dreaming of... Do you know more about that? Can I find the ported code parts somewhere? EDIT: You may check this video out, if you're interested. It's my favorite JKA fragvid Most hits of this sicko are absolutely impossible with default cfg (yt cutted the audio....)

Yeah I am indeed no expert on the field Do you have any ideas on how to solve the "hax.cfg" problem without making JKA some kind of radioactive rootkit? And if I got it straight, you do not consider the client-sided value fix/lock solution for cvars to be a good idea, don't you? And thanks for the hint to CompJA, didn't hear of it yet! @@Hugo: Yea, I already thought about a U4 porting as well. But you are right: Time and money.... I hoped to find a less complicated solution by patching the openJK code in some way. With a team of 5 to 10 experienced coders who have in-depth knowledge about id-tech3, that shouldn't be an absolutely impossible task. I guess.

Hello folks, I guess everyone who ever tried to play JA in some more serious and competitive way somewhen became kinda fed up with the major role that cfgs, cvar- & "lag"-unlockers (etc.) can play. Obviously, the only ways of creating sufficient e-sport conditions for JKA are either to port the whole game to another engine, or to see what could finally be achieved by modifying the openJK code. Being aware of the fact that the Q3 engine clearly ain't the most convenient solution for such a kind of game, I still think it could be possible to improve the fairness of matches by implementing some basic but appropriate multiplayer-code enhancements. I thought about that yesterday, and do now want to present you some of my ideas. Feel free to give me feedback of any kind What we need 1. An anticheat-workaround for avoiding runtime memory patches 2. The same fixed netsetting values for every client on the server 3. Client- AND server-sided code improvements 4. Some cfg-freaks who REALLY know what JKA cfg-tweaking is about (since my personal knowledge is rather limited) My suggestions 1. The "Anti-Cheat-Engine" I don't think that the implementation of some external memory-surveillance program like punkbuster would make people happy. My idea was to make the client regularly create hashes of static parts in the game process memory on runtime (e.g. SHA-1/256 or MD5 - the latter being already implemented for pk3-integrity checks on pure servers) and send it to the server in a special packet every 10 to 30 seconds (chosen randomly). I doubt that his would have a serious impact on the bandwith or FPS performance. Do you? However, the server then simply compares the hashes (i.e. the client-hash with the concrete hash of a trusted jamp-process) and either kicks the client directly or at least displays an according svsay message for every player if the given strings don't match. Obviously, hash-spoofing can be an issue here, assuming the project to be open source. But let's not precipitate things for now and try to keep it simple - this is only supposed to be a basic brainstorming. 2. Fixed netsettings/cfg cvars In order to keep things fair, it's necessary to force certain settings for ALL clients to be the same. This could be achieved by either adding the flag CVAR_ROM (read-only flag, combined with various if/else limiters in the client exe) or CVAR_USERINFO, therefore letting the server read + correct the values, if necessary. Some of the lethal cmds that everyone should know are: rate -> fixed value: 25000 - since lowrate staff players are a bugged pain in the asscl_maxpackets 63 -> the most neutral value that doesn't create unfair advantages for any of the 3 saber types. Plus, it disables lag unlockers (keep in mind that this one correlates with the clients fps rate)com_maxfps 125 -> kinda obvious, I guesspmove_fixed 1, _msec 8, _float 1timescale / cg_timescalefadeend/fadespeed -> This one is already fixed in openJKsnaps -> I'm unsure if this one should be locked, since we already fixed the rate... But assuming that competitive players usually don't have ISDN, I'd suggest a value of 40cl_packetdup 1 -> If we locked snaps and rate, this is just like finishing the jobcg_smoothclients 0/1 -> Depends on the way we treat timenudge...cl_timenudge 0/-X -> Probably the most important one. I think this should either be "globally" zero or set individually (= player-specific) by a continuous void that computes X = (cl->ping) * -1, so that the "virtual latency" of every client is around 0 (The last solution could produce rendering bugs, tho. Plus, it resembles some kind of hardcoded LU... But the main point is >equality< between the players, nothing else)I'm sure that there are plenty of other settings which influence the gameplay and thereby create uneven conditions between the players. That's where we would need a q3/jka cfg expert. Points 3. and 4. have already been discussed. ------------------------------------------------------------------------------ As already stated, I only want to initiate a spontaneous brainstorming. Besides some simple minor changes on the MP client (= some values locked + flagged read-only) I didn't do any actual programming work yet. And to be honest, such a project - if finished according to all the suggested functionalities I mentioned above - would clearly exceed my C/C++ capabilities. That's where YOU come into play And now, just tell me what you guys think. If a thread on the topic does already exist, please post a link - since the forum search didn't provide me with proper results. Sorry. Let it flow! Cheers, xnc