mrwonko

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.

You can give the info_player_start a spawnscript, and use BehavED from the SDK to write a script that changes the player's team and force powers, but I'm not so sure about the player model. It can be changed via script, but I think the model breaks when reloading the game?

If I remember correctly, using console commands is the more reliable way to change the player model. The only officially supported way of executing console commands that I'm aware of is through menus. So you could modify the "New Game" menu to load your map and set the player model instead of showing the character creation screen.

Did you put the changed file into a new .pk3 file using the same file path and give that pk3 a name that alphabetically comes after assets2.pk3?

Could you upload the original glm, the .blend after importing, and the exported .glm?

If you're not using this version of the plugin, vertex normals are likely getting lost on import. This can lead to weird lighting, with sharp edges appearing at the edges of meshes where there were previously none. To verify if this is what's happening, try re-exporting the model without making any changes at all. If it still exhibits the issues, this is the likely cause.

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.

You can probably already use the "model" command in the console to use those models in MP. To make it show up in the model selection screen, it needs an "icon_default" image in the folder of the model (look at existing MP models for reference) in the usual format (non-progressive jpg, png or tga, with power-of-two dimensions).

One restriction to be aware of is that the model has to use the default humanoid skeleton to be usable as a player model in MP. No, you can't play a Rancor, sorry.

Do you need instructions on how to extract the necessary files from MB2 and package them for base?

You should also note that you can't redistribute those models without permission from the original author, but it sounds like you're just doing this for yourself.

The folder structure inside the pk3 is wrong. Everything is inside "mina_aizak", when it should be "models/players/mina_aizak". I think you also need an "icon_default" image. Otherwise it looks fine.

For the model to show up in the game, the file names must match those of base player models, you need a model_default icon, and the model has to be based on the _humanoid skeleton to work.

What files do you currently have in which folder? Could you share the PK3 you made?

19 hours ago, jedley01 said:

I opened the BSP file with Notepad ++. The particular map I want to edit is t1_fatal, but there is no music setting listed in that file, only soundsets.

You will not be able to make the necessary changes with Notepad++. It's technically possible, but overly challenging. Look up a guide on Entity Modding instead, the Q3Map2 "-onlyents" mode is your friend here.

But happy to hear you found a way to achieve it with less effort instead.

I can think of two ways. You either use the same song for exploration, action, etc., which might mean it starts over from the beginning whenever you enter/exit combat, or you use Entity Modding to change the level's music setting from a dynamic one to a single track. I don't remember how to set up dynamic music, so I can't tell you how to undo it, but a static track is usually configured by setting the "music" property on the worldspawn.

Yes, any model can be turned transparent through the use of shaders. You may also have to edit the textures to get the best results. I don't have time to go into the details.

However, this may reveal geometry inside the model. For example models often have the inside of their mouth modelled so that they can open it and talk, and if you simply made everything transparent, you would permanently see their transparent teeth inside their head. So you may have to make additional changes for optimal results.

No, all I know is the ctrl+k shortcut for automatically assigning target/targetname to a pair of entities, but at least in GtkRadiant this is not smart enough to handle complex waypoint connections, esp. target2/3/4. Maybe one of the other editors has an easier way to do it?

2 hours ago, Wundai said:

When I started waypointing I did not connect them either, but this resulted in them not being used by NPCS.

Sorry, I did not mean to imply you should not connect them at all. The game only auto-connects up to a certain distance, manual connections are a good idea. You should just not connect everything with everything.

I think there's an upper limit to the total number of waypoints, I vaguely remember the number 1000, but don't quote me on that. Maybe there's also a limit on the number of connections? I don't have time to check the source code right now, maybe somebody else knows for sure.

I still don't understand the purpose of the target_delay. Why not target all the spawns directly to the scriptrunner? And either way, instead of a target_delay with wait 0, you should use a target_relay for clarity.

Use the "nav show all" command in SP to see if waypoints are working correctly. If they are blue instead of yellow, they are flying waypoints, and won't be used except by e.g. probes.

I would recommend against connecting every waypoint to every other, as far as I know the game will verify these connections when it loads the map, increasing loading times.

Why the target_delay? Why the task? Why the UseReward target_scriptrunner?

I'd try it like this:

{
"angle" "270"
"origin" "728 1424 -56"
"classname" "info_player_deathmatch"
"target" "PlayerSpawn"
}
{
"classname" "target_scriptrunner"
"count" "-1"
"targetname" "PlayerSpawn"
"usescript" "ffa3/init"
"spawnflags" "1"
}

with scripts

/////ffa3/init/////
set ( /*@SET_TYPES*/ "SET_VICTORYSCRIPT", "ffa3/reward" );

/////ffa3/reward/////
set ( "SET_SOLID", "true" );