mrwonko

I'm not saying it shouldn't be hosted on JKHub, this is probably the best place for a wiki, I just mean it should be easy to download a backup in case we ever need to move it elsewhere.

I'd like to second the wiki/tutorial system plan. Some more detailed ideas: Firstly, it should be collaborative. The best results are almost always arrived at by improving iteratively. It might be a good idea to have all content under a suitable Creative Commons licence. Contributing has to be easy, to encourage as many people as possible to share their knowledge. The content should not be tied to JKHub. We've had multiple sites go down in the past, taking vast amounts of tutorials with them. Use a system that makes it easy to access and export the content. In terms of structure, we need to provide clear paths for modders trying to learn a new area, like how to make a player model. There will be overlap between paths, for example I expect most will contain information on pk3 files. So there would be a single page explaining pk3 files, which is then referenced by multiple paths. Another use case are code references. A page on mapping might list the jump heights at each force level, it would be useful if it could then link to the relevant piece(s) of the source code that determine(s) this height. Another common use-case is "this thing isn't working, how do I fix it?" I'm not sure what the best way to present this kind of information is.

It's not too detailed, but it might not have the additional lower detail versions of the models (the LODs). Like I said, you can use ModView to find out if that is really the problem. If it is, fixing it requires a modelling program like Blender and knowledge of how to use it to reduce the model detail, as well as an understanding of how to correctly set the LODs up for export to the game. Sadly there's not much documentation on the latter.

When you save a jpeg in an image editor, there's often a checkbox called "progressive", which must not be checked. The icon is probably treated like any other texture, which means you can also write a shader for it. Check the shaders of those models that use a different image, I suspect they have one for icon_default.

Once you modify the model to add a jetpack, you will have to give it a name, and you can then toggle its visibility using the .skin file, just like with the mask. But you still need to modify the model first, you can't attach models to each other without that (or coding a mod).

You can use the ModView tool from the JKA SDK to find out if the model has LODs (Levels of Detail). Usually hit detection uses a version of the model with less detail (fewer triangles), maybe this model doesn't have that, which might lead to the crash.

There might be something wrong with your icon_default image that prevents it from being loaded. Common mistakes include using unsupported image sizes (width and height must be powers of two) or enabling progressive mode for JPEGs.

That script looks fine, maybe the previous value persists when you restart the level? In that case you'll have to set it to 0 at the start. Another way of achieving the same thing is to use a target_counter to count the fallen enemies. Instead of a deathscript, you can use the npc_target, which gets triggered when the NPC dies, to connect the skeletons to the target_counter, and then connect the target_counter to a target_scriptrunner to execute the ladyjedi01/babysleep script. I'm not sure if that only works once, or if the counter gets reset upon triggering.

Yes, you can build a special version of the application that makes development easier and enables additional bug detection checks. These debug builds are typically not released to the public, when you download a build off Github you get the so-called "Release" build, which as the name suggests is intended for release to endusers.

The best place to report OpenJK Issues is the issue tracker on GitHub. Did you build OpenJK yourself? If you're using a Debug build instead of a Release build, additional debugging features may be enabled, which could explain this behaviour.

I also did a video tutorial series on this a long time ago, this is the first part. I don't remember if it's any good, and it's certainly outdated, but much of what it contains should still apply.

If I remember correctly the saving is broken in 1.4 from Windows 7 onwards (possibly Vista, too). The code was just plain wrong and only worked by accident in earlier Windows versions. I think there were two workarounds (besides updating to a newer version): either you can manually add the ".map" when saving the file, or you can go to the preferences and switch to an alternate version of the load/save dialog, I don't remember what exactly the option is called.

Please share a screenshot of the hierarchy in the outliner in Blender with everything expanded. There might be disconnected pieces. I don't think duplicate names are an error case I ever considered, I don't know what will happen in that case, I've made a note to investigate some day.

Try using forward slashes "/" instead of backslashes "\" in your shader paths. Backslashes are Windows-specific, while forward slashes are the portable default expected by Jedi Academy.

I believe you'll have to modify the source code to make NPCs other than Kyle use grapple, but I'm not completely sure. I don't know about mods removing the need for iknowkungfu, that would also require changes to the code.

The Jedi Outcast and Jedi Academy skeletons have different bone structures, so you can't merge animations from one with the other. Regarding your other questions, you'll need to provide more information. What are you trying to achieve, what are the steps you took, and when does it fail how?

The file formats and the engine impose several constraints on top of GL1.1 performance issues, like limits to the number of vertices per mesh on a player model (1000, but actually 500 if you enable projected shadows). If I remember correctly, first person weapon models use the MD3 format, which only supports vertex animations. That's not ideal for first person arms. I'm pretty sure you won't get first person weapon animations without coding. And if you have to change the code anyway, you might as well do it properly. I think you should use the normal 3rd person player model and create special 1st person animations for its arms. Then you can display only the arms (this is already supported for dismemberment), so you have animated arms matching the player's current player model, to which the weapon can be attached in the same way it is when you're in 3rd person. I don't know which parts of the code you have to change to make this happen.

Switching the editor's mode will give you access to the singleplayer-specific entities, but won't delete existing multiplayer entities like team-specific spawnpoints etc. You may have to manually remove those. Keep in mind though that a singleplayer map has different design considerations from a multiplayer one. Multiplayer maps usually loop back on themselves, avoiding dead ends, while singleplayer maps are often linear with a start and an end. A map built for one may not work well for the other. But it can certainly work, maybe with some small changes here and there.

Where do you need this? Can you put it on a moving brush? A func_bobbing might work, I don't know if that can bob sideways.

The func_bobbing needs an origin brush to define where the model is supposed to go, or it will spawn in the origin of the map. I also recommend nodraw_nonsolid over trigger for dummy brushes. An alternative method is targeting a misc_model in the desired position to the func_bobbing ("target" key on the misc_model, "targetname" on func_bobbing).

Just to clarify, you've added a player model, not a weapon model, right? GLM uses so-called "Tags" to represent locations on the model like where it holds weapons, they're represented by special surfaces. You can check them using the ModView tool from the SDK. It's usually easiest to copy them from an existing model. What software do you use?

Try devmapall, I think that's supposed to reload all resources.

Did you read the pdf manual that comes with the exporter? It should explain model_root_0.

The lightgrid is a 3D grid throughout the map that stores the light brightness/color/direction at each grid point, which is used for dynamic lighting e.g. on first person weapons. I suspect you can use the system/lightgrid shader to define the extents of that grid, but I don't know for sure.

If I remember correctly, this can also happen if you have any vertices/edges that are not connected to a face. Cagelight modified the exporter so you no longer have to split at UV seams, you should try his version: https://github.com/cagelight/jedi-academy-blender-suite