mrwonko

It would help if you'd specify the modelling tool you're talking about.

My Blender plugin suite contains a GLM Importer and an MD3 Exporter. MD3View can do MD3 to GLM conversion if you don't need animations. https://jkhub.org/files/file/1413-blender-264-jedi-academy-plugin-suite/

It is redundant and thus discontinued.

Definitely back to EF, I already checked that. So if the worst happens we can probably count on the Free Software Foundation to back us up. Unless they actually had a different license for the code and just didn't change the files out of laziness (and lack of necessity, really). Still, let's wait for official word before taking action. For now, code away happily.

Okay, let me sum this up. You're saying a game has a hard time being profitable if you use an open source engine. I asked why, you started talking about piracy. I made the point that in that case DRM free games wouldn't make a profit either. You said yeah, they don't, unless you have an established following. I listed Super Meat Boy as an example of a DRM free game without a huge following (surely not everybody who played it played Meat Boy on Newgrounds?) that sold a lot. Now you're telling me you were never talking about DRM free games in the first place? So tell me, how is creating a new IP and selling it and being profitable using a GPL engine as Open Source any different from creating a new IP and selling it and being profitable using a closed source self-made engine without copy protection, as countless indies have done? Hell, I even have an example for you: Thirty Flights of Loving uses idTech 2 licensed under GPL and is subsequently open source, that still sells, right? So far, the only point you've made about why Open Source games specifically can't sell is ease of piracy, which applies just as much for DRM free games like Super Meat Boy or anything on gog.com. Your other arguments are just about selling games in general. Yes, selling a game is hard, but no harder if you use an open source engine, that's all I'm saying.

What, like Super Meat Boy? I'm telling you, piracy : purchase rates have nothing to do with the size of your fanbase. Yes, selling a new IP is often harder than an established one, but that's not because people are more likely to pirate it. That didn't work in the past on Linux? Yeah, it should work once we're done. That might happen in the future, yes. Personally, I'd like to investigate that further in a separate branch that abandons binary compatibility with old mods, but others have expressed interest in improving this in OpenJK.

Yeah, we're not quite sure what happened there yet. Raven is probably still figuring it out themselves. The main project, OpenJK, is here - that's basically the original code with various improvements. (Not quite ready yet, give it a couple of days.)

Copy protection is always hacked sooner or later anyway and from then on only hurts the paying customers. So your point is "don't make your game open source, it becomes too easy to pirate"? Then how come gog.com still exists if their DRM free games are so easily copied?

And right there you have one of the reasons you can sell GPL stuff. Assets. The main other one being support.

For the most part just like any other game. How is Doom 3 BFG marketed? It's open source after all.

Yes you can. This is GPL and that's all you need to know. And even ignoring that, the id Tech engine 3 is GPL as well, you're free to use that without licensing it as long as your code adheres to the GPL. No, if that were the case they would've removed it, like they removed the FeelIt and Bink stuff (eventually). You can create your own assets and sell the resulting game.

Huh? Why would that be frowned upon? If you release under GPL you grant rights for commercial use. See the Lugaru fiasco on how not to do it though. Maybe because you don't want to share revenues or like open source? Or you're a long time Jedi Academy modder that is already comfortable with the engine. Maybe you just want the nice mod support of idtech 3. There are a couple of reasons I could think of.

I'm not eezstreet, may I still answer? If not, screw you I'm doing it anyway. No, this is not built on top of Open Jedi Project, it's largely orthogonal to it. You can still play Open Jedi Project in OpenJK. OPJ is a Mod, OpenJK the engine (although an improved modbase is included with the source).

Yeah, so since the Jedi Academy source got released, we can go nuts with high detail now. Provided this project takes long enough we'll have normalmaps, parallax occlusion mapping, dynamic lighting and higher possible polygon counts. Maybe even tesselation. So it would be fairly cool to create a reference level of what is technically possible. And if that does not happen in time, we can just bake a full render - lightmaps & mega textures, Blender style!

Improving AI is not a focus at OpenJK at the moment, but it might be something to investigate in the future. I agree that better AI is better.

I'm fairly sure MB2 has custom code to make it animate, that won't work in base Jedi Academy.

You hardly need to do any coding. You need to remove the CD check and that's about it. Mostly you just need to recreate the assets since you can't use Jedi Academy's, most importantly the animations. And if you simplify movement outside the water to walking, crouching and jumping, you only need very few since most of your game is in the water, with what I believe are already custom animations. That requires access to Hydroball's source code though - do you have that? Otherwise you'll either need to recreate all animations or accept glitchy animations.

If you created the UV by marking seams and running unwrap, it's trivial since the seams are highlighted. If you chose some kind of auto unwrapping, it's more difficult. Try using a gradient texture like this one, you should see the seams fairly clearly.

Yes it could. First person and third person use different models. Check if it works with the default model.

Probably an error in the shader, disabling the depth test or something. Did you change anything there? Post it, please.

If there ever was any rush, the release of the source code changed that. I'll be busy poking the code now, but that doesn't mean we can't do this as well.

Wrong. Splitting is required if there are any seams on your uv map, i.e. if you have to make cuts in your model to be able to map it to the texture. Learn what UV Seams are.

I don't need to tell you how amazing this is. Give me a year. Raven is aware of the mixup by the way.

Well shit.

Justified, since I actually missed your post somehow. Why did I only get a notification about the bump? Regarding your actual problem, try what redsaurus said.