mrwonko

Well, with a sufficiently detail-brushed map the -vis stage shouldn't take more than a minute, surely not more than 5, in my experience. (Then again it's been a while since I last worked on maps so my memory might be wrong.) In an extreme case your entire map might be detail and you manually place occluder brushes (which is what the antiportal texture is for).

Well, there's there's stuff like grates made out of brushes as well as decorated windows in there, that should definitely not be structural.

Better FPS.

In that case, also include the .map, because lots of information gets lost when you decompile a .bsp back into .map.

That's during -vis, right? That's bound to take long if you have lots of structural brushes, but you generally shouldn't. I'll hopefully start writing tutorials shortly, vis will be one area. I'd appreciate if you took a look here and told me if you need any other tutorials. Easiest way for us to tell you what's the problem with your map is to take a look at it, by the way.

Ignore that and feel free to leave the .md3 out if you're just using misc_model.

Regarding mono/stereo: target_speaker sounds need to be mono (after all there's only one speaker) while background music (the music key in worldspawn) has to be stereo.

The whole purpose of the -vis stage is to calculate the visibility, hence the name. To that end it takes into account only the structural brushes. The point of it is so the game only needs to calculate what's currently (potentially) visible. If you were to put a huge structural box around the map and make everything else detail, the -vis stage would conclude that everything is always visible, so you'll want to retain the basic layout of the map, while making details... well, into detail brushes.

The Source Engine is based on the Quake 2 Engine and thus lacks the Quake 3 Engine's new Patch Meshes for curved surfaces. Q3Map2 can turn patches into "ordinary" geometry with the -patchmeta switch, but the Source Engine has its own compiler without support for patches.

Sure, have as many mirrors as possible, there's no point in exclusives when you're sharing information.

Or we could, you know, just use JKHub's Tutorial section and Wiki? But thanks for the list, I'll see if I missed anything.

Hey, I've been thinking about how so many tutorials have been lost... Maybe I should write down what I know about Jedi Academy modding, which is actually quite a lot. So much that I may miss some things, so I thought you could help me list what tutorials are needed. Please contribute here. I hope I'll find the motivation to actually write these. Maybe I'll try writing one every day or two, that way I'll eventually be done. Thanks, mrwonko

GTK is short for GIMP Tool Kit, which originated from GIMP, unsurprisingly.

Well, I chose that model to test my glm exporter because its textures were simple enough for me to do well myself. I guess I should model & texture way more to get better at it and be able to make "proper" models. There's so much I should do though... (Like learning for my exams right now, instead of reading JKHub.)

May I ask why?

JKA supports PNG, but I believe it loads more slowly, or so I've heard. I never benchmarked it myself. I suggest you convert to JPG which would also reduce the filesize and can be done in a matter of seconds using batch conversion.

I for one appreciate being spared from dickhead-skins and nude Jans.

Understandable. On the other hand I've been using Blender for 8 or so years, so it's my tool of choice. But I totally get the criticism.

There's also this certain plugin for that one major free modelling suite... https://jkhub.org/files/file/1413-blender-264-jedi-academy-plugin-suite/

A player only sees another player's custom skin if they have it installed, too. Whether that was done manually or through an automatic server download (given the file is available on the server) doesn't matter.

Yeah, there's nothing wrong with asking here, I'm probably the only one who still looks at map-forge anyway. Just a bit of a knee-jerk reaction to cross-posting.

Ask in all the forums! Don't forget about gamefront!

Sounds like Q3Map2 can't find the textures, which should also be noted in the compile output. That causes it to use assume a default texture size, which is usually way too small. Make sure the basepath gets set correctly. This may be a problem with radiant but can easily be circumvented by manually invoking Q3Map2, say using Q3Map2GUI.

You'll need to write a shader to have the transparent parts of your texture be transparent in the game - take a look at e.g. a grate in imperial or some leaves in yavin for how such a shader has to look. Changing a skybox (e.g. adding a moon) is a matter of painting onto the texture (or a copy, ideally, then copying the shader and adjusting paths). As for the prismatic brushes in the picture - take a look at the 2-point-clipping tool (shortcut X) to cut through brushes as the least error prone method of shaping them.

The worldspawn is any brush/curve that's not part of an entity, so just select some ordinary brush and open the entity settings to configure it. You'll have to experiment with the values, I only know the tech behind this stuff, I'm terrible at actually making stuff look good.