odd because i usually put item_* 0 units off the floor.

are you using worldcraft? maybe you need the fixed entities list thing. 

Has anyone tried adding spawnflags to an entity in WorldCraft/Hammer beyond 2048? (i.e., 4096, 8192 and upwards).

It doesn't seem to want to store them (even though it has checkboxes for them). 

I like your nickname 

... if you are using WC replace your existing quake.fgd with this http://www.planetquake.com/greyvoid/Quake.fgd

This will solve all sorts of problems 

I use GYKRadiant. It just never occured to me that the entity file in radiant is well commented. 

Thanks. 

Is it safe to change the fgd file in worldraft when working on an almost done map? 

But if you're feeling insecure just take a backup of your old one before you replace it. (Or just make your Quake configuration in Worldcraft use the new fgd.) 

I do it constantly in Hammer with no ill effects, older versions of worldcraft may be different. 

I have a problem.

I was trying to make a map for the 1000 brush pak and was therefore using the Dkte3.wad. However, after saving the unfinished map whenever I tried to load it, I got a 'Couldn't load wad file...' error, which crashes the editor.

By trial and error over several days I found that the map file was(still is) being saved with an empty line immediately following the line '//BSPFAVORITES0010'. On older maps, I notice that listed on the line should be the texture names of ten favourites e.g.
//BSPFAVORITES0010
//A_LAVA1;A_WATER1;A_WATER2A;ARCH01;ARCH02;ARCH04;ARCH05;ARCH1;ARCH1_B;ARCH1_R. I am assuming therefore, that the editor 'knows' that as the commented line says there are ten favourites, their names will be found on the following line, which will enable the editor to display said favourites in the textre window. On not finding them, it gives up the ghost.

Does anyone know what setting I may have inadvertantly changed? Has anyone seen a similar problem in other editors? Can anyone help?

It has taken so long to discover this that I have missed the 1000 Brush Map deadline. I now have to save my work less often, which for me means less compiling, and then edit the map file in TextPad before I can re-load it into the editor. Most frustrating and begining to wear a bit thin.

The editor was written by Yahn Bernier. 

the answer, but after inspecting some other maps made by BSP, the favorites line doesn't seem to require 10 items, they could be less.

I believe Tyrann is the expert on BSP here. I have the editor installed so I could see if I could reproduce the behaviour if you send me the map. 

Favourite/favorite: bloody hell!

At least I can now see the FavoUrite setting in Bsp.ini that I could not find before - our friends across the water use American whereas I stick to plain English!

What this has shown me is that regardless of the setting, Quake101.wad works fine as do plenty of other wads. Dkte3.wad appears to be the culprit: I have found several other wads that give the same problem.

What I cannot see at the moment is what the difference is to BspEditor as far as these two example wads goes.

The display of textures in the Favorites List is set in bsp.ini (show_favorites=1), and regardless of how it is set (along with 'numfav' to set how many textures to show), Dkte3.wad causes a blank line to be saved. This happens even if show_favorites=0 and numfav=0. Also, what is not clear is why, when these are set to zero, the map is still saved with
//BSPFAVORITES0001
//ADOOR01_2
It may be to do with the format of the commented lines: these lines are not needed for the building of the map but tell Bs[Editor things about how the editor itself is set-up.

So, concentrating on the wad files for a minute, I can see that Dkte3 has no * prefixed textures (no moving water, sky or lava), and only a few + prefixed textures when compared to quake101. Am I getting warm?

I will send aguirRe two simple maps showing the problem but don't let that stop anyone else coming up with the answer :-) 

you could open the wad up in Wally or TexMex, select the textures you intend to use and then add those to your basic Quake101 wad.

PS Sorry you missed the Pak. Wont be the same without you. 

You're filling my mailbox! What are you sending me? 

Sorry. You usually ask for the map and wad file in a zip file?

But it seems as though OE split it into 14 parts and this has caused a problem at both ends: I didn't realise anything actually got through. Once again, sorry.

I have subsequently sent two simple map files only, via Hotmail (attachment<1k), showing the problem. 

I'll try that in the morning. Thanks. 

it was just the map file that was the problem. I've received 22 emails totalling over 11 MB. My poor modem ...

It appears as if the split file is incomplete so I don't know if I can put it together. If you have such big attachments, please upload somewhere and offer a link instead. 

to puzzle out the important parts of the MIME message. On my system, I get the same problem opening 123.map. After manually changing the line
//BSPFAVORITES0010 into
//BSPFAVORITES0000,
opening and saving in BSP then seems to heal the map file. Repeated opening and saving after that seems OK. 

any place i can learn how to use custom textures in hl2? 

http://www.interlopers.net/content.php?article.91

Various
http://www.interlopers.net/content.php?article.cat.48

There are many sites poping up with tut's, just keep an eye out 

While I'm not use with antilight, can somebody help me an explain how antilight are declared (field in light entity, color, etc...) in a map ?? I supposed it's done like light entity, but what are the differences ??
Thanks 

Is just a normal light but in the "light" field (Or Brightness field if you're using WorldCraft) you put a negative number instead of a positive one.

I'm not sure how you make negative colored lights. In good old arghrad you could make both the brightness and the color components positive and negative, so if you had a light with "light" "-200" and "color" "255 -128 0" you'd end up with a light that sucks up red light (negative * positive = negative), emits green light (negative * negative = positive), and leaves blue light alone (negative * 0 = 0).

Also, antilights only affect lights of the same "style", so a flickering antilight won't have any effect in an area where there are just normal styled lights, but it will suck up light from other similarly flickering lights.

And last but not least, read the readme for the light util, these things are usually explained pretty well there. RTFM! ;) 

what czg said and RTFM indeed! 

Thanks !!! In fact antilight are no more than "negative brightness" light... BTW, I've read (perhaps too much quickly) the readme file of my light tool, and I didn't find the stuff.... perhaps I missed it... Anyway, thank you very much for these important precisions.... 

Could you explain please... I think it's a quick short cup like IMHO, or soething else, but I didn't understand this one (AFAIK not more by the way... )