mrwonko

The version on this website is outdated, I have yet to get around to uploading the latest version (I want to do some more fixes/improvements first). I would recommend updating, because older versions may not work on the latest Blender and can lose vertex normals on import.

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.

FYI the player.npc file you found is for the NPC version of the player used in cutscenes.

When you are playing the map, you can use the console command "mapname" to find out the name of its bsp. I don't know how to find out which pk3 file it's in, though.

Welcome back. Looking great!

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.

In principle, adding support for new video formats should very much be possible, but nobody has done it yet, to my knowledge.

I don't know why your counter is off by one (I guess something unexpected targets it?), but I can explain the "cm_inlinemodel: bad number". Triggers are brush entities, i.e. their volume is represented using brushes, which get compiled into "inline models", i.e. brush models baked into the bsp file. Entity modding keeps these unchanged, and on this map there seem to be 166 of them (*0 to *165). You can reference existing ones, and move them around, but you can't add new ones, at least not with the existing tools.

Limitations stimulate creativity, could make for a fun contest. But 20 brushes seems extremely low. How about 42 or 69?

Works for me in EternalJK MP. But you should use slashes ("/") instead of backslashes ("\") in the .sab file.

The latest version should be fine.

Did you write a .sab file in ext_data/sabers for it? Sharing the PK3 is probably the easiest way for us to find the issue, agreed.

The JPG issue you allude to is that JA doesn't support progressive JPG files. You don't have to use TGA to fix that, saving it as a non-progressive JPG also works. I don't know of anything else that causes this error, but the message is very vague, so it's hard to tell for sure.

You need to find out what the name of the model used by Movie Duels 2 is by checking inside the pk3 file(s) of the mod. It will be somewhere in models/players/. Then you need to rename your Jango of choice to use the same name, but only move the model.glm and model_default.skin, keep the textures in place to keep things simple. Afterwards make sure the Jango Fett pk3 file comes alphabetically after the Movie Duels pk3 files so that it takes precedence. Alternatively, edit Movie Duel 2's Jango NPC file (somewhere in ext_data/npcs/) to adjust the model used to the one you want.

1.4 is ancient, it has been superseded by 1.6, which is a direct upgrade and should be used instead. NRC has a different lineage and subsequently feels different to use, so it can come down to taste, but NRC is generally considered more powerful.

First, use ModView from the SDK or check the animations.cfg to find out which specific frames you need. Then import models/players/_humanoid/_humanoid.gla with https://github.com/mrwonko/Blender-Jedi-Academy-Tools/releases/tag/nightly, making sure to only import the frames you need, attempting to import all animations takes a veeery long time.

You can configure a couple of settings in the .npc file of the enemy. You can extract it from one of the assets pk3s, it should be in the ext_data folder.

I wish I could remember the details, I can't look it up right now, but some tools use an asterisk to mark tag surfaces and distinguish them from regular surfaces, while others don't. If I remember correctly, there is no asterisk in the glm file itself, but ModView displays it? I think in Blender I chose to display it the way it is in the glm file.

You can re-rig it using Jedi Academy's skeleton, but that will be a significant effort.

From what I understand, you need to add an extra tag surface to the model to define where the left saber should go, and weigh it to a bone that only exists in JA. The fact that the bone only exists in JA complicates matters… I think it basically means you can not rely on the automatic JK2 to JA conversion built into the engine, the model has to explicitly use the JA skeleton with the extra bone. I don't know if anyone has ever written a guide on how to do that, or if it's even been done before. Now, if we had a tool that saves the result of JA's automatic JK2 conversion as a glm file, that would be relatively easy to fix, but I'm not aware of such a tool existing.

You need to find out why exactly it breaks that texture. Maybe it changes the associated shader? I would take a look at the .shader files of EY4 and see if any of them are for the sand in t1_danger, provided you know what texture that is. Also check the console to see if there are any error messages on t1_danger.

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.

You need to rotate the hilt including the blade tag, but excluding the tag that defines where it's held, which I think is called tag_parent.

Yes, it's called Entity Modding and there should be multiple tutorials about it on this website.

When I said "editing the map" I wasn't referring to just the .bsp, but also editing the scripts. But FYI you can actually edit the entities in a map without having to decompile it (and losing lighting etc.), it's a process called "entity modding" and there are multiple tutorials about it on this website. So one solution would be to use entity modding to change cutscene 2 to run a different script than Mara_Stand.ibi. Another might be to put all the logic into dkyle.ibi and dk.ibi and leave Mara_Stand.ibi empty?