after working on for houres, I came up to this point, an animating newboss, without defend, freezing in its last stand frame.

http://members.home.nl/gimli/bos.dz 

The first problem I see is that the order of the frame macros in the qc file doesn't match up with the order in the model. You need to have the frames in the same order in both. This is because quake doesn't read the names of the frames at all, it only reads the numbers. The frame names are purely to make the code readable, and the compiler just assumes that, eg. the 16th frame you list in the qc file is also the 16th frame in the model.

So rewrite the frame macro definition to:
$frame stand1 stand2 stand3 stand4 stand5 stand6 stand7 stand8
$frame attack1 attack2 attack3 attack4 attack5 attack6 attack7 attack8
$frame die1 die2 die3 die4 die5 die6 die7 die8 die9 die10 die11 die12
$frame hurt1 hurt2 hurt3 hurt4
and the death/pain animation should be fixed.

If you want to stop it freezing and instead react when it sees you, try setting
self.th_run = newboss_attack1;
in the spawn function. Also, if you don't want that stand animation to loop like it does, change the last stand frame function to

void() newboss_stand8 = [ $stand8, newboss_stand8 ] {ai_stand();};
Notice that this is newboss_stand8, and the nextthink is also newboss_stand8 - it calls itself. That way it freezes, but not in the same way, it's still thinking every frame, just not changing. I don't think this change would work well for an actual monster as it is, but it's something to experiment with. 

I'm really knocked out by the fact for overseeing such a small logical factor.
For houres I stared the qc file, and the only thing I could find was another newboss.mdl in my progsfile with a base texture skin0 frame.

But this is great! Like with the rat it puzzled me so long what could make these monsters go. Again, thanks for your explanation.
Think I'll make me some extra frames for the stand animation.

I used a MOVETYPE_NONE to see if the monster should stand, but it seems to shamble away. 

At the moment, it's the ai_charge(10) lines which are moving the monster, as that instructs the monster to move 10 quake units towards its enemy. ai_charge(0) would stop it moving there. You don't need to make it MOVETYPE_NONE, but if you do it shouldn't move at all. I don't think it will drop to the ground when spawned if you do that though, so be careful. 

As it is a boss type in a lava suit it don't need to move. What I need now is a way to defend itself. Like giving it a missile to shoot.

I searched on Inside3d to look for some code to make it shoot. And although I found a lot of other fun stuff, the ai code soon made me aiai. 

probably the easiest way would be to just use the ai_run routine but with 0 distance, because ai_run does all the useful things like checking attacks and whatever. cheap hack, but it works. :) 

I agree with necros on that one.

As for making the missile attack, I'd look at the code for the enforcer, as it has a fairly basic attack. The important functions are

Laser_Touch : This is what the missile should do when it touches something. The entity it touches is called "other", so you can see the function deals 15 damage to other.

LaunchLaser: This spawns the laser, sets it up visually, sends it in the right direction and speed, and sets its touch to Laser_Touch.

enforcer_fire: This works out where to fire the laser from and which direction to fire it in, then calls LaunchLaser.

enf_atk1 - enf_atk14: These are the frame functions that animate the model. Notice how functions 7 and 11 call enforcer_fire, for the double shot the enforcer fires.

You should also note that the enforcer's th_missile is set to enf_atk1. If a monster has a call to the function ai_run, it will evaluate whether it has a shot at the player, and if it does will call it's th_missile. If it doesn't have one then this does nothing, but if it does then it'll change animation and start firing. Try mimicking this at first to get a working projectile, then adjust it to make a more suitable boss attack(more damage, harder to dodge). Don't forget that you can use the same frame in several frame functions, so newboss_attack1 can have the frame $attack1. 

That explains a lot.
Sad I don't get the other side of the qc surroundings, as I could imagine for what these resulting scripting is relaying on.

I tried pasting the enforcer's qc into the newboss, but as I expected, it results in a
***enforcer.qc:42: Laser Touch redeclared
***enforcer.qc:105:LaunchLaser redeclared

I also made The Mage from 3Dinside, and although the qc scripts was totally different, it worked straightaway I wanted.

For me its pure magic how these different qc scripts obtain these effects!
I reckognize the functions of these declarings Laser_touch, but as soon as I use a void() opening a script I get redrawn by wrong punctuation.
While The Mage relays on 75% of the Vormit, it is still an Unique_New Model. 

in the newboss.qc, Laser_Touch to something like
boss_Touch wherever Laser_Touch appears in that file. You could just place the Newboss.qc after the enforcer.qc in the progs.src and remove the declarations in Newboss.qc, but since you are going to be changing the attributes of the function you might as well start with a new one. 

Has anyone ever has vis crash while it was working? I ask this because, I have been full vising this one map for... 3 weeks now and it is still working on the same portal, for 3 weeks! I dont know if it crashed, or if its still working. And, would loading a map that has vis working on it disrupt vis, or make it crash or something? This is just getting ridiculous. I am using aguiRes latest utilites. 

If the map is complex enough, it is definitely plausable to be stuck on a single portal that long. 

Make sure vis is still running at full speed, check with Task Manager. Some OSs may pause the running application if you use the keyboard or mouse on the open console window.

It *is* unusual to be stuck in one portal for three weeks though, the longest time I've had was a few days. But so far it has always come through (at least on level 4).

How many leafs/portals do you have and how far has vis come? 

From what I see in the task manager, vis appears to be running. It's taking up 50% of my CPU, and every once in awhile its mem usage goes up by a few K. Sorry, I do not know how many leafs/portals I have in my map, how may I go about checking? But I will tell you, vis is at 61.61% done so far. And, is vis saving its progress while its working on this portal, or only in between portals? 

Why only 50%, normally it should be almost 100, do you have a dual CPU?
#leafs/portals is printed at the first lines of the console/log file and you can also see it in the .prt file (just a text file).

Unfortunately, vis is not saving while working on a portal, only in between them. You can see the last save time on the file date/time stamp of the .vis file.

Also, there's a rough progress bar for slow portals, has it moved lately? 

I do have a dual CPU, which is a good because I can do other things while vis is running. According to the log, I have 4500 portalleafs and 15354 numportals.

And that rough progress bar you mentioned, it started at "--". It has not moved since. 

Then there doesn't seem to be anything obviously wrong, you just have an extremely unfortunate map from a vis perspective.

Either you'll have to sweat it out, or abort and try to find out what's causing this problem. You might want to try to add -v (verbose) and run again, vis will restart that portal.

My latest vis version will print out the coordinates for each portal *before* it starts processing it and you can then use this to find the portal.

The coordinates are taken from one of the vertices of the portal and should hopefully help you locate it. Just note that a portal can be very small or big, so it might be difficult to pinpoint it. 

Why only 50%, normally it should be almost 100, do you have a dual CPU?

I heard somewhere that CPUs with "hyperthreading" technology can't give more than 50% of the CPU time to any one process. At least I think that's what I heard; it's been a while. 

My latest vis doesn't print the coordinates for the current portal in verbose mode; it prints the portal number. You can then use that to find the corresponding coordinates from the prt file (see also readme).

All the vertices of the portal are visible on the prt file line for that portal.

You can even do this check while vis continues to run. Just copy the bsp/prt/vis files to another directory and start a new vis session from there with the -v option and abort when you see the portal number. 

I think that's just an indication issue; I read an article that also noticed this and they checked processing times and they were OK. Otherwise the hyperthreading tech is more stupid than it has any right to be ... 

like this: http://negative.net.tc/images/fitz0004.jpg
how to get rid of them again? already tried changing the brushes, splitting them up, but to no avail. any universial remedy? 

it looks like either a brush problem (if it's like this before vis) or a portal problem. The cause is similar; bad brush junctions.

Zoom in close to see if they're on grid and also check neighbour brushes, sometimes a brush can "poke a hole" in another brush.

If you still can't find the culprit, try deleting neighbour brushes until the issue goes away. One or more of the deleted brushes are then the likely cause.

See also my ToolTips, Portal Problems.

If all else fails, send me the zipped map+wad and I'll take a look at it. 

After another session of my Q1map I see the light.exe produce a strange effect of dark and black shadows on my textures.
I didn't move one light, and before they were all smoothly lightened. 

my Light together with QuArK and its ETP map format, you could try adding the -etp option. 

That helped a lot, I keep learning tnese compile optoins. Think I squashed the map by loading it in an older Quark version.

I have made a VoreBabe and a Vore-egg.
I've been changing the shalrat.qc so it throws vore-eggs. I also made a working VoreBabe model.

But I can't figure out how to make these two in a shalrat.qc The VoreBabe I made startgo with the Spellmaster.qc
So I pasted the Ogre_Grenade_Explode into the void() ShalMissileTouch;
and it worked, the Shalrat started to throw eggs. But I wanted the VoreBabes get out of them, and that is just to high for my qc.

When I give the eggs a lifetime of 4 seconds, for let's say 2 Vorebabes, the Shalrat throws much too often. If I ever get so far spawning them out of the egg.
Looks like a Shalrarebit...
http://members.home.nl/gimli/shalrat.jpg 

Realising Quake 1 supports animated (.SPR) sprites, and knowing you can place a light entity that appears as a sprite... I need to make a few steam sprites to put by broken pipes.

Making the sprite itself should be easy (and I see FrikaC has some tool that supports SPR, but I haven't tried it yet to see if it's capable of making a .SPR)...

But my main concern is, how can I make it an entity to place in the map? If anyone has anything ready-made that I can easily modify art-wise (I'm no coder, so I won't touch QC), that'd be great!