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. 

thanks for the help/explanations guys, I think I have it solved (am about to test map).
I imagine negke (side note: negke weirdness rules) could do some interesting stuff with invisible movers (although it seems like a func_whatever can't be ONLY clip brushes and has to have some normal brush component). 

I just deleted a giant rant, but if anyone is willing to help me with a map or two, deadline QEXPO 2011, I would really appreciate it. Hell log the hours and I'll pay em back next fall. Once I finish my characteristically-Tronyn-stuff, I'm interested in checking out weirder ideas regarding Q1SP. I've loved the ULTIMATE DOOM ULTRA VIOLENCE view til now, but there are many other views. 

 

I am bad at some things and worse at others ;) 

negke would use skip brushes to define the bounds and go nuts with clips within. Remember, it takes only two tiny brushes to make it work.

negke weirdness 101: clip maze!!!

Tronyn: Yeah, what kind of help are you talking about. I mean, not that I would want to help a RANT DELETER...