Yes, it's indeed related. If the door isn't triggered, everything works as it should. But why? 

door_fire expects to be called from the master door in a set of doors. Just make sure that the hacked door entity has owner set to itself - you may need to include a copy for each skill configuration which includes the door if the entity number changes in different configurations.

Two comments on setting that field right. Firstly, the higher up the list of entities you can put the hacky door the better, since there's less chance the entity number will change that way.

Secondly, there's a good chance you'll be screwed over for coop by this. Single player reserves only 1 entity for players, but coop has to reserve up to "maxplayers" entities even if that many have not connected yet.

Best thing to do might be to create two version of the door, one for a server with maxplayers 1 (the single player version) and one for maxplayers 16 (the maximal coop version). One door would have an owner 15 greater than the other. Then killtarget off whichever one will crash the game using the coop detection trick as soon as you can. People who want to play coop would have to set maxplayers 16 for it to work - I don't think there's a way to detect server capacity through qc.

Good luck! 

I'll just remove the entire puzzle on coop. Let's see how I can squeeze the additional entities in... on skill 2 the map is practically on the edge of maxedicts.

A reminder that I shouldn't forget to coop test my maps in the future. 

As neat as the coop detection hack is, I can't afford it. In fact, I'll have to solve it the cheapest way possible with a simple killtarget trigger. Is there by any chance a way to make a trigger that removes itself after a while if it isn't touched? 

Yeah, turns out that's pretty simple. Just add

"think" "SUB_Remove"
"nextthink" "60"

to a regular trigger_multiple to get it removed after 60 seconds. The counter will go away if someone triggers it. 

I actually tried that but with an into_notnull and the trigger touch/use fields which didn't work. I thought the trigger_ entities' think field was locked to InitTrigger. 

does scaling up textures on triggers and other invisible things (clip even?) reduce lightmaps?
what about skybrushes?

i do this out of habit, but i don't remember if it actually does anything or not. my gut tells me yes but i've been wrong about stuff like this before. 

Hmm I think invisible things are ... immune? ... to lightmaps. At least, that would make sense to me. Not sure about skybrushes, but being fullbright I would assume it too wouldn't matter. 

triggers: yes

clips: no

skies: no 

thanks!

yeah, in retrospect, it makes sense that clips wouldn't as they are only part of hull1 and 2. and skies are treated as liquid i guess?

but yeah, thanks for clearing that up. :) 

I just gathered my wits and lost them again...
Did recheque my last map and saw I scaled up all skymaps an clips to reduce lightmaps as I was on the 32768 brush limit.

Must I use a toppicname now again? 

32,000 brushes? That's one mighty big map; mighty f'kin' big. 

 

Oh well. 

Yes, the map had 2954 brushes and marksurfaces were at the limit. (about 32768 I think)

But again, does it reduce the lightmap count scaling up clips and skytexture?
Triggers I understand, but after a half year I don't know why I took that much care. 

skip doesn't work when it's external bsps loaded from an entity? shit made me very very sad. :'( 

 

... 

Ah, i see why that fails.

The world model is rendered differently from bsp entities. So, to make skip work on both types, a different trick is used on model 0 versus models 1 and higher.

The problem with external bsp models is, they are model 0 in the bsp file, so newskip applies the trick that makes worldmodel skip work, but the game renders them as entities, not worldmodels, so the trick doesn't have any effect.

It is fixable, but i'm not sure how easy it would be. Worst case is we would need a special command line option to tell the skip tool that it's dealing with an external bsp model rather than a level, and process it accordingly. 

aw that's too bad. mostly it would have been great in helping to light the bmodels but you can still do it fairly well by making all the shadow casting walls 1 unit behind the world geometry in the actual map. 

hmm... what were you trying to do exactly? 

well, i've been replacing some brushwork in my map with external bsps.

at first, i was just replacing 'object' type brushwork, like a pillar or coffin type of thing.

but my map has a lot of high roofs as well, and while they may have fancy precompiled light cast on them, dynamic light should never touch them, so i was planning on replacing all the ceiling zones with external bmodels. unfortunately, recreating the lighting in external bsps means creating the brushwork to cast the shadows. having the ability to make invisible walls would have been awesome for that.

but like i said, i've made do with pushing shadow casters 1 unit behind the map geometry. it's still there, but you just don't see it. 

I have a set of very fast-moving func_trains to fake an animation (flag in the wind). Their speed is set to 4000 and they stay on their target position for 0.1 seconds. Despite sv_maxvelocity being 2000, the high value does the trick; setting speed to 2000 would make the movement visible.

This setup works suitably well in many engine ports, but not so much in Glquake and direct derivates. In those, there's a visible delay, the trains move out of sync - it looks like sometimes two 'frames' are shown (wait at the target path_corner) at once, then one remains empty. Each of the three 'frames' start at a remote spot, then move to a delayed path_corner (wait 0, 0.1, 0.2 respectively), then to the flag pole one (wait 0.1), then loop with another remote one (wait 0.3) and the pole.

What could be the reason for this different behavior? 

I realize it's probably hard to tell without actually seeing it for oneself, so here, in the castle map. 

i don't know what's wrong, but i don't think sv_maxvelocity has anything to do with it.

the reason a bmodel warps from one spot the another is because of how it's coded in qc.

when a movement is called, qc determines the time it will take to get to the destination. if it finds the time taken to get to the destination is less than 0.1 seconds, it simply does a setorigin instead of actually moving it.

that said, i have no idea what's going on here... have you tried making the flag frames have a targetname and them triggering them?
might be some hiccup while the map is spawning that the trains have slightly different times? i dunno. really wild guess there.