mrwonko

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.

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.