you are correct, it does loop forever.

doing sub_null is a good idea and I don't know why ID chose not to do that. it's possible that at the time they were doing the scripts that entities had to be 'active' with a nextthink and valid think to be able to move (this is how bsp movers work, for example).

what i prefer doing is to make an ai_dead() method that i run at the end of any monsters death anim. this way I can hook things in easily to all monsters and in this method, i'd just do a self.think = SUB_NULL; along with a self.nextthink = 0.

if you really want to be nuts, doing self.nextthink = 0 is probably the most efficient because that will cause it to never think with a single operation. but that's just getting silly. ;) ;) 

Got eeeem! 

So, here we are again ... Is there any way to use the "cvar_set" function without it spamming to the screen?

For example:
cvar_set ("sv_gravity", ftos(self.count));

Works great but it spams the fact that's changing it to the screen... 

is using stuffcmd an option? 

Good idea, but it spams the results too.

I mean, it's not terrible but it's less clean looking ... 

/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.