I used to have a 'mod' a long time ago, when I was about 15 years old and all it was was a progs file. All it did was produce zombie gibs (the ones they hurl I think) which would follow the trajectory of bullets fired into enemies and stick to walls behind, then slowly slide down to the ground, producing good old quake blood particles the whole time. I think it was really cool, but I cant find it anywhere and I wouldnt know where to start in programming it. Does anyone know where I could find such a file, or have the time to 'knock one together'? 

When did The Forge go down? 

It just does that sometimes. A pain in the butt when you need to consult the site but can't. 

I downloaded The Reckoning - the Q2 mission pack - textures (from Quaddicted) but they can't seem to work (wrong format or something) with WC 3.3.

It'd be even easier if I were able to rip the exact set of textures Lunaran used in Lunsp1. 

WC 3.3 has to convert WADs to HLWads in order to use them. If you are using the Quakeadapter package, theres some sort of program with it that automatically converts them for you, located in the program files\worldcraft folder.

Maybe this helps?

Alternatively get a program that rips mips from bsps and converts them into WADs, although WC 3.3 may still have to convert to HLwad to use them. Are you using the Quakeadapter package with 3.3? 

Will only work for Q1 with the Quakeadapter, unless you make your own version. To rip a wad from a bsp use TexMex, though you'll still have to convert it to use with 3.3, and if its bigger than 1024 textures then it won't load at all; you'll have to split it up.

The wads that TexMex creates are automatically usable for any Q1 specific editor - 3.3 was locked for HL1, which is why you need the adapter. 

Yeah, Q1 is the game I was talking about and yeah, Ricky, I found the texture converter and converted them to hlwads.

Thanks. 

Does anyone have scrolling rock/grass textures? 

Does anyone know where I can find Biffs new improved IDbase textures? 

You mean tiling? All should be if they're made for games. In both cases try Quaddicted;

http://www.quaddicted.com/wads/

Not sure if it has what you want, but its hard to imagine it not being there. 

I meant textures that give the illusion they're scrolling, like the waterfall textures (+1_fall etc). 

i dont think those exist. but you can easily make them yourself using, e.g., using offset in photoshop.

byeee 

Too much Doom? Linedef tag 48! 

http://www.bspquakeeditor.com/

Support for high-res textures and sky_boxes.

Dropped support for BspBuild (boo... ) so I won't be upgrading. 

Are there any tutorials on using 24-bit TGA's in Quake? It seems like some refuse to tile correctly.

If not, how do disable/override using 24-bit textures in FitzQuake?

Spanks! 

3 point clipper looks cooler in bsp than radiant. :( 

Anyone know of a compiler for Quake 1 that supports origin brushes? There's talk on the inside3d forums of one existing, so it'd be great to have a copy. 

that would be great to have if it exists, and I think it is at least possible that origin brushes could be supported, but I don't know offhand whether the quakec func_rotate_* code would have to modified to work correctly with it. 

At the moment a rotate_object with a target uses the matching target entity as it's origin vector. Then all the brushes are moved that distance in the opposite direction so that they line up again. That's the same effect as the origin brush would have, so the hipnotic code would work straight away. Still might be worth revisiting that code though... 

That's the same effect as the origin brush would have

Well it's not just the actual pivot point that is important. It's also the default placement of the brushmodel in the world, which affects things like texture alignment and dynamic lights -- both of which are incorrect the way we currently do rotating brushes. 

Could find the time to streamline / rebuild from scratch the shitty rotating code it'd be nice.

It doesn't have to be easy to build a rotating object, but it should be possible in, say, a speedmapping session.

I suppose AguirRe is the one to ask about compiler compatibility. 

I see what you mean now. In terms of default placement when you load the map, it'll load in the right place, you wouldn't have to fiddle with the origin any. In terms of whether the texture alignment/lighting would be correct, that would really depend on how it was written. The most straightforward way of doing it would just use the hipnotic code straight away, except it would calculate the origin value based on the origin brush instead of the targeted entity. So it'd have the same problems. You could rewrite the whole thing - and if you were bothered to do that you might as well add origin brush support at the same time. But I wouldn't want to... 

Heheh ;)