NAB622

Sure, I can do that! Might take some time, though. Depends on how complicated the brush work is.

That's one possible solution, yes. If you need the edges to be rendered, then you'll have to split the brush up along its length into multiple brushes. The clipper tool can do that for you in seconds.

The cap pieces are the end pieces. Let's say for instance that you made a long, tall column using a 24-sided brush. The top and bottom pieces of that column that contact the floor and the roof are the "Cap" pieces. Those are usually the culprits with this error. I wouldn't worry about any other errors until you have the TW_VERTS error fixed, since a rogue item can cause numerous issues. However, that web page I linked should have just about every error you can have during compile in it - save the link, it's a great reference! MAX_MAP_VISIBILITY is a toughie, though, because even though the cause of the error is always the same, it generally means combing through your work to fix your technique. http://nab622.com/tutorials/MappingErrors.html#compile_time_errors-max_map_visibility

http://nab622.com/tutorials/MappingErrors.html#compile_time_errors-max_tw_verts (It could just be something as simple as running a brush cleanup to fix a corrupt brush.) The node without a volume is just a warning - I wouldn't worry about it unless you see something wrong when the compile is complete. But it is entirely possible the two errors are related: http://nab622.com/tutorials/MappingErrors.html#compile_time_errors-warning_node_without_a_volume__node_with_unbounded_volume__node_has_0_tiny_portals

As far as server.cfg goes, make sure you set both bot_minplayers and sv_maxclients to the appropriate values. Then your addbot command should work correctly.

Couple things here.... The in-game score menu is only able to show 20 players, so if there are more than that, you won't be able to see them there. In the console, type /status to get a full list of all connected players on the server. Second, make sure bot_minplayers and sv_maxclients are both set to the correct value. I just ran mp/ffa1 as a test, with both variables set to 32. The game automatically added 31 bots to the game for a total of 32 players.

How are you launching the server? JA+ servers must be launched by the command line, and you must add the parameter +set fs_game japlus to the command. For instance, if you are using a batch file on Windows: jampDed +set dedicated 2 +set fs_game japlus This will launch the server in a dedicated text-only window, and will launch with japlus enabled.

As for the window breaking, if you want the simplest method, you could easily make the window a func_breakable if you want players to be able to break it. If you want anything more complex than that, like objects flying at the window to break it, you'll need to either make a system of target_delays and a bunch of other goodies, or (Ideally) script it. Now.....having players get pulled towards the window might be tougher than it looks. I think target_push is probably your best bet, but I've never used it before. (I have used trigger_push in the past, but it has a tendency to take control away from the player, so while it would work, the players would not be able to resist the push.)

Is it just on one map, or is it across all maps? Unless your computer is out of RAM, I've never heard of an issue like this before. If it's just on one map file and you don't mind posting the file, I can try loading it on my end to see if it's something inside the map, for what it's worth.

To edit your worldspawn, select any brush that is not part of another entity, and press N. However, given your description, it does not sound like this is your problem. I think the prospective solution you're looking for in the worldspawn is the distancecull property, which will only help if your brush is disappearing over very long distances (Unless you previously edited the distancecull property). I think it's more likely you have a vis-related issue, or possibly a corrupt brush or shader - can you post pictures of what's wrong (The brush before and after disappearing in-game, and maybe the brush on the grid in Radiant)?

No worries! Glad you got it figured out.

Looks like your lightmap compile didn't run, or stopped due to an error. Are you getting any error messages during compile?

After looking at the error again, it seems like it's rendering the texture where the diagonal outlines are supposed to be...have you tried pressing J a few times to cycle through the render settings for outlines? It's hardly a fix, but possibly a decent workaround.

That's weird. I haven't seen that kind of behavior since Radiant 1.3, actually. Have you tried playing with the "ATI Cards with broken drivers" setting in the preferences? Or is it maybe installed in a folder where it conflicts with something else? Other than that, I'm at a loss.....

As I recall, you are correct, models must be outside of a pk3 to be used, preferably located in the base/models folder. The only thing Radiant will load from a pk3 file is textures.

Yeah, there's no reason that should be giving you the error.....Do you mind if I were to take a look at the map file? I might be able to help. From what I'm seeing right now, though, it looks like it just might be light leaking between the rooms somehow.

Any time you have switchable or styled lights, there is a limit of 4 styles on every surface. The only way to exceed that limit is to change the source code and recompile. There are a few things you might be able to do to reduce the number of styles you are using, but I have to ask; are you trying to make rooms with a single switched light per room, like sithcouncilv2, or something more elaborate? There might be some other things going on as well.

Okay. Is there an alpha channel on the texture, then?

Can you post the shader for the affected texture?

The missing assets are likely base JK2 assets. It is unlikely someone will freely upload them to the internet. JO is pretty cheap, though - it's on sale right now for $3.50 on Steam. I remember buying a CD on eBay years ago for pretty cheap, too. It's a really good game - why not just grab a full copy of the game? It's worth it for the single player alone, IMO.

Where is the "Origin" point of that model? Is it in the center, or at one of the sides? If it is inside the brush behind it, q3map2 will cull the model out during compile, and thus it will be invisible. Edit: As far as the missing textures, if you flush and reload models and then flush and reload shaders, it usually fixes the issue, but that might be outdated info.

I know that if you teleport a player above a vehicle, the player will fall onto the vehicle and enter it. Maybe the same will work with NPCs and the emplaced_eweb, but I really don't know.

I'm a little late, sorry. The reason MAX_MAP_VISIBILITY exists is to save the user from loooooong looooong compile times. The more portals you have in your map, the compile will take exponentially longer. Judging by what you've said, it sounds like your map is being sliced up so much by the default blocksize that it has tripped the threshold of portals for this error. It is also possible that your map "Leaks" - and if it does, this can also cause the error. It is always a good idea to load up your .prt file and investigate the root cause of the error. It's pretty easy once you know what you're looking for, and could be as easy as making some brushes detail, adding a few hint brushes, or fixing a few leaks. On compile, a "Portal" brush is generated that encapsulates all enclosed areas of your map, and the blocksize value (Default 1024) is used to break this "Portal" up into manageable sections on every axis. Next, every structural brush in the map is CSG subtracted into these sections. Since the sections are small, it confines any rogue slices to a localized area, which prevents them from generating thousands of unwanted slices all through the map. If your map has a very large, open area, then yes, you will need to increase the blocksize to prevent the blocks themselves from tripping the threshold - but if you change the blocksize to 0, you disable the block slices, and therefore you must make absolutely certain to use hint brushes to prevent your brushwork from making rogue slices all over the map, or this error will likely happen again in the future. And even if it doesn't cause an error, you still may suffer unnecessarily long compile times (VIS compiles should take a few minutes at most). On the other hand, if your map leaks, then when the portal file is generated, it will not know the outer boundaries of your map, and portals will be generated all over the place and then sliced, which is also not good and can throw you over the limit. Hope this helps, as there is a lot of bad info floating around out there...

Protip for the future - any shaders that show the gray and white "Missing texture" will throw an error in the game console. Always check there first to see what's wrong, because things like path issues will be very easy to spot. ?

Ohhh, okay. Yeah, that should be pretty easy to do, if you intend it to involve all players. With some advanced techniques, you can make it so players can choose whether to participate or not - so some people can play a casual FFA chatroom, while others play a TFFA match in a secluded area. But that would be some pretty involved stuff. It would require overriding the spawn system for players, and I'm not sure it could tabulate total team scores reliably. Something for me to think about...