Thanks. That reminds of wanting to create non-solid snow. Isn't the Func_illusionary used to make a brush non-solid? I suppose that would do the snow trick.

And ofcourse, I'd never ask anyone to overwrite anything. Ideally, you could just put the new.mdl into a pak file or in id1/progs and the engine would just always check that progs folder if the map file dictates it. But I guess it's too easy to think that way :) In Q3, you can just add all your stuff into a pak file, whether it's models, textures, sounds, or whatever. 

The difficulty is not so much that quake doesn't offer pak files and things to prevent you overwriting somebody else's models. The standard quake progs doesn't offer any way to specify a model to precache from the bsp file. So the only conceivable way of loading a custom model is by using one of the existing filenames, which would of course overwrite something.

The suggestion is not meant to be a serious on(I think), so you need a modified progs.dat in order to load ANY custom model sensibly. By that point you need your own mod directory and there is no danger of overwriting other's files. Unless you decide to use somebody else's mod which supports custom models, in which case conflicts may need to be considered. 

Thanks for the answer. The problem is that I want to make a deathmatch level that people can download automatically from the FFA server. So a mod is out of the question. I guess that's not possible then... 

A thought I had after replying there...

Problem: Map releases that take advantage of a mapping-centric mod like remakequake or quoth may have other custom resources outside of the traditional bsp files, for example custom sounds, models and skyboxes. The pak file sounds like a great way to distribute all of these things without risk of dozens of file conflicts. However, the system of loading consecutive pakN.pak files means that users have to jump through renaming hoops to pop the new map at the top of the list and risk clobbering a custom map when a patch for the base mod comes around.

Proposal: add a "-pak name" switch to engines. This would place the named pak file at the top of the search path for any files, allowing overriding of all models as well as supplying the location of new files.

Players using an engine with this feature would be able to leave maps distributed as pak files with an identifiable name in the directory, and load straight from them as they wished. Older engines would not be left out, although they would have to rename the pak they wanted to use to pakN.pak.

It might sound like this adds bloat to a command line that already needs -game and +map specifiers. Correctly designed mods could eliminate this though, by ensuring that quake.rc calls autorun.cfg, a config file with a dummy implimentation in the mod's pak files. Loaded pak files could then override this with their own autorun.cfg - containing a command to load the (first) map in the pak.

(Custom map paks overriding quake.rc directly should be avoided, since that file may be updated by future patches to the mod. Supplying the autorun.cfg is basically saying "this one is ours, and that one is yours".)

Extension: The command line could accept "manifest" text files listing a collection of paks rather than a single pak. However, this might be overkill, and it certainly should be in addition to rather than instead of the single pak loading system. 

for quoth at least, fitzquake and aguirre's engines have a -quoth switch that works the same as -hipnotic and -rogue, so you can effectively load your own mod on top of quoth.

Darkplaces does even better and has the ability to specify multiple gamedirs, so mods can mod mods ad infinitum. 

I'm working on a map that will use only the original Quake textures. I want to apply a texture to a cylinder (actually it's an hexagonal prism) that will make the cylinder look like a screw. Something like in this image : http://upload.wikimedia.org/wikipedia/commons/7/78/Screw_bolt.png

Any ideas what texture I might use ? (cropped, rotated, etc) - just to get that effect. 

any texture with ribs -- then just rotate each face the same amount and slide them around until they line up. You might have to adjust rotation to get them to line up all the way around. 

Wow, that was fast :)

Thanks metlslime.

Yes, that's what I was thinking about, I need something like this : http://farm2.static.flickr.com/1111/1069643021_01b41ff384_o.jpg

But how to get it from standard Quake textures ?
I searched the metal textures, I didn't see anything suitables, everything is too flat or with "bubbles" 

Yeah, metlslime, I had them in mind before I posted. I was trying to come up with something inbetween the effective but hardcoded -quoth switch and the overly elaborate darkplaces stuff. 

http://necros.quaddicted.com/temp/worm.jpg

:D 

necros, that's an impressive piece of work. But I cannot do my "screws" from polys for 2 reasons :
-the screw is quite small, it's smaller than a shotgun bullet
-I have a lot of screws and I'm very near to 32k marksurfaces limit (I went beyond this limit, but I deleted some rooms and now I'm back to about 30k)

Anyway, that screenshot looks awesome, does it move ? Any chance to see the full map ? :) 

now make a worm that's missing chunks from the threads, and wheels that are missing teeth to go with it! 

ah ok. i only posted that because i originally tried to make the worm gear out of textures too. but i swapped to a model because the spur gears looked funny meshing with a texture.

you could make a screw model though, that was just 6 sided (plus top and bottom, so ~20 tris?). it would make texturing the thread easier on a model skin maybe?

anyway, yeah, that worm gear is part of a new map/mod i'm working on. it's taking forever though, so no promises on release dates.

also, can i lobby for more lightmaps in quakespasm? maybe around 512 lightmaps or 1024? :D i built this whole terrain mountain as a sort of 'brush skybox' but had to remove it because i ran out of lightmaps, lol.

i think fitzquake's (and by extension, it's variants) current bumped limits could use some normalization.
for example, static entities has been increased, but ambient sounds has not, so you can add more torches than ambient sound slots which effectively acts as an artificial static entity limit.
or in this map i mentioned, it's possible to be under the faces/marksurface/vertex/clipnode limit, but run out of lightmaps.

now make a worm that's missing chunks from the threads, and wheels that are missing teeth to go with it!

maybe cause it's a lazy sunday afternooon, but i don't get it. what's good about gears with missing teeth? wouldn't they just stop working when they get to the broken part?
unless you mean like some sort of puzzle? 

subject: overlapping brushes

I know you shouldn't have those, but what about water? If I want to flood a building with water, it looks bad when I cut the water around pillars etc, cause you'll see those cuts in the moving water texture...

And architecture partly covered in snow? What is the best approach when you want one brush (snow or water) to partly cover up other brushes? 

What's wrong with overlapping brushes? 

I know you shouldn't have those

Wrong. 

water will be cut pretty badly no matter what method you use, so i tend to just cover up areas with a single water brush.

if you are using fitzquake, make sure you use r_oldwater 0. this makes the engine use a much better looking water. 

I thought you increase the chance of having Z-fighting (flickering) if one brush is contained in another brush (overlap).

Another reason I've read about is longer rendering times when you overlap brushes...

On top of this, I've seen multiple good mappers stressing NEVER to overlap brushes, including Pingu who stated in an interview to work neatly and that there's not a single overlapping brush in A2: Return To Atlantis.

I'm not pretending to know anything, but I do know what I've read. Kind of strange how people here say it's not bad to overlap brushes... Now I'm confused.

And Necros: thanks for the tip. Although that doesn't help people who play my map and use another engine ofcourse :)

BTW: are detail brushes used in Q1 (vs structural)? I'm using BSP Quake Editor right now, and there is an option to 'add detail' or 'remove detail' but after I selected and added the detail, it's not reported in the 'map info' (detail brushes: 0). I'll check in another editor as well.

I've read that if you got a lot of stuff in a room (like a bunch of candleholders, charis, tombstones, etc), it's best to turn those into detail brushes and let the main brushes that are suppoed to block Line Of Sight be structural... 

i don't know why, but overlapping brushes will cause zfighting in newer engines like q3 and d3. in quake, qbsp will manage to remove overlapping WORLD brushes without any issues. (overlapping func_ or other visible bmodels WILL cause zfighting with other bmodels or the world).
afaik, it doesn't cause any problems once the bsp is in the engine.

i'm not sure where we are atm concerning the compiling aspect of overlapping brushes. i don't overlap because i like to work clean, but it's just personal preference. 

OK thanks necros. You have an alarm going off when there's a new post? You seem to be on top of things :)

Is there anyone who can comment on the Detail/Structural question pls? 

Change brush groups into func_walls or func_illusionaries to avoid breaking up surfaces, or float them 1 pixel off the floor/wall. 

Overlapping brushes are ok, especially for weird off-angle arches and such. 

Anyone got any tips/tutorials/techniques for creating the best rocky/uneven terrain in Quake 1 bsp? :E 

Can anyone tell me what kind of triggers connections i have to do in order to make 4 buttons to trigger a door ? like if all are ON then the door should open .. if 1 is OFF the door shouldnt open (logical "AND" condition) i use the Quake 3 engine (GTK Radiant). Thanks in advance :) 

Create a Trigger_Counter (with a name of course :) )that activates at 4, and make it's target the door. Make each button target the counter, and make each button's reset time -1 so a single button can only be used once.