mrwonko

How about upgrading to 1.04?

Could you elaborate on this? Are you thinking about an extra file per face state? Maybe you can ignore the depth? The only thing that causes outward movement on your faces is blowing out one's cheeks, right?

You rarely need more than one waypoint_navgoal. Just have a proper waypoint net. And the only thing that needs to go into a dowait task is SET_NAVGOAL, since that's the only way to wait for him to finish. But since you don't want to wait for that anyway you don't need a task at all.

Since Jedi Academy itself is Open Source, OpenJK is no less insecure. To the contrary, exploits are actively being fixed while nobody patches Jedi Academy itself anymore. Find out how your server got crashed (e.g. by running a packet sniffer) and relay that information to the OpenJK team and I'm sure they'll fix it.

I browse with 7 zip, but I have most of them unpacked into base so I just used windows search.

A search for "eweb" in the models folder did the trick - models/map_objects/hoth/eweb_model.glm

Related to that: I hope to learn to take the time to write my knowledge down for JKHub. In general I want to learn to work better, I don't get enough done.

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.