I know some people (include me) are interested to work with the Daggolin's work: MVSDK (The improved basejk code, not the engine). Basically, is an "All in one mod", which runs in any game-version, so we don't need to code a mod for 1.02, 1.03 or 1.04 separately. And, this will comes with various bug fixes and enhancements.

While Daggolin is working on the multi-version support, I think we should begin to suggest what would be the bug fixes and enhancements.

PD: i listed some things... but i dont remember more right now
EDIT: I know somethings are fixed in JK2MV yet. but idk if somethings need to be fixed only via game-code.

Bug Fixes(Errors that prevent the proper functioning of the game)

Crashing Exploits

Fake Players

Saber Stealing from Spectator

Turret Chair Crash

Team Follow Bug

Callvote Exploit

Duel Challenge Bug

TheDestroyer stuck Bug

Force Get-Up Bug

Enhancements(Internal functions could be improved or new features)

Improved g_slowMoDuel functionally

String colored messages after a colored name

1st person Turret Chair view

Widescreen/Eyefinity Support

SinglePlayer Map Entities Support

Some More limits (cg_fov, name length etc...)

Last edited by Tr!Force on 24 Nov 2015, 23:21, edited 3 times in total.

ouned wrote:as far as i know all security related bugs already have been fixed

i know... but all of them can be done by engine? (the current jk2mv), i think some bugs/improvements need to be done via game-code... (i dont know really)

Widescreen/Eyefinity Support

ouned wrote:cg_fov?

Not cg_fov, thas for the 3d render, im talking about the 2d render, the current code is an streched 640x480. look at this. (i did a noob paint lol, im not at my PC right now), in my tests i fixed, but only for huds...

so is rendered like this (look at the colors):The Player Tr!FoRcE is dancing.

So in that case we can just add the ^7 to get the rest in white... but there are some cases when there are multiple strings variables from another sources:trap_SendServerCommand( -1, va("print \"%s" S_COLOR_WHITE " %s\n\"", client->pers.netname, G_GetStripEdString("SVINGAME", "PLCONNECT")) );

in that case we can just add the S_COLOR_WHITE to prevent this, but need to be "fixed" in various places...

Tr!Force wrote:i know... but all of them can be done by engine? (the current jk2mv), i think some bugs/improvements need to be done via game-code... (i dont know really)

JK2MV and MVSDK isn't the same thing. The MVSDK has nothing to do with the engine, but will become a new, clean, and fixed codebase, which will hopefully be used by future modders over the original basejk sourcecodes. Hence the MVSDK can fix things that needs to be done via the game-code.

Tr!Force wrote:

Yeah, I have this issue with the stretched HUD too

ManiaC wrote:i dont like the color thing.

The example Tr!force gave with the "dancing" was how a lot of the messages look in the normal JK2 code, e.g. when someone captures the flag and such things. His suggestion was not to make them look like that, but rather to have them fixed instead

Tr!Force wrote:i know... but all of them can be done by engine? (the current jk2mv), i think some bugs/improvements need to be done via game-code... (i dont know really)

JK2MV and MVSDK isn't the same thing. The MVSDK has nothing to do with the engine, but will become a new, clean, and fixed codebase, which will hopefully be used by future modders over the original basejk sourcecodes. Hence the MVSDK can fix things that needs to be done via the game-code.

i know jk2mv and mvsdk isnt the same thing. (i said at the beginning of this post), but ouned says "security related bugs already have been fixed", and my question was if all bugs can be fixed via jk2mv... i thought not. i think some things need to be fixed via game-code. idk

Kameleon wrote:

Tr!Force wrote:[streched hud img]

Yeah, I have this issue with the stretched HUD too

everyone has that problem (jk2 and jk3),i discussed this with some guys attemped to fix this, like "ent, from joMME" or "eezstreet from openJK"... huds are easy to fix (editing all cgs.widthRatioCoef), but there are some texts or fonts which would require modified renderer... same with the jk2 menus i think.

Kameleon wrote:

ManiaC wrote:i dont like the color thing.

The example Tr!force gave with the "dancing" was how a lot of the messages look in the normal JK2 code, e.g. when someone captures the flag and such things. His suggestion was not to make them look like that, but rather to have them fixed instead

I don't quite get why you make a "To-Do List" for other people instead of suggestions, but whatever.

Tr!Force wrote:Bug Fixes(Errors that prevent the proper functioning of the game)

Most of them are fixed already, including many that weren't listed here.

Tr!Force wrote:Enhancements(Internal functions could be improved or new features)

Improved g_slowMoDuel functionally

String colored messages after a colored name

1st person Turret Chair view

Widescreen/Eyefinity Support

SinglePlayer Map Entities Support

Some More limits (cg_fov, name length etc...)

As for the mvsdk itself we want to keep it very simple and as base as possible. I don't think singleplayer entities or support for longer names should be added to the mvsdk serverside. If anything black color in names could be made available, but no "real changes". The "widescreen support" and the stretched HUD fix however are something I want to have in the mvsdk and a compiled version of the mvsdk is supposed to be included in future jk2mv releases (once it's ready).

Currently the problem is mostly the syscalls when running the serverside in 1.02 mode. Due to the sharedEntity struct being shared among the game module and the engine both can access and modify the "shared entities" at any time, so with the mvsdk internally using the 1.03/1.04 structs and the engine using 1.02 structs the structs need to be converted not just once, but every VMCall and every syscall to ensure everything runs fine and both - game and engine - can access the struct at any time. This however leads to massive CPU load (even on modern systems), cause there is an incredible number of conversions going on. We could "work around" the performance loss by not converting the struct for every syscall, but that possibly leads to the engine doing unexpected things every now and then and even then, parts of the botlib always require a conversion or the bots will behave very very weird and glitchy. I have been testing a version where only the botlib related calls are converted online for a few weeks now and so far it runs fine without side-effects.

I would like to release the code, but I was rebasing my repository and dealing with the performance bug at the time real-life pulled me away from working on jk2 mods. So my top priorities related to the mvsdk should be to evaluate which might be the best way to deal with the conversion/performance issues and to finish rebasing the repository, so it got a proper history (will be a couple of big commits after the re-base is finished, but it should have a history then, starting with the proper basejk code, without lots of work-in-progress commits). I didn't start with a public repository cause it started out as a test and I didn't expect those tests to become the "mvsdk".

Little screenshot of the CPU load on one of my server during a test, converting the struct at EVERY syscall (yes, that number seems to be above 100):

i know jk2mv and mvsdk isnt the same thing. (i said at the beginning of this post), but ouned says "security related bugs already have been fixed", and my question was if all bugs can be fixed via jk2mv... i thought not. i think some things need to be fixed via game-code. idk

JK2MV can fix a lot of things, but it can't fix any bugs in e.g. the bg_ files, without breaking mod compatibility. Those bugs can be fixed through the mvsdk though. The mvsdk fixes all known bugs that can be fixes through the qvm, and JK2MV fixes all known bugs that can be fixed through the engine ^^

Daggolin wrote:I don't quite get why you make a "To-Do List" for other people instead of suggestions, but whatever.

well, is what i tried to say, i mean something like a "suggestion list" lol (i edited now)

Daggolin wrote:

Tr!Force wrote:Bug Fixes(Errors that prevent the proper functioning of the game)

Most of them are fixed already, including many that weren't listed here.

i know many things arent listed there, but if every was fixed, or, if every can be fixed via jk2mv, is ok, is not needed... it was not clear for me at the beginning

Daggolin wrote:

Tr!Force wrote:Enhancements(Internal functions could be improved or new features)

Improved g_slowMoDuel functionally

String colored messages after a colored name

1st person Turret Chair view

Widescreen/Eyefinity Support

SinglePlayer Map Entities Support

Some More limits (cg_fov, name length etc...)

As for the mvsdk itself we want to keep it very simple and as base as possible. I don't think singleplayer entities or support for longer names should be added to the mvsdk serverside. If anything black color in names could be made available, but no "real changes". The "widescreen support" and the stretched HUD fix however are something I want to have in the mvsdk and a compiled version of the mvsdk is supposed to be included in future jk2mv releases (once it's ready).

oh i see... in that case, is ok, i agree for a very simple base.

Daggolin wrote:Currently the problem is mostly the syscalls when running the serverside in 1.02 mode. Due to the sharedEntity struct being shared among the game module and the engine both can access and modify the "shared entities" at any time, so with the mvsdk internally using the 1.03/1.04 structs and the engine using 1.02 structs the structs need to be converted not just once, but every VMCall and every syscall to ensure everything runs fine and both - game and engine - can access the struct at any time. This however leads to massive CPU load (even on modern systems), cause there is an incredible number of conversions going on. We could "work around" the performance loss by not converting the struct for every syscall, but that possibly leads to the engine doing unexpected things every now and then and even then, parts of the botlib always require a conversion or the bots will behave very very weird and glitchy. I have been testing a version where only the botlib related calls are converted online for a few weeks now and so far it runs fine without side-effects.

I would like to release the code, but I was rebasing my repository and dealing with the performance bug at the time real-life pulled me away from working on jk2 mods. So my top priorities related to the mvsdk should be to evaluate which might be the best way to deal with the conversion/performance issues and to finish rebasing the repository, so it got a proper history (will be a couple of big commits after the re-base is finished, but it should have a history then, starting with the proper basejk code, without lots of work-in-progress commits). I didn't start with a public repository cause it started out as a test and I didn't expect those tests to become the "mvsdk".

Little screenshot of the CPU load on one of my server during a test, converting the struct at EVERY syscall (yes, that number seems to be above 100):

mvsdk_cpu_load_edited.PNG

lol :shock: i thought something like this would happen. i agree with we could "work around" the performance loss by not converting the struct for every syscall, because doing something like that, will make us elderly ...

i know jk2mv and mvsdk isnt the same thing. (i said at the beginning of this post), but ouned says "security related bugs already have been fixed", and my question was if all bugs can be fixed via jk2mv... i thought not. i think some things need to be fixed via game-code. idk

JK2MV can fix a lot of things, but it can't fix any bugs in e.g. the bg_ files, without breaking mod compatibility. Those bugs can be fixed through the mvsdk though. The mvsdk fixes all known bugs that can be fixes through the qvm, and JK2MV fixes all known bugs that can be fixed through the engine ^^

There is actually quite a few bugs that are being fixed in both, jk2mv and the mvsdk. Some of the fixes inside of the engine are rather "work-arounds" and would be better implemented in the modules anyway.

Tr!Force wrote:i know many things arent listed there, but if every was fixed, or, if every can be fixed via jk2mv, is ok, is not needed... it was not clear for me at the beginning

Things that can be fixed in both, jk2mv and mvsdk are fixed in both. Through the mvapi the mvsdk can tell jk2mv to disable some of the jk2mv-fixes cause the mvsdk comes with its own set of fixes for those things thare are better fixed in the modules instead of the engine.

ouned wrote:actually the last commit was nearly 2 months ago
i never understood why people tend to say "i never find the time to work on it" instead of "i just don't feel like working on it in the moment"

:twisted:

Cause there is a difference between not feeling like it or not having the time. If you are busy with lots of other things (real life) those sometimes get higher priority, even if you would prefer to work on something else (like the mvsdk). And the 2 months isn't exactly true, as I have done some more testing with a fork I used for the CTF server and that's where I tested the performance a bit further and fixed a few more things.

I originally didn't expect my "tests" to evolve into the mvsdk and I tried not to get too much attention on it, knowing that I would most likely run into time issues due to real life, however it obviously became a topic. (I hate unfinished projects people wait for).

I understand that the work is halted, and you don't have time to continue it atm. How about releasing what you wrote so far so I can scrap it for bugfixes? :D It would help me a lot. Is it going to be GPL-licenced?

fau wrote:I understand that the work is halted, and you don't have time to continue it atm. How about releasing what you wrote so far so I can scrap it for bugfixes? It would help me a lot. Is it going to be GPL-licenced?

i asked the same thing, ouned told him the same, but he doesnt want release any "unfinished" thing, and he doesnt have any time to finish...

is why i started to make my own version of multi-version qvms ... i have some little done

Well, I can tell you that there are plenty of bugs, even game-crashing ones in sdk code. Maybe jk2mv fixed all exploits, dunno. I would prefer to have them fixed, as many as possible. At least for jk2mp.exe users.
Hell, the first thing I did in my mod was debugging and fixing a bug in Info_RemoveKey that was caused by using memcpy on overlaping memory intervals. Apparently it didn't affect the old lcc build. jk2mv can't fix such things.

fau wrote:Well, I can tell you that there are plenty of bugs, even game-crashing ones in sdk code. Maybe jk2mv fixed all exploits, dunno. I would prefer to have them fixed, as many as possible. At least for jk2mp.exe users.
Hell, the first thing I did in my mod was debugging and fixing a bug in Info_RemoveKey that was caused by using memcpy on overlaping memory intervals. Apparently it didn't affect the old lcc build. jk2mv can't fix such things.

fau wrote:Well, I can tell you that there are plenty of bugs, even game-crashing ones in sdk code. Maybe jk2mv fixed all exploits, dunno. I would prefer to have them fixed, as many as possible. At least for jk2mp.exe users.
Hell, the first thing I did in my mod was debugging and fixing a bug in Info_RemoveKey that was caused by using memcpy on overlaping memory intervals. Apparently it didn't affect the old lcc build. jk2mv can't fix such things.

In Daggolin's mvsdk he haven't just fixed e.g. the common crash bugs, q3fill, saber steal, etc, but also more or less all memory bugs, as far as I am aware

It's nearly ready. I was hoping to finish things around christmas, but obviously other things got in the way. It's mostly working, but there is still a performance issues that can't really be solved. It can be "tweaked", though. However in the current state bots in 1.02-mode cause players to randomly get wrong animations. To improve performance at least a tiny bit I want to add a syscall to JK2MV to disable struct-conversion for the game-module, cause the mvsdk is going to work only with 1.04-structs internally (just like JK2MV). I don't plan to completly re-structure and refactor the whole multiversion codebase again (the original state was a prove-of-concept and not really good, which is why I didn't want anyone to base on that, yet).