mrwonko

You could hex edit the BSP files to edit the texture names, just make sure to overwrite existing bytes instead of inserting new ones. You'll also need to write some new shaders for your new sky boxes.

Looks like the XL Engine source code is available so that seems like a good place to look for information on the level format. Should allow a programmer with some time and interest to write a converter...

I would've also used a "shadow map", though it could be rendered in realtime to allow dynamic objects to stop rain and to account for changing wind.

Talking about modern C++ - have you been keeping up with the changes? What excites you, what are you looking forward to? Personally I'm in love with move semantics and eagerly awaiting concepts, modules and opaque typedefs. (Not really related to JK I guess, but I'm curious.)

nuff said

Nice to see you around here, I vaguely remember pestering you about releasing JA's source code a couple of years ago

If memory serves there's a flareshader key or some such on lights.

I don't think the model_root objects themselves are exported, only their children, but I'm not sure.

I don't think antiportals are one-way... Generally the windows being curved is probably an issue.

Is a space skybox sufficient? In that case just put a wall with a skybox texture there. Based on my understanding of bsp, what you're asking for is also possible in vis - in theory at least. I think the format distinguishes between leaf x can see leaf y and leaf y can see leaf x. I'm not aware of any way to make q3map2 generate such visdata though.

I'd guess 2^31-1, but I don't know for sure.

Or perhaps someone else could.

I suggest asking some actual blender users, on a blender forum or chat. I'd have to see the problem in person to investigate this, but I really can't be arsed... It's not a priority for me any more, there's only so much tutoring you can do before you tire of it.

Just check you're not on an RP server where unprovoked attacks are frowned upon.

Yes.

Not interested, but could you share some more details so other potential candidates get a better idea of the amount of work this entails?

I don't remember where I first learned it, but there's plenty of Blender tutorials out there. You might need to enable bone weights in the armature modifier and change the display of the bones in the object properties to see the envelopes.

As a rough first approximation weighting via bone envelopes works pretty well, too. Look it up, it's a normal Blender thing. You can then convert that to vertex paint and hand-tune it.

No, you convert directly from .bsp to .ase. When converting from .map, you also need to take the step to .bsp first.

Just keep in mind that while the GPL allows you to sell your game, you still have to provide the source code to anyone who buys it, who can then do the same. That might not be a problem since you still own the assets, see Blendo Games for successful examples of games built on GPL idTech engines.

If you barely know what you're doing, learn to use Blender first. There are plenty of tutorials on that. You need to learn about basic navigation, modelling, uv mapping and skeletal animation at least, I reckon. I believe Blender can retarget animations from one skeleton to a different one, which you could use if the model doesn't quite fit the AT-AT's skeleton. I don't know how exactly to do that though.

Actually, if you're playing modern games the graphics are typically too expensive to render in 4k, but if you play old games on a modern graphics card you should have some performance to spare for higher resolutions.

Where NPCs look is probably determined by tags, check if you moved any.

The shield is probably still weighted to the droid skeleton, check the armature modifier. Generally I suggest learning to use Blender first...

I'm fairly sure assassin droids have their own skeleton so that's probably the issue here. I think you can import the droid first, then rename his skeleton (both the object and the armature) before importing the stormtrooper.