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. 

i watched it for a while, it seemed to start out in sync and then when i had a framerate hiccup due to my antivirus scanner kicking in, that made it get out of sync.

I'm not a quakec expert but I think keeping movers in sync implicitly using just timing like this might be framerate dependant. If so, maybe you can script it so that each frame explicitly triggers the next frame, ensuring that they'd stay in sync (is there a message fired when the train arrives at a path_corner, for example?)

Or maybe they could be func_doors instead of trains, that stay open for 0.1 seconds and have an extremely high "speed", and trigger the next door 0.1 seconds after they are triggered (using delay maybe). 

yeah, i'd try out metl's suggestion using doors and trigger_relay daisy chain.
those will be guaranteed to always keep things in time. 

Should one trigger (a trigger_counter in this case) be able to activate a 'target' and a 'killtarget'?

I am using one to do both but it does not activate both - it will do either/or but not both.

SUB_UseTargets suggests that it should do both? 

I think there is a bug that they can't both work from the same entity.

Create trigger_relay to do the killing part and that should solve it.