mrwonko

Sorry, I did not mean to imply you should not connect them at all. The game only auto-connects up to a certain distance, manual connections are a good idea. You should just not connect everything with everything. I think there's an upper limit to the total number of waypoints, I vaguely remember the number 1000, but don't quote me on that. Maybe there's also a limit on the number of connections? I don't have time to check the source code right now, maybe somebody else knows for sure.

I still don't understand the purpose of the target_delay. Why not target all the spawns directly to the scriptrunner? And either way, instead of a target_delay with wait 0, you should use a target_relay for clarity.

Use the "nav show all" command in SP to see if waypoints are working correctly. If they are blue instead of yellow, they are flying waypoints, and won't be used except by e.g. probes. I would recommend against connecting every waypoint to every other, as far as I know the game will verify these connections when it loads the map, increasing loading times.

Why the target_delay? Why the task? Why the UseReward target_scriptrunner? I'd try it like this: { "angle" "270" "origin" "728 1424 -56" "classname" "info_player_deathmatch" "target" "PlayerSpawn" } { "classname" "target_scriptrunner" "count" "-1" "targetname" "PlayerSpawn" "usescript" "ffa3/init" "spawnflags" "1" } with scripts /////ffa3/init///// set ( /*@SET_TYPES*/ "SET_VICTORYSCRIPT", "ffa3/reward" ); /////ffa3/reward///// set ( "SET_SOLID", "true" );

What exactly do your scripts look like at the moment?

Yes, hand-editing BSP files is not advised, because it basically contains a "table of contents" where the "page numbers" (byte offsets) need to be adjusted when you change how long a "chapter" (like the entity definition) is. If you use q3map2 to update the entities inside a bsp, it takes care of this for you.

The SET_SOLID should take effect immediately (at most 1 frame delay), but there's a wait(50) that presumably delays everything?

In SP there's the g_icarusDebug cvar, but it looks like that doesn't exist in MP. Maybe there's a JA+ specific cvar for controlling the nonsolid period after duels?

Yes, you can overwrite the entities of a BSP file without changing anything else about it using the right tools. The process is usually referred to as "entity modding" and there should be guides somewhere, maybe somebody else has a link.

I suspect that scripts don't support non-ASCII characters. I think you can reference strings in the print statement (using an @ or something?), that will likely fix it?

Yes, you could also learn entity modding and adjust the gravity in every map.

Hmm, all the config files I know only get loaded once when the game is started, but gravity needs to be changed every time you load a map, I think. The best I can come up with is binding it to a key so you only have to press that instead of opening the console and entering the command, look into the /bind command for more on that.

Once you've enabled cheats, you should be able to change the g_gravity cvar using the console, which should change the jump trajectory.

I think you'll need two different versions of the shader, one with vertex lighting for misc_model and one with lightingDiffuse for misc_model_breakable.

You can either replace the visuals of an existing gun, which is rather simple and does not require any changes to the code, or you can modify the game's source code to add additional weapons. To modify the source code, you first need access to it, and as far as I can tell, the Movie Duels source code is not public, so you don't have that option there, but it could be done for JKA:SP. I can go into more detail on how to replace an existing gun, but I've never added a new gun.

Usually this happens when the paths are not configured correctly. You should point Radiant to the GameData folder, if I remember correctly. If you entered the wrong path during installation, the files for editing (unpacked shaders etc.) may have been installed to the wrong place, and may need to be moved manually.

That's the "missing texture" image. I would have recommended checking your image resolution and file format, and checking the console for errors, but you've already done that… Maybe try entering `developer 1` into the console (with cheats enabled) before loading into the map, if you're lucky that might provide additional clues?

You can use a target_counter to count the number of killed NPCs. Give your NPCs an NPC_target matching the targetname of the target_counter, and configure its count accordingly. Then target it to the NPCs behind the door. You can give them a spawnscript to make them run out the door, and I would recommend putting a trigger_multiple with target and target2 behind the door so it stays open until the NPCs have left, in case they take too long (e.g. due to being pushed by the player).

I suspect the skeletons used by the games differ, so it would require additional effort to re-target the SoF2 animations to the JA skeleton. It's technically possible (though I don't know exactly how to do it), but the result would be illegal to distribute.

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.