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. 

 

so, clip brushes can't move. anyone got any suggestions for how they... could?
(I have a ladder, func_door, which moves up/sideways, but I want the player to be able to climb it easily (ie normal rapid clip brush stairs) once it is in place. Any ideas? 

but the player is exposed, and would have to be very careful. And I don't want to piss people off or force them to play a certain way. I do that enough already. 

Texture them with skiptex, and skip 'em! ;) Effectively a clip brush which can be funked. 

thanks
that is a very good idea
but, I'm afraid, then the wily (or just curious) player will randomly walk up these invisible stairs before the visible ladder (func_door) is in place? 

actualy wait maybe I'm misunderstanding
if I can func_door a skip brush and make an invisible yet clippable brush which can have entity functions that would so solve my problems. 

Just move the invisible 'func_door ladder' into position at the same time as the visible ladder :) 

you can totally put clips in func_doors. 

This works, but there are special things you need to do.

The main issue is that only the visible brushes of the func_* will be used to generate a bounding box that is used for physics optimization. So if a clip brush sticks out beyond that bounding box, players and monsters will be able to walk through it. If the player enters the bounding box, THEN they will correctly collide against all brushes, including clip brushes.

So, the thing you need to do is make sure you have visible brushes that extend in all 6 directions (+X, -X, +y, -Y, +Z, -Z), so that your bounding box is correct.

For example, a visible ladder that has clip brush stairs -- the visible brushes are already tall enough and wide enough, but the front of the ladder is the problem -- add another brush somewhere (maybe below the floor) that extends forwards as far as your most forward clip brush. This will force the bounding box to be correct. 

Isn't there a catch with clip brushes - that they don't count for the 'extents' of their entity? So you need conventional brushes to mark the outer edges of the entity.

None of this applies to skip brushes though, so that will work fine. Remember that skip blocks rockets but clip doesn't if that matters! 

For the record, I think this is a qbsp bug, but an engine could theoretically fix the data at map load time. 

That's what I was getting at. I even posted the shorter post this time round and still got sniped... 

so if you had custom progs that let you manually set bbox size, you could have clip brushes beyond what qbsp would set as the bbox then. 

Not sure actually... I'd have to check the code to see, but I think the bounding boxes generated by qbsp and used by physics are seperate from the boxes set in quakec using setsize(). But maybe not.