I'd agree that including the scorpion in a mod like Quoth without permission is strictly speaking illegal. It's the same for maps that use texture sets from other games like Quake 3 or Daikatana, taking an art resource and re-purposing it in a similar setting, essentially is a act of redistribution without permission.

Morally speaking, I'd say what differentiates it from including the entire pak and all the maps is a matter of substitution. Including all the maps would make your mod a complete substitute for the mission pack. Someone who downloaded that would have no reason to buy the mission pack, harming that product's potential sales. Including the monster in a different mod doesn't do that; the value of Scourge of Armagon is preserved.

I guess it's kind of a map-centric view of things, but I think the experience of the mission pack is "play through these particular maps", rather than "play against this monster in some notional maps which may or may not include the maps supplied". If a cease-and-desist order were made, we'd comply without hesitation, but for a free mod I doubt we'll ever see one. 

you can just say it's a parody and get off scott free... that's how I got away with all those murder rapes. 

The Mapper's Ethic for Other Mod Inclusion:
I won't include the maps.
I won't include the demos.

I will include the monsters I want.
I will include the items I want.
I will include the code I want.
I will hide them in the .pak file(s).
I will include a "Special Thanks" in my readme.txt, whatever it may be called.

I might consider notifying the author before releasing my map...
...if I can find their contact info.

I won't release if the author doesn't want me to, but they will have to act fast.

I will revoke a release if the author of content I have used wishes me to do so.

Signature___________ Date________

Here's a pen ./

Side question: Didn't the Drake Mod use the Quoth Drole? 

A. The castle will rise from its vortal depths... 

it doesn't need to be so complicated. ask before using stuff, if they say no, don't use it. if you can't contact them and you've done due diligence, just use it-- it's likely a really old asset anyway. 

Aside from hiding the brushes casting the shadow inside a sky brush or behind a func_wall there is another way but you need to be sure that the brushes involved are well out of the way of game play because even though you cannot see them the engine WILL treat them as a solid (invisible) brush so you and the monsters cannot walk or shoot through them.

You will need a BSP compiler that supports the skip texture and detail brushes (Tyranns does using the entity name, func_detail).

Make whatever shape that you want to cast a shadow and make them all func_detail (you can group them and then do it all at once) making sure that you use ONLY the skip texture. Viola, an invisible brush that casts a shadow. A solid (as far as light is concerned anyway) clip brush so to speak.

An additional benefit of this is because the compiler changes the func_detail into a plain old everyday brush it has no effect on the number of entities\models used in-game.

This works for two reasons. All detail brushes are rendered so that vis compiler will ignore them but the light compiler will see them as a solid brush. By adding the skip texture the bsp compiler will not let them get drawn in game. If you simply did a skip on a solid brush it wouldn't cast a shadow but this trick, where an entity (func_detail) is turned into a solid in the middle of the compile process does work so that the light compiler "Sees" the brushes even though the player does not.

But like I said, it's an invisible solid brush so you need to be absolutely sure that's it's out of the way (rocket launchers and Skraggs are an obvious no-no here and probably tar babies and fiends as well, oh, and no way for any enemy to shoot at you or jump on you from above). It also cannot be touching "Anything" aside from itself (in other words it must be free floating, it can be a collection of any number of func_detail + skip brushes touching each other but that's it) otherwise the contact points will give you a HOM effect.

Have fun! 

I went for the age old method of hiding the brushes inside the sky volume though I enjoyed all the different methods suggested.

I'm not 100% sure about using the Q symbol in the way I have in the end, the area I used it in seems a bit busy now. 

Tyrann's tools
_shadow 1 with skip texture shove it anywhere 

Adds to your entity count. Func_detail does not because it gets converted into a regular brush during the compile process. 

That's why I suggested using an info_null, which will get removed. Both ways still add a model precache though. 

Is there a limit to the number of precaches? 

What's the limit for engines nowadays? 

Personally I prefer the "fuck the limits" option and go for full bsp2 support. Quakespasm is my current favorite for this. Afaik it has no limitation on precaches. 

255 is the maximum that will work in all engines. Lots of leading engines do increase this limit, but because it requires a protocol change it's not trivial to do. This means lots of minor source ports don't have the feature. 

Hey guys,

New to this. I want to use the textures Sock used in his maps. His readme's state that these are modifications of the original textures. Is there such a thing as a Sock wad I can use?

Or do I have to go through all the bsp's, find the directories, filter the textures and somehow create my own wad?

Sorry if asked before. Did a bit of Googling but most things mentioned tools on how to make wads.

Regards,

Sprony 

the textures in his .pak files, you could get something like pak explorer to get the .wad files.
I believe you can also take textures directly from .bsp files using TexMex. 

At the bottom of THIS page is all the links you will need. TexMex will extract textures from BSP files and ADQ will open up PAK files. I do include all source materials with every release, map + wad file.

Once you have extracted all the wad files out of all the different pak files, just put them in the same directory as your map and add them to the wad line on your worldspawn.

Eg - "wad" "common.wad;animated.wad;liquid.wad;zendar.wad" 

Thank you! 

Since I am already taking the ijed approach with respect to map size, I will ijed my precaches too.

Thanks for the tip.

P.S. 255!! Thats pathetic!! 

whether all engines support "alpha" property for the entity? 

99% of them do (100%?) 

I decided to give Trenchbroom a try. It works great. However, I'm wondering if my directory setup is correct because there are so many programs out there.

In my regular Quake folder I got a 'Id1' folder. In there I made a 'textures' folder containing several wads. I also got a 'maps' folder. I added a 'utils' folder as well but when using 'ne_q1spCompilingGui' it needs all my compilers in one folder. So I also made a 'compilers' folder.

The whole compiling story is not clear to me. I've downloaded TYRUTILS and the files by Bengt Jardrup. I'm not sure what the difference is. Also, all compilers come with several files but it seems you only need the .exe's in order for it to work?

Bengt Jardrup also has convmap.exe. Is this the aquirre converter I see mentioned several times? I have to learn Trenchbroom better so I want to make the more complex brushwork in GtkRadiant 1.4 and convert that to Quake. According to the explanation I read I need to make an 'output' and 'workingfolder' directories inside the 'Id1' directory. This doesn't seem to work so I probably misunderstood that.

Any insight into the correct setup would be great. I read the Quake Wiki and I've found useful information using Google as well, but never the complete picture so that's explains the questions above. 

You really only need a the vis, light and bsp .exe files. The other files are probably readmes and source files (for budding programmers).

I just store everything in my trenchbroom folder for mapping, texture wads, compilers and .map files. When you create the .bsp file all your textures are compiled into it so these aren't required to go into your quake directory. (plus it makes your quake directory cleaner).
As for Trenchbroom, I store it inside my drop box folder so that my work is always always always backed up. 

the output folder is the one where you are putting your maps to run.

so if you are making a normal map, the output folder should be /quake/id1/maps

the working folder can be anywhere. this is where the .map file is copied from it's original spot, and then compiled (the compilation process creates a bunch of files that are mainly needed only during compile time).
after the compile is done, the .bsp produced is put in the output folder. 

I was mapping with the extras mod with the func_water lifting.
Now I'm breaking up with the thing called z-buffering.
It means that func_water brush expands out of it size.
So a space left out still gets troubled with the greyness of the func_water.

Is there a solution to this?