Ramikad

The Dreadnaught has a black shiny hangar floor (look for t3_byss textures). Other than that, you might take a look at some Vjun textures.

As in it would slide open inside the rest of the curved wall? I'm not sure how well it would fit with a brush-made patch structure - it might glitch through the walls. Anyway, you can experiment making the doors, plus one origin brush for each door at the center of the elevator, so that you'd just have to make a script to rotate it of, say, about 20 degrees in the right directions when it opens, and back to the original angles when it closes. I'm also not sure how well such a door would do with portals - the doors in BlueIce Nightfall, if I remember correctly, had a few brushes as the physical door and an invisible, proper door for the culling. Only tests will tell.

Apparently it reads "Target Dist", followed by some numbers I couldn't decypher.

An alternative would be to use effects from JKG. The gfx are pretty damn good.

Try with a script: //(BHVD) set ( /*@SET_TYPES*/ "SET_NO_FALLTODEATH", /*@BOOL_TYPES*/ "true" ); If that doesn't stop the damage from being taken by the enemies, you can try that script plus a modified cushion shader on the floors, so that it works only on NPCs.

Seems to be Sunset on Coruscant by Rgoer.

To set textures for a .glm model, you have to set the path to the texture (models/<path>/<texture>.<format>) as the shader key, under Ghoul 2 Properties. For .md3 files, you'll have to set Custom Properties for each mesh of your model, namely: g2_prop_name <name of the mesh> g2_prop_off 0 g2_prop_shader <path to the texture, including models/> g2_prop_tag 0 md3shader <path to the texture, including models/> I'm not sure if all of the above are required, but that's how the JA Plugin manual puts it.

That can't be helped, unless you edit the map to run a script on start that sets the objectives you want to see in the datapad. Moreover you can't add new objectives as easily as you can add a new mission briefing, at least without code modifications, because in the base game you can only replace the objective descriptions, but not add new ones.

It won't always help. When all else fails, the only other solution is to fill those holes manually, with a patch or a brush, either right on spot, or just a little lower, to give the illusion that there are no holes in the geometry.

They're more correctly mission briefings - the typical definiton of objectives would be what you have to accomplish in order to complete the mission, and that you can check in your datapad (TAB or M key). What you need to do to show mission briefings while a mission is being loaded is to modify briefings.str, so to add a new REFERENCE and related LANG_ENGLISH (or any other language), like this: // Note to translators: // If a sentence is the same in your language then please change it to "#same" // // eg: // LANG_ENGLISH "HALT" // LANG_GERMAN "#same" // // (This is so we can tell which strings have been signed-off as ok to be the same words for QA // and because we do not store duplicate strings, which will then get exported again next time // as being untranslated.) // VERSION "1" CONFIG "W:\bin\stringed.cfg" FILENOTES "" REFERENCE <MAP NAME> LANG_ENGLISH "<Mission Briefing>" REFERENCE ... LANG_ENGLISH ... ENDMARKER Then you'll have to put the modified briefings.str in a new strings/English folder, and pack everything up in a new .pk3.

It is really hard to tell what's wrong with that face. As a first impression, I'd say the shape of the eyes is a bit off. The lower eyelids should probably be more open, and in general the face would need more details and definition that in the original game is handled by shaders not existing in JA. Maybe it's the hair a bit, too.

Downloads are working for me, so they should be alright. Must be something on your end. @@Circa ?

Flip a coin and choose either Glad I could help!

On a more serious note, you could VASTLY improve the looks of it making a simple brush tri-soup, say, 3 couples for side, plus one, or to improve the effect further, two to create the ceiling. A quick example of what I mean:

Vaguely reminds me of my experiments with the Skipray I take it you exported the animations .gla with gla reference to the original skeleton, models/players/_humanoid/_humanoid? Other than that, I usually Insert Keyframes for Whole Character. I can't think of anything else that could be causing this.

In singleplayer, you can type playermodel to see informations about the model used and the current skin. In multiplayer, you can type /model, and it will do the same. It's a bit harder in MB2, because from what I recall the /model command is disabled, to prevent being changed into another character. You could theoretically try /modellist, which lists all the models currently being used, and see if you can spot the one you're looking for.

Another way is to painscript the NPC to check their health and remove the weapon when it's too low (near death), I'm not sure if it will work on simple deathscript.

I'm not sure if it's possible through scripts, but a way to achieve this would be to put a system/nodrop on the floor. Potentially, taller system/nodrop or even submerging the whole map with it might prevent any weapon from being dropped.

To summarize, you'll have to import the _humanoid.gla player skeleton. Then you'll have to scale and pose the model accordingly so that it fits the skeleton. Then you'll have to rename the meshes to appropriate names with a _0 at the end (this basically tells Blender that you're dealing with the LOD 0), and create a hierarchy - for example, parenting Mesh3 to Mesh4, which in turn is parented to Mesh2 (Object -> Parent Object). You'll probably have to split the meshes further, basically separating them into multiple meshes (see below). Once the hierarchy and the renaming is done you'll have to create a new Empty object, name it model_root_0, and parent it to scene_root, as well as parenting the first mesh in the hierarchy to model_root_0. Then you'll have to place tags (or Import them from another model) and parent them to the correct meshes and set in the right location. Then you'll have to assign a Ghoul 2 Property to each mesh (Object -> Ghoul 2 Properties -> Add G2 properties). Input the correct mesh name, without the _0, as the name, and [nomaterial] as the shader. Once you've done this for all the meshes, start over by adding a Object Modifier -> Armature. Make sure the Modifier name is set to skin, and as Object select skeleton_root, binding it only to Vertex. Do NOT apply it, just leave it like that. Rinse and repeat for all the meshes. Now here comes the fun part. Select a mesh, select Edit Mode, go into Object Data, and create new Vertex Groups which you'll have to name after the specific bones you need for that particular mesh - you can look at the skeleton hierarchy, or just select the bones in Edit Mode / Pose Mode to know which bones are in that part of the mesh. Then you'll have to select groups of vertexes of that mesh, and assign them singularily to each Vertex Group (bone). For example, in the case of the right leg, you'll have to assign the correct vertexes to the specific Vertex Groups of rtail, rfemurYZ, rfemurX, rtibia, rtalus - all of this being mindful of the Weight value, which if set incorrectly will cause bugs with animations with that model in-game. Once again, rinse and repeat for all meshes and related bones. When exporting, you might incur into a wicked error, which would read "UV seam found! Split meshes at UV seams." The solution here is either to split the mesh into multiple meshes where the UV seams are (basically, separating into a new mesh every "island" in the UV map), or you could try and select the seam Edges (either on the model or selecting them in the UV Map with the option "Keep UV and Edit Mode mesh selection in sync"), then select Mesh -> Edges -> Edge Split. This is pretty much the method of importing a usable player model in Jedi Academy from an already created model. Good luck with it!

To be honest I experimented a lot with scripts, and sometimes they froze the game - not exactly a crash to desktop, but the game still stopped working. Other crashes can be caused by NPC_spawner entities with no NPC_type input. But once again the game freezes in that case, it doesn't exactly crash. Other than that, I find that reference to models/players/player/model.glm quite strange. I'd suggest to investigate on it.

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.