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 ;) 

 

 

I need a Q1monster that can walk, but also swim.
Would this be a holdup to the walkmonster_start code?

I mean, I can't put both in a qc-script?
Or something like a fly/walk monster? 

kell and i toyed with this for a bit and it's definatly possible.

i would recommend you make a new ai_run function. in it, you need to check the pointcontents() of some point (i used the origin) in the monster to check every frame if it is in a liquid or not.
if it's not in the water, you need to remove the FL_SWIM flag (and likewise, add it if it's IN water). the FL_SWIM flag is what lets fish and stuff move around in water. apart from that, there's very little that needs to be changed, although i'd recommend adding a new trigger_jump type brush entity to help the monster make the transition between water and land, unless you want to build ramps all the time. 

Sounds like the Nehahra Jagger. 

for your answer, necros. Fact is my qc knowhow isn't bigger than a mouse, and even that I could make hardly go walking.

If I look at the ai_run function I haven't a clue where to begin.
There's a FL_SWIM flag in the monsters.qc where the options for moving monsters is specified.
So I guess making a new ai_run function isn't enough. 

What is the best way of doing coloured lights?

What light util is best (does AguirRe's support coloured lights?)?

To my understanding a light ent needs to have the key;

'_color'

with a value of something like

'255 0 0' - pure red
'0 255 0' - pure green
'0 0 255' - pure blue

Fitzquake is a good engine to use? Any others?

I have tried experimenting but when used a method like the one described above, Darkplaces seemed to show the lights as being rather ugly incorrect 'rainbow' type effects?!!

What am I doing wrong?

Note - I am aware that there are supposedly two types of bsp coloured light info files - a bsp30(?) with the info stored within the file, and a 'lit' file which would go alongside a bsp29(?), and that bsp29(?) is compatible with non-coloured light supporting engines.

This is what I know (or what I think I know), any help mucho appreciatado!