Jump to content


JKHub Staff
  • Posts

  • Joined

  • Last visited

Staff Member

mrwonko belongs to the Staff group.


About mrwonko

Contact Methods

Profile Information

  • Gender
    Not Telling
  • Location
  • Modding Interests
    Jack of all Trades

Recent Profile Visitors

6,867 profile views

mrwonko's Achievements

  1. As it says, try running the game using a command line interface. Right-click the folder containing the executable, "Open in Terminal" and enter the name of the executable. You should then be able to see a more detailed error message.
  2. For animations, you can also do a lot with shaders! By overlaying up to eight layers, you can mask out areas, have moving/pulsing images, and do all kinds of neat things. As far as I know, shaders should work the same in menus as they do in maps. I think 4096x4096 is the largest texture size I've heard of people using successfully, and there shouldn't be much need to go further. Good luck!
  3. The menus use a virtual 640x480 canvas that gets stretched to whatever resolution the user is actually using. So to always look correct, you need one version of the menu for each aspect ratio. But I think you can do the image squishing in the .menu file, you don't need to squish the texture itself? A menu editor is high on my priority list, but I don't know when I'll get around to it.
  4. Dark science. Cloning. Or, on a more technical level, an npc_spawner with count -1 can spawn an unlimited number of NPCs. We'd have to check the entities in the map to know for sure. As for the sand worms, the intended solution is to avoid/distract them, not to defeat all of them. I imagine the faster variant is there as way to keep you from running out of the level. Again, we'd have to check how the level is built and what the corresponding source code looks like to know for sure.
  5. In Jedi Outcast, the surface is disabled in the .glm file and then turned on using the npcs.cfg file. In Jedi Academy, the .glm typically has all surfaces enabled, and then selectively disables them using the .skin file. I suspect there is no way to turn them on using only the .skin file, you'll likely need to modify the .glm. So download the latest version of the Blender tools from Github, import the .glm (refer to the manual for the required folder structure so it can find the corresponding .gla), go into the object properties of each hidden surface, find the Ghoul 2 Properties and untick the "off" checkbox, then re-export the .glm.
  6. I don't see "TORSO_COLLAR_OFF" anywhere in the code you posted, I wonder how it ends up in the error message. Can you post the full NPC definition?
  7. Like I said, use surfOn. I don't see it in that npc you posted.
  8. The relevant surfaces are torso_galaktorso_off, torso_collar_off, torso_galakface_off, torso_eyes_mouth_off & torso_galakhead_off, as you can check via ModView from the SDK. In Jedi Academy, surfaces get disabled via the .skin file, but apparently Jedi Outcast uses ext_data/npcs.cfg instead. Here's an excerpt of the Stromtrooper Officer: STOfficer { playerModel stormtrooper surfOn torso_pauldron_off surfOff "torso_armor_neck_augment torso_body_neck_augment" It uses the "surfOn" and "surfOff" settings to enable the pauldron. You should be able to similarly enable the missing Galak surfaces.
  9. This tutorial goes through the steps required to export a new vehicle from Blender into Jedi Academy. It does not teach how to create the model itself. Before we start make sure you've properly installed the Blender JKA Plugin Suite. http://jkhub.org/ind...eenshot&id=1413 Blender 2.64+ - Jedi Academy Plugin Suite v0.2.1 The Jedi Academy SDK is also useful as it includes ModView, a Model Viewer for glm/gla files. Then just create your model as usual. There's plenty of tutorial on that so I'm not going to reiterate. You can even have multiple levels of detail, though some limitations apply. (See the part about the G2 Properties) But when creating the UV maps you'll have to keep in mind that the GLM format saves UV coordinates per vertex, not per face. So any uv seam on your model has to actually be a split in the model. The easiest way to do this is to also mark any seam as a "Sharp Edge" as well (in the Edge menu opened by Ctrl+E)... ... and use the Edge Split modifier to create the splits there. (Be sure to enable "Sharp Edges" and disable "Edge Angle".) If the exporter were more clever it could do the splitting automatically, but alas it can't. While we're on the topic of UV maps: Every vertex needs UV coordinates. Every. Single. One. Even those on hidden tag surfaces. (I never said they need to look good, right?) You'll get an error to remind you otherwise. Next, a word on shading. Jedi Academy basically uses smooth shading on everything. To preview this in Blender, you can enable it for all faces by selecting them all (A) and enabling Smooth Shading (W -> Shade Smooth): -> So everything will be smoothed. You may not want that, but once again Edge Splitting helps: Just mark any sharp edges as such and use the Edge Split modifier as above. As above? That's right, any UV seams will inherently not be smoothed on the model, so keep that in mind when choosing the seams. All this splitting may add a lot of additional vertices. Be careful to stay below the limit of 1000 vertices per mesh that Jedi Academy has and split the mesh where necessary. As for animations: Jedi Academy's animations are skeleton-based so you'll have to use an Armature. The actual animations you'll need vary from case to case - if you're doing something swoop-like, you won't really need any (you still need to export a one-frame root animation and the model has to be properly rigged), but in my case I've got an x-wing like model with landing gear that has to be folded in/out and turbines that need to rotate into flying position. This is similar to the X-Wing, so I take a look at the X-Wing's animations in ModView. Base your vehicle on existing ones or you might have to code the new behavior. (My VTOL won't have a hover mode, for example - it'll fly like the x-wing.) Whatever you do, make sure you have a single root bone (i.e. without parent) called "model_root" and there's a proper hierarchy in your skeleton, loose bones will go missing and if there's no model_root animations won't work. Wing opening is analogous to rotating the turbines, and the gear is just the same, so let's create the animations! The gla files are just one long list of frames, so set the scene up in a way that all the animations are played in a row. Keep in mind that you can play them backwards too, which is used in the x-wing as well. Again, there's plenty of material on skeletal animations in Blender, just refer to that. Feel free to use IK and all kinds of crazy rigs, there shouldn't be any problems as long as you're using a single Armature in the end. You'll have to write a configuration file describing the animations: Their name, when they start, their duration, the FPS etc. There's a plugin to aid with that, so let's use that. First, we have to mark the beginning of each sequence of the animation. Do this by placing a Marker at the appropriate time in the timeline (M) and renaming it to the desired name (Ctrl+M). Also make sure the animation duration is set correctly, which it will have to be for the export as well. Just leave out the backwards playing animations, this is a rough first version. Then use the animation marker exporter to export it to a file called animation.cfg, which should then look somewhat like this: // Animation Data generated from Blender Markers // name start length loop fps BOTH_GEARS_OPEN 0 15 0 24 BOTH_WINGS_OPEN 15 22 0 24 Edit that to fill in the missing sequences, using the one from the vehicle you're basing your new one on for reference. This is what I ended up with: // Animation Data generated from Blender Markers // name start length loop fps BOTH_GEARS_OPEN 0 15 0 20 BOTH_GEARS_CLOSE 0 15 0 -20 BOTH_WINGS_OPEN 15 21 0 20 BOTH_WINGS_CLOSE 15 21 0 -20 BOTH_VS_IDLE 14 1 0 20 ROOT 14 1 0 20 There's a special kind of surfaces in glm files: Tags. They signify positions, and in vehicles they can be used to define where the exhaust effect should be played, where the muzzles are (i.e. where shots come from) and, for vehicles like swoops, where the player should be placed. This could be done pretty well using an Empty in Blender, but those can't be properly weighted to a skeleton so surfaces are used instead. It works like this: The origin is at vertex 2, the X-axis towards vertex 0 and the Y-Axis towards vertex 1. In Blender there's no built-in way of displaying the indices that I'm aware of so take care to create them in the right order. Raven has the guideline of making the X Axis short and the Y Axis long, but they too occasionally screw up (take a look at the X-Wing's tags, for example.) Take a look at your exported model in ModView to make sure your tags are correct. The exhaust effects and shots in Jedi Academy go in the Y- direction, so place your tags accordingly. (Again, feel free to look at existing models for reference, for example in ModView, which also allows display of vertex indices.) Keep in mind that tags, too, need to be UV mapped, although they will be hidden. The tags for the muzzles are called *muzzle1, *muzzle2 and so on, while the exhaust ones are (predictably) called *exhaust1, *exhaust2 etc. Again, ModView is your friend for finding out the right names. But how will the exporter know which surfaces are Tags? You'll have to tell it! You might've noticed the "Add G2 Properties" button in the object settings. Press it and you'll be able to set some glm specific settings. You will have to add these properties to all your objects! Why? Because glm files can have multiple Levels of Detail (LOD), so to be able to match them they need the same name across the board, and that's done using the "name" property. You also have to define the material to be used on this object, using the "shader" setting. Multi-material objects are not supported, so you may have to split your meshes. Also keep in mind that the same materials have to be used across the different LODs! The settings from LOD 0 (the most detailed one) are the ones that actually count, for the other levels only name is relevant. (And it has to match the name of an object on LOD 0! You can't add new objects on lower LODs!) The "Tag" checkbox is to tell the exporter what's a tag, and the "off" checkbox is supposed to be used for hidden surfaces, but ModView instead looks for names ending in "_off" and Jedi Academy uses the skin files instead. You also have to set up a proper hierarchy. In playermodels, this is also used for dismemberment, in case of vehicles it's mostly mosmetic. (Although I think they can lose parts when exploding, too? Someone investigate!) The important thing is that the hierarchy is used for LODs, and all you need to know is this: At the top level, you need to have a scene_root object. (Add Object adds an Empty placeholder perfect for this.) All objects will be exported in scene_root's space, i.e. if you scale scene_root down to 10% scale you can work at 10% scale and still export full-size. Keep that in mind in case you've imported a player model to get the scale of your model right: Use the same scale in your scene_root as you used during the import! Your armature has to be a child of scene_root and needs to be called skeleton_root (both object and armature). However, if you've imported a playermodel for scale, make sure your armature is not called skeleton_root or the importer will try to use that armature for the imported model! While we're on the topic of scale, don't scale your bones! There's no support for scaling in gla files since that's hardly ever necessary. For each LOD, you'll then need another (Empty) object, called "model_root_0" (or "model_root_1" for LOD 1 (less detailed than 0) and so on). This object should have exactly one child, the root object of the exported hierarchy. (For Raven's models this is an extra surface called "stupidtriangle" that they needed due to their inferior exporter. ) Below that, it's up to you unless you need dismemberment, but every part has to be in the hierarchy somewhere. Here's what my hierarchy looks like: Remember that the names here are not the ones used for export, the exporter uses the ones from the G2 Properties. The last thing to do before exporting - and you'll likely only want to do this just before exporting since it makes editing the model later harder - is to apply all the modifier except for the Armature one and to triangulate all the meshes (Ctrl+T). And then it's just a matter of exporting with the right setting. First the gla, since the glm will have to reference it. The important thing here is to clear the "gla reference" field. If we were creating new animations for an existing skeleton we'd enter its path here, but since we're creating a completely new skeleton we'll leave it empty. If you're not working directly within your base/mod folder, you may have to setup "Base Path" as well, refer to the manual in that case. And then the glm. Make sure to point it to the gla you just exported in the ".gla name" field, omitting the ".gla" extension. The file has to be called model.glm. And then it's just a matter of copying the appropriate .veh file in ext_data/vehicles and an .npc file in ext_data/npcs and adjusting them. Here are the files I ended up with, including the .blend files before and after applying the modifiers. (They may differ in some other ways, too, I was playing around a lot while writing the tutorial.) Since this is mostly about the model the .veh file isn't quite perfect and I didn't create unique graphics for the UI either. mrw_vtol.pk3
  10. Are you trying to make a serverside-only modification or do you plan to redistribute your modified bsp?
  11. No need for a deathscript, NPCs should use their npc_target upon death, so you can directly connect them to the target_count without any scripting.
  12. Who executes this script? How is it triggered?
  13. You must be using an outdated version of the exporter, I get the following error: Furthermore: After I fix those two issues, in-game I get the much more reasonable error Though it sadly does not tell us which surface. Grab the latest version at https://github.com/mrwonko/Blender-Jedi-Academy-Tools/releases/tag/nightly and see if that gives you clearer error messages. Let me know if anything is unclear.
  14. That's 1.8 billion, not 18 million. With that out of the way, it looks like the exporter crashed halfway through exporting the model (hence the error message), and now the game can't load the half-written file. Based on just that error message, I can't tell exactly what's wrong with the model, but some number appears to be too large. Please share the .blend file so I can reproduce this locally.
  15. This is an issue I do not want to reproduce, installing that many mods sounds like too much of a hassle. I read some of the related code to see if I could figure out what might theoretically be the issue. Your screenshot looks like SP to me, so I checked the SP code, but it should work the same in MP. The first thing that jumped out is MAX_SHADER_FILES = 4096. You should be able to check if that's the limit you run into by adding a Com_Printf log like so if ( numShaderFiles > MAX_SHADER_FILES ) { Com_Printf("Too many shader files (%d > %d)", numShaderFiles, MAX_SHADER_FILES); numShaderFiles = MAX_SHADER_FILES; } at the limit check in ScanAndLoadShaderFiles. But I suspect it's currently impossible to run into that, because you probably run into the MAX_FOUND_FILES limit first, which is also 4096. A message about that could go before the return in the limit check in FS_AddFileToList: if ( nfiles == MAX_FOUND_FILES - 1 ) { Com_Printf("MAX_FOUND_FILES (%d) exceeded, ignoring file %s", MAX_FOUND_FILES, name); return nfiles; } If those are indeed the limits you're hitting, I would recommend you keep doubling both of them until it works. Don't immediately set them to something super large, as increasing the limits will increase the amount of RAM needed, and you only have so much of that. Also be aware that a single broken shader file can break other files as well, which can also cause the kind of issue you're experiencing. When that happens, the broken mod needs to be removed or fixed.
  • Create New...