Right, that's what I was using - I thought it seemed a bit on the buggy side in windows 8 

Windows 8 I don't know, I use 7. It does have some bugs in it.

Trenchbroom was cool, but I ran into a bunch of bugs with the version I was using. It takes a bit to learn coming from radiant, but it totally seems like the benefit to workflow would outweigh the hassle in the end since it all takes place through the camera without any orthographic views.

Plus it's actively being worked on by people here, so you can bug them about it. 

Trenchbroom seems too awkward for me - I'm very much from the old school of needing to lay things out precisely in 2d views. It seems to take too long for me to place things properly in TB.

Next question - in netradiant, is it possible to specify in the .ent file default values on certain entities? e.g. so that a newly placed light would always start with specific light, wait, delay values etc? 

I'm not a Radiant user; I couldn't get past the interface long enough to really build anything with it.

For Quake I used Worldcraft and now Trenchbroom.

Worldcraft has a Quake injector zip made by Baker which gets it set up - if you use the newer, valve version. It works fine, but you have to convert textures to valve wad3 format, which is a hassle. Old WC1.6a is another option, where you don't need to convert textures, but doesn�t have (now) basic features like texture locking.

QuArK... exists, but the interface is like a brick in the face, I'm amazed anyone can use it. Then again, some of the most talented mappers turn out great maps with it, so what do I know. It does suffer from floating point errors but also offers model editing or at least viewing to some degree, but I couldn't figure out how to use it.

There is also BSP editor, which looked interesting when I checked it out, ahead of its time when made and apparently, sadly, no longer updated.

I'm not mentioning other editors because I either didn't use them or they're not good. And probably forgetting a load too. 

TrenchBroom 2 will have 2D views. They already are implemented and being tested. 

(Please don't stop working on TB2) 

JACKHAMMER. :) Thank you... 

Toetag... but it fell into the category of oh no I didn't

sorry what

<goes to drunk thread> 

I won't. It's too much fun. 

 

 

Hello, very quick question - what's the latest/best Radiant-derived editor to use for Quake (1) these days?

Another vote for Netradiant.

Next question - in netradiant, is it possible to specify in the .ent file default values on certain entities? e.g. so that a newly placed light would always start with specific light, wait, delay values etc?

I think you have to do that in QC, but I'm not 100% sure. 

Next question - in netradiant, is it possible to specify in the .ent file default values on certain entities? e.g. so that a newly placed light would always start with specific light, wait, delay values etc?

I think you have to do that in QC, but I'm not 100% sure.

I know that in Worldcraft (and TrenchBroom for that matter, anything that uses a .fgd file) you can set a different default light value (the default is 300) and at its core other than different formatting to add stuff specific to NetRadiant, the .ent file is essentially just just an .fgd in different clothing.

So to answer the question, yes you probably can change the default light value (or anything else with a default) HOWEVER anything that you did prior to altering the .ent file will stay the way that it was unless you adjust them separately.

Don't forget to make a backup of the .ent file before you mess around with it. 

Thanks for the advice - after shopping around I think I'll stick with Netradiant for now, but I'll look forward to trying the new Trenchbroom 2, with its 2d views, when it's released.

I think you have to do that in QC, but I'm not 100% sure.

I'm not sure I understand - how would the compilers recognise any QC code? (e.g. light compiler)

So to answer the question, yes you probably can change the default light value (or anything else with a default) HOWEVER anything that you did prior to altering the .ent file will stay the way that it was unless you adjust them separately.

I have had a good look in the existing .ent file and I can't seem to find anywhere where a default is being set on anything. Hmmm... 

radiant and qe3 don't set defaults on entities at all - they don't set any keyvalues you don't personally set except for origin and classname.

the 'default' is whatever the compiler, progs.dat, or engine assigns to the value, depending on which of them pays attention to the particular key. 

I'm not sure I understand - how would the compilers recognise any QC code? (e.g. light compiler)

The engine does. Lots of entities have default fields and values set in QC. Lights actually, now that I think about it, are an exception.

The engine runs the QC spawn function for anything it finds in the bsp, and defaults are taken from there (such as the health of the monsters.) 

Ok, thanks, I probably should have been clearer in that I was specifically looking to set defaults on light entities.

Anyway, I guess I'll just copy/paste an existing entity in the map, which should avoid me having to type all the fields out every time I create a new one. 

So I made some bars func_detail in and thought that they wouldn't cut up world_brushes. But appearntly they do. http://i.imgur.com/5oFwsBT.png

So I'm just wondering what's considerd good practice. Should I be cautious of ending up with too much unintended geometry? Is it better to have something like this floating near ground and ceiling not touching or is that over-optimizing?

Made a Q3 level before but still a bit green when it comes to BSP work. 

since func_detail does not affect vis, i think making them float 1 unit away should be perfectly fine.

otoh, that screenshot seems like it is a very closed off isolated area, so likely the performance gain of getting rid of all those extra cuts will be negligible. but if that was outdoors? or the cuts were propagating into other cuts? then it would be worth the few seconds to move the faces away, I think. 

Work a little differently to most other brush based engines. Func_detail in Quake will stick make bsp cuts however they are ignored by VIS.

Good use of detail is basically saving you time when you vis a level. 

Thinking about how your faces will split takes a lot of time to get the balance right. It could be a simple case of having a bar run along the bottom and top of your bars might produce nicer results. 

Func detail is really just to cut down on vis times and not really to cut back on faces. It's a balancing act between the two. If you want to have less faces then "Lift" the bars one unit off of the floor and ceiling when you do your final cut. Nobody will notice anyway.

The main thing to keep in mind about about func_detail is that where it touches the void you "Can" get a HOM effect in some situations so something like trim (and your bars are a sort of trim) is usually a big no-no unless you offset it by a unit (and again, it's not usually noticeable to even the most critical eye).

I'm not too sure about how that might effect "Dirt mapping" though because as I understand it it needs hard corners to properly do the calculations.

I would suggest that you just block out the level first and do a fast vis to check for leaks (and add at least 25% to whatever you think is enough room. It's not like you're paying for the paint, plaster, tiles or a heating bill) and add the "Trim" at the tail end of the process, which is going to eat up that 25% pretty fast anyway. 

if you need it to butt into the world for whatever reason, but don't want cuts, then func_wall that mother.

Just don't go hogwild with func_wall though, for ~*reasons*~ 

 

Detail brushes will not cause HOM as long as you don't use them to seal the void. And if that happens then you get a leak and vis fails.