mrwonko

Just don't ever use spawnflags 2. Automatic conversion from models into brushes is terrible - you get one brush for each face, and that's way too many.

It's just a simple model format into which Q3Map2 can convert your map so it's convenient for Radiant-created models. Models lack a lot of the features of brushes and patches - most notably lightmaps and collision - but can have finer detail than brush geometry and are scalable. Sometimes you want to use models for performance reasons or because you run into brush-related limits - e.g. having lots of patches (like a detailed round room) can decrease performance, presumably due to the amount of calculations necessary for collision detection. I had such a case and I improved it by turning the room into an .ase model and creating simplified collision objects. No, it lacks top and bottom. But you can use a script to create a cutscene that positions the camera correctly for skybox screenshots at your current position.

The model has to use the _humanoid skeleton. There's a german tutorial on http://mrwonko.de/tutorials/player_modelling_tut.htm, the images may be of help.

Just placing waypoints too far off the ground turns them into flying ones, if memory serves. That, or they drop to the floor and you have to change some setting. Either way, use "nav show all" in the console in singleplayer to see how it turned out - yellow waypoints are ordinary ones, blue ones are flying ones, if memory serves.

Nope: { "nonopaque", 0, S_CONT_OPAQUE, 0, 0, C_TRANSLUCENT, 0 }, /* setting trans ok? */ /* all translucent brushes that aren't specifically made structural will be detail */ if ( ( compileFlags & C_TRANSLUCENT ) && !( compileFlags & C_STRUCTURAL ) ) { compileFlags |= C_DETAIL; }

Whose parm1 are you checking? Shouldn't the whole check be inside the affect duel7_tele_parm block?

QUAKED info_player_start (1 0 0) (-16 -16 -24) (16 16 32) KEEP_PREV DROPTOFLOOR x x x STUN_BATON NOWEAPON xFrom sp_entities.def. Spawnflags 64 is NOWEAPON. But yes, in MP you probably can't do that without a mod.

If memory serves info_player_start has a spawnflag to start without any weapons, including the saber.

Given how the glm format works that must've either been the editor's fault or yours. Maybe you inserted when you should've overwritten, or accidentally deleted something?

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.