Ramikad

I agree about having more control on the map, but I can't think of anything else that might cause a crash other than a script malfunction.

isn't it simpler to make the lift a triggerable func_door? It essentially eliminates the need for scripts that might cause crashes if there's something wrong with them.

I'll never understand the need for those ginormous pauldrons.

True, but those files may contain multiple NPCs with different names.

Perhaps the latter... but how am I making a new skeleton by not moving the bones?

In Blender the hierarchy works like that. Check out the X-Wing, for example: Moreover, if the hierarchy of vehicle and humanoid meshes is more or less the same, that shouldn't be the problem, since humanoids work fine with that hierarchy.

Same here. If I had to choose, I'd say Green. Other favourites are Viridian, Cyan and Blue.

So far it has no animations, I just filled it with a few empty frames. But even still, reimporting the model it looks the same as it was before exporting it. Anyway, here's the hierarchy:

Check out this old project if you want some incredibly good references for the Death Star visuals and architectures: http://boards.theforce.net/threads/death-star-jedi-academy-sp-mod-wip.50005697/

I checked with a hex editor, and basically the skeleton .gla reads "models/players/skipray/skipray", while the model reads "models/players/skipray/model" (the model itself), followed by "models/players/skipray/skipray" (the .gla file). Compared to the other vehicles, it is pretty much the same. The model hierarchy should be pretty much okay. I have the typical model_root_0, as well as skeleton_root, both parented to scene_root, both with their own hierarchy. The transforms are also cleared, so I doubt that's the problem. I tried exporting the model rigged to a TIE Fighter skeleton, completely unchanged except for the new name, and that also caused the problem. So the issue has to do with the skeleton. It's strange to me that if I try re-importing the model back in Blender, along with its skeleton, it looks and works perfectly. Same as ModView. Also, I should point out that the tags in-game aren't distorted, they are exactly where they're supposed to be and "mostly" they fire in the right direction, except sometimes, at certain angles, they shoot elsewhere. Here's the model (.glm, .gla and .blend), if you guys want to check it out: http://en.file-upload.net/download-11850121/skipray.zip.html Some screenshots, no wireframe. How it looks like at certain angles: How it looks like when I enter it: As you can see here the muzzle tags are at the correct locations:

This time I tried rigging it to the TIE Fighter single-bone skeleton first, which worked out fine. Then I tried adding specific bones to that skeleton for the landing gears animations and the rotating S-Foils on the rear, and rigged accordingly, but at that point the model in-game is screwed. It really puzzles me that the model animates fine in Blender, it animates fine in ModView, but is distorted in-game, and even then just sometimes at specific views. So there must be something wrong with either the additions to the skeleton or while exporting the .gla. But I examined the exported .gla, checked out the paths set in both the .gla and the .glm themselves, and at a first sight I couldn't find anything "improper" compared to what the base vehicle models paths look like.

An alternative to the giant skybox solution is to make paths through sand dunes that are too high to climb, and basically make skybox corridors at the top of the dunes. With some creativity you could also put a slippery shader to the sand on the top, plus a script which makes the player fall down as he approaches it and plays a sandy effect localized on the player.

Turns out I must've messed something up with the skeleton. Thanks for the heads up guys!

So, I decided to try something new and attempted to get in-game a Skipray Blastboat I modelled from scratch - you can thank the Trilogy of Thrawn for that. It partially works. I can spawn it in-game, it flies, the animations "work", it fires... but it suffers from a strange glitch which renders it completely distorted, but just from certain points of view. I'll let the screenshots talk, wireframe view for better understanding of the model geometry (nevermind the test textures and projected UVmapping): Here's what it's supposed to look like, and what it looks like on certain angles: And this is what happens when I rotate the camera at certain angles or hop on board: Another view of what it looks like if I stand completely still close to it: And here's what happens when I crouch at the very same spot: I can't figure out what's wrong with it. I used Blender to rig it to a modified version of the X-Wing skeleton. All the meshes seem to be correctly weighed to the proper bones, and in Blender itself I can pose it correctly. The hierarchy seems set up fine. But I must be missing something. Any ideas what the problem might be?

Sure, you can. You'll have to play around with an origin brush on the door and scripts to move it properly, and it might cause some problems with culling, but it's doable.

If you don't need players to see the outer shell of the structure and the corridors you can just put the skybox brushes right over the windows. Sort of like a shutter.

Reading around, you may want to try and increase your _lightmapscale a bit, and check out the shader that causes it.

Compiling time is always an extremely volatile variable. What you can do in general is to make sure that anything aside from the walls, floors and ceilings (as well as the sky) are set as Detail Brushes (Select the brushes -> CTRL + M). It's also imperative that any surface that can't be seen is caulked. You can also play around with the blocksize and chopsize keys.

If that mission leads to Mos Eisley you could use a Ronto model.

Then you should check out the scripts taking place during that time.

If the console returns no errors, the first thing that pops in my mind is that it's most likely a bug with either a script, or a NPC spawner in the map, that has no NPC_Type set.

It's even easier in SP, a quick change in weapons.dat to redirect to the new weapon model.

What problems are you having exactly?

setforceall 0.

GLAMerge, as the name says, merges the original .gla skeleton and animation file with the new animations in a second .gla file. So it does not overwrite the original animations, but rather adds them at the end automatically - to replace animations you'll have to set the original animation marker in animations.cfg to play the new frames, after 21376.