WIP: Account system, various fixes for 1.02

Discussions about modding, questions, mod requests or just show off what you're working on.
Post Reply
ozzeh
Posts: 13
Joined: 16 Dec 2015, 21:32

WIP: Account system, various fixes for 1.02

Post by ozzeh »

So I was bored and decided to make an account system for jk2 (1.02), inspired by Lugormod from jk3. In Lugormod, players were able to register accounts on the server and use them for tracking stats, authenticating administrative permissions, and various other things. so far, I've managed to get a working account system in the game module and am almost done with the admin part too. it's all written in C though.

the mod also has various "bug fixes", such as client 0 damage reduction and rolling in the beginning of a saber swing to cancel it, forcepowers crash, entity limit crashing (think sentry and seekers).

if and when I manage to complete this, I will probably be posting it around here somewhere.
User avatar
Boothand
Administrator
Posts: 986
Joined: 24 Feb 2015, 08:21
Contact:

Re: WIP: Account system, various fixes for 1.02

Post by Boothand »

Sounds cool! What kind of stats would you keep track of?
ozzeh
Posts: 13
Joined: 16 Dec 2015, 21:32

Re: WIP: Account system, various fixes for 1.02

Post by ozzeh »

Boothand wrote:Sounds cool! What kind of stats would you keep track of?
anything I can think of, right now stuff like kills, deaths, flag captures, flag returns, score earned, time played, duels player, and duels lost. more stuff if i can think of any
User avatar
Tr!Force
Posts: 433
Joined: 26 Feb 2015, 12:25
Location: Chile
Contact:

Re: WIP: Account system, various fixes for 1.02

Post by Tr!Force »

nice, lugormod account system is rly nice.

¿how ur admin/account system will work? ¿how will store the user stats?, any chance to show the features? (user registration, delete account, change password, the things will store on their account, etc...)

ive made a small account system few years ago (i attached few screenshots above). if u want more ideas or suggestions for ur mod i suggest u to make an UI like a login box, or some menus to see all info (i wamted to so in mine). Using the console and command is too antique...

PD: i think the "bug fixes" isnt needed because jk2mv already had done.

Image
Image
Image
"The dark side? I've been there. Do your worst." - Kyle Katarn
  • JK2 & JK3 Code-Mod Developer
  • Jedi Knight Plus Mod Project: Click Here
  • E-Mail: triforce@gznetwork.com
  • Discord: TriForce#8785
ozzeh
Posts: 13
Joined: 16 Dec 2015, 21:32

Re: WIP: Account system, various fixes for 1.02

Post by ozzeh »

Tr!Force wrote:nice, lugormod account system is rly nice.

¿how ur admin/account system will work? ¿how will store the user stats?, any chance to show the features? (user registration, delete account, change password, the things will store on their account, etc...)

ive made a small account system few years ago (i attached few screenshots above). if u want more ideas or suggestions for ur mod i suggest u to make an UI like a login box, or some menus to see all info (i wamted to so in mine). Using the console and command is too antique...

PD: i think the "bug fixes" isnt needed because jk2mv already had done.

Image
Image
I store the account information the same way lugormod does, by using account files named user.uac. The stats, admin auths, and password are all stored in here, though the password is hashed. As far as fixes go, jk2mv can't fix the client 0 bugs because they're in the game code, and last I checked the sentry crash still works with the current release (v1.1) of jk2mv.



Can those UI changes be done without the client downloading a custom ui module? I know (or I think I know) jk2mv can require clients to download certain pk3s, but I'd rather not require any modules at all. Or can the .menu files themselves send custom commands to the server?

edit-not using DLLs
Last edited by ozzeh on 18 Dec 2015, 03:47, edited 2 times in total.
User avatar
Tr!Force
Posts: 433
Joined: 26 Feb 2015, 12:25
Location: Chile
Contact:

Re: WIP: Account system, various fixes for 1.02

Post by Tr!Force »

ozzeh wrote: I store the account information the same way lugormod does, by using account files named user.uac. The stats, admin auths, and password are all stored in here, though the password is hashed.
that is just nice, specially the password protection
ozzeh wrote: As far as fixes go, jk2mv can't fix the client 0 bugs because they're in the game code, and last I checked the sentry crash still works with the current release (v1.1) of jk2mv.
jk2mv engine works over the entire code (server & client side). ouned and Daggolin told me all knowns bugs are fixed... is weird if u say the client 0 bug or the sentry crash is present. :shock:
ozzeh wrote: Can those UI changes be done without the client downloading a DLL? I know (or I think I know) jk2mv require clients to download certain pk3s, but I'd rather not require any DLLs at all. Or can the .menu files themselves send custom commands to the server?
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. :)
Image
"The dark side? I've been there. Do your worst." - Kyle Katarn
  • JK2 & JK3 Code-Mod Developer
  • Jedi Knight Plus Mod Project: Click Here
  • E-Mail: triforce@gznetwork.com
  • Discord: TriForce#8785
Kevin
Administrator
Posts: 393
Joined: 07 Jun 2015, 08:36

Re: WIP: Account system, various fixes for 1.02

Post by Kevin »

Always interesting to see new modders pop up :mrgreen: We're quite a few active modders on this forum, so you should feel quite at home :lol:
Tr!Force wrote:PD: i think the "bug fixes" isnt needed because jk2mv already had done.
Still a good idea to fix the bugs in case it would ever be used on a server that doesn't run JK2MV :)
Tr!Force wrote: Can those UI changes be done without the client downloading a DLL? I know (or I think I know) jk2mv require clients to download certain pk3s, but I'd rather not require any DLLs at all. Or can the .menu files themselves send custom commands to the server?
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 ;)

And yes, client zero bugs are not fixed in JK2MV, so it is great to see you fixed them yourself :D Fixed those two client zero bugs a long time ago myself, but if you happen to find any new client zero bugs other than those two, be sure to let us know :D
User avatar
Tr!Force
Posts: 433
Joined: 26 Feb 2015, 12:25
Location: Chile
Contact:

Re: WIP: Account system, various fixes for 1.02

Post by Tr!Force »

Kameleon wrote:Always interesting to see new modders pop up :mrgreen: We're quite a few active modders on this forum, so you should feel quite at home :lol:
+1
Kameleon wrote: Still a good idea to fix the bugs in case it would ever be used on a server that doesn't run JK2MV :)
In that case we need to promote and encourage the use of jk2mv all old and new jk2 players. is like a marketing plan, we must promote innovation and the new develops.
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 ;)
that is just a point i forgot to say (the dll thing). i agree because 40% of jk2 players uses linux or osx (include me). I do not see the point of using dll unless you want to work with the engine like nt 's mod (which would not be at all possible with jk2mv)
Kameleon wrote: And yes, client zero bugs are not fixed in JK2MV, so it is great to see you fixed them yourself :D Fixed those two client zero bugs a long time ago myself, but if you happen to find any new client zero bugs other than those two, be sure to let us know :D
in that case, ¡go on! :lol:
Image
"The dark side? I've been there. Do your worst." - Kyle Katarn
  • JK2 & JK3 Code-Mod Developer
  • Jedi Knight Plus Mod Project: Click Here
  • E-Mail: triforce@gznetwork.com
  • Discord: TriForce#8785
User avatar
Daggolin
Administrator
Posts: 794
Joined: 23 Feb 2015, 13:05

Re: WIP: Account system, various fixes for 1.02

Post by Daggolin »

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.

Regarding the sentry crash that should be fixed since the first release of jk2mv. If you found a way to still crash jk2mv servers we would appreciate some more details so we can fix it in later versions (or make a pull-request, if you want to).

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.

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

Nice to see a new modder around. Keep up the nice work. ;)
ozzeh
Posts: 13
Joined: 16 Dec 2015, 21:32

Re: WIP: Account system, various fixes for 1.02

Post by ozzeh »

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.
Last edited by ozzeh on 21 Dec 2015, 03:45, edited 1 time in total.
User avatar
Daggolin
Administrator
Posts: 794
Joined: 23 Feb 2015, 13:05

Re: WIP: Account system, various fixes for 1.02

Post by Daggolin »

That sounds nice. I have plans to make logical entities server-only as well, but I wasn't aware Lugormod on JKA aleready has such a feature. I actually did lots of entity related changes (modifying them ingame, own new types of entities, ...), but it's only in the dark Twimod on the dark server. I decided against releasing that mod cause it is based on the old (and ugly) codebase of Twimod by ouned (from when he started programming) and the code also contains my first encounters with programming back in 2009. You can imagine the mod is ugly coded, insecure and instable. I am really surprised I managed to get it somehow stable on dark. It is actually that messed up that there is horrible memory issues through all the qvm. Declaring a variable at the top of a function leads to random things like lightning and drain not hitting people anymore, weapons getting deleted on pick up, etc. And that is totally not a mod or codebase anyone should use.

However I want to make a new mod "from scratch" once the mvsdk is ready and released (the work on multiversion qvms actually started for the "new mod", but as it is exactly what we need for jk2mv as well I figured it makes sense to first make a stand alone sdk before going on with a new modding project). For that new mod I want to include all the map modding features from the dark server as well as many new things. The dark server is capable of running those spmaps that don't exceed the submodel limit by the way. I have a few people interested in working with me, so that's what I am planing to work on once the mvsdk is ready and real life leaves enough time to spend on own projects. If you are interested in that project or code pieces from the dark Twimod just let me know. ;)

And I am sorry, but I can't give you an ETA for the mvsdk. I think I am going to try to solve one main issue and push a working version into a public repository, giving others the chance to work on the mvsdk as well.
User avatar
ouned
Administrator
Posts: 596
Joined: 23 Feb 2015, 13:03
Location: Gliese581c

Re: WIP: Account system, various fixes for 1.02

Post by ouned »

ozzeh wrote: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
Pls stay compatible with qvm's.
Can you compile for
- win32
- win64
- linux32
- linux64
- macosx32
- macosx64
- possibly arm / linux in the future
?

With using qvms you can basically avoid all kind of library / linking issues and lay out that problem to the JK2MV devs^^
Of course that only works if you don't need any special things like network access etc.

Some additional stuff you can use:
https://github.com/mvdevs/jk2mv/wiki/API-Overview
Post Reply
Created by Matti from StylesFactory.pl and Warlords of Draenor (modified by jk2.info)
Powered by phpBB® Forum Software © phpBB Limited