what? 

.. sorry Von, I've been screwed by the green color of Fern's name. Actually post #12166 was for Fern :P 

I had the same on responding you for jtl.
Someone must have made that teleporter, falling out in small cubes. 

Is it possible to create an entity in Quoth that would sit and quietly emit a rocket/grenade trail? 

Search the teaching old progs dat thread. What you need is to assign a mdl - either the rocket or grenade (or create a new one which is empty but still has the rocket or grenade trail flags on) to an entity.

I think the method is to apply such a model directly to an info_notnull.

The difference between the two trail types is that the rocket has the glow decal. 

One caveat to that: non-moving particle emitting entities do not emit particles. :(

What you could do is make a one vertex model with an emitting flag set, attach that as a model on a func_rotate_train and have it move between two path_rotates 1 unit apart at a very slow speed. 

I know I'm usually the one suggesting hacks, but this case I'd say don't. Firstly because hacks are a problem in mods that might release a new version: either the people making the mod need the testing power of a major studio to catch potential breakages, or you run the risk of your map being broken by a patch. We don't have that kind of testing, so why take the chance?

The second reason you shouldn't use a hack is that there is an entity specifically for this purpose: mapobject_custom
http://www.quaddicted.com/webarchive/kell.quaddicted.com/quoth/quoth_tutorial.html#mapobject_custom
Make a model with your required flags and away you go.

Once you've done that you might find that no trail appears from an object that isn't moving. If so then look at spawning an invisible model with the grenade trail set using the info_rubble
http://www.quaddicted.com/webarchive/kell.quaddicted.com/quoth/quoth_tutorial.html#func_breakable

There is a model called air.mdl in the quoth pak which is intended for this purpose (it's the effect used by the polyp breath attack). 

ta for the info guys :) Will try it when I build up the motivation again :p 

negke mentioned that they have two skins... but I have no idea how to change the skin. I want one to match a blood theme and negke said there was a brownish one, which might work better than the red one. 

i think by just setting 'skin' to '1'. there's no 'official' code to support the skin.

incidentally, fitzquake allows -quoth which can be used in combination with -game, so you could make a mod dir with a new polyp skin and then you would run quake -quoth -game than and the 'than' mod files would override quoth files without interfering with quoth itself. 

Kell made a nice tutorial website you should read. Please have a look here http://www.quaddicted.com/webarchive/kell.quaddicted.com/quoth/quoth_tutorial.html ;)

For Vermis skin answer, please look here: http://www.quaddicted.com/webarchive/kell.quaddicted.com/quoth/quoth_tutorial.html#vermis 

I will try that (the skin 1 thing). I looked at a polyp with impulse 101, but I didn't spot any skin parameter so I thought maybe it wasn't suppported, and that negke was just dreaming.

JPL: thanks, the guide is very helpful (was already using it) but there are quite a few small things missing from the doc. 

Does anyone understand the Vermis?

I have placed the bottom of the Vermis bounding box 128 units below the 'ground' level. At that height, when I stand next to the Vermis he can't bend down low enough tp grab me.

Also, when on an elevated section and behind a wall that is low enough for me to see and shoot him without having to jump, he does not see me and continues to shoot at the last point that he has sight of me (before I went behind the wall). That means I can just move along the wall and continue shooting until I kill him without fear of being killed. If I jump up, he sees me OK but when I move along the wall again, he just carries on shooting at the last point and I can carry on shooting him with impunity.

Is this normal Vermis behaviour?
Is there an optimum height for placement so that he can grab me when I try to run past him?
Is there enything I can do to ensure that when I can see him, he can see me? 

The reveal scroll cheat is unfortunately only an aid to debugging map problems, rather than a real wand of revealing. It simply runs the eprint command on the entity which it finds. The rules of eprint are that it skips over the 100+ fields on the entitiy which are set to zero, and prints just the ones which have values. This means it's not very good for feature discovery, as you have to turn on the features before you can discover them...

What I will try and do is zip up all my "unit test" maps which are meant to thoroughly test all the quoth entities, to try and catch regressions in new versions. They are a useful reference because if you see something you want to be able to do in one of the maps, you've got a .map that demonstrates how (admittedly polyps with alternate skins are not part of that...yet). The problem is my existing hosting is about to disappear so I'm still working on a new home.

I will share one tip that I don't think made it into the mapping guide, and I forgot about until a few weeks ago so I'm worried I never posted about it. Quoth supports "flags" on the developer command. If you set developer 2 then all triggers in the map will become visible. If you set developer 4 then monsters with the teleport flag will be visible before they spawn (but blink on and off). You can add these flags together to get both effects. Developer messages appear at all levels but 0. 

negke never dreams such things up!!
(except sometimes) 

Is this normal Vermis behaviour?
Yeah, the vermis will shoot at the last spot it saw the player until it sees the player again.

Is there an optimum height for placement so that he can grab me when I try to run past him?
I just winged it every time I added it into a map; moved it up and down until it was in a good position.

Is there enything I can do to ensure that when I can see him, he can see me?
Not really. The vermis can only 'see' from a single point like all other monters.
Unlike all other monsters, it's huge. In ne_ruins, for example, I allowed larger monsters to 'see' from two separate points which helps them keep track of their targets better and reduces the chance of exploiting.
The vermis should probably have been able to 'see' from multiple points along it's vertical axis.
As it is, there is nothing that can be done. 

Oh bugger, another bright idea bites the dust! 

I notice in the released Vermis code:-

//if (trace_ent != targ)
// return FALSE;

Is that why it keeps shooting? 

no I didn't load a saved game, it happens when just loading the map from the console. Even if I quit the game, run qbsp+light from scratch, start the game again, and then load the map, the weird behavior persists.

it happens in every engine too jsyk

:( 

If I quit the game, run qbsp, start the game again, and load the map, it looks and plays terrific. If I quit the game afterwards, run light on THE EXACT SAME MAP, start the game again, and load the map, I get monsters in walls and floating above the floor. 

Apparently your brushwork is so terrible that it even affects something completely unrelated. Perhaps you might want to consider some subtle grid-love after all... 

Yes, for the most part. If those lines were not commented, it would stop shooting when you were out of sight.

Also, the vermis' 'eyes' are actually at '0 0 25' relative to the monster's origin (about where that bulb is near the middle of it).

also, it uses visible() in it's run function to determine is enemy_vis is set but then enemy_vis is never actually used.

Looking back, I was a pretty shitty coder back in the quoth days. :( 

No seriously I was going to do that anyway...
(even though this is AFTER snapping all brushes to the grid) 

Hook a fella up with your unlit and lit .bsp, not just for rubbernecking, I'll see if I can help, honest! 

No can do. Made a few modifications and utterly destroyed it. I *could* theoretically go to the most recent backup but I don't much feel like reconstructing so much work just to recreate the error it inevitably led to.

For your amusement though, here's what it looks like now. Amusingly enough, the number of errors actually GROWS when I remove brushes. wouldn't you expect the other way around?

http://www.suspenlute.com/stuff/raep.jpg