mrwonko

Your map's size is too damn high. It needs too much memory to compile the light stage. -lomem is one thing that may help, or if you have a 64 bit operating system you can try a 64 bit Q3Map2 build which can handle more than 2GB ram. Also, maybe don't do -super 2, that's 2x super-sampling, which calculates every lightmap at twice the height and twice the width for 4x the memory usage. The downside of lomem is increased compile time. Maybe try -fast or -faster for faster compiles at the cost of decreased quality.

Oh I just have this hunch that the game wasn't meant to have grass models with 30K vertices and 20K triangles placed once per square meter... Call it intuition. Also, the model is untextured and has no UV map. I suggest you use surfacesprites for your grass needs, but hey, it's up to you.

Q3Map2 can handle .3ds models just fine as far as I'm aware, given the texture paths are relative. That model looks a good deal too complex though.

It's necessary, called t-junctions. There's a Q3Map2 switch, -notjunc or some such, to disable it, but that can lead to visual anomalies. The reason are rounding errors in interpolating the edges, leading to 1-pixel-wide gaps between trianges, like so.

The plugin is untested in Blender 2.7 and may not work. Try 2.69.

When you say that it sounds like you really should read the shader manual lol.

Shaders are pretty close to how graphics hardware works - or used to work 10 years ago, it learned some new tricks since then. You'll basically want to learn about blending (see glBlendFunc), the depth buffer (or z-buffer) and how it doesn't support transparency very well (which explains why you see so much blendFunc GL_ONE GL_ONE in shaders and what depthWrite and depthFunc are all about and kind of plays into alphaFunc as well) and then it's just a matter of understanding that all the stages in a shader are drawn in sequence. And it helps to know about vertex colors and understand that they can be used for lighting (which is particularly used in misc_model without spawnflag 4) or blending (for alpha-blended terrain). Well, and then there's surfaceparms and q3map2 specific keywords and a couple of other things, but understanding how the stages work is the most important part.

A unit is roughly an inch.

To add bot support, join their team to get access to its source code, without which it's impossible. The "simplest" thing I can imagine is still pretty hard: Port over the singleplayer's pathfinding, which is superior to the multiplayer's and should be a good foundation. Will still need quite some work afterwards, but nowhere as much. They won't want to do that though because the singleplayer code is GPL-licensed, so they'd have to make their code open source were they to use parts of it. Anyway, begin by learning C and probably some C++. I'm not sure about scaling, but I believe the answer is the same: You need access to the code.

I have no idea how 3dsmax's exporter works, and it completely depends on that.

\ vs / may matter in some cases, you should use /. And the paths need to be relative to GameData/base/, so you don't want something like C:/Program.../base/models/map_objects/mymap/foo.jpg, just map_objects/mymap/foo.jpg. The texture has to have width and height that are powers of 2 (e.g. 512*256) and if it's jpg it mustn't be progressive.

Define prefabs.

To determine what is visible from where, the map is split into small areas, and then visibility between them is calculated. These areas are created using the structural (i.e. non-detail) brushes. So a many-sided brush will create lots of areas. MAX_MAP_VISIBILITY means you have too many of these areas. You don't want many small areas anyway - one area per room is usually sufficient. Which is why you just want very simple, straight walls and floor for each room, and pretty much no detail whatsoever. Maybe I could do the necessary repairs for you... Is the version you sent me the most recent one? Can I go ahead and edit it, then send it back? It's missing a couple of textures, by the way:

You need to be waaaay more aggressive with the use of detail brushes. You can press Ctrl+D to hide detail brushes, Ctrl+P to hide Patches, and Alt+2 to hide entities. That will leave you with just the structural brushes as they're considered by vis. Now ask yourself: Is this basically an empty room with plain, probably perpendicular walls? If no, it's likely more complex than necessary. Take that spiral staircase: First of all, You definitely don't want every single step to be structural - do you have any idea how many portals that's going to create? The number is too damn high. And secondly, the room itself is round - but as far as visibility is concerned you really only need a cuboid. The 12-sided brush in the center doesn't help, either, contrariwise. Well, just let me make a couple of screenshots... Other things: There are quite some broken brushes and patches, which you should get a warning about on compiling, in 1.6 and 1.4 anywayThe Area Portal texture must only be applied to one side of the brush, the rest ought to be system/skipDon't worry about Entity Leaked, that happens whenever an entity is inside a brush but in the case of models at least that's not a problem - Map Leaked is the bad leak

It would be much easier if you just uploaded the map for us to take a look at.

Just setting a target and a wait sucks. Use target2 and a toggle door instead.

It's up to the exporter. It may or may not support tags and if it does it can do them however it wants. Consults the documentation. (Judging from the download page which makes no mention of tags I'd say it may not support them.)

How about you supply a model for us to reproduce it with? In general, it's not necessarily a problem with the model, MD3View doesn't support MD3 quite correctly, if stuff is not in the expected order it gets confused (but the format totally supports this).

Feel free to share a map where such a problem exists and we can tell you why it's happening.

If you just have a func_door with no targetname a trigger for opening and closing it will automatically be created, no need to do anything else. If you want to place the trigger manually (and again, you usually don't need to) use a trigger_multiple and set both the target and the target2 to the func_door's targetname.

Sounds very much like a UV problem. There may be a face with no UV Map, or a face with less than 3 vertices, but the latter should be impossible...

Properly unpack the models folder into GameData/Base. In order to be able to load a .glm it is REQUIRED to load the gla. The two belong together. Since the .gla name referenced in the .glm is relative to GameData/*/ (it has to be), the importer needs to be able to find GameData in the path and the .gla in the same folder as the .glm - usually .../GameData/base/models/players/_humanoid/_humanoid.gla. Also, read the manual that's included in the .zip file.

I would imagine that to be in some way related to normals, though I can't tell how exactly. Maybe they're facing the wrong direction and the material is two-sided?

By the way, does this forum have an ignore option?

The game needs to be able to figure out where the path ends. To figure that out it looks for the first null-byte. Since there is no null-button on your keyboard you'll need to set the raw value, which is possible in a hex editor.