Jump to content

MBII


Exmirai

Recommended Posts

Posted

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.

Posted

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.

Posted

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

Posted

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
Posted

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
Posted

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.

Sentra, Onysfx, eezstreet and 1 other like this
Posted

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
}
Posted

Note: Fix your shitty ass site so that it doesn't get blocked by NOD32.

Appears to be some kind of false positive and I've mailed them about this weeks ago.

Posted

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.

Posted

Well there we have it folks. Let's try not to attack others with slight remarks. The MBII team is no different than any other modding team. They work on it when they can. They have lives too. No need to view them as incompetent people of any sort.

 

:winkthumb:

ent, Omicron, therfiles and 3 others like this
Posted

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).

Circa, Acrond, Didz and 1 other like this
Posted

Here's an idea I've been thinking of:

 

MBII on OpenJK's rend2 could be MBIII, and dump the MBIII UDK in favour of MBIV UE4 which would be a non-Star Wars game that could be sold.

eezstreet likes this
Posted

Here's an idea I've been thinking of:

 

MBII on OpenJK's rend2 could be MBIII, and dump the MBIII UDK in favour of MBIV UE4 which would be a non-Star Wars game that could be sold.

 

I'm not updating all of MB2s maps. That is just not gonna happen.

Posted

i have read-ed some where that it should be easy to convert UE3 maps over to UE4 maps with a simple little tool there comes with UE4 engine

Posted

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
Posted

I don't think it would be doable really, since the code would need to be changed quite a bit to support Linux. They don't like to make huge, drastic changes anyway.

Posted

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.
Posted

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.

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...