 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Yes and no: it is possible to include your wad in the texture browser by copying the files, instead of creating links. Actually this feature (i.e link creation) is buggy, and it forces the mapper to reload the textures each time the editor is launched.
OTOH, it is good to do so as copying the wad does not let the player to include modifcations "on-the-fly"... Well, it is just a matter of habits... and creating the links is just a 20 seconds time before being able to map, if all your wad files are located in the same folder ;) > Radiants are a mess of lines if your map gets complex.
Radiants have a very convenient function to hide and unhide stuff (select and press H, shift-H to unhide), as well as a cubic clip button that will hide most of the map beyond a short distance from the camera. ^ ^ You should work mainly in the 3D window anyway, and since the default render mode is textured, you won't see any lines. Press Alt-H in radiant to hide unselected--this allows you to quickly grab what you need to see and hide everything else. I probably use this + Shift-H more than any other key combo in radiant.
Just press I to invert the selection, then use H to hide it. Same result. Should have thought about this before posting.
If selecting all entities of a certain classname in the entity list doesn't work for you, what about Shift+A?
too many beers after reading last post.
Quark. Yes. Still trying to credit Armino Rigo. I was so glad with my no-warnings map in Quark. Loading it in BSP made it 1864 warnings. I wonder what Radiant will do. > I was so glad with my no-warnings map in Quark.
Loading it in BSP made it 1864 warnings. I wonder what Radiant will do. Haha :) May sound strange, but reloading it in BSP the map had no hom's, as in Quark6.3.
Sad the side has stopped updating, as I use Quark from the first version'97. What is this floating point error issue? I know it has to do with not right placed brushes, not integers that are replaced, so mislignment is caused. DMM seem to suffer from it, Quark has it. It feels as if BSP is more accurate, although changing an editor is really hands crossed helpfiles. I dont use last version to...
6.5.0.7 is the one I use... very nice... updated some times but always return do this version It's not a Quark floating point error, it's just the way Quark is making maps for Q1. Enliten's Quark map (just posted) has a brush coodinate of:
( 68 28 -0.00002 ) Quark purposely put a brush edge at -0.00002, and not snapped at 0.00000. It's not an error. There might be a setting in Quark to avoid this. I donno. It's possible to change the coordinates back to integers in the viewwindow. Sometimes it works, not with wedges and noncubiks.
Quark tends to have a wicked leak error. Replacing cubes helps, but as I entered the 38767 clipnodes, I gave up trying to understand what went wrong with replacing the same volume of polyhedrons and getting weird outcomes. BSP give a lot more warnings, but it are all healpoints. I posted on quark forums some time ago:
Quark etp means that it writes a lot of decimals in the Classic Quake -> no decimals. Faster to prozess for the tools better framerate ingame, cleaner. But it also means that you should stay on grid. at least 8x8 or 16x16 is really recommended. 4x4 and 2x2 only for details. It's also recommended not to use things like rotation angles other than a multiple of 90� or quick object makers. You won't need more for quake1. I use this format. Valve 220 is hammer/worldcraft format of the Brush Primitive, I think it's radiants format also check "Don't write floating-point coords" and "Use Integral Vertices as Threepoints" I should start mapping again during winterbreak, want to finish something. Studying Architecture is really time consuming :-( and playing with blender keeps me from mapping. I used Quark a lot with turning side angles and then forced to grid, which caused a lot of offgrid brushes. I once even took the time, to correkt them all with notepath.
Snapping corners to grid seems to be more usefull as the poly keeps its integers. Link seems to have a Qsoll error. Grid and rotation and map format.
Valve 220 needs to die - imagine you work in a team, and someone wants to open your map file. Eep. Problem. That's just a no-no. Grid: You can use 1 unit for stuff, that won't break, at least it hasn't broken anything for me yet. I use 4 unit grid regularly for example after rotating stuff etc. I used 2 unit a lot with Radiant's Polygon Builder plugin. The stuff it created needed to be snapped to the grid, and anything above 2 unit grid deformed the polygons too much, so I snapped the whole crap to a 2 unit grid and checked it afterwards by zooming in and controlling all vertices. I build ladders and handrails on a 2 unit grid regularly. Nothing breaks. 1 unit is usually only required to get tricky stuff working or to build really thin stuff. Rotating things... this can indeed create problems. Loading an external 1 unit doesn't break
but imagina a brush that has every vertex on 1 1 grid: the brush is defined by planes not vertices, so it may result in floats easily. And if you force the one unit grid, the vertices are NOT on grid not present in 1.6, which uses normal map format
didn't someone write a converter a while back?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |