Improving MB2 Client and the future

Noob

Just a Guy
Donator
Movie Battles II Team
Posts
1,524
Likes
1,638
I have written topics on jamp vs Mb2 client before about their differences and I have come to a conclusion on what should happen for the future. These ideas will improve quality of life for both players and the devs. All it takes it a little effort on the devs side. Here's what I mean. I am an avid jamp user, and for good reason. It's more polished and in my opinion more stable. However with a few changes to MB2 client we can ditch the 3 engine mess that MB2 devs have to code for.

1. Openjk UI is horribly unoptimized for widescreen. I don't know if this was an over sight, but from these two images you can see that the widescreen fix does not work for openjk as seen with jamp. Things that come to mind are the enormously scaled text boxes and stretched hud. All the settings in game are the same (including the apparent Mb2 client "widescreen UI")
4d9afq1.jpg
MyA26yN.jpg
2. It would be easier on the dev team if they made Mb2 client function exactly like jamp with the added benefits of OpenJk (Such as tabbing in console, new font colors, etc) and proceed to include jamme within the MB2 client, while ditching jamp support altogether. That way the devs only have to work on one engine for the rest of MB2 development, and could lead to open source, or further expansions for availability. (Think steam mods, or MB2 standalones)

my tl;dr list
1.Clean up MB2 client UI, make it function exactly like jamp with openjk benefits
2.Integrate jamme into MB2 client
3.Ditch Jamp support, run through launcher only (Keep a system to log steam hours through appIDs?)
4.Extremities like open source or standalones to be considered after
5.profit
 

eezstreet

Movie Battles II Team Retired
Posts
242
Likes
299
The thing is, the widescreen stretching was present also in the original game (jamp). I don't really know how the widescreen stretching fix stuff works but if it works in jamp and jaMME and not OpenJK then it might be a cgame change coupled with engine hacks. It's fixable on the engine part but I think that's also part of the jaMME GPL code that's getting removed. So...next update might make all clients look like OpenJK but someone correct me if I'm wrong.

Either way, you are right and I would agree with you. Cutting the cord of jamp will reap a lot of valuable benefits like removing the need for the launcher to run as administrator, focusing development primarily on one engine target, and in the future allowing for stuff like rend2 (which has been showing a lot of promise under the changes SomaZ has recently made).
 

Puppytine

Slayed dreamer
Posts
2,237
Likes
1,493
1. Openjk UI is horribly unoptimized for widescreen. I don't know if this was an over sight, but from these two images you can see that the widescreen fix does not work for openjk as seen with jamp. Things that come to mind are the enormously scaled text boxes and stretched hud. All the settings in game are the same (including the apparent Mb2 client "widescreen UI")
Not gonna be fixed until MBII goes open-source and GPL.
The fact is, to implement widescreen fix in MBII Client, they need to link MBII Client to MBII dlls, but MBII Client is GPLed and MBII dlls are proprietary. Linking GPL code to proprietary code and vice versa is prohibited by GPL.
Two of Movie Battles developers already said they aren't going to give their consents to license MBII under GPL, so...

Though devs can actually implement it and pretend they don't violate GPL, since ent already denies that GPL is violated by jaMME ratio fix.
3.Ditch Jamp support, run through launcher only (Keep a system to log steam hours through appIDs?)
Please don't.
While they are engines to choose, we can always suggest to people those can't get MBII Client to work switching to other engine.
And MBII Client doesn't have a Steam support (statistics and stuff) and I don't know is it possible to implement it (DRM?).
So...next update might make all clients look like OpenJK but someone correct me if I'm wrong.
No, changes should only affect jaMME.
JAMP is perfectly fine since EULA of JAMP is far less restrictive than GPL, and nobody are going to enforce it anyway.

Buuuuuuut... If some GPL code is used as actual implementation of widescreen fix, then HUD in JAMP will be stretched as well :(
I just hope MBII devs weren't SO reckless to put GPLed code directly to MBII dlls (aside from already confirmed violations, indeed).
 
Last edited:

Noob

Just a Guy
Donator
Movie Battles II Team
Posts
1,524
Likes
1,638
Making applications run a specific AppID to make steam think you're playing another game isn't unheard of. I don't think Valve cares either.
 

Puppytine

Slayed dreamer
Posts
2,237
Likes
1,493
Making applications run a specific AppID to make steam think you're playing another game isn't unheard of. I don't think Valve cares either.
Well if Steam provides some public API for third-party applications, then one of the problems is solved.

But I must add that jamp performs better on older machines.
 

eezstreet

Movie Battles II Team Retired
Posts
242
Likes
299
Please don't.
While they are engines to choose, we can always suggest to people those can't get MBII Client to work switching to other engine.
And MBII Client doesn't have a Steam support (statistics and stuff) and I don't know is it possible to implement it (DRM?).
Wouldn't it be better to have one client that always works no matter what though, instead of having people choose?
I've been looking into how these idling programs work and I think I have a rough idea how it can be done without including the Steamworks API.

No, changes should only affect jaMME.
JAMP is perfectly fine since EULA of JAMP is far less restrictive than GPL, and nobody are going to enforce it anyway.

Buuuuuuut... If some GPL code is used as actual implementation of widescreen fix, then HUD in JAMP will be stretched as well :(
I just hope MBII devs weren't SO reckless to put GPLed code directly to MBII dlls (aside from already confirmed violations, indeed).
Yeah, that was something I was concerned about as well. We'll have to wait and see what happens.
 
Posts
1,388
Likes
1,310
Mbclient didnt always have the distortion did it?

And what about fixing jamp client or whatever? I stopped using it due to the dynamic crosshair bug.
 

eezstreet

Movie Battles II Team Retired
Posts
242
Likes
299
Mbclient didnt always have the distortion did it?

And what about fixing jamp client or whatever? I stopped using it due to the dynamic crosshair bug.
No idea, but the idea was about a fixed jaMME/OpenJK that does everything well.
 

StarWarsGeek

Internal Beta Team
Posts
497
Likes
403
That's odd, that bug was fixed quite a long time ago for me in JAMP, and I haven't heard anyone else complain of it since. Try resetting/deleting your jampconfig? You sure you're not just seeing the sway from the default cg_thirdpersontargetdamp setting?
 
Posts
1,388
Likes
1,310
I'm scared of my config. About 4 years ago it stopped adhering to borders and now its 3 lines down, and near infinite across.

Nope, still there. I gave up on it. Maybe its some random ass virus, bug, remnant on my pc, I've made do with mbclient.

Forget about me. I'm the guy whose hand you let go on the cliff. Q_Q
 
Top