mrwonko

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

Just wanted to let you know I've not forgotten this, just ignored it. Or something. Hands are hard to model. Basically, I was right all along: So yeah, maybe next year? God I have so many things I want to do.

You could enable "snap to vertex" whilst moving the vertices to get them to align nicely.

The nice thing about convex brushes is that collision detection against them is pretty fast. Yes, it's theoretically faster with less sides, but I wouldn't start optimizing that before finding out how much performance it costs. Now patches on the other side are pretty expensive. I believe it's the collision, although it might be the rendering; at one point I converted a round room from patches to an ase model and gained quite a lot of performance.

Not exactly true; it only works for rigged models, yes, but you can do the rigging in Blender. My Fluttershy playermodel was completely created in Blender to test the exporter.

Git (and Mercurial, a similar software) allows you to store old versions of files and go back to them as well as some more advanced stuff that's mostly interesting to coders. These backups can be stored anywhere - usually on your own computer, but you can also upload them online.