That's weird, but if there is nothing actually wrong with the map and the alignments are "fixed" to look correct in this editor, will they still look right when seen in the game? 

OK. All the .map file texture info has to be passed on to a compiler before the map becomes a .bsp.

Now, the modern compilers we use support Half-Life texture protocol (because awesome people made us awesome tools since '96).

The original id1 .map sources have id1 texture protocol info inside them. If you compile those sources with a COMPILER then they will come out just fine.

BUT

If you load those sources into WC3.3, it doesn't know how to handle the id1 texture info, so all of the textures just become misaligned, or aligned to a 0,0,0 world grid.

If you then export a new .map file from WC3.3, then you are overwriting the original source. Just to clarify, when you import a .map file into WC3.3 you are changing it's format to .rmf. WC3.3 has to export from .rmf format, back into .map format so you have something which the compilers can then make into a .bsp.

The reason for WC3.3 having different texture protocol is because it allows a much more functional texture-lock feature (i.e. the texture lock actually works(!)). 

If you use 1996 vanilla qbsp.exe to compile your map, and it is id1 texture protocol, it will work fine.

If you use 1996 vanilla qbsp to compile a WC3.3 .map, it will throw an error (Erk! I dont understand Valve220 texture protocol)

If you use Y2K+ qbsp (e.g. txqbsp, treeqbsp, hmap2 etc), then they look FIRST at what the protocol is, and then they will compile accordingly. 

1) Install WC1.6a, and WC3.3.

2) Load an original .map file into 1.6a

3) Save it as .rmf

4) Load then new .rmf into WC3.3

5) Have a look at the textures in the map

Are they still misaligned?

I don't know the answer to that question, hence the need for the experiment. 

Above steps worked Ricky, thanks :)
Couldn't install wc1.6a on win7 though. 

256 Models exceeds standard limit of 256.

My current map just generated this error.

4820 brushes, 1476 entities.

Exactly which entities count toward this limit?
Is it only brush based entities like doors and such or does it include some of the point entities like path_corner or trigger_relay.

I don't have a lot of doors and lifts, but there's a lot of triggers and counters and relays. 

Triggers
Buttons
Doors
Trains
Func_walls

Basically anything which is an entity, which is made from brushes.

I think that func_illusinaries are NOT classed as models, but I could be wrong.

I think that the map also counts as one.

I forget.

Fitzquake 0.85, Darkplaces, AGlQuake, DirectQ etc all allow for more than 256 bmodels. My current map has well over 500 ;) 

every entity made out of brushes in your map is a unique model and counts towards the total. This even includes triggers since they have a brush.

On top of that, every unique external model file used by the level (*.mdl, *.spr, and *.bsp for the ammo boses) is counted once. So 10 ogres that use ogre.mdl, will only count once. (But then there is the ogre head too, so that's two unique models.) 

for func_wall or func_illusionary etc bmodels, you can have multiple brushes inside the single entity. So for example if you have say 20 brushes in a room that you want to be func_illusionary, you can select them all and create a single func_illusionary that will count as 1 bmodel. Instead of 20 seperate func_illusionary that will count as 20 bmodels. 

Thanks metlslime and RickyT23.

I was confused because bspinfo was telling me 193 and I thought I was safe.

I just now added up all the brush based entities, including illusionaries and one worldspawn (as reported in Netradiant) and I get a total of 193. The difference is obviously the monster/ammo/item models. I would assume the torches count also (one per type?).

And thanks Daz, that's a good tip. I should be able to trim the count a little bit by doing that.

I know it's not a real problem to exceed this particular limit, but I'm trying to avoid it if I can. 

When adding multiple brushes to a single func entity, visibility has to be taken into account. For sometimes, if a good portion of such a func is in a vis-blocked area, it's possible that the whole entity disappears when looking at some of its brushes from a certain angle (outside the room). At other times, it may just render everything regardless of the surroundings.

Multiple-brush illusionaries can easily cause "too many efrags" warnings, so you may want to make sure they are not too far apart. 

"When adding multiple brushes to a single func entity, visibility has to be taken into account."

Yep, I ran into this problem trying to group some DM spawn pads into one func_wall. In some spots they would disappear even though they were in plain sight.

Oh well. I was still able to eliminate a lot of models just due to re-evaluating how I was doing things and combining some stuff.

Also, last night I was testing with Reaperbots and got a Movetype_push error. I did a little checking and found a bunch (like 5 or 6) brush entities with no brushes. I'm not sure where they came from but I don't think I put them there. I suspect some bug or quirk in Netradiant or possibly I'm doing something wrong.

Anyway, that freed up a few more models, so now I'm down to 239 total which will hopefully leave enough to finish this map. 

Yes, sometimes Radiant doesn't delete the entity correctly when deleting the brush. No idea when then happens, or if a certain action has to precede it. There's an "ungroup" option. Such rogue entities can be removed by going through the entity list (L) and looking for brush-based entities without a ">" icon next to it.

Bengt Jardrup's engines and possibly Fitzquake show a warning in developer mode if such an issue is present. 

Sometimes. IT allows you to select the problematic entities via the 'check for problems' dialogue, then I just delete them with the delete key :D 

It happens when you add a brush entity to another (combining them). Doesn't happen when you just add brushes to an entity. 

Modern engine should fix the flicker problem with large func_s. It was disussed and solved at i3d, I think, long ago. 

Is it possible to have a monster clip or any way to contain monsters to a specified area? In Quoth or with engine mods maybe? 

A trigger monsterjump will do it, with low values.

There are a few other, possibly cleaner hacks that can do it - for example cutting a 16 unit trench in the floor, then filling it with a func_illusionary will stop monsters from walking over it, since it interrupts their navigation. 

My skies end up solid, i.e., rockets explode! What could be wrong? I use tools from http://user.tninet.se/~xir870k/ and GTKRadiant 1.5.0. 

Oddly knights, hellknights and dogs walk over even a 32 width x 32 depth gap, even though they don't walk down a 32 high ledge.

Trigger_monsterjump 10\10 does the job, but they get stuck for a bit. 

I was only remembering, now we use progs for that sort of stuff.

Want an (unpaid) job?

http://icculus.org/remakequake/forum/index.php

If not, then your only recourse is an altered progs - no doubt Preach knows a decent way of doing things in id1. I managed it once under Quoth, but as I remember it was very limited and only with melee enemies. 

I think that's an engine issue. 

Nonsolid sky: Txqbsp does it automatically, Treeqbsp needs the -transsky switch for it to work.

'Monsterclip': Low trigger_monsterjump works just fine, but 10/10 sounds a tad low. Experiment with the values - so that the monsters don't get stuck, but don't visibly jump, either. It's not a perfect solution, but it does the job. 

I guess I should have tested it in another client as it seems that DarkPlaces always have solid skies :(

Btw whats the difference between Txqbsp and Treeqbsp and when is one preferred over the other? 

first, i'd use neither, unless you are talking about aguirre's versions of those compilers. second, txqbsp is better iirc, since aguirre spent more time on it. i've noticed it seems to handle complex brushwork better but that's nothing concrete.