mrwonko

How so?

May or may not work, depending on whether the format has changed since...

You mean the weapons used in first person, which are usually MD3 files? You'd rather use GLM?

Take a misc_model, give it a _remap old/shader/path;new/shader/path property.

Why misc_model_static? Go for misc_model, I'm not aware of any big limitations regarding them (unlike misc_model_static, which should for one count towards the entity limit of 1024) though I never stress tested them. And yes, I too think that you should just use brushes for visibility and physics and go for models otherwise. I'd have to do some research on lightmapped models, but I don't think they're particularly problematic.

https://jkhub.org/files/file/1413-blender-264-jedi-academy-plugin-suite/ There are a lot of things you have to do correctly for it to work. Take a look at the pdf in the archive and at the vehicle modelling tutorial, which covers most things as well: [sharedmedia=tutorials:tutorials:127]

But that's actually one of the main things your importer should handle, it's bound to happen a lot.

No I wouldn't be.

I have no idea what and SBD gun is, but replacing weapon models isn't all that difficult, provided you can model.

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?