mrwonko

You don't need tasks at all. Just rotate and wait. The other problem is that rotate 360 means rotate to the 360° position on the shortest path, not rotate by 360°. i.e. it means rotate from 0° to 0° or not at all. You'll need at least 3 rotates to 120, 240 and 360°.

No. Not with that little information.

PK3 files are just ZIP archives with a different extension. Open the saber's PK3 file and in the ext_data/sabers/ folder open the .sab file (a simple text file) and change the sabers name (the one before the "{") to that of a base saber (dual_1 to dual_5 and single_1 to single_9). Save the file under the same name plus .sab. Example: You have a saber_viszla.sab containing viszla { name Viszla // ... more here } You want to replace the single-bladed saber 1 (the Arbiter) with it, so you change it to single_1 { name Viszla // ... more here } and save it as single_1.sab. Make sure your PK3's name is alphabetically after assets1.pk3 so it is loaded later, overwriting the existing ext_data/sabers/single_1.sab.

Open them in ModView (part of the JKA SDK) and look at the surface names. Ignore anything starting with "*".

In particular the bit about reading the manual. There's a .pdf included in the zip.

As you mentioned, the opening text crawl is just an image. Replace it. I think it plays depending on the level name (yavin1?), but may also be accessible as a special .roq/video...

If that helps, it means you don't have a proper waypoint network. A single navgoal can send an NPC across the whole map if it's set up properly. In the case of doors, you want one waypoint close to it on each side. As I said, try "nav show all" to see the network, it will also highlight temporarily blocked paths (such as those caused by doors), NPCs will be able to pass through there if the next waypoint is close enough for the door to open when the NPC is there.

Try "nav show all" to see if the waypoint network is correct.

Generally, no, you can't use the Star Wars IP without permission pretty much ever. Practically, it's up to them to tell you to stop, which they might not. And you can't use any assets, either, until it's explicitly allowed. The one exception is that Raven/LucasArts allowed porting of JK2 Assets to JKA.

Usually you'd use the BS_CINEMATIC behavious state for enemies that are just supposed to follow scripts... That will turn just about all AI off.

I'm not sure about the exact limits, but in general: There's a limit on the total number of entities, which I think is 2048, and that includes shots fired during gameplay etc.misc_model is turned into static geometry during compilation; if there's a limit, it's pretty high and probably depends on the number of different materials per model as well.There might be an NPC limit, if there is, it's probably somewhere in the hundreds, maybe 256 or 512. I don't know if spawned NPCs also count towards the entity limit, or if only their spawners do.Lights are only used during compilation to create the lightmap and basically unlimited.Effects could be limited in some way as well, possibly both in total and in the number of simultaneously visible ones.

First, check if that also happens with an unmodded game. Could be an OpenJK bug, if that's the case, file a report on its github page or wait for someone working on it to notice this post. Find an easy way of reproducing the problem.

Why create a folder away from the game? Just put the files where JA will load them, i.e. JKA Folder/GameData/Base - I've never had problems with that, and the results can be tested without having to copy them first.

No, weighting is done via vertex groups, which are kept on move.

I see. Then I don't know what to do.

Yeah, it actually just sets the material name since that's what the ase exporter uses.

Which importer do you use? The one from my suite? I think that one only sets a material, but not the UV Image; so you'll only see it in rendered mode.

Personally, I'd prefer a thread per issue.

In that .blend you supplied, does it already error when you export or only after you've moved something? In case of the latter, could you supply a .blend that's already broken?

Release as patch/diff, that should be fine. Or just sed masterjk3.ravensoft.com for master.jkhub.org with some null padding.

misc_model_static is dynamically lit. To my understanding, during compilation, a light grid is created: the brightness at positions of fixed distance is determined and stored, which is then used for "dynamic" lighting. Presumably the closest position is dark. Try creating a lightJunior, which is used in addition to the light grid for dynamic lighting.

That's normal-ish. It happens when a bone has multiple children, making it ambiguous where it should go to. As long as it's just for single player, you can create an entirely new rig for it, I think. (Multiplayer models must use _humanoid.)

The properties are ignored in favor of .skin files. I'd rather take a look at the .glm result than the .blend source.

I've tested it up to 2.69, which is where it worked for me.

Just take a look at existing base player models and do it exactly as it is done there? Make sure you have proper entries in the .skin files.