mrwonko

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.

Exports just fine for me. What Blender Version are you on?

I believe that could be caused by missing UV coordinates on vertices, but moving them shouldn't cause that; is moving really enough to cause the error? Could you upload a .blend that fails to export so I can take a look?

A target_scriptrunner will by default only execute once and needs a count of -1 to be re-usable. You also need to set the runonactivator flag or the script will run on the target_scriptrunner instead of the player.

SET_ORIGIN works, I've used it before. Is the script running on the player? You'll need an affect("player") otherwise. (Maybe be affect("kyle") in JK2.)

Isn't notarget about you being ignored? So just make the prisoner notarget?

I don't quite understand the problem, can you strip it down to a simple example map that I can play around with?

You just use global variables: //(BHVD) declare ( /*@DECLARE_TYPE*/ STRING, "g_greeting" ); set ( "g_greeting", "hello" ); affect ( "NPC1", /*@AFFECT_TYPE*/ FLUSH ) { set ( "g_greeting", "goodbye" ); signal ( "greetingChanged" ); } waitsignal ( "greetingChanged" ); if ( $get( STRING, "g_greeting")$, $=$, "goodbye" ) { set ( /*@SET_TYPES*/ "SET_HEALTH", 0 ); } free ( "g_greeting" ); Don't forget freeing it once it's no longer required as there's a fairly low limit, it may have been 16.

Hello, Your text is very difficult to understand. Is translated automatically? The mostly ends in ziemlichem gibberish. It seems as if you wanted to describe a mod. Sorry, you write anywhere, which is the mod; do you have a link? Oh, and Fluttershy model, you speak of, this is mine? I use allowed in other mods nowhere, so it should be forbidden according to my understanding of copyright. I've got no problem with as long as you mention that it is mine, but it would have been better if you had asked me first. Question in the future, perhaps a man if he likes translate your text into English, which is probably better. Yours sincerely mrwonko