Preach, you've shown before how any info_notnull could be turned into a custom ammo/health/armor. Can it be combined with the triggerable trigger hack to create spawnable goodies? 

Ahh you probably don't follow our conversation :) I want to make hackles map, with entities supported by Quoth. In Quoth you can set health/ammo to respawn in MP-like style. What I would need is spawning on demand.
I did few ammo hacks, for example stealing ammo from a player. I think spawning ammo should be doable through notnull, but as I said, I'm looking for some legit solution :)
Now I'm just using invisible lift with quoth's respawn option :P 

Invisible lift with health on top, to be precise. 

The current accepted way to do it in Quoth is to use an <a href="https://tomeofpreach.wordpress.com/quoth/tutorial/info_groupspawn/2>info_hordespawn</a>. Set both "spawnclassname" and "spawnfunction" to the classname of the item you want to spawn. This will be supported in future versions of Quoth.

And yes, we know it's a bit clunky, the next version of Quoth will have much better support. 

The current accepted way to do it in Quoth is to use an info_hordespawn 

I totally didn't thought too put there other classname than enemy ones. 

What is the technical reason behind this warning?

I suspect it is this, though perhaps Tyrann, ericw, Baker, or Preach (the coding gurus I know of on here) could correct me. When the map is portalized, it gets sliced into 3d volumes called leaves (leafs?). Each leaf is then used for the vis calculation to know what gets drawn. I suspect that this warning occurs when you have the intersection of multiple generated leaves such that the intersection forms a new leaf out in the middle of empty space with nothing in it.

Is this correct? 

First time I saw this warning was when I used a polygon to clip out another one.
I think it has to do with the way the map is divided into leafs.
I'm not a binair but I think it is a warning one of the vertices is openend for another space. 

I've been googling the past hour off n on and can't find the engine console code to do that. 

Whenever I see that error I usually just move or change some brushes near the error message coordinates. Usually that will fix it. But not always. Sometimes with complex brushwork I've had to convert parts into a func_wall.

On the other hand, it's just a warning. Most of the time it's hard to find any actual problems that it's causing. 

@madfox, that sreenshot doesn't show the leafs, that's just "r_showtris 1". To see the leafs you need to use darkplaces and "r_drawportals 1", or some editors can load the .PRT files.

When the map is portalized, it gets sliced into 3d volumes called leaves (leafs?).

Portalization is about reconstructing polygons that are the "portals" between adjacent leafs. This happens after the BSP tree is built, so the map is already sliced into leafs at that point.

My understanding of that warning is, the BSP tree structure indicates that there should be a portal here, but the clipping process (which is not exact) used to reconstruct the portal ends up clipping away the entire thing. So it probably is a very small scale error that you can ignore. I'm not totally sure though. 

In fte quakec development suite I'm compiling my famous progs.dat, I almost so ignorant about that theme, so my first solution was delete all qc's than I'm not using, as grapple.qc, hipdecoy.qc, holes.qc, etc. But every time compiling with hipitems.qc, mult_wpn.qc and more qc's, the holy TE_EXPLOSION have an error I don't know how to solve... 

As I remember it's pretty much what Eric says - a portal somehow ended up inside a leaf and therefore got removed. It's similar to 'leaf portals saw into leaf' and has no or marginal negative consequences.

Probably shouldn't even be a warning, just an 'info'.

Jonison - the files you deleted are still being told to compile by the list in progs.src.

Even if you remove them from there, most likely there are references in the rest of the code as well - see what the compiler complains about and then comment out /* */ the references one by one. 

I am adding /* */ to all errors, but to ALL qc fails of the progs.scr? 

You could, but you're removing lots of code there - things will stop working.

I meant remove the files you deleted from src (so it doesn't try and compile things that don't exist) and then comment within the qc files anything that has dependencies elsewhere.

It's a surgical job - you can comment out entire files, or just odds and sods within them. 

there are a lot of console calls, I'm just thinking of developemode. Is there a start before other console notes work? 

 

Is there a way around this?

I had "safety nets" as trigger_teleports at the bottom of the map in case of player falls. The ranger just falls right through the trigger. Everything is linked as it should. Is this a known issue or is there a workaround for this? 

Having said trigger_teleports with targetnames renders them to only shoot off when triggered. I was hoping I could kill them off as map progress happened. Oh well! 

How about adding an overlapping trigger_multiple which activates the teleporter when the player touches it? 

Alternatively, if you're using Quoth, you could use the targetname2 field to name the trigger_teleport, which won't change the behaviour of the trigger but will enable you to killtarget it. 

That is exactly what I did last night, I just didn't want to triple post haha. That is what happens after "jamming" for many hours in one sitting I guess! The trigger_multiple works perfectly and since they area already in place, I'll just keep it that way.

It is nice to know someone would have came up with the solution if my brain didn't' attempt one final push last night! 

Any way to killtarget a func_illusionary?

Want to pass through a transparent field that "turns off". I have the transparent field as a func_illusionary so I can pass through it.

I have a work around that uses a func_wall and the kill trigger is just a few units before passing through the field. At this point, I am just curious. 

In Quoth, you can change the classname to mapobject_custom and it should work the same but with the ability to killtarget it. 

Again, works...no questions asked. Thank you, it is much easier than to do the func_wall hack.

Okay, on a roll another one:

Kill a play_sound? I searched and found to toggle a sound by playing a null.wav on the same channel, but what about flat out ending the sound.

Example:

Object emits a sound, if you pass through it the sound will stop. There would be multiple instances of this object throughout the map. If this can't be done it is not a big to do, I can work without it.