Well, I looked over everything and I'm certain I did things right. You forgot to mention I need to work with the ZOMBIE.MDL by putting it in a progs directory.

So, in the map - the zombie is completely stationary and not in crucified pose. Yet he moans like he does when in that pose. Also, I triggered him and he didn't move to any path_corners I set. I even removed the trigger_once and walked up to him, but nothing happened either. 

...if you want a hack for multiple explosions using one button then tie sequentially named func_explosions (fe1, fe2 etc.) to trigger_counters with increasing count numbers but the same name. 

...that might've been a bit confusing.

Make the launch button target a series of trigger_counters named "missile", but give each trigger_counter a higher count value than the last. Now make each trigger_counter target a different func_explosion... to make things easy, get the trigger_counter with count 1 target the func_explosion with the name fe1, trigger_counter with count 2 targets the func_explosion with name fe2 etc. 

The misc_zombietrain shouldn't moan at all, unless that's some bit of code you've added. There are no sounds that automatically play with certain animations, and the misc_zombietrain doesn't even precache them, so they'd only be loaded if you had other zombies in the level. Could you make a quick testmap with just a misc_zombietrain and a few path corners, and see if you get the same result? 

What I originally didn't realize I needed to do, was rename the monster_zombie to misc_zombietrain and set the fields. I just tried and it works well.

Though, is there anyway to have him in his crucified, animated pose while retaining his train functionality? Or at least how might I have him stationary but in the crucified pose? (He's just stood straight up). 

I may not have been clear enough in my explanation of how to edit the zombie model. You need to duplicate the crucified animation, and only make the second, copied version of it into a framegroup. If you do that, the framegroup should be frame 198 of the zombie model, and so the line that sets the zombietrain's frame to 198 will make it animated while crucified. I'm guessing that the problem is your modified zombie doesn't have a frame 198, so it loops back to frame 0. The first crucified animation should remain as individual frames, as the normal crucified zombies need those frames to be seperate. 

I'm pretty sure that's how I did it, but I'll try it again... 

Is this what you mean? Cause if I do it how I understand it, the total frames goes to 204, not 198:

http://www.phait-accompli.com/q/s4/pre/qme1.jpg 

One is that the total framecount by QMe counts all the frames in a framegroup seperately, so the last frame in the grouped crucifixion is number 204 according to QMe, but that's not how the quake engine will see it. Since the last frame is 204, the first frame should be 198. Since quake treats all the frames in a framegroup as one frame, they will all have the number of the first frame, 198.

Except....There are four other animations that are grouped in your copy of the model, painb through to paine. Each one of these sequences was 10 to 20 frames long in the original model. However, since they are framegroups now, they are each only one frame long. Which brings the total count of frames as quake sees it to about 140.

If you're using some other mod which requires them to be grouped, then you're going to have to work out which frame the grouped crucified animation is, and use that value instead of 198. Otherwise, ungroup them and it should work out.

Oh, and one more thing I should have said before but forgot, rename the second crucified sequence, it's possible it could cause a problem. I really should have put that in the first post, as it's not obvious you need to do it. What usually happens is the two sequences with the same name end up merged into one, but if one is grouped and one is ungrouped it may not happen. Still, best not to take chances and give it a different name. 

bspinfo -copyents %1
sed s/info_notnull2/info_notnull/ %1.ent > %1.edited.ent
copy %1.edited.ent %1.ent /Y
del %1.edited.ent
qbsp -onlyents %1.ent


The stupid copying thing is because I couldn't figure out a 'overwrite old file' switch for the rename command, and if you make sed output to to same file you input from you get a blank file and if you mke sed append to the same file you input from you get a doubled file. Not foolproof, but it works.
Get sed here: http://www.cornerstonemag.com/sed/ 

Should prove to be useful.

On an entirely unrelated not, I'm sure I remember once seeing a compiler for Q1 that supported a nodraw texture. But now I can't find it, did I just imagine it? If you know where it went please let me know, it would be handy for a mod I'm doing. 

Did you mean skip texture?

http://www.planetquake.com/tyrann/files/skippy-0.0.zip 

Thanks! 

Is there any obvious reason why performing a QC "monster in wall" check (i.e. !walkmove(0,0)) for fish should cause them sometimes getting moved way outside the entire Q1 addressable grid, e.g. (100000 10 5)? I've used this extra check for some time in vanilla Q1 without any obvious problems, but doing the same in Nehahra seems to be bad.

In this particular map (neh2m5), fish often swim through walls both with and without the extra check, but it appears as if the check sometimes cause them to really move outside the grid to completely invalid coordinates making them impossible to kill.

Oh, and has anybody been able to run the Nehahra QC build tools in WinXP? I can only run them in Win95, they are some Borland DPMI apps. 

If you delete the original ent file first, you can rename the new one without problems. It's the same number of batch lines, but it's slightly faster as there's no data movement. Not that it matters much with small ent files though ... 

I can't seem to find a working link for "Remaic" - a Quake demo editor allowing camera setups and different perspectives, etc. Might anyone have Remaic Studio, or know a working mirror? 

Here:

http://speeddemosarchive.com/quake/downloads.html 

:) 

FOr those of you who have experienced cracks in your arches or pipework, here's a look at what causes the problem and how to remedy it.

1. Can see here cracks in the arch on the left and right of it: http://www.phait-accompli.com/q/s4/pre/prob_arch1.jpg

Here is the editor shot, you can see small misalignments: http://www.phait-accompli.com/q/s4/pre/prob_arch1-ed.jpg

2. And here the arch is fixed http://www.phait-accompli.com/q/s4/pre/prob_arch2.jpg
after straightening up in editor: http://www.phait-accompli.com/q/s4/pre/prob_arch2-ed.jpg 

What is the difference (or the different use) between self.think and self.think1?

I can find a definition of 'think' as "function invoked when entity must act
", but nothing for 'think1'. 

.think, as you probably know, is a special field according to the engine. When the local time on the server exceeds an entity's .nextthink, the engine automatically executes the function stored in .think.

.think1 on the other hand, is not a special field, it's an added field. If you were writing a mod from scratch, you'd have to include .think, but not .think1. The only time a function stored in .think1 is called is when the QC calls it.

So, when does the QC call .think1? Well, only in one place to the best of my knowledge, and that's in subs.qc, in the functions SUB_CalcMove and SUB_CalcMoveDone. SUB_CalcMove essentially calculates how long you have to wait while moving at a given speed before you reach a point on the line, and then sets the entity to move at that speed, and think at that time.

When you have a object like a door or a platform that moves to a destination point using SUB_CalcMove, you might want it to have a think function be called when it arrives. However, the .think function is already used up, because when the object reachs its destination you must call SUB_CalcMoveDone. SUB_CalcMoveDone basically sets the origin of the moving part to exactly where it should be, there might be rounding errors otherwise. So you store the other function you'd like to call in .think1. When SUB_CalcMoveDone is called, you'll notice it checks for a .think1, and executes it if it's there. SUB_CalcMove sets this .think1 automatically.

Oh, and SUB_CalcAngleMove does the same thing. So two functions use it. Generally if the object isn't some kind of a door or bsp object, it won't use .think1 at all. Monsters, for instance, use their own navigation code rather than this function, so think1 is just empty. Which is a bit inefficient really, it seems like you could merge one of the th_stand fields with think1 and save an entity field. Oh well, the quake QC code wasn't really written with total efficiency in mind... 

I've been trying to make a spiraled hollow pipe using the 0:2 2:1 1:2 2:0 ratio (the standard czg/spog/fingers curve). Now, CZG's curve tutorial (http://czg.spawnpoint.org/curv_tut/curv_tut.htm) stops one step short of this. The last pic he shows is of a spiral platform, if I understand correctly, but I want a curved pipe. Help please? The idea is that I want to have a solid cylinder core with a ascending curved pipe wrapped around it, that the player can walk through.

While I'm on the topic of that tutorial, many of the steps CZG goes through in that tutorial, based on worldcraft, seem impossible given my current understanding of radiant, which I am now using. You can't stretch or skew multiple brushes such precise amounts... or can you?

So... prefabs, ratios, more tutorials, etc would be much appreciated. I've been banging my head against a wall for too long on this. 

I've been thinking of such things too. Go up a few posts and checkout my bit about cracks appearing in arches/pipes as you're bound to encounter those.

Maybe I'll see if I can do what you're describing, but it'll be tough. As for Radiant - would holding ALT while dragging a vertice do it? (guessing) 

Thanks for your help: little by little I am getting to grips with QC. 

AguirRe - I'm confused as to how to change the width of a spotlight. I did it once a long time ago, but after reading the readme for your lighting tool, and fooling around - all I can seem to do is move the spotlight's angle around - it doesn't get any thinner, which is what I want to do.