MaceMadunusus

I play MB2 for lightsaber duels only so if this successor thing doesn't have them I won't even consider giving it a try.

We will have them in some form. The style and such should remain the same, but the visuals and name will be different (still energy based and glowy).

As someone who develops Movie Battles... remember that while it is a mod, it is also a gamemode. Just because both the gamemode, and the name of the mod are the same, doesn't mean it doesnt apply here. In that sense, coop from OJP can be added as well. 

The Movie Battles mod name encompasses everything about movie battles, the UI, the effects, levels, models, community, etc.

The game mode is the 5 minute objective based rounds similar to siege with limited respawns, using 7 standard classes and abilities per team that are not specific to any one map as well as a map design based around that, which are much smaller than siege levels and do not contain multiple-stages to the assault.  Its much easier to call the gamemode "Movie Battles" than it is their "Open/Semi-Authentic/Full Authentic" counter parts.

So, with that said, there is nothing wrong with adding other gamemodes from other mods such as Coop from OJP to this list. I can't think of any more of the top of my head, but no real reason not to include them if they are different enough from the base game (JA+ for example doesn't count).

Pugmod works differently. I wanted to base q3mme port on pugmod at first but ended that everything has to be done from scratch.

@MaceMadunusus, so how to contact or what?

Unknown at this time due to our forums being in an iffy state while in the conversion process from a very old version of vbulletin. I'm not a coder, so I wouldn't be the one dealing with it directly.

@MaceMadunusus, I thought a bit more and ended up with that the best thing I could do is to make some additions in CGAME part of MB2. So I will add mme mod compatibility there, and then leave it as is for main developers, all they'd need to do is only to check my repository from time to time with new changes in jaMME CGAME part and update their MB2 CGAME. So all users will use original CGAME of mme, but MB2 users will have to replace it with their specific one. Rest elements (engine+renderer and ui) should work fine indepedently.

Thats no problem, already has to be done with Pugmod. Since this is more featured, we could just phase out pugmod entirely if they require essentially the same thing. Might be nice to PM us if there is updates though, or have an official thread on the forums once it is implemented to remind us of updates. We don't pay attention to JKHub or even the githubs of most jka mods as much as we probably should due to all of us having a limited amount of time.

Eez and Didz are both right. You can cheat and do all of those things without access to code. 

MBII source stuff isn't just about security, so remember that. That was just an example. Also, Owen was a massive douche.

Ent, were in the process of upgrading the site slowly (only happens on weekdays) so the forums are slightly broken right now. So no internal discussion is going on atm regarding this due to that. I will say this though, while it doesnt guarantee anything, applying for the team directly to get jaMME working is likely the fastest way to go though certainly not the only route. We have had developers on before for short periods of time for short tasks. However, staying away from engine mods is likely the best thing from an inside point of view as it may mess with any OpenJK compatibility already existing. You would have to talk to Eez about that though, since he is the one who added that.

That one holocron gamemode from JKO is one you forgot

of the base games: CTF, Siege, Holocron, and TFFA for actual gameplay. Didn't really care for dueling, ysalamari or JM that much. FFA was good for just hanging out tho.

While I do love all those gamemodes, and I have a bias towards it, MBII was really the only thing that kept me in JKA so I've gotta say that.

This transition seems like a poor idea to me.  As someone familiar with both systems and who uses them extensively, I don't see the benefit.  I mean yes, UE4 is better, but if you're already working all that content in UDK, I don't see the point in moving to UE4.  Not only are you then having to pay monthly (or pay once and go without updates) for a license for the engine for every person working on your project, but you also will have to recreate almost everything you've done up to this point.  Seeing as how you are not using high detail assets or anything over-the-top I don't see where a free project like this is going to benefit from the move.

It took me 2 days to convert all of the items from MB3's UDK, into UE4 including all entities, materials, levels, and rescaling of assets to the metric system. People have also already made conversion plugins in order to transfer items like light entities, cameras from matinee, and other things into UE4. Overall, it really isn't that daunting of a task as you make it sound. They had done a lot of work sure, and personally I agree with what you have said based on the amount of content I have personally seen of the project, but they can still benefit from it even after taking time for the conversion I believe. UE4 is a lot simpler in many respects, and might even allow them to do things they couldn't have prior thanks to blueprint being massively better than kismet and the editor functionality for level design being so much more fluid and standardized. It really is up to them though.

@lervish, I wanted to make it compatible, and even asked a user @Onysfx to post about it on MB2 forums to attract MB2 users so they could ask MB2 developers give me come codes. But it was ignored so I could not make anything.

On MB2 forum: http://community.moviebattles.com/threads/39692-Jamme-for-MBII?p=777239

If you want it so much, then contact to developers and ask them to provide me some codes. I don't know other solution... Oh yeah, they can always make it as their own feature since the code of jaMME is opened.

I personally prefer adopting jaMME for MB2 than visa-versa.

Lerv is a MB2 developer. It wasn't ignored. There are concerns internally about giving source code out to someone we don't know that well. That isn't to say the work you have done isn't adequate or done well or anything because this mod is amazing and I would love to use it. We just have trust issues. Plus the issue of updating what you have with releases, or what you do to upgrade jamme if it goes the opposite route. Would an API be better so that it didn't require rebuilding every time there is releases?

I'm actually currently re-making the multiplayer maps on UE4   Well the JKA ones anyhoo.

Did you directly port them over? Or are you starting from scratch and guessing values? I noticed a scale difference of about 3.06 when porting MB2 maps over for MB3 using an ASE compile.

Sure, I don't see why animated normal maps aren't possible, but I don't really see how they're useful at the same time. You'd probably want vertex deformation as opposed to animated normal maps.

Likely more useful for a map related shader, like a func_usable with a toggle based animmap change.

It achieves nearly the same thing while giving almost no performance hit. Not a big deal in a game as old as this, but hey. Not everyone is running a GTX 770 like myself

 

I always forced 4x MSAA in JKA since I had a Geforce 7800GS... of course I'm no longer on that, but my framerates were always fine, even on that old card when I had it. I wouldn't worry about it.

I'm done with any serious MB2 work for a wee bit now... sooooo, SP TIEM NAOW!

That's what happens when we're in feature lock. Least you don't have trailers to make XD

Hey guys, I wanted to give you an update on this.

Release for MB2 is closing in, and there are still some issues with OpenJK working (There are some crashes while using it). Eezstreet isn't entirely sure what the cause could be (there could be a hook in cgame for all I know that what he did doesn't take care of, but I'm no coder). It is being looked into, slowly, but OpenJK support might have to come in a hotfix shortly after release to avoid delaying. Hopefully that won't be necessary, but if it is, please don't get too mad at us.

I just added OpenJK support to the code.

 

/me runs

Okay, then the question is did you check what the others did? Defiant said he started code in the thread a few days ago but then got torn away, StormChaser said he also worked on it a little. There is no point having duplicate code across it. Either way, post in the OpenJK thread in dev, cause it doesn't seem like you posted to tell everyone . People stepping on eachothers toes is part of the issue why the code is so jumbled all over the place.

I think the code only goes back to RC1-ish fwiw, maybe even farther back.

Thats when we switched to the HG. There is a backup hidden of previous versions. You might not specifically have access to it. The same happens for the map source as well in the beta SVN. Only certain people have access to that, it isn't a team permission.

Is there no backup/history at point of the currently released version which could be re-released with hacks removed/detection added?

There should be somewhere yes. The only part of MB2 we've had to remove from revision history is the physical SVN for all the assets (Code is separate) due to running out of disk space. So it should all be there. But there isn't much point in digging it up, doing that work, then testing to be sure its all proper when we want to hopefully release a new build this summer anyway. Easier to just do it on the current build to not take up limited time the beta testers have.

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.

This is something that happens when people come on and off a project thats been going on so long. A lot of things are a mess in MB2's code related things. Even if something is simple for an outside project, it isn't quite the same for MB2 because of how much coding hands were traded off. I know you're just talking about some of the more basic things, but that still kinda applies. We start updating things to say a new version of VS, forget filters or whatever. Happens. MB2 isn't something any of us praise for having the most user friendly code base in the world.

This stuff is something I'll be changing for the MB3 version. Rules and such so the code base will never get to a hard to manage state like MB2 is.

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.

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

Hey Mace, it's good to see you're still lurking here

 

Firstly, we can't take credit for the current features in rend2. We're actually porting this across from the ioquake3 project which @@eezstreet started off, and now I'm continuing hopefully to completion. Once all the regular JKA stuff works I'm planning to rewrite a fair amount to take it to the next step.

 

JKA itself hasn't really been upgraded. It still only uses a single core - the aim of this is to up the renderer as far as we;re capable of doing. Having said that, I can tell you that the renderer is still very inefficient and currently it's doing too much CPU processing to feed the GPU fast enough (at least on my computer, with an i5 3750k and an AMD Radeon HD 6870). This is something that can be solved without utilising multiple cores though I believe... at some point I might look into using multiple cores but that would require a huge effort.

 

So my aim is to get somewhere near UDK-quality in terms of detail - using models will be preferred over regular brushes as the same models can be instanced/drawn in one go, rather than having to submit multiple draws. Textures, I'm not really sure how you can have more detail other than by making it bigger

 

I'm not sure what gloss/roughness algorithm we're using, I would have to delve into the code to find out.

 

For dynamic shadows, I believe rend2 uses cascaded shadow maps with regular PCF filtering (judging by the weird edge patterns I've seen). The shadows are kind of buggy so they need improvement. I don't think RTW is used by many (any?) games at the moment, so I'd prefer to go with something that's proven to work well.

 

Textures and lightmaps are pretty much the same. Rend2 attempts to pack lightmaps into a texture atlas, but nothing like that happens with regular textures - do games still do this? I plan to add support for .dds textures in the future to provide a fast path for texture loading. I'm still not decided as to what I want to do with lightmaps.

 

Shader models don't really apply to OpenGL but I can tell you that rend2 use features roughly equivalent to those found in DX10.

 

There's still a long way to go, and as you might have seen from the last few pages of the thread there's still a lot of teething issues. Hopefully all of this work will be worth it in the end though

 

Hopefully that answers all of your questions, @@MaceMadunusus!

Hopefully you can optimize the usage of the renderer within that one core. At the very least, when you get to that point, it might be fine just separating the renderer from everything else so that all the game code, physics, network, etc can all sit on one core while the renderer can sit on another. That might be enough for JKA.

I don't think you are going to get to UDK's quality level without a ton of work. UDK is much more optimized than most engines out there. However, using meshes that draw in one go is certainly possible with the OpenGL version you are using which makes me happy .

Cascaded shadow maps themselves are hugely inefficient in general. A few games do use RTW, not many at the moment because its still pretty new in the DX11 feature set and consoles didnt support them till the new ones came out.

A lot of games still do texture aliases. It is a pretty decent way to optimize texture rendering if you aren't using OpenGL 4+ (3.3 is likely what you are using) or DX11. An example of which was already mentioned, UDK

Should have likely said GLSL version there, but yeah you answered it.

Thanks @@Xycaleth!

Glad to see you guys are still working pretty hard on this. And glad to see you now have proper Specular, Gloss, and Environment Cubes as well. I have known that you have had normals for a while, but seeing those editions are much more exciting to me.

I haven't been paying too much attention and mostly skimmed over things so I ask:

How much have you upgraded JKAs ability to use the power of newer computers? For example, baseJKA uses only roughly 15% of a GTX 660 FTW edition at maximum settings and as you know one CPU core. 

If yes to the previous, how much more room would we have for detail in meshes, brushes, and textures?

What version of Gloss/Roughness do you guys use? For example, UDK uses black for fully reflective, while Marmoset uses white. I am assuming you are using the White for fully reflective based off of the shader values posted.

What dynamic shadow model are you using? For example, I believe the most efficient, most recent, and highest quality variant for games is RTW (Rectilinear Texture Warping)

Have you guys increased JKAs ability to properly load textures & lightmaps (Higher resolutions, better efficiency like using texture aliases)?

What shader version/model have you guys been utilizing?

So far, you guys have been doing a good job from a visual standpoint. Maybe there is hope for me getting some of my newer stuff into JKA at some point. Like these: 

also incase this helps: http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_slides.pdf

MoonDog's also shown me a more efficient way to do those circular doorways. (Compare with Post #8)

 

 

Thank you MoonDog for being awesome. Just saw this thread so I would have suggested the same thing earlier, but looks like I don't have to.

This looks pretty good so far, especially for using the byss texture pack. A lot of people use them in wrong ways. Everyones got my minor critiques so far, I have a few more but I'm not gonna pick till I see some more

Am I the only one who sees this with a pinch of salt??

 

The modding side is brilliant, what about the exploit side and the new ability to riddle with more damaging things like Q3 limitations?

Using existing Q3 upgrades, they fix a lot of the vulnerabilities of the engine itself. Not to mention all of the upgrades the community has already made to the original SDK to stop those exploits. With the source, we can also patch new ones a lot quicker without fucking around trying to find out if we can fix it or not, or if we have to hook the engine to do it. Plus, the Q3 engines source has been released for a long time, and JKA's isnt that different from it as well so if they really wanted to take some time they could have made those exploits much sooner than now.

Eh, its 4am and I feel like I am having a terrible time wording this, I hope you can see what I mean.

On behalf of the MB2 team - "Wooooooohoooooo"

I love you, you just made me laugh my ass off.

Holy shit, I seriously didn't expect this to come out of the closing of lucasarts. This is fucking awesome.