Then it's probably what czg said; sometimes items don't like to be too close to solids or other stuff (lost bonus item). 

I recall having a similar issue. I use Radiant. While I've never had an issue with placing items next to each other, if they are next to a wall they will sometimes disappear as mentioned by czg et al. I always place items at least 8 units from the nearest vertical surface. 

Then i guess its just a fact of life, then. I just thought that there was some way to get around it. Away from the walls, they go! 

In Quake 2 you can rotate items just by setting the angle key, but in Quake, this doesn't work - everything just appears axially aligned. However, I know that it is possible to rotate item boxes because I've seen it done in several maps before - notably one of Neg!kes speedmaps that ends in an underwater tunnel with lots of boxes rotated at funny angles.

How is it done? From memory I thought it was done by giving the item an angles key with pitch yaw roll values.

Please tell me!

By the way, is the fact monsters won't shoot through transparent water a reason any of you sp mappers would consider not vising for transparent water? It's really lame when you can just hide 1 ft underwater and pick off all the monsters without them firing a single shot.

As for the item problem ray is experiencing - it sucks indeed. If you desparately want the boxes next to each other, perhaps you could try placing them staggered above each other so that they are not touching until Quake drops them to the floor. I've no idea if this works though ;) 

yes, items can be rotated either with "angle x" or "angles x y z". the latter was used in said speedmap. though rotation does not prevent them from dropping out if they are too close to a wall, and one has to experiment a bit with their location. it's their bounding boxes that matter here again (same with walkmonster in wall issues).
items can touch other items without problems, they can even be spawned within each other (same origins). they cannot touch monsters, however, and if you place them above the monster, they will drop on its head and stay floating in mid-air when the monster moves away.

than: that sucks a little, yeah. but then again it's not that much of a problem, i guess. opaque water should mainly be considered in terms of vis blocking or visual aspects. 

Yes, I would consider not using transparent water in that case. However, that would of course depend on the balance between how enhanced the visuals are and how much combat can take place in that spot. 

"TexMgr_ReloadImage: can't colormap a non src_indexed texture: lightmap02"

I get this notification (twice) in fitzquake when loading my map. The map loads and plays without problems. What is the meaning of this warning?

I also launched the map in Bengt's glquake and in joequake-gl and I don't get such error. 

the error message is newly introduced in fitzquake 0.80. Would you mind uploading your bsp, or emailing to me, so that I can examine it?

I'm pretty sure it's a bug in fitzquake and not a bug in your map. 

I can't send you the bsp right now for some reasons. Maybe in few weeks.
Thanks for the info. 

running across the same problems ATM with item boxes; like in my last map I'm rotating them all randomly to give that more natural feel instead of a load of regimented nail packs sat in rows - it's bad enough that demons and hellknights helpfully leave bundles of shotgun shells lying around anway just in case a slipgater blunders into the place.

The only way I've found is to playtest and make a long list (ie. handwritten) of what's missing / intersecting with other stuff.

For now it's just 16WC units from anything else and testing in a dummy map before cop/paste into the final version when they have to be close together or near a wall. 

In my case, since the map in question will have its own progs, I put some code in PlaceItem() in items.qc that, if the item has a certain xadjust or yadjust flag, it will set the x or y origin plus or minus 16 units. Just needs to be called after droptofloor() obviously. Doesn't appear to be a workaround for standard progs though. :( 

Or did I once have a texture set with a dinosaur fossil in it? Has anyone seen one?

Thx. 

Have you tried looking in Rogue? It seems like there are some archaeological textures in there. 

Yep and nope :(

I was thinking it was in the Heretic or Hexen tex's, but no luck there either.

Has anyone seen a lost dinosaur fossil texture anywhere? 

in clay mud, but I don't remember where. 

Head knows what I am talking about :)

I just wish I could remember which flippin' WAD it was from! 

sin.wad! 

Possibly.

Can you send it to me?

Thx. 

I found a small bug in your engine. I usually load my map in your engine by using shortcut with +map command. I get no warnings. So I missed the moment when I got over one limit. I noticed it only when I changed the skill and loaded map with map command in console. I got a warning:

SV_CreateBaseLine: excessive signon buffer size (9202, normal max = 7998)

What is it? And can you fix that warning messages bug in your new version? 

If you changed skill (typically to a higher skill) and reloaded the map, the amount of monsters/items usually increases. That's why you now get that warning; doing the same procedure in a normal engine would probably throw you out with a SZ_GetSpace ... error.

If you don't specify any skill at startup, the default is 1 (Normal).

Or am I missing something here? 

kind of re-inspired by the forcefield discussion:
is it possible to create a nonsolid wall (like func_illusionary) that is not treated like a static entity, so it can be removed with killtarget (info_notnull hack or something)? 

Yeah, this is possible. The basic method can be found in post 36 in here:
http://www.celephais.net/board/view_thread.php?id=37116&start=26&end=50
The example there looks like it would create a player model, but actually what matters is the modelindex n.

So if you set n to be the modelindex of an existing brush entity, you'll get a copy of that brush entity as a non solid removable info_notnull at the desired point. If you want to use an original brush model, one that isn't already in the map, you'll have to add it in as a func_wall somewhere, then remove the func_wall from the entity list after you've compiled the map. Probably easier to just leave the model in the map hidden unless you're pushed for entities. 

thanks! 

would that also work for moving entities - like a nonsolid door, for instance? 

Yeah, you could do that, but you'd only want to do it for simple, non linked doors. Well, I say that, but linked doors would really only be a matter of filling in more fields manually.

Basically to do it, just look at the func_door code in doors.qc, and imagine that running on your info_notnull. Then manually set all the fields to the values they would get. So for instance set

touch door_touch
use door_use
...

Although touch is actually a bad example as you don't need it here. Add any sounds you want, assuming they're precached elsewhere. Don't set think or nextthink, as you need them to set up the model. Also, don't set SOLID_BSP or MOVETYPE_PUSH, the former for the obvious reason, and the latter since it assumes SOLID_BSP. MOVETYPE_NOCLIP should work fine although I've not tested this.

Since you can't use think, you won't get a call to LinkDoors, as I alluded to above. But you can use the same trick about imagining running the LinkDoors function on some entities that should be linked and then manually setting what you would get. This involves manually creating a chain of entities in the enemy field, but refering to each component in the door by it's entity number. Ouch. So don't do that unless you really have to, and even then, probably easier to start with real doors, run the map, dump the in game entity info into a text file, then convert the entities to info_notnull, feed this info in and recompile.

Skipping the LinkDoors function means you also don't get the automatically generated trigger that surrounds it to open it. The easy fix here is just make it so your "door" is triggered by a trigger_once or trigger_multiple so it doesn't matter. You'll also need to set the enemy and owner fields to be the door itself in the simple unlinked case - remember that these fields expect an entity number, not a targetname.

Looking at this bit of code has also given me another exciting idea, but I'm gonna work on it and post it in the new tricks thread. This assumes it pans out...