mrwonko

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?

With conversations, it's important to have the correct NPC play the voice line, so that the audio comes from the right direction and the correct mouth moved. Since the level originally had no audio, it didn't have to worry about that, and apparently had all voice lines in a single script? I don't fully understand the problem you've encountered, can you link to the map you're editing?

Jedi Academy's skeleton is only more complex in some ways. For example there's another bone for the left-hand saber. But in other ways, it's simpler: you no longer have bones for each individual finger, for example. An automatic conversion should still be feasible, and would be the best solution imo. This kind of task does not require any creativity or thought, you simply perform a list of steps. You don't need a human for that.

GIMP is likely best free option for applying filters and the like, but if you're looking more towards painting, check out Krita.

Oh, of course, yes. I interpreted "need[ing] to shift to lower-poly models" to mean "as models become more distant", but in hindsight it was probably referring to lowering the max LOD level to improve performance. So to be clear: One case where the game "needs" to shift to lower-poly models is for far-away models. How far exactly depends on your resolution, if I'm not mistaken. I would recommend against omitting LODs for all but the simplest models.

It should be included with the download, you can also find the latest version at https://github.com/mrwonko/Blender-Jedi-Academy-Tools/releases/tag/nightly

As explained in the manual, the surface names are defined in the ghoul 2 properties. It can't use the object names, because those impose a shorter length limit than necessary.

Lower levels of detail are also used for collision calculations. Omitting them can lead to crashes when the model gets hit by a saber/projectile, aside from the expected performance issues. Don't do it.

If you can't find an importer for 3.0, you can also use an older version, then save the model and open it with 3.0. Blender's .blend files have very good backward- & forward-compatibility.

There's a scale setting during import which defaults to 10x because Blender's units are much larger than Jedi Academy's. The size gets applied at the top of the hierarchy and is implicitly inherited downwards. When you detach an object from the hierarchy, it no longer receives the 10x smaller scale adjustment. As long as both models are imported with the same scale factor, you should be able to move objects between them. As a fallback, you can import the models with 1x scale.

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.

If you enable "runonactivator" on the target_scriptrunner that the info_player_start targets, you don't need the "affect" in your script. But yeah, like MagSul said (and like I did in my initial reply), the noweapon flag suffices.

I strongly suspect you can check force power levels in a script, much like you can set them via script.

There's a "NOWEAPON" spawnflag on info_player_start, as far as I remember. Enabling that should be sufficient, as you start the game without any force powers by default. That said, both spawnscript and target_scriptrunner should work for running a script on the player upon spawn.

MD3 is limited to 1024 units in each dimension (-512 to +512), so is unsuitable for large models. Other than that, the format used is irrelevant, because Q3Map2 embeds the model in the .bsp, it no longer references the original file. I'm surprised that spawnflags 2 does not work as intended, I would have expected it to. Note that you can shoot through system/clip, if I remember correctly system/physicsclip is a bulletproof alternative. I don't know how/if you can define the material of auto-generated clip brushes. You're talking about the surface flags that control the sound of footsteps, the types of effects played etc., right?

The most reliable way to clip (=add collision to) a model is using brushes. In theory, the collision mesh you're using should also work, though they're not commonly used in JA. I can't tell what's going wrong without looking at the map.

Android usually runs on ARM processors, which is a different type of architecture that has to be specifically targeted when compiling code mods, it can't run programs for PC. In theory, code mods are possible on Android, but the mods have to be built specifically for Android, and JKtouch also needs to support it (I don't know if it does). I don't know if anyone has ever tried it.

I believe the damage is caused by a trigger_hurt, not a script, so you have to use entity modding to modify the level's .bsp file. There are a handful of guides in the tutorial section to help you get started.