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. 

What you need is a feature of play_sound_triggered which wasn't written up in the tutorial (until just now!). You need to set spawnflag 1 to make the sound toggle. You also need to set a wait value, so note the workaround in the article if you are using a sound file which loops by itself. 

Thanks Preach, that worked. Another hurdle I found is I need to trigger those sounds when semi-close to the source or it will cease to play. I remember that issue with the waterfalls way back when.

Easily done though. 

Hoping it fits in this topic.. I have to say that all Fitzquakes do not work with Minigl 3dfx drivers .
I need that because I play Quake on a rather old pc and need those extra-frames ! 

Hey there, I'm currently finally learning how to map thanks to the awesomely user-friendly program that is Trenchbroom and I'm having trouble using Necros' compiling GUI. I've set my working folder to trenchbroom\maps and my output folder to quakespasm\id1\maps but when I compile a map, it stays in my working folder and isn't copied to my output folder, which prevents me from testing it right away. I have to copy the bsp into my game folder, run the game and then load the map all manually, which hampers my productivity and makes trial-and-error quite a chore. What am I missing? 

Did you specify your map file in the working folder? I don't have the program open right now but you need to tell the GUI the actual map file you are using as well...not just the path to where the map is located. 

It is under the source map section of the GUI, below the LIGHT section. 

Yes, the map name is specified in the source map section. 

Maybe check permissions on the map path?

Could you share a screenshot of your GUI setup? I can't pinpoint an obvious issue. 

Check permissions on the map path? I don't quite get what that means or where to look. I'm no computer whiz and I need things to be user-friendly. Also, currently my only internet is on my phone so it would be difficult to share screenshots. 

I think since Quake writes save games into its own folder that pretty much anything else should have access also. 

Also, could you just use the maps folder for the .map files in the first place? That's how I've always done it. Well, sort of. 

Copying to output destination is final step, maybe when it fails one of the previous steps, it never executes copy command and bsp stays in working directory?
Just a guess...