mrwonko

default_scale is for the editor. Okay, then you may have to adjust the paths in scripts/user*.proj...

I'm not sure, but I think you can't quite change all the setting for 1.6 from the editor itself, look at ja.game/local.pref and games/ja.game in the radiant install directory, I think one of them (probably the latter) has some paths in it, too.

Basepath should be GameData, not base, it's the path where base is located, not the path of base.

Q3Map2 can't find the textures when compiling and thus assumes a (very small) default size. Supply the correct fs_basepath, or, if you're compiling from GTK Radiant, set that up properly.

Length is not an issue, it's always a fixed 64 characters maximum, as long as you don't exceed that you should be good. But why don't you use a .skin file for texture changes? Looks like you changed some other value besides the texture paths in the model though, maybe you didn't overwrite the bytes but inserted some? If it's of any help, here is the file format definition for glm. Oh, I got Ninja'd.

Do you think that may be because such a huge project is hard to pull off? If so, you may want to consider that before starting one yourself. Also, you may want to elaborate on your idea some more. "Jedi Knight 4" is somewhat vague. (And before you ask: No, I'm not interested to join, just giving some tips.)

Credit where credit is due - I did not write that, I merely link to it.

MD3 is mostly used for static meshes, though they can have per-vertex animations but those get pretty huge. GLM is for models with skeletal animations - mostly players/npcs/3rd person weapon models. These have external animations in GLA files which can be shared between GLMs, which means you only need one set of animations for all humanoid characters. Both MD3 and GLM support Tags. For models in your map you can use MD3, but the compiler can also handle .ase, .obj, .3ds, .lwo and more, but out of those only .md3 files can be animated. For players you have to use .glm and creating those is pretty darn complicated. For weapons you need a .glm for 3rd person and .md3 files for the first person model. First person weapons get around the problem of animations getting huge by being split into one file consisting only of the tags and others that are attached to it in code, but this method can't be used in maps.

No, creating tags is the most painful thing.

It is! Great!

Seconded.

Right. You're just using a horribly outdated version of the plugin. Where did you get that? I thought I added links to the latest version everywhere... https://jkhub.org/files/file/1413-blender-264-jedi-academy-plugin-suite/

Are you sure those "broken pieces of triangles" aren't just the tags?

With a little work it's possible to make it work in vanilla, but for mods you need the cooperation of the creators - the Pi is ARM, right? That needs to be specifically compiled for that architecture then.

No, my blender importer imports weighs, if you use that it's just a matter of re-UVmapping it. That's still quite some work, especially if there are multiple LODs, but it's manageable.

If you mirror your model, including the UV map, the texture will be mirrored, yes. You need to edit the UV map to change that. Whether that would be a tough job depends on lots of details.

Your map's size is too damn high. It needs too much memory to compile the light stage. -lomem is one thing that may help, or if you have a 64 bit operating system you can try a 64 bit Q3Map2 build which can handle more than 2GB ram. Also, maybe don't do -super 2, that's 2x super-sampling, which calculates every lightmap at twice the height and twice the width for 4x the memory usage. The downside of lomem is increased compile time. Maybe try -fast or -faster for faster compiles at the cost of decreased quality.

Oh I just have this hunch that the game wasn't meant to have grass models with 30K vertices and 20K triangles placed once per square meter... Call it intuition. Also, the model is untextured and has no UV map. I suggest you use surfacesprites for your grass needs, but hey, it's up to you.

Q3Map2 can handle .3ds models just fine as far as I'm aware, given the texture paths are relative. That model looks a good deal too complex though.

It's necessary, called t-junctions. There's a Q3Map2 switch, -notjunc or some such, to disable it, but that can lead to visual anomalies. The reason are rounding errors in interpolating the edges, leading to 1-pixel-wide gaps between trianges, like so.

The plugin is untested in Blender 2.7 and may not work. Try 2.69.

When you say that it sounds like you really should read the shader manual lol.

Shaders are pretty close to how graphics hardware works - or used to work 10 years ago, it learned some new tricks since then. You'll basically want to learn about blending (see glBlendFunc), the depth buffer (or z-buffer) and how it doesn't support transparency very well (which explains why you see so much blendFunc GL_ONE GL_ONE in shaders and what depthWrite and depthFunc are all about and kind of plays into alphaFunc as well) and then it's just a matter of understanding that all the stages in a shader are drawn in sequence. And it helps to know about vertex colors and understand that they can be used for lighting (which is particularly used in misc_model without spawnflag 4) or blending (for alpha-blended terrain). Well, and then there's surfaceparms and q3map2 specific keywords and a couple of other things, but understanding how the stages work is the most important part.

A unit is roughly an inch.

To add bot support, join their team to get access to its source code, without which it's impossible. The "simplest" thing I can imagine is still pretty hard: Port over the singleplayer's pathfinding, which is superior to the multiplayer's and should be a good foundation. Will still need quite some work afterwards, but nowhere as much. They won't want to do that though because the singleplayer code is GPL-licensed, so they'd have to make their code open source were they to use parts of it. Anyway, begin by learning C and probably some C++. I'm not sure about scaling, but I believe the answer is the same: You need access to the code.