mrwonko

I find that hard to believe, unless you mean having names longer than 63 characters, which would indeed lead to problems. But yeah, just like using the Rancor model in MP anything else with a custom skeleton is incompatible without a custom mod.

If you place a waypoint above ground, it will be a flying waypoint, presumably used e.g. by the flying probes. However, when you create elevators that NPCs should be able to use you'll want to place waypoints in the shaft, which would usually be flying waypoints. My workaround for that is creating small nodraw_solid brushes below those waypoints and turning them into one big func_usable with the startoff spawnflag. Add some scripts that insert a couple of commands to make the NPCs properly wait for the elevator and bam! Your NPCs now know how to use elevators to get around. Oh, and concerning all this waypoint talk: In SP the console command "nav show all" will display the waypoints, their connections and NPC paths. Essential for checking your waypoint network. While we're talking about useful console commands: "icarus debug" will show all script commands as they're executed.

But you can't count on players having OpenJK, right?

They're not converted to brushes, unless you force them to (e.g. because you want them lightmapped). Which is why converting brushes to ASE models gets around some limitations - that wouldn't work if they were just converted back. There's also a limit to the number of waypoints - 512 I believe, and those don't count towards the entity limit I believe - but few people seem to know how to use them anyway. The number of ROFF files is limited to something like 16 I think, as are vehicle types. (Not vehicle instances per map.) I believe there's also a limit to the number of pk3 files, but I don't exactly remember. You also need to keep the number of portals low - I think there's a hard limit, but it's also a matter of performance: You realistically only need so many. This is about vis portals, not the camera ones. The latter have a limit of only 1 being rendered at the same time - if you can see 2 portals, one won't be rendered correctly.

That's like saying "don't want illegal copies of your game/book/movie? Don't publish it!" It may be true, but that doesn't make those unauthorized copies any less illegal.

And how on earth is that supposed to help?

Just a random guess: Try turning the window into a detail brush, this may be related to vis optimizations.

You can't legally redistribute any images you have no rights to, and you don't since they weren't granted. JKHub may not have a problem with it but that doesn't make it any less illegal.

Well, you have this: rgbGen lightingDiffuseEntity rgbGen const ( 0.000000 0.500000 1.000000 ) //The RGB values - 0, 128, 255 You can only set rgbGen to one value, so the latter overwrites the former. So instead of changing the colour based on diffuse lighting you set a fixed value. I suggest you just copy the texture and tint the image itself.

Bespin.

Just an FYI: I did not read this because it was in an obnoxious red. It doesn't make your text seem more important, it's just ugly.

The only base sky shaders set up to emit light are normallight, bluelight, orangelight, test, test3, right_light, test4, test5, kejim_light, new_test, artus_light, yavin_nodraw, hevil, hoth, siege_1, hevil_2, test_korriban1 and rail_sun. If you use any other shader it's normal to have no light.

I don't know about the model, but his sword has been made. There was a request on the gamefront jk3 forums a while back.

MD3 vertex coordinates must be within [-512, 512[ on all axes.

I'd guess you've scaled the trunk cylinder object down but the md3 exporter you're using doesn't take that into account. Try applying the object scale to the mesh so it's unscaled. Without any information on what you're working with we can't tell you how exactly to do that, obviously.

And you think the modders others have listed did not earn the recognition? Nobody would list somebody if that person didn't get their attention somehow. You should have made it clearer that this thread was for praising the people you named and not for discussing who else deserves praise if that's what you wanted. But since this thread is degenerating quickly I suggest everybody simply creates a page on the wiki for the modders he finds noteworthy and explains their achievements. There's a category for modders which you can add them to by having [[Category:Modders]] in the text. I'll start doing that myself after uni.

Because anything thinner than 1 unit might as well have no thickness at all, i.e. be just a plane.

Darth-Arth deserves a spot on that list, his Mapping Academy got a lot of Germans (including me) into jk2/jka modding. Who was behind map-craft again? Somewhat sad to see Darth Norman no longer on that list, he made great stuff... But not as popular maybe?

Is that GMT? Hmm, I might start something yet... Nah, probably not.

Due to rounding errors the front and back of the brush end up being the same, so the brush is infinitely thin, which is illegal. Just make it thicker, there's no reason for it to be that thin. Remember that brushes can intersect one another without a problem. Just make all the sides/back system/nodraw. And make sure it's a detail brush, obviously.

Wrong. sv_pure 1 causes the game to exclusively load pk3 files, while 0 loads both loose and pk3 files.

Look through your q3map2 log. Chances are it contains lots of texture not found warnings. If q3map2 can't determine a texture's size it assumes a default value which is pretty small (16x16 or something in that order of magnitude, I believe), leading to the kind of incorrect scaling you're experiencing. In order to tell q3map2 where to look for textures you need to set fs_basepath or whatever it was called accordingly.

People know, but pretty much all the forums in which they've written about it are offline now. A lot of information has been lost. The error indicates that q3map2 ran out of memory. You can try compiling with -lomem, trading decreased memory usage for vastly increased compile times, or, if you have a 64 bit operating system, get a 64 bit build of q3map2 that can use more than 2-4gb of memory.

Yeah, that's just an unnecessary source of confusion. In the glm format a vertex can only have one UV coordinate, so if two faces have different uv coordinates at a vertex (i.e. the edge is a seam, a cut in the uv map), that has to be exported as two vertices. But that's really something the exporter could take care of. In general this topic made me realize how unnecessarily complicated the creation of playermodels is - a dedicated tool could make it a lot easier. I have a lot on my hands at the moment but once I'm done with all that I may take a look at creating such a thing, but yes, currently creating playermodels requires a ton of technical knowledge and you have to keep dozens of things in mind.

It's GPL, so it's 100% legal. If the GPL release was legal in the first place.