/n /n /n

/n
/n 

/not 

it does? i have used stuffcmd a lot, i honestly don't remember it doing that. :( 

Maybe changing the gravity is a special case ... it actually lies too. It says gravity has been set to the older value instead of the current one. It's a major troll. 

stuffcmd ( player, "sv_gravity " );
stuffcmd ( player, ftos(self.count) );
stuffcmd ( player, "\n" ); 

You should use servercmd instead of stuffcmd, because in coop the player may not have the rights to change server settings. Not sure if it spams the console less... 

My QuakeC has never heard of servercmd or server_cmd ... ?? Google is coming up pretty dry as well. 

i think he meant localcmd. executes commands as if they were typed on the server's console. (stuffcmd is like if the player types it) 

http://www.gamers.org/dEngine/quake/spec/quake-spec34/qc-menu.htm

is useful. i remember printing this out way back... lots of nice info in there and easy to sort through. see 8.10 for localcmd. 

Thanks for trying but, no, same ... 

Might be that changing gravity is just one of those things that Quake feels the need to tell everyone about. :) 

ohh bizarre, i just noticed that. i think that is the only (or one of the very few?) variables that, when changed, prints text to the console.

whelp, you can try mfx's suggestion of just adding 3 extra '/n's to push that output away, but they'd have to be on the NEXT frame, so you couldn't just do localcmd("sv_gravity 100\n\n\n\n\n");

you'd need to track when you changed the gravity, and then next frame run the newlines on stuffcmd for EACH client. ugh..... 

I tried setting it up so it would think 0.1 seconds later, jam 3 newlines in but it seems to ignore those for whatever reason. Nothing happens.

Unless there's an elegant solution, I'll just live with it. Chalk it up to Quake being Quake... 

Try setting .gravity on every entity individually? 

How does quake do it for e1m8? 

E1M8 is a QuakeC hack ...

cvar_set ("sv_gravity", "100");

I guess they don't care that it spams the message out. Or maybe you just don't notice it during the level load, I dunno ...

It's right at the very top of "void() worldspawn" ... 

yeah, i think at the time that command is run, the player isn't spawned in yet, so they never receive the message.

try using metl's suggestion of setting .gravity while cycling through every entity in the map with find()... it's goofy, but it'd work quietly. 

Some time recently, either in this thread or modeling help (I think), someone (probably preach) talked about ways to make an entity out of more than one alias model, and have them move in sync via quakec trickery.

It's not a hard problem at all - unless the entity is an AI being moved around by the navigation code. then movetogoal might not succeed for all parts of the collective entity because some of it will collide with something and the rest won't, and you'll get a discontinuity. Constant setorigin()s are laborious and not fully reliable, especially in the above case, and polling/setting velocity will lead to weird one-think lags after direction changes. Maintaining yaw is just as bad.

It might actually have been some CSQC or FTEQW extension? Nobody documents anything over there so it's impossible to just look it up.

My parameters are that I'm okay with one entity being the collision master and all the rest being nonsolid, but if the 'master' is still being driven by ai_forward()s and all that the 'slave' has to react accordingly. 

A better way to ask (with some forethought put into it):

movetogoal() in quakeC is called during the think cycle, but it's evaluated during physics/touching, correct? So if the master does an ai_forward(20) at an enemy 10 units away, physics will move it 10 units (until the boxes touch). If the slave is thinking in tandem (and it should be if it's also trying to match frames) then it will already have thunk by the time physics gets around to the master's SV_MoveToGoal(). It can't see that little bit into the future physics cycle to know how far its master is going to move. So, is it impossible? Or have I got this wrong? 

no, the 'physics' of the ai moves are done as they are called. this is how you can use walkmove and get a return value on if the walkmove was successful or not.

this means you can recursively or iteratively solve walkmoves in a single frame and you don't need to rely on child entities to think for themselves. you can have the master run all the thinking on its children so make sure everything is synchronized. 

btw: movetogoal does not return anything, but you can just check if the origin of the entity after you called the method is the same as before. if they are, then it failed... 

How do movetogoal and walkmove interact with model lerping? 

only seems to matter where the monster is at the end of the frame, not matter on how many times any of those methods were called. 

If you do decide to go down the setorigin route, I recommend use the EndFrame function from

https://tomeofpreach.wordpress.com/2014/05/24/easily-fixing-the-endframe-function/

This ensures no QC which runs later in the frame can desync your models. 

So my approach should be
- give each model the same origin for sanity's sake
- make sure the attachment thinks second, presumably by having the master itself spawn() the attachment so it's a higher numbered entity
- have the master be aware of how far it actually moved each think and notify its slave(s)
- maintain the same ideal_yaw and yawspeed on all parts
- do a final setorigin() in an end of frame function if necessary (wouldn't having the master setorigin() the slaves at the start of its own think have the same outcome?)

didn't ijed do something like this in RRP? with destroyable gun arms or something?