my antivirus program was freakingout about vis and light XD now i have that also worked out! 

At least there is progress. Now you should only have normal mapping problems.

When you build a map out of brushes there is an "inside" and an "outside". The inside is the playing area where the light and monsters and player belong. Outside is the "void".

Think of the "void" as water and the inside of the map is like a submarine, where the air is. You must use brushes to make sure the inside is completely sealed from the outside so that the water will not "leak" in. 

glad it worked out. I'm not sure what is causing the antivirus warning.

Ahh, I built my map so that brushes dont overlap each other, should they overlap to prevent leaking?
They don't need to overlap, the brushes that form the outer boundary just need to seal tight (they should be snapped to grid).

It didnt draw lighting because you have a leak in your map.
light.exe should work fine with leaking maps, it will take longer to compute lighting though, and run a lot slower in game. 

im really making good progress on my map and learning, i love how textures can be stretched, rotated and alligned in very fine detail. Triggers are pretty simple also (at the moment).
my map already has alot of lights and it and the compiling time is pretty high, about 10 mintes at the moment. is it normal to have such high compilation times? 

I usually have about 43 seconds for light using ericw's multithreaded tyrlight.exe. Although, I do have an 8-core 3.4ghz processor. Qbsp takes forever at about 2min. Vis takes like 5-10min. Depends on your map size and whether or not you have a leak. 

Naite said compiling time is around 10mins, which is consistent with your 5-10min estimate for vis. 

There's no way to say for sure without knowing what kind of computer it is, what the map is like, and what is used to compile it.

I can build the same map on two different machines and compilers and it takes almost 40 minutes on one to about 3 minutes on the other.

So, it depends. 

The only certainty is that vis is usually a lot longer than bsp and light. 

Thanks Mugwump! Its good to know that vis takes a long time.

Im very inspired by the videos by Custom Gamer in youtube, where usually Daz talk about cool maps. Im very impressed by the maps made by sock and i was wonder how do i create coloured lights, fog and a skybox? 

ok, now i have a recursion on leaf 551. whats that all about? 

now i fixed the problem i accidentally copied a bunch of bruches and sent them to the far corners of the void. :D
my map is a spacemap and its got alot of light entities in it along with brushes that are shaped as terrain. is that the reason my compiling is taking 2586 seconds. Visdatasize is 104036. 

Hi i want to create a func_train.

I created a brush gave it an world entity property func_train and created entity path corner. how do i name target and targetname?

does the train have a targetname? or do i assign target name to the path corner entity (for examlpe traincorner1) and then give the func_train target (traincorner1.) 

heres a screenshot of how i thought it would work.
http://i.imgur.com/Of019KP.png 

I know there is lifts/paltform, but is there possible to make brush that is like a floor but then rises scales up and is still locked to the floor level only the size changes? Because I have no any other idea how to make forces fields or force field floors like in this Metal Monstrosity by Sock. There is these yellow force field floors appearing after pressing some buttons. But that is not func_train? 

Horizontal func_door?

You can always check the source of metmon and see exactly how Sock did it as well. 

Space maps are usually pretty wide open and will take a long time to vis unless constructed very carefully. It's debatable whether anything more than vis -fast is worthwhile. Maybe if it has a lot of inside areas.

Func_train needs a starting target to move to. Give the first path_corner a targetname and use that as the func_train target. Give the first path_corner a target. Use the targetname of the next path_corner for the train to move to. And so on.

You can't make a door or platform that changes size. You make it as big as it needs to be, then place it down in the floor or whatever until it's used. Then it will rise when used and appear to "grow".

You could also just make a flat brush into a func_door that rises and lowers when triggered. 

Great success! thank you Rick! now i have a better understanding of triggers and trigger names, i also created a door that works with a trigger 

All I can think of is two func_trains or func_doors both placed inside walls/floors other sides waiting.. after pressing button, both of them moves to the middle where "lights touches" and that is what made that effect look so natural. So if this is the only way to do it, then shall be it since it works. 

is that the reason my compiling is taking 2586 seconds
Again, it's impossible for us to judge your compiling times without knowing your hardware, software, and the size and complexity of your map. 15-20 years ago, maps could take days to vis. Yes, days! Things are much better now but it still takes some time. You'll never compile a map in the blink of an eye, unless it consists of one boxy room and not much else.

A skybox is a set of 6 textures named according to the sides of a cube: the Sahara skybox, for example, is comprised of sahara_bk.tga (back), sahara_dn.tga (down), sahara_ft.tga (front), sahara_lf.tga (left), sahara_rt.tga (right) and sahara_up.tga (up). They're to be placed in a \gfx\env subfolder, either in \id1 or in a mod folder. I know how to tell a map to use a specific skybox via an .ent file for Darkplaces, but a more knowledgeable mapper will be able to tell you the better, engine-independent implementation method.

Same with fog: I could tell you the .ent file method but that's not the better method, which I do not know. I've read that CZG used brushes as fog in his Honey masterpiece. Maybe you can study it to see how it's done.

Colored lighting comes in two flavors: .rtlights a.k.a. real-time lights achieve better results but are restricted to the engines supporting them, namely Darkplaces and FTE. .lit or .dlit files are more widely supported but have more limited possibilities and are not processed in real-time. RTlights are edited directly in Darkplaces (type apropos r_editlights in the console for a list of the various commands and their effects). A program called MHColour can generate .lits automatically but the results can range from good to very average depending on the map. You can edit .lits manually but again, you'll need the input of a more knowledgeable mapper for that. 

As for leaf recursing, I've found something about it on this very old help page: http://www.quakewiki.net/archives/quakelab/vis.htm
Check the 4th entry in the chart. You might also find some use to the rest of this page (except the "editor" section, which seems to no longer exist). Not sure how much of it all is still relevant but I doubt it's completely useless. 

Am I missing something? Both J.A.C.K. and TrenchBroom(which i believe is what hes using) have these options within the editor. first three pictures are Trenchbroom, the last one is J.A.C.K.

even QUARK had these in the editor.

http://imgur.com/a/BqHiG 

Heh, like I said, "more knowledgeable mappers"... I'm still wrapping my head around the building phase. 

Im wondering where you got the information to do it in that way. It seems like it might have been the way to do it back in the day, but its far from convenient now.

also, that troubleshooting guide might not work for him as its likely based on the original compilers. hes using tyrutils.

dont knock yourself. It doesnt surprise me you can edit them thru the .ent and .lit and such, but it just never crossed my mind to do it like that or that it was a way that people would teach each other anymore. 

.ent files are still used a lot in Darkplaces and in fact, AFAIK it's the only way to add something in a map without having to de/recompile it. Basically, if the map is not yours and you don't have the source .map, you're stuck with .ent editing.

it just never crossed my mind to do it like that or that it was a way that people would teach each other anymore.
Which is why I've stressed several times that it wasn't the best method and that other, more experienced mappers would know the way. The guy had questions left unanswered, so I wanted to provide whatever rudiments of an answer I could muster. 

Fog is a key/value pair that is set in Worldspawn.

"fog" "n.nnn"

It ranges from 0 to 1. Lower values seem to look better, 0.5 is pretty thick fog.

You can set the color by adding an optional RGB value:

"fog" "n.nnn r.rr g.gg b.bb"

Fog can also be typed in as a console command, just leave off the quotes:

fog 0.25