Jump to content

MBII


Exmirai

Recommended Posts

At the moment, no. It's up to them.

They'll have to remove any engine modifications they use, including some anti-cheat stuff. From what I hear, that's the main reason they won't support it. It's been discussed for about a year now with no verdict.

Link to comment

They will create any excuse to get out of any work, even to call bugs as features or easter eggs.

It took them years to fix the hit location damage and I'm sure kyle bug hasn't been fixed yet. I remember when changing to Jedi class it would automatically switch you to Sith, that one was also known for years and may still exist. Each new version took about a year or more to release.

Link to comment

Yes, I've talked it over with them.

 

Apparently, their latest tests work fine with OpenJK. However, their engine hooks are still in place. It's pure luck that nothing breaks, but it isn't safe. As I understand, the plan is to add a cvar which indicates whether or not the client is running OpenJK. But I think they use custom hacks for certain things. Not sure. A lot of the coders involved now are pretty amateurish when it comes to Q3, so it'll be most likely be assigned to me to work on it. So far, I've only done minor fixes and code cleanup, but whenever I get out of my current rut, I'll look into it.

 

The current plan however is a complete hat toss. I've heard conflicting things from at least 5 different people. Some claim no, the mod is never going open source. Some claim that it's part of the active agenda. Others claim that they'll only release the source once the mod is dead. Either way, there's a big-ish release that's being worked on. I dunno why they haven't teased it or anything.

therfiles likes this
Link to comment

They will create any excuse to get out of any work, even to call bugs as features or easter eggs.

It took them years to fix the hit location damage and I'm sure kyle bug hasn't been fixed yet. I remember when changing to Jedi class it would automatically switch you to Sith, that one was also known for years and may still exist. Each new version took about a year or more to release.

I don't even know how to respond to this bullshit. Sure, they are slow and do some thing badly, but kylebug is just fun and I've never seen anyone demanding devs to fix it. It rarely happens anyway. The Jedi class bug doesn't exist. Never happened to me the last 5 years..

And so what that updates take a long time? There are not many developers anymore and they are adults and it's a miracle that they still care about developing this. Also, the updates are mostly bugfree.

therfiles likes this
Link to comment

Our current focus is getting a release out. It's that simple. We've been getting development back on track the past months after it was pretty slow-paced for a while. 

 

 

 

They will create any excuse to get out of any work, even to call bugs as features or easter eggs.

It took them years to fix the hit location damage and I'm sure kyle bug hasn't been fixed yet. I remember when changing to Jedi class it would automatically switch you to Sith, that one was also known for years and may still exist. Each new version took about a year or more to release.

Developing MBII doesn't earn us any money. We do it in our free time and all of us either have work or school. If you happen to be a millionaire, you're welcome to pay us so we can speed things up. :P

I'm getting pretty tired of the whole open source complaining. It's not going to happen on the short term. Most people asking for the source also happen to be the people claiming our team consists out of amateurs and our code is shitty. 

 

 

 

The current plan however is a complete hat toss. I've heard conflicting things from at least 5 different people. Some claim no, the mod is never going open source. Some claim that it's part of the active agenda. Others claim that they'll only release the source once the mod is dead. Either way, there's a big-ish release that's being worked on. I dunno why they haven't teased it or anything.

I can pretty much guarantee that opensource is going to happen one day. What I can't guarantee is when.

If adding support for openJK is as simple as a cvar, if statement or something else then sure I'm all for it. However open source isn't on the agenda until we're ready for it and until then that's simply the way it's going to be.

 

Call us lazy, call us amateurs. We're just enthusiasts who like to mod a 10 year old game and have fun doing it.

Onysfx, therfiles, Sentra and 1 other like this
Link to comment

You don't need to open source it to make it compatible with OJK. All of the stuff I was shown for hooks used is irrelevant with OJK engine.
 
I only see you being the ones complaining instead of making 1 cvar to turn if statements off (That cvar can be the version string of the engine for runtime detection even).  Wouldn't even have taken you 5 minutes a year ago.
 
The alternative method would be to take a little more time and use the newer API.  But then you are semi in the grey area of using GPL code in general.
 
Note: Fix your shitty ass site so that it doesn't get blocked by NOD32.
 
This will also detect jamp.exe on windows so you might need to get more creative.

char version[MAX_CVAR_VALUE_STRING] = { 0 };

trap->Cvar_VariableStringBuffer("version", version, sizeof(version));

if ( strstr( version, "2003" ) ) {
	// do JAMP stuff here
}
else {
	// OJK or other non jamp compat engine
}
Link to comment

There was probably something on the forums or hacked at some point and it got flagged and has been ever since.  AFAIK they won't listen to users telling them its false unless there's someone on the site ownership's end to confirm.  Strange that its still blocked though if you said something.

Link to comment

Compatibility with OpenJK is a simple if statement for their engine modifications. No idea why this takes so long.

 

Most of us want to finish our launcher that we can pack a OpenJK build with, so that we know random pubs don't have some weird dev or beta build that could fuck with things by accident. It also will give MB2 people easier access to OpenJK.  Plus the things Sxx mentioned. Trying to get things ready for release first, then we can do little tasks like this when doing the final testing. 

 

You guys do know how long it has been since an update to MB2 was released right? Well I'll remind you: December 2012. It isn't like we released a build without OpenJK compatibility since OpenJK started. Don't worry, its coming.

 

Also remember, a lot of us are short on time (I went awol for almost two years till recently as an example).

Didz, Tx606, Circa and 1 other like this
Link to comment

Most of us want to finish our launcher that we can pack a OpenJK build with, so that we know random pubs don't have some weird dev or beta build that could fuck with things by accident. It also will give MB2 people easier access to OpenJK.  Plus the things Sxx mentioned. Trying to get things ready for release first, then we can do little tasks like this when doing the final testing. 

 

You guys do know how long it has been since an update to MB2 was released right? Well I'll remind you: December 2012. It isn't like we released a build without OpenJK compatibility since OpenJK started. Don't worry, its coming.

 

Also remember, a lot of us are short on time (I went awol for almost two years till recently as an example).

 

Awesome :) The "compatibility" I speak of is just to remove the engine hooks needed to patch exploits if the engine that's loaded isn't retail JKA 1.01 (be that OpenJK or some other engine).

 

My solution would be to compare a hard-coded hash of known runtime assembler for a certain function in the retail JKA 1.01 engine (say Com_Printf), and then compare the actual runtime assembler hash for that function with the hard-coded hash.

So if the hash for the function matches what's in the code, you can be sure it's the basejka engine and your engine hooks will be safe to place. (As safe as engine hooks go anyway...)

 

I used this technique in my MMProxy server-side proxy mod for Makermod, to ensure it was running on top of the real engine. (Otherwise the engine hooks would surely fail)

Onysfx likes this
Link to comment

the code would need to be changed quite a bit to support Linux

Not really. Most of the changes are in the engine. I had JA++ client compiling on Linux years ago with minimal effort, and would have run on OpenJK executable.
Link to comment

Not really. Most of the changes are in the engine. I had JA++ client compiling on Linux years ago with minimal effort, and would have run on OpenJK executable.

I should have clarified, and I don't mean to step on any toes here, but the current setup is a bit of a mess. There's something like 3 .sln files, an xcode project, and a make project, and not all the MS ones are up to date with the proper files and filters and such. The problem wouldn't necessarily be the code as much as it would be dependencies, make, and so forth.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...