mrwonko

Are there any sorting issues? That shader looks like it would lead to distant surfaces sometimes being rendered in front of nearby ones...

I vaguely remember once experimenting with moving dynamic lights, but I don't remember if that was some entity property on a func_something or by attaching a misc_flight... I just remember that it looked pretty bad.

Kind of... Not very active these days, I'm a bit tired of explaining the same things over and over again. (Generally. I'm not talking about this specifically.) So I mostly lurk these days.

How exactly do you want to play them? As an animated texture? Do you have the necessary shader?

Yeah. Don't use it, you get way too many clip brushes that way. (Unless we're talking about terrain models with large faces.)

Select the skeleton and go into pose mode to preview your animations in Blender. You'll notice that the head doesn't move as you pose the bones. It doesn't have the correct skeleton selected in its skin modifier. I don't see how this explains the problems you're having though. It works in ModView, it references the correct gla file...

The other way around.

I suggest instead attaching a scaled misc_model to the func_useable using target/targetname.

Areaportals are for doors, their VIS-visibility is toggled when the door opens. Antiportals are always opaque to VIS (albeit not rendered in-game). I imagine as you enter a two-sided antiportal, the world behind you vanishes (while you still can't see in front of you), then as you emerge on the other side, that half of the world pops into existence.

Keep in mind that this only makes sense if you properly use detail brushes or have models you want to block VIS.

Well, keep in mind that visibility is offline in idTech3, so everything behind it is only approximately invisible. I'm not sure there are any in-depth tutorials on antiportals in particular, but I recommend just learning about VIS in general.

Take a brush, put system/skip on all sides except the one with antiportal on it. The brush will not be included in the bsp and thus won't be visible ingame, but will be taken into account during VIS calculation, i.e. leafs on the opposite side won't be rendered. As far as I understand misc_models are stored as trisoups in the bsp and can thus only be completely visible or invisible, unless you forcemeta them using spawnflags 4 or an appropriate shader.

The easiest way to investigate this is probably if you upload the model (.blend) for us to look at, if I find something I could record a video explaining the problems.

Is this in Radiant only or also ingame? I have an inkling that it may be due to texture filtering, in which case it would only be in Radiant and may be fixable by changing the filtering mode (not sure where you can do that, but the options should include something like Bilinear and Trilinear). Maybe upload a sample so we can check what it looks like for us?

An entity consisting solely of system/origin doesn't work because during compilation that brush is removed and only its location is used, resulting in an entity without a model, which is illegal. Add a small system/nodraw brush to it as well, which won't be removed.

Read the plugin's manual, it describes how it works. In particular how it finds the model by searching for model_root_0, which in your case has no children, leading to an empty model.

I made this comic about that kind of thing. It's not going to stop, you won't be able to police it, especially not outside JKHub, so stop caring so much. You're not getting paid for your mods anyway, and while I get that recognition/appreciation is nice, most people won't actually look into who made something let alone go out of their way to thank them, so it really doesn't make much of a difference. That's how I feel about it, anyway. You're free to feel different, obviously, but I don't think it'll do you any good.

You basically want the waypoint network to span your entire map so NPCs know how to walk from one end to the other. Try "nav show all" in the console in SP to see whether they connect properly (they don't if there's an obstacle, for example).

Read the errors, fix them. Then realize VS2010 has a super outdated compiler and get VS2015.

You basically got it, http://www.simonoc.com/. I never knew him as sock, interesting... He's on twitter, too.

Open the model in modview and make sure the surface names match the ones in the skin file.

JK2 models work in JK3 out of the box.

One of Sith-j's, I think... Sunset over Coruscant or somesuch. --edit-- Oh well, close enough.

No, this is actually only the case for model_root_0 or whatever the root in the hierarchy is called, everything below that is traversed automatically and the _0 suffix is just a convention used on import. For export only the properties count. The name of the mesh is irrelevant as well, only the g2 property counts.

The g2_ prefixed properties are for GLM export, md3shader is for md3 export. I sadly don't have time to look at your model, but that's an exceptionally unhelpful error message.