mrwonko

Somebody's been working on volumetric fog for rend2, I wonder if that looks any better...

I'm not very active in OJK development these days, but I'm definitely interested in helping design new file formats. It would be great if we could find something that everyone is happy with, so we don't end up with different engines using different format variations. Or if they do, the engine should at least be able to detect whether it supports a given file, so it can stop and print a useful error otherwise.

I welcome having more separate config files, but they should work incrementally. Meaning that if you e.g. split the weapons.dat into separate files per weapon, it should still first load weapons.dat for backwards compatibility, and then individual files may overwrite weapons or add more. This sidesteps the issue of redistributing original assets or derivatives thereof, because we can keep using the original files in OJK.

Quote

The name of the textures may seem weird but they are correct, and they are both located in base/models/map_objects/mymapname directory along with the model, so I really have no clue why Radiant fails to load them

I would have expected the model to use the full path to the texture, i.e. models/map_objects/mymapname/2FECBE8A93113C9545F7552069239BA6t, and I think Radiant expects the same. I didn't know that the game supports just putting the file next to the model and using it with just the file name.

Note that if you change it to the full path, you may exceed the 64 character limit for file paths in the engine.

Can you share the model and the textures? Maybe there's something wrong with the paths or the file format or dimensions or something. The error log that says “Texture load failed: "2FECBE8A93113C9545F7552069239BA6t"” sounds like the model has the wrong texture path, but if md3view can display it, something is weird.

Making transparent brushes detail is a good habit, but it should happen automatically if you use nodraw_solid for the invisible sides instead of caulk. There's also a surfaceparm you can give your shader to make it behave in the same way, but I'm not quite sure which of the ones nodraw_solid uses it is; probably either surfaceparm trans or nonopaque.

info_null is only visible to the compiler q3map2, which removes it so the game never sees it. It thus does not count towards the in-game entity count, but cannot be used by the game, either. It's useful for things like defining the direction of a spotlight, which is calculated by the compiler.

In theory, the compiler could do something similar for fx_runner, because its direction can also be defined using the "angles" property, which q3map2 could theoretically derive from its target. In practice, it's the game that derives the angles from the target, so you need to use an entity that is not stripped out during compilation, like info_notnull or target_position.

Or you can create a patch for q3map2 that enables it to target info_notnull.

Oh, if the .map is included, it's probably simpler to edit that using NetRadiant Custom and recompile it instead of trying to edit the entities in the .bsp.

There are different ways to do it, but typically a wave of NPCs will use their npc_target property to use a target_counter on death, which counts up to the total number of enemies in the wave and then triggers the next wave. If that's the way it's built, you'll have to edit the entities in the bsp file, for example using 

Sounds like a bug in the code. Since the code was never released, I don't think it can be fixed. Have you considered trying JA++ instead?

How about sharing your solution, so others can learn from it?

I'm not entirely sure if you need a shader to get correct lighting for the model, maybe not.

On export, every vertex can only have one UV coordinate and one normal. So if you have sharp edges or UV seams, the vertices along them will get duplicated automatically on export. You can re-import the exported glm to see the result.

To get around it, manually split the surface in question. Ideally aim for less than 500 vertices per surface after exporting, because dynamic shadows cause the limit to be halved.

Quote

resulting in a few vertices referencing more than 4 bones.

The exporter should automatically discard any bones beyond the 4 most impactful ones.

There are different ways of weighting models, but they're not specific to Jedi Academy. You can look for general advice on how to do weighting in Blender, the only important thing is that it needs to be done using an armature.

I would not start by assigning individual weights using vertex groups. For a rough first pass, bone envelopes should provide a more convenient workflow. Weight painting would then only be used to further refine the result. But this is not my area of expertise, I know just enough to get something working, but probably not efficiently.

That error should not happen, can I see the .blend file that produces it?

I'm not aware of a concrete overall vertex limit, but performance will suffer eventually. Try to stay close to what the original models use, this will both help keep things smooth and improve visual cohesion with the base game.

Typically, caps are hidden until dismemberment. But I'm not sure if that's hardcoded, or if models explicitly mark these cap surfaces as initially disabled. If it's the latter, you should be able to have caps that start on. Or just don't give them the magic cap names, just make them "regular" always-on surfaces. Having a cap that doesn't behave like one would probably just be confusing to anyone examining the model.

You should not need to hex edit your models. Just make sure that when you unpack the original files, you keep all the paths intact, so that _humanoid.gla ends up in WhereverYourJediAcademyIs/GameData/Base/models/players/_humanoid/. Then you can refer to it as models/players/_humanoid/_humanoid.gla in the export settings and the game will be able to find it.

Take a look at 

 and let us know if you still have questions.

Sounds like something that needs to be fixed in the game's source code. Or you can limit your FPS.

Usually, collisions e.g. with lightsabers are calculated using a lower LOD (I think 2) to keep them reasonably cheap to calculate. Since the model doesn't have any LODs, the calculations become too expensive, they need too much transform space, which has a hard limit. Some custom engines may raise this limit, which could be why you had no problems before? Either way, I would recommend giving the model LODs 1 and 2 which are roughly in line with the vertex count of vanilla models.

Can you share a pk3 with everything required to reproduce the issue?

Clear out the skin setting in the import dialog when importing glm files without skins.

What exactly is the bug? Do NPCs sometimes turn off one blade to use fast style, or do they use fast style with both blades extended?

In theory it's possible, but I don't think we have the necessary tools. SomaZ' Blender BSP plugin gets closest, but it looks like it cannot add new brushes (yet?). Or maybe it could be done using a misc_bsp?

The original source code release included some of the xbox code, maybe that can help you make sense of it? There's a mirror at https://github.com/jedis/jediacademy.

The way I remember it, the title crawl comes from a single image file, which is hardcoded, and it only plays before one specific level. So there's no way to combine multiple mods with opening crawls without modifying the code.

Keeping each mod in its own mod folder is probably the easiest way to handle it. Restarting the game to change mod is not so bad, and helps avoid other potential incompatibilities between the mods as well.