mrwonko

Usually, collisions e.g. with lightsabers are calculated using a lower LOD (I think 2) to keep them reasonably cheap to calculate. Since the model doesn't have any LODs, the calculations become too expensive, they need too much transform space, which has a hard limit. Some custom engines may raise this limit, which could be why you had no problems before? Either way, I would recommend giving the model LODs 1 and 2 which are roughly in line with the vertex count of vanilla models.

The way I remember it, the title crawl comes from a single image file, which is hardcoded, and it only plays before one specific level. So there's no way to combine multiple mods with opening crawls without modifying the code.
Keeping each mod in its own mod folder is probably the easiest way to handle it. Restarting the game to change mod is not so bad, and helps avoid other potential incompatibilities between the mods as well.

What do you mean by "mark"? Are you referring to the sharp shadow? Lighting is based on normals, if there's a seam at that point you may want to merge the involved vertices or align their normals for smooth blending.

You're using an outdated version of the plugin. The latest one is for Blender 4.1 and shows the more helpful error message "loading LOD 0 from Blender: could not load surface l_leg: Surface has invalid vertex: Could not retrieve vertex bone weights: l_leg_0 has no armature modifier!"

No, you cannot change the lightmap using entity modding. The only way to get rid of it is to use a fullbright shader that ignores the lightmap, but a) that's going to look terrible and b) there probably aren't any existing fullbright shaders for the textures you want to use, and you cannot add new shaders through entity modding.

In Jedi Outcast, the surface is disabled in the .glm file and then turned on using the npcs.cfg file.
In Jedi Academy, the .glm typically has all surfaces enabled, and then selectively disables them using the .skin file. I suspect there is no way to turn them on using only the .skin file, you'll likely need to modify the .glm.
So download the latest version of the Blender tools from Github, import the .glm (refer to the manual for the required folder structure so it can find the corresponding .gla), go into the object properties of each hidden surface, find the Ghoul 2 Properties and untick the "off" checkbox, then re-export the .glm.

So it turns out that's not quite true. If the file is not listed in the torrent, I didn't download it as part of my jk3files scraping. However, there are still some mods I downloaded separately, just to play them. Looks like Expedition 1.05 is one of those, I found an 11-year-old file on my hard drive. I've uploaded it to my website, the download link on the page you posted should no longer be dead.
 
--edit--
On closer inspection, while the readme of that file does contain "File Version: 1.05", its filename is "expedition1.06_readme.txt". Chances are this is a WIP release I received at some point? The full 1.06 release correctly says "File Version: 1.06"

That would best be done using a sun light, which can be done using a custom sky shader, as described at http://q3map2.robotrenegade.com/docs/shader_manual/light-emitting-shaders.html, or using a directional light entity with a special key I can't quite remember, possibly "_sky" set to "1".

I think the version of my add-on in the Download section here only has an MD3 exporter, no importer. But it does come with GLM import & export. That said, don't use that version, there's a newer, better version available at https://github.com/mrwonko/Blender-Jedi-Academy-Tools/releases/tag/nightly that I should submit to jkhub some day… But that one no longer has the MD3 exporter, because Somaz has a better one as part of https://github.com/SomaZ/Blender_BSP_Importer.

I experimented a little, and the name of the .shader file appears to be irrelevant. What helped was renaming the pk3 to come alphabetically before assets, e.g. aaa_animated_sky.pk3. I think for shaders, pk3 load order is reversed from what it usually is.

If it doesn't work on Blender 3, you're using an outdated version of the plugin. The latest version is available at https://github.com/mrwonko/Blender-Jedi-Academy-Tools/releases/tag/nightly

To be able to use (any) Radiant, you need a .map file, but the game only ships with the compiled .bsp files. You may get better results by using SomaZ' BSP importer for Blender and then exporting from Blender.

The problem is not the Blender version, but the plugin version. Older versions of the plugin do not import normals. Use the latest version from here.

If the plugin shows up in the addons window so you can tick the box to enable it, it was installed correctly and you should see new importers & exporters for glm, gla etc. Could you provide some screenshots of your addons window and the import/export menu?
The latest version of the plugin is available here, it should work in the latest Blender version (3.00). It is virtually identical to cagelight's fork, I've just updated the manual and re-packaged it for easier installation, but like I said, if you can tick the addon box, you have already installed it correctly.

An NPC file is only needed to spawn it as an NPC in single player. For multiplayer, adding the icon_default image should be enough, as far as I remember. Just keep the original folder structure intact, add the icon, and you should be good to go, unless MB2 has added some kind of copy protection.

I suspect that scripts don't support non-ASCII characters. I think you can reference strings in the print statement (using an @ or something?), that will likely fix it?

Things that are too far away won't be drawn, leading to this effect. I think there's some way to change the distance, adding some property to worldspawn, but I don't remember the exact name. Something along the lines of cull distance or far plane distance maybe?

I'm fairly sure assassin droids have their own skeleton so that's probably the issue here. I think you can import the droid first, then rename his skeleton (both the object and the armature) before importing the stormtrooper.

Yes, the game code is in the DLLs. Initially that was the only available source code.
 
As long as the interface is kept compatible, game code mods and engine mods can be mixed and matched. For example if you only edit game code, players can choose to run your mod in vanilla, openjk or any other engine replacement.
 
If you choose to edit the engine (in which case you'll likely want to base your changes off openjk to get all the bug fixes) you'll have your own version and any future patches must come from you.
 
There's also the matter of licensing, but I won't get into that, just use GPL.

Yeah, some shaders don't work properly on models... I think one workaround was using a misc_model_static instead, though you could also try finding the problematic part of the shader and fixing it or giving the misc_model spawnflags 4 (to force it to be handled similar to brushes).

Is this in Radiant only or also ingame? I have an inkling that it may be due to texture filtering, in which case it would only be in Radiant and may be fixable by changing the filtering mode (not sure where you can do that, but the options should include something like Bilinear and Trilinear).
 
Maybe upload a sample so we can check what it looks like for us?

The part in front of the comma is the name of the surface you're applying a texture to, you mustn't change that. Instead you can have multiple .skin files (at least in Jedi Academy) for each variant.

What are you editing the images with? There's probably some sort of clone brush that allows you to copy parts of the image elsewhere, that should do the job.

There's a German tutorial describing it: http://mrwonko.de/tutorials/darth-arth/2004/installation-1.4.html I'm not sure how applicable it is to 1.6 though.

As the q3map prefix implies, that's a Q3Map2 feature - you just need a compiler version that's new enough to support it.