Are they by any chance next to walls, since WC has a problem, where the in editor placement is actually 16 units off of the actual placement on both the horizontal axis. 

I think metlslime or somebody has a fixed .fgd. In the mean time, try putting the lower-left corner of each box where you want its center should be. 

yeah tried somethin like that, dunno, i just totally re-arranged the item placement.

expect PH8DM1 to be up tonight. it was originally my coagula map but i just pulled it all from my ass and had no idea where it was going but it makes a decent DM.

Heh.. 

i thought they "fall" through stuff. i had it when using the same map for q1 and q2 (same rmf, different textures and compilers). never had it otherwise... 

Is this possible? How? 

I mean when a monster is killed, lets say it drops an item such as ammo or a key, etc. 

There's a way to do some dropping but not all using just the map editor. Grunts, ogres and enforcers drop backpacks, which means you can give them anything that gets passed on from players through backpacks: weapons and ammo. Unfortunately, these monsters directly set the amount of ammo they have for their own weapon, so there are certain ammo's you can't set for certain monsters.

Grunts can carry any ammo except shells (they will invariably have 5 shells in their backpack no matter what you set it to).
Enforcers can carry any ammo except cells.
Ogres can carry any ammo except rockets.
To set the ammo values, use these:
ammo_shells
ammo_nails
ammo_rockets
ammo_cells

The 3 monsters can carry any weapon you want:
float IT_AXE = 4096;
float IT_SHOTGUN = 1;
float IT_SUPER_SHOTGUN = 2;
float IT_NAILGUN = 4;
float IT_SUPER_NAILGUN = 8;
float IT_GRENADE_LAUNCHER = 16;
float IT_ROCKET_LAUNCHER = 32;
float IT_LIGHTNING = 64;

Simply set the monster's "weapon" value to the number you want (note that in most mods dropping an axe or shotgun is pointless...).

Unfortunately, if you want to drop keys, runes, or other tidbits, or you want any monster to be able to drop them, you're going to have to edit the QC code so that the drop backpack function in items.qc includes keys and runes for monster deaths (or preferrably creates another dropped item that looks like the key, so that it's not hidden in a backpack!). You'll also want to make sure that your dropped key will never delete itself or dissapear... 

I know nothing about C++ much less Quake C, lol. Oh well, I'll just.. figure an alternative. 

http://jmap.web1000.com/temp/dropit.htm 

Does anybody know where can I find dinosaur age themed textures or anything like that (cave textures, stones, bones, swamp, etc)
I've got some ideas about Q1DM map and need some textures for it. 

Would the "Tomb Raider" textures on Fatty's site be of any help? 

There's one thing I still don't get about BSP's, and it's really a shame to ask this after 4 or 5 years mapping, but

I still don't know how to make CLIPs. CLIPS WITHOUT A BRUSH. I can't believe that every mapper that use clips manipulate the .map files manually or tell QBSP to skip leafs or Idonno. Almost everyone knows how to separate a clip from its brush but me. And it's very embarassing, coz I know that it's a mostly basic thing in mapping.

Please help!! 

Thanx. I'll take a look 

if doing a -fast on vis is fast, and a -level 4 is slow, than it stands to reason that a -level 1 should be faster than -fast but slower than -level 4.

well, doing a -level 1 on my map gives an estimate of 298 hours (!), whilst a -level 3 gives an estimate of 6.5 hours.

i'm not really seeing the logic here... any reasons?

i'm using aguiRe's modified RVis+ 

one more thing, and this question is directed to aguiRe... why do the percentages sometimes jump back down... for instance:
Full: 36.0%, Elapsed: 17:37, Left: 1:03:38, Total: 1:21:15, 21%
Full: 37.0%, Elapsed: 20:27, Left: 1:43:15, Total: 2:03:42, 16%
Full: 38.0%, Elapsed: 21:41, Left: 1:42:59, Total: 2:04:40, 17%
Full: 39.0%, Elapsed: 22:57, Left: 1:48:26, Total: 2:11:23, 17%
Full: 40.0%, Elapsed: 24:54, Left: 1:29:00, Total: 1:53:54, 21%
Full: 41.0%, Elapsed: 27:28, Left: 1:53:44, Total: 2:21:12, 19%
Full: 42.0%, Elapsed: 30:09, Left: 2:19:12, Total: 2:49:21, 17%
Full: 43.0%, Elapsed: 33:48, Left: 2:49:06, Total: 3:22:54, 16% 

Well, I'm not aguiRe, but it's because the time remaining is only an estimate. The first percentage is like normal rvis+, the second percentage is the how much of the total estimated compile time has elapsed. When the estimate gets updated, this percentage figure jumps around with it. 

It sounds like you are confused about what clip brushes are.

A clip brush is just a brush that has the clip texture applied to all it's faces. When the map is compiled, this brush will be invisible, but you won't be able to walk through it. You can shoot through it though.

The things you are saying above don't make sense. 

If your talking Q1 or Half-Life, clip is simply a texture whose filename is
clip

Apply that to all faces of a brush and presto!
Just make sure you use the clip texture that appears in all wads by default. The id clip texture looks like this:

http://www.signsofkoth.co.uk/clip.jpg 

Tyrann's right about the 2nd percent figure depending on the current estimation. This in turn is updated when the integer part of the 1st percent figure changes (e.g. when 40.6 becomes 41.3).

It may seem confusing at first, but that 2nd percent figure (which may go up or down) is the most important number on the line, since it's a clear indication of how the process advances.

Usually, the vis process is fast in the beginning and then slows down more or less during its lifespan. Therefore the estimation is more accurate in the later stages (unfortunately).

As for different vis levels behaving strangely, I've seen that as well. Sometimes I've seen vis got stuck completely when using "unusual" levels (1-3). Therefore I strongly recommend only using fast and level 4 for normal operation.

If level 4 is too slow (298 hours *is* slow ...) and you won't settle for fast vis (which is recommended for maps with very open nature), then I suggest looking for the standard methods; vis blockers, func_walls for detail brushes etc.

With my version of RVis you have an extra indicator "max leafs visible" for help tracking down spots with high r_speeds. Normally, the long vis processing times can be *significantly* reduced by doing some small changes to the map and with only minor appearance effects.

Remember, long vis processing times is normally an indication of vis failing completely, not that it will do a good job. If you don't want to change the map, then settle for fast vis or even *no* vis if the map is open enough, i.e. arena-like.

If you need help with the map, just let me know. 

Elaborate - what's the advantage? 

Detail refers to any solid, visible architecture ( so that exculdes clip and triggers ) that doesn't complicate the compile process' divisions of the 2D surfaces and 3D spaces.

Example:
If you have a flat wall with a thin light fixture ( like the square plate with a gothic cross light ) then the wall, despite being only a single brush, will be fragmented into several surfaces around the light fixture. Also, volume of space around that feature will be divided up into several smaller volumes to fit around the protruding metal plate.
By making the light fixture 'detail' it no longer interupts the compiler's cutting-up of your .map, so it can use far fewer surfaces; the wall might consequently be made of only 2 or even 1 surface.

Quake 2 and 3 both have detail as an option; Quake 1 and Half-Life do not.
Using proper Q2/3 detail makes the light fixture solid to movement and lighting, but invisible to the division process.
In Q1 and HL, you can get a similar effect by making the light fixture a func_wall. This is because brush entities do not interupt the dividing up of you map during compile: they don't vis block.
Doing this has 3 drawbacks though -
1. They don't block vis, which can be a problem with some features/layouts.
2. Brush entities, including func_walls, do not stop light during the compile. So the wall mounted light fixture wont have a nifty shadow around it :(
3. There's a limit to how many brush and point entities you can have in a map, including how large they are. I discovered this to my cost when building Part III of Contract Revoked, what with all them teleporters. I believe CZG used a lot of func_walls for detail in, IIRC, Insomnia. 

is there a fgd (is that the right name? me forgets) so i can do some heretic2 mapping in Worldcraft v1.6?? 

If level 4 is too slow (298 hours *is* slow ...) and you won't settle for fast vis (which is recommended for maps with very open nature), then I suggest looking for the standard methods; vis blockers, func_walls for detail brushes etc.

actually, it's the other way around... the level 1 estimation was 298 hours, i just completed a level 3 vis and it took 8 1/2 hours... that's mostly what i was trying to understand-- how a lower level vis could take longer than a higher level one.

thanks for the other explanations though. :) 

vis works by flowing through the level from each leaf -- sort of like the paint bucket tool in a paint prog, except that it does line of sight tests as it flows.

higher vis level settings will make the line of sight tests more stringent, which takes longer per test, but it also means that the test is more likely to fail. The sooner vis decides you can't see down a certain winding hallway, the sooner it can stop flowing down that hallway. This is how higher vis levels can sometimes be faster. 

thanks, metlslime. that cleared it up nicely. :)