mrwonko

GTK Radiant, the tool for creating custom maps, is cross-platform. You might have to compile it yourself for Mac, I don't think there are binaries, but in general it should work. The script compiler on the other hand may not be available on Mac? I'm not entirely sure. As for editing existing maps: This is easiest if you have the original .map, as was already said. This is available for mp/ffa5, mp/duel8, mp/ctf4 and mp/siege_hoth. Decompiling a .bsp to a .map on the other hand results in loss of a lot of information, e.g. lighting and texture alignment. If you're only going to add new entities, there's an option to compile only the entities though, but you can't add new brush-entities (like triggers, that make stuff happen when you enter them (e.g. spawn enemies) or doors etc.), which severely limits you. You could also ask mappers that have released MP maps for the .map files to them, I suppose.

I would suggest you start by changing the texture of a model, to get a feel for how Jedi Academy modding works in general. Modelling is no easy thing to do, and by starting here you should already know: How to unpack the models and other dataHow to change it, ideally while working with a copy and not the original (unless you want to change how the original looks, but usually you'll want the modifications to be separately selectable)What a .skin file is and what it does, since you'll need one for the model as well, especially if you want to be able to change the head back and forth.How to pack the finished mod into a .pk3 for easier distribution If you've never created a model before, maybe you shouldn't start with something as complex as a playermodel... A lightsaber would be simpler since it doesn't need to move. That said, stitchting together existing models is about the simplest possible new player model, although somewhat tedious and there's still a lot that can go wrong. The only tool I'm aware of that can import and then re-export a playermodel (without any extra work required for it to keep working) is Blender in combination with my plugin suite. Well, when I say no extra work, I am referring to a single model. Stitching two together does require quite some work - you'll have lots of duplicate parts that need deleting and you'll also need to fix the hierarchies, i.e. parent-child-relations between different parts, like making the new head a child of the old body. (The model is split up in multiple parts to make dismemberment possible.) And this needs to be done for every Level Of Detail (LOD). (There are multiple versions of the models in different levels of quality - the game switches to a simpler one when the model is further away to improve the FPS.) Sadly the plugin suite lacks proper documentation. One of these days I'll write it. But you should learn how to use Blender first anyway - for the changes you're trying to make you'll need to know: How to navigateHow to select thingsHow to delete thingsProbably how to hide and move thingsHow to change the hierarchy/parent-child-relations - to this end it would be useful to understand the Outliner since it gives you a quick overview of the hierarchy.As for how to create a model with variants (i.e. species) - you should start by taking a look at the existing ones and seeing how they work. Good luck and welcome to JKHUB and Jedi Academy modding!

I vote for models/map_objects/jkhub_pma/modelname

I thought this was serial, not parallel? There's no need to sync any shaders when working that way, you just add yours when its your turn.

And I'd suggest 7-zip, which is basically the same except better and free. Take care to keep it inside a maps folder, i.e. have a maps folder in the archive. Yes. And about a lot of other things.

Which version of radiant is that?

I want to tell you that what happened to you can't have been due to changing mp_entities.def, that doesn't make any sense. I'm not denying it happened to you, but I'm very surprised. Could you try to reproduce it and give a step-by-step-guide?

If you haven't created any custom textures etc., just a new map, it would be enough to upload the .bsp you get when compiling. But usually you'd put all the custom files required by your map (including the map itself) into a zip archive and rename it to .pk3. Check out some custom maps - the .pk3 files are just zip archives so archiving programs like 7-zip or winrar can open them just fine - to see what it should look like.

I completely fail to comprehend this. Entities are just a set of key/value pairs and are saved as such. You can even use unknown classnames and radiant will fall back to a default display, so missing defintions can't be a problem. Which version did you have problems with? I hardly have any experience with 1.5, but I don't see why it would be any different, unless it changed the file format, which wouldn't make sense and in which case compatibility would be screwed anyway.

I don't see why that would be the case.

That's for turning off the n-th blade of a saber, so on a dual-bladed server it turns of both. (If you have some modded 5-blade-saber you're out of luck)

Get the JKA SDKStart BehavEdConfigure BehavEd (Are there still any tutorials on this available somewhere? I've got an old German tutorial archived on my website, maybe the pictures will help)Recreate the above scriptSave it in gamedata/base/scriptsHit the compile buttonGo ingame, enable cheats, enter runscript <scriptnamehere>

I believe it can be done with an ICARUS script like this one: set ( /*@[member='Seto']_TYPES*/ "SET_WEAPON", /*@WEAPON_NAMES*/ "WP_SABER" ); set ( /*@[member='Seto']_TYPES*/ "SET_SABER1BLADEOFF", 0 ); set ( /*@[member='Seto']_TYPES*/ "SET_SABER1BLADEOFF", 1 ); set ( /*@[member='Seto']_TYPES*/ "SET_SABER2BLADEOFF", 0 ); set ( /*@[member='Seto']_TYPES*/ "SET_SABER2BLADEOFF", 1 );Which could be bound to a key using the runscript command. --edit-- Sorry for the Ping, Seto, it's JKHub being stupid. That should be @<nothing>SET in the script.

If you get (way) more fps than the server you'll get connection problems.

I've run into limits regarding the total number of brushes before. You can only have so many. And if you try to do a -vis compile without actually preparing the map for that you can run into portal-related errors as well, I think I've seen that before.

I'm just saying that instead of making the automatic model name guessing work you could just set the correct path in the .sab.

Okay, I'm out then. Bye.

Doubt it. You just either lacked the .sab file or specified an incorrect path there.

I don't, but if you'd post your files I might.

There's no need to panic, @MagSul.

Does it display correctly in md3view? It looks like you're using a custom texture, in mp you'll need to set sv_pure 0 or pack them in a pk3 in order for them to work porperly.

You'll need a custom property called md3shader on the object (not the mesh!) with the texture you'd like to use as the value. I'll try to find some time to improve the exporters in the coming weeks, they need proper error messages and documentation.

Or animate a camera path using Blender, export it as .roff and play that via script.

Sitting in Uni I have no access to actual shaders for reference, but off the top off my head: You could take a look at Chewie's furIf you're going to use it on map objects as well: q3map2_nolightmap and q3map2_onlyvertexlighting or whatever they're called. A saber is never going to be processed by Q3Map2 though, so a simple omission of the $lightmap stage will suffice. (Models are not lightmapped, after all.)A single stage for the textureblendFunc GL_ONE GL_ZERO so it overwrites anything previously rendered (in detail: multiply new pixel color (source) by 1, previous (destination) by 0, add results)alphaFunc GE128 so alpha values greater or equal to 128 will be drawn, values below will not. (Alpha tests should (usually) be all-or-nothing to avoid problems)depthWrite so that written pixels also get written to the Depth Buffer (so stuff behind it will not be drawn in front)rgbGen vertex to use vertex colour (i.e. per-vertex-lighting) for colouringSo something like this:path/to/shader { { map path/to/texture blendFunc GL_ONE GL_ZERO alphaFunc GE128 rgbGen vertex depthWrite } }

I hate just giving an example without explaining how or why it works, so instead of giving you shader code I'll explain the concept. Making a texture shiny is achieved by overlaying a second, transparent texture that then moves around (the reflections). To then prevent certain parts from being shiny, you could overlay another texture with transparent parts on it. The non-transparent parts would thus hide the shininess. The exact shader varies depending on whether you need a lightmap etc. You're thinking of an on-character HUD akin to Dead Space? Having procedural shaders is not unheard of: Jedi Knight Galaxies has weapons with Ammo Counters and Hydroball has the in-map scoreboards, but this requires code modifications which make it pretty tricky if you're not into coding. I would assume this requires coding as well, but I don't know for sure.