Well I need that actual light entity information, you have sent me the information for somebrushes with a light texture on them.
The light entities will be at the bottom of the document (the .map file that is) and will look like:

{
"classname" "light"
"light" "200"
}

As for the command line options well I would use (for a map the size you have) -extra4 and nothing else.

But yeah you can use a "wait" key in your entities to make the light spread out further or be more concentrated.

A wait of >1 will make the light more concentrated, i.e.

{
"classname" "light"
"light" "400"
"wait" "2.5"
"origin" "blah, blah, blah"
}

And a wait of <1 will make it go further, i.e.

{
"classname" "light"
"light" "200"
"wait" "0.3"
"origin" "blah, blah, blah"
}

You can also use "delay", but Im no expert on that one. I seem to remember delay of 2 being nice effect. 

That's a door that's fullblack? If it a door or other entity (func_wall or whatever) then it fullblack because the origin is outside of the world.

This means that it doesn't start inside the vis'd (lit) space.

Select it, the red X in the centre is the origin - if that's outside of the lit space (inside a wall, like yours seems to be) then the whole thing won't be lit at all. So make a recess for it to fit into or make it smaller so the origin is inside the world.

It's worth remembering that although entities look like they're normally brushwork in many ways they behave like point entities.

In other words, they only care about where their origin is when it comes to light and vis. 

Those were missing from the above post.

Also 'brush entities' as opposed to 'entities'.

Having a baby is the greatest thing in the world, but your head is all over the place for lack of sleep. 

Its an optimisation (AFAIK) of AguirRe's that the compilers don't light all brush entities no matter where they are, like id's did.

Definately a plus, but also shows another b0rky map feature common in the originals.

Mind you, very easy to be aloof ten years+ after the fact. 

Thanks for the help! The last post is what i wanted to know. I found it weird that the original quake maps had different lighting when starting in Worldcraft. Thought it was a problem in my Worldcraft configuration or something.But that explains it all.

And i am not sure if you notice that the in_game_screenshot.JPG was a screenshot of the original E1M1.bsp not mine small testing maps.

Anyway Big thanks! 

That's why I said that AguirRe (who's compilers come bundled with the wc3.3 adapter) made optimisations that id didn't.

If you used their compilers it'd work without showing the door black but take alot longer. and run very slightly slower in game I think as well. 

you lucky father and happy mother.

apparently the same goes for a good map:
Having a map is the greatest thing in the world, but your head is all over the place for lack of exit. 

silver_key-gold_key-exit.

change-feed-sleep.

Now that's a nerd comparison. 

PakExplorer: 'explorer' type view, limited to 8 character filenames. sucks.

PakScape: 'explorer' type view, not limited to 8 character filenames. converts all upper case chars to lower case and progs.dat is case sensitive. sucks.

DZip: not limited to 8 chars. doesn't change char case from upper to lower. is NOT an 'explorer' type view, just a long list of crap so very difficult to organize pak files. (as it's primarily for zipping demos anyway).
sucks.

are there any other pak file programs? one that doesn't limit file chars to 8 or change the case around and that has a proper way of displaying files so as to be able to organize things well? 

That is one thing QuArK can do very well. 

there is a pak plug-in for total commander. It satisfies my needs for exploring pak files. 

i was under the impression that both of those could only open and extract files from paks? 

Nope, QuArK let's you save just fine. 

I have just tested and the tc plugin is creating pak's as well. Very straightforward 

Pakker 

thanks :) i wasn't able to check myself today.
wasn't able to find pakker though, but i should be able to use quark as i've already got that. 

http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/pakker10.zip 

so, i made a few pathetic textures and im trying to get texmex to put them in a wad, like i did once before i think, but now when ever i try to import it gives me "was ignored" on all the textures

the textures are in .bmp format and i believe they are 8 bit color

...i don't get it any clues? 

i remember that happening, and don't really recall why it did, but i'm pretty sure if you convert your bitmaps into 24bit targas, the problem should go away.

it might have to do with the 8bit bitmaps not having the correct palette (it's not enough for it to be 256 colours, it has to be the correct 256 colours). 

Are the bitmaps compressed? That might be it. 

Your texture, then 'paste image as new mip' in TexMex. 

those both worked :D

... i don't know how to compress bitmaps so i dont think i can decompress them :S 

I'm working on a terrain map. I use triangle shapes to lift the corners to equal heights and then use force to grid 1 to fit the brush.

Sometimes the brush takes the grid on a counter line and it is possible to move the brush back into its original position, gaining a clean, converted brush.

Othertimes it gets out of grid and causes the vieuw to get out of position.
http://members.home.nl/gimli/align.jpg

The first method , without forcing to grid, brings a well compiled map with errors, caused by the compiler with warnings and heling points. But a fitting brush order.

The second , with force to grid and reposition, brings a misaligned map with less errors and a better compile log, and a rather blurry brush fit.

How to avoid the process and which would be best suitable?
I never minded thes misalignements, I'm already glad the compiler takes it. But then again, the small difference could change vistime considerably. 

when i make terrain in qe3, i just do my terrain mapping in 3d view after copying and pasting all the triangular shaped brushes i need.
i keep the grid on 16 (or 8 if i need fine details) and just pull individual vertices up or down depending on what i need in the 3d view.
this usually creates good results for me. 

It would be really ace if editors allowed you to select say, 4 brushes and lock 4 vertices which all interleap with a simple keyboard shortcut, then you just drag the locked vertices into the appropriate position as one, and then "ungroup" them.