1)if you only change the tex set and keep original animations or even base models, I don't think so.
If you make your own mmonsterarium, own animations and textures, why not

2)For code I think it smart to write your own, rather than keeping originals.
New monsters are reliable when standing on own ground.

ps:
don't forget your own weapons and callibration. 

First level of Scourge Of Armagon - The Pumping Station -

Tell me where are the liquid brushes that move? 

it's one of Hipnotic's feathers in the qc.
you can use it by using the progs.dat from the Scourge of Armagon,
or be clever and extract it from the hipnotic.qc and use it in your own mod.

Source Scourge Of Armagon => hipnotic.qc
http://quakeone.com/navigator/
download the Hipnotic DevKit. 

all you need is the HIPWATER.QC and add it to your own qc file.

If you open the start.bsp you can see it added as:
model func_bobbingwater 

But for now i'll have to pass on using it. I'm an almost complete newbie, the hipnotic.fgd that i got from Quaketastic isn't loaded by WC, and this is for SMP_170, and i'm short with time already.

For the next time i promise that i'll check better the list of entities in the Forge, that entity is there and explained.

Madfox, check 12914 again, i said start map, not hip1m1 map. :) 

/*QUAKED func_bobbingwater (0 .5 .8) ?
Used to emulate water. To use, create a thin water brush and center it
on the water line of the body of water to bob. The amount of the bob
is the depth of the brush.

The hipnotic func_bobbingwater QC code is NOT moving water. You can create moving liquids but you will need a special QC/entity and extra functions in the client.qc file. 

if I wanted to stagger when monsters teleported in would I be best using trigger relay or something? I tried putting a delay key on trigger_teleport but it didn't seem to work :-/ 

I have a really complicated way of teleporting monsters into a fight in the map I'm working on. They're on a door that moves sideways slowly when triggered and they're separated by small walls that keep them from moving. As the door slides out from under them, they fall into the teleporter brush. Sounds complicated but I can teleport in pretty much any number of monsters with an adjustable delay using just 4 entities. Can be tricky to make sure they don't telefrag each other though because they all go to the same teleport destination. It could be set up to use multiple teleports though. 

@Cocerello - I compiled the hipwater.qc file with the bobbing thing, and original Q1 v106Qqc a new progs.dat.
I made a map with
classname func_bobbingwater
and copied a polyhedron tex +water02 in it.
It works fine and you can find the progs.dat down under.

@Sock - I'm not sure what you mean?
I compiled the hipwater.qc with old v106qc and proqcc, and played with a classname func_bobbingwater, and all goes fine.

you can find the hipwater progs.dat here 

I used the Pox Extras moving water in FMB-BDG2 that I released recently, and it was quite effective for giving the effect of flooding an area. There were some issues regarding viewing the surface from within the moving brush i.e. when you're swimming under the water, but this was eventually fixed within the map quite easily.

Search for 'moving water' in the Mapping Help thread for some details. 

@MadFox, func_bobbingwater is not a liquid, it is just a moving brush model with a liquid texture. If the player touches this entity they will fall through it.

@Mike, This is why I wanted to see your qc source, I was curious to know what stuff you used. I had a look at the Pox stuff and the func_water is very interesting. I like the idea of switching gravity to emulate being inside of a liquid, I have a different solution luckily! :) 

Is great, we included it in RMQ as well.

func_watertrain and func_water not only work, but also have other controls like giving the player drag or force (flowing river) and a custom c-shift for mud / blood / whatever. 

Sure, the pox mod has these advantages also.

But it doesn't have the easy-way of extracting one qc file and add it to your own. At least there are three other files involved, so the tweaking gets harder.

I used the func_movewater in several maps but it only works for small sized brushes.
Also sad the watertexture doesn't animate.
I made a special texture for it.

Adding the pox mod to my own map included a large quantum of other funcs I didn't need.

And afterall.., I got curious after Cocerello's question and then I started investigating.

Didn't knew the water effect of the hipwater.qc was only a fake for eyecandy. 

In the original Quake they used a bunch of trigger relays with delays (in e1m7 for the gibs fountain effect in the episode closing scene). To see it being used you can download the released map sources from Romero and see how they timed it. It's mostly set up in the room that the player cannot get to. 

The Pox moving water is not animated the same as standard Quake but it does move.

I used a brush that was 2496 x 960 x 272 without any problem.

I didn't use the 'mangle' (current) as the player has to turn several corners whilst under water.

The easiest way to use the Extras is to incorporate them all if you don't want to fiddle around. I think my progs.dat ended up at 750 - 800K, and I had most of the Extras in there even though I ended up not using much of it in the game.

I thought it worked quite well (although that's only my opinion). I don't recall anyone making any comment about it, so it must have been acceptable to everyone - can you imagine someone here NOT saying something if it was tosh? 

Hey guys, sorry if this thread already brought this up before, but I'm making a new game and I want to make some new map textures. I can get as far as getting all the textures into netradiant but for some reason they won't size properly.

They do connect and cover the whole brush in a pattern but they are way to big. I tried experimenting a bit by including some PK3s from Xonotic and they sized correctly with no modification, but when taken out of the PK3 they did the same as my textures.

I also tried the surface inspector but that only downsized them to a certain degree. Any help? 

Apparently there is a 0.1 sec delay at path_corner's due to this pesky bugger in SUB_CalcMove:

if ( (tdest == self.origin) ) {

self.velocity = VEC_ORIGIN;
self.nextthink = (self.ltime + 0.100);
return ;

}

and it's adding some stutters to my...um...special setup. :) 

The only way I can see to do is use some kind of hack to run SUB_CalcMoveDone on the func_train as soon as the new destination is reached. The difficulty is seeing where you might stuff the hack! There's no way (I know of) to set a custom "use" field on an entity which is SOLID_BSP, as all the functions which make an entity SOLID_BSP change the use function at the same time. Have I forgotten a way where you set SOLID_BSP as an entity key and then find a function which runs setmodel without changing the solid status? Negke?

th_pain and th_die are easily applicable to a standard func_train, but you'd need some way to prevent anything else inflicting the damage. Similarly touch is going to be useless if you need the player to stand on it. think and think1 are used by the func_train anyway, so they're out.

Best bet I can think of is trying to make one func_train style entity which surrounds and follows another, damageable func_train. Then you. The inner core is damagable but the outer core protects it from general attacks. The only thing which ever gets a chance to attack it is a hacked info_notnull which goes off inside it when you need to skip the delay. The details there are a bit vague though, like how to make one func_train follow the other. 

press 'P' - brush - default texture scale
.shader scripts can change default scale of individual textures 

and a custom func_train_qma or something...only problem is that I want support for a handful of quoth monsters too. I guess I can decompile the quoth progs and create my own mod and scavenge the models and sounds. Anyone done that before? Not exactly ideal though. 

I have to have an exact number of path_corner's for set1 in order for it to mesh properly with set2. Having an exact travel distance is no issue, but I really really don't want to have to recalculate the whole setup again to get rid of the hiccups on what would be a smooth operation. 

How many decimal places does qbsp retain in entity fields. For instance I'm using a wait value of 5.639025 (Don't ask) and I'm wondering if it's getting rounded because I'm getting some wierd behavior. Also, do all objects start on the same frame? Like monsters on walkpaths, func_trains with no targetname, etc.? 

Forget it! Don't even try to pair func_trains up when their travel paths aren't exactly the same length and same # of corners. Must be some sort of engine rounding bias because at first it will work perfectly fine, everything all lined up. But after several loops it gets out of sync one side or the other. I managed to zero in on a figure that works for about 10 loops: 5.6390295 but I can get almost 15 loops out of 5.65. ???

Back to func_door chaining...boo 

qbsp saves all entity fields as strings; and i'm pretty sure it just copies whatever is in the map file without changing it. (though there is a limit of 1024 chars per string, but you're definitely not hitting that limit.)

In-game the wait time is stored as a 32-bit float, which should almost store your exact value. According to this page, your value of 5.639025 will be rounded to 5.6390252 or floored to 5.6390247, both of which are very close. 

Quake uses standard 32 bit precision floating point values for all entity fields. That's 23 significant figures in binary - good enough for about 7 places in decimal. So yeah, not nearly enough for what you're trying to do. Also remember that your set-up will break if one of your trains gets blocked by a player for a few frames, and the other doesn't. Custents has a synchronised func_train entity which is designed for keeping multiple trains in lock-step - the example they build is an escalator.

Interesting side note: the engine does track some quantities in double precision. One of the most important is the server time. Since it's constantly having small increments added to it, there's a need for higher precision. QC of course can't access the value at the higher precision, but it still benefits from the better tracking.