Tr!Force wrote:
that is just nice, specially the password protection
I agree. I am currently using md5 hashing, though I am looking in to the possibility of importing SHA512 instead.
Tr!Force wrote:
UI changes (.menus) need client downloading, but in a pk3... and yes, .menu files can send & get custom info from the server, and send info to the server (u can do everything u can do via console, set commands, binds, get info, send info, etc... .menus are only like a mask) a lot of mods on jk3 does that, not to much people knows how to use the console, so is better to get in a interface. :)
That's good to know. I just scanned through some menu files and some code and found I can access convars and send commands, so that is ideal. I will look in to this too.
Kameleon wrote:
Some UI related things can be done entirely with .menu files :) For things that require some stuff from the UI code to work, you can choose to compile your UI as a qvm instead of a dll ;)
Yes, of course.
Daggolin wrote:JK2MV is only an engine mod so far, so it can't really address all bugs from the game or cgame modules (like the client 0 bugs). Some things would actually be better fixed inside the modules (jk2mv's way works, but it's technically "just a workaround"), so you can use the "mvapi" inside your mod to disable certain fixes/workarounds in the engine, so you can deal with them inside of the module.
We are planing of including custom game, cgame and ui modules in later jk2mv releases, using a merged code base for 1.02, 1.03 and 1.04 modules, cause the way the original code for the modules works is only compatible for one version (1.02 mods won't even load in 1.03/1.04 and vice versa). I already started working on such a codebase and had an initial "multiversion vm" code almost ready, but then problems came up and I didn't have any time to solve them and clean things up. However once I get the time I want to fix those things and create a repository for that codebase so anyone can base their mods on that instead of the basejk sdk. The code comes with fixes for as many issues as possible.
I like that idea, having modules compatible with each version of jk2 would be great. Do you have any ETA on that?
Daggolin wrote:
Regarding the use of dlls, I can understand that it's a lot more comfortable to write mods using modern c-standards, accessing all the libraries (for instance for hashing) or simply allocating memory with malloc. However there are a couple of reasons for using qvms rather than native libraries for jk2 mods. One of them is native libraries being specific for one operating system. Having 32 & 64 bit versions of jk2mv for windows and linux, as well as the universal version for mac means you have to compile your modules at least 5 times each to reach all versions of jk2 people actually use. QVMs simply work on all platforms and even mods made in 2002 still run on all versions of jk2, independent of the operating system. Another reason is security and trust. The QVMs are meant to be limited in what they can do (no direct syscalls, only indirect file i/o through the engine's API, ...). That's one of the reasons the QVM is that "limited", but it also prevents QVM-mods from doing really evil things. For that reason Quake 3 and JK2 actually read QVM mods from within pk3s, they don't do that with dll/so/dylib mods. This means you can provide a cgame.qvm or ui.qvm for your mod through the ingame download feature, where native libraries must be installed manually by the clients. Litte more on QVMs:
http://fabiensanglard.net/quake3/qvm.php.
Yes, I am familiar with QVMs. It is nice having secure modules that can be used across multiple platforms safely. They were a bitch to hook and play around with before the real source was released. That is my only gripe with them though :P
Daggolin wrote:
Regarding the encryption of passwords I really like when servers and mods do that, however it's not that safe, as the server can still read everything in clear text if he just wants to. Knowing passwords are encrypted some users (and admins) tend to get careless. They start using their "default passwords" or share login files with the hashed passwords, not even knowing how dangerous that is. The only thing that prevents users from using their "default passwords" and protects them would probably be to generate random passwords for the users and only store hashes of those random passwords. It would be a bit less comfortable for users, but it would be more secure. However I am probably going to stick with hashing in future mods, too. Or maybe they get a random password on regisration with the possibility to change their password later in a more "complicated way" later on that makes sure they're aware of the risk. But whatever, I am getting off-topic here. :P
Yes I am also quite familiar with how the commands are transmitted in plain text, this was an issue in jka with lugormod too. For additional security, I have been using lugormod's "security code" idea requiring users to enter an extra code when logging in from a new IP address. It is a pain in the ass if you have an IP that likes to change a lot, but it adds (a little bit of) extra security in case someone gets the password. On that note, I like the idea of using a generated password upon account registration so I will look in to adding that too.
Daggolin wrote:Nice to see a new modder around. Keep up the nice work. ;)
New to the forum perhaps, though I started dissecting JK2 back in 2006 and have been tinkering with it on and off ever since. Most of that was breaking the game and finding out how to fix it though, because I got tired of people crashing the server I frequented and wanted to do something about it. I could go on and on, but I'll save you from the boring story :P. And thanks.
I am also thinking about modifying the entity system to be like lugormod. That is, any entity the client doesn't need to know about won't be transmitted and will be stored separately as a logical entitiy. I also want to look in to what entities in various SP maps cause clients to drop and look in to ways of patching them through the game module. I know that most of the SP maps can't even be loaded due to the submodels limit, though there are several exceptions. Eventually, I would like to add commands (and maybe a UI) to add, edit, and delete various entities on the map and save the entities to a file. That's a long ways down the road though.