mrwonko

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.

On 4/13/2021 at 5:27 PM, Automa said:

what is a Debug build? One of those used by developers? Never seen any, there are only plain releases on the official Github builds' page...

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

21 hours ago, ZeroRaven said:

isn't the pickup version also an md3?

I don't know. Possibly, though I would've guessed it's the glm.

As far as I remember, you'll need two versions of the weapon, a GLM for third person, and an MD3 for first person. You can use the MD3View / ModView tools from the Jedi Academy SDK to look at existing models for reference, there'll be tags that define e.g. where the weapon is held. It might be easiest to import an existing weapon as a base for a new one.

7 hours ago, NAB622 said:

ASE models can only be used with a misc_model entity (Not sure about misc_model_static).

misc_model_static doesn't support ASE. Basically anything where the model is loaded by the game only supports MD3 (e.g. misc_model_static, misc_model_breakable, anything using the model2 property), but since misc_model gets embedded into the BSP by Q3Map2, it supports additional file types. (Fun fact: this means you don't need to ship the model with your map!)