trap_SendConsoleCommand problem

[torhu]

I use trap_SendConsoleCommand to send button presses to the server, for a couple of things that need to be fast and reliable.

I do it like this:
trap_SendConsoleCommand("+button14; wait; -button14");

This is being used for issuing commands to bots on your team or something in TA, so I figured it's a good way to do stuff. Button commands seem to register faster on the server than sending commands as strings. And it's done exactly like this in the vanilla code.

But the problem is that sometimes the '-button14' part doesn't seem to work. Maybe every once 50 times you use it, button14 gets stuck in the '+' state.

Would it help to just add more 'wait' commands, or should I send -button14 a few times later in the code, to be sure?

I can't reproduce this reliably, so it would be nice to get some opinions before I start testing.

[4days]

remember from scripting rather than programming that there were problems with the length of a 'wait' value (so one person might have a script with 'wait 5' but someone else would need 'wait 10' for it to work).

have you tried spending some time ordering bots around to see if the same thing (not working 1 in 50ish times) happens?

[torhu]

remember from scripting rather than programming that there were problems with the length of a 'wait' value (so one person might have a script with 'wait 5' but someone else would need 'wait 10' for it to work).

Seems to get even worse if I do that. Not better anyway.

have you tried spending some time ordering bots around to see if the same thing (not working 1 in 50ish times) happens?

Not yet.

EDIT: Seems that if I do just trap_SendConsoleCommand("+button14;-button14"), it works better. Haven't been able to reproduce the bug with that script yet. But isn't skipping the 'wait' command supposed to be a bad idea?

[^misantropia^]

How about sending the "-button14" command at the beginning of the next frame? That ought to eliminate all timing issues.

[torhu]

Isn't that what the wait command is supposed to do? I guess I could try, but...

[^misantropia^]

Isn't that what the wait command is supposed to do?

Not quite. wait n merely postpones execution of the command until the n-th call to Cbuf_Execute (qcommon/cmd.c, might be called several times each frame). Using a high value for n isn't a solution because you'll block all commands.

[Silicone_Milk]

How about sending the "-button14" command at the beginning of the next frame? That ought to eliminate all timing issues.

Really does seem like the best solution to the problem.
I say just try it out and see if your problem is still there.

[Timbo]

I'm not sure I understand why you don't just use a server command?

[torhu]

This stuff is part of the weapon selection in the mod (wq3). It's got a Half-life like system where you get a menu that you select from, and then click fire to choose, or alt-fire or esc to cancel. So when cgame opens the weapon menu, it has to notify the server that the next +attack will be to select a weapon, not to fire. Otherwise you fire anyway, because you can't stop the button commands from reaching the server (afaik). And if you set cgame as keycatcher, you wouldn't be able to control the player while switching weapons.

I'm not sure I understand why you don't just use a server command?

That was the original system:
trap_SendConsoleCommand("wp_choose_on\n");

Problem was that the server didn't always get the message. Maybe it drops them on high load or something? Think I tried using trap_SendClientCommand() instead, without much improvement. But I may recall incorrectly...

I replaced it with this:
trap_SendConsoleCommand("+button14; wait; -button14");

Which solved the original problem, but created a new one. button14 sometimes stays in the 'on' state, it seems that the "-button14" part doesn't always work. That means that weapon choose mode is constantly reenabled on the server, and you can't fire the gun.

So for the fix (I hope):
What I've tried now is to have the server not reenable weapon choose mode before it has seen -button14 first. So button14 has to go down, then up again. Then I only need to make the client check that button 14 is set to 'off' when the choose mode is enabled, otherwise send "-button14" again. To make sure that choose mode works the next time around. It seems that the "+button14" part always works.

This solution hasn't failed so far. When you're in weapon choose mode, the following code is run in a function called by CG_DrawActive. delay starts off at 1 each time you enter choose mode, so the check is run every other frame.

Code: Select all

if (delay & 1) {
	cmdNum = trap_GetCurrentCmdNumber();
	trap_GetUserCmd(cmdNum, &cmd);
	if (cmd.buttons & BUTTON_CHOOSE_MODE) {  // is button14 still depressed?
			trap_SendConsoleCommand("-button14");			
	}
}
delay++;

Might seem like overkill, but just sending "-button14" once, on the first frame after the initial "+button14; wait; -button14" got sent, didn't work every time.

[Timbo]

Problem was that the server didn't always get the message. Maybe it drops them on high load or something? Think I tried using trap_SendClientCommand() instead, without much improvement. But I may recall incorrectly...

sv_floodProtect 0 (iirc). You then need to reimplement flood protection in game. Q3's flood protection is a complete pain in the ass, and rather crude -- it just drops things on the floor at the first opportunity, without any queueing or anything.

EDIT: http://svn.icculus.org/tremulous/trunk/ ... &view=auto
Search for commandQueue_t.

[torhu]

I rediscovered sv_floodprotect just a day or two ago, so I haven't quite looked into that yet. Was kinda hoping I hadn't gone through all this trouble for nothing. Do you happen to know if it's per client or not? Because sometimes it seems to be very easy to trigger, if that's what's going on here.

About you flood protection link - I would have to consider if it's ok for us to put GPL code in the mod at this point.

[Timbo]

I rediscovered sv_floodprotect just a day or two ago, so I haven't quite looked into that yet. Was kinda hoping I hadn't gone through all this trouble for nothing. Do you happen to know if it's per client or not? Because sometimes it seems to be very easy to trigger, if that's what's going on here.

Of course it's not per client -- it's a server setting.

About you flood protection link - I would have to consider if it's ok for us to put GPL code in the mod at this point.

If you're doing a standalone version as your sig tends to imply, this must be GPL too and thus it is OK to include other GPL code.

[torhu]

If my fix works, which has so far, it's easier to just keep it, and still be able to use sv_floodprotect like before.

Of course it's not per client -- it's a server setting.

So you're saying that if one client sends too many server commands, the server might drop commands from other clients too? Just curious.

If you're doing a standalone version as your sig tends to imply, this must be GPL too and thus it is OK to include other GPL code.

I'm not quite sure about this, is the consensus here that you can't release a GPL engine while keeping the mod (vm) files non-GPL?

[Timbo]

So you're saying that if one client sends too many server commands, the server might drop commands from other clients too? Just curious.

No I said the setting is server side meaning you can't enable flood protection on a per client basis, which is what I thought you meant. The flood protection mechanism itself is per client.

I'm not quite sure about this, is the consensus here that you can't release a GPL engine while keeping the mod (vm) files non-GPL?

If your "new" engine is simply Q3 without any changes it's definitely a grey area. If the mod requires features of the engine it's less grey (in favour of the GPL being required). Suffice to say, I don't really understand why you'd be intent on doing this, and you'd be highly likely to get a pretty cool reception within the development community. If it's some notion of protecting intellectual property you can forget it -- pretty much everything possible has been done already in mod space. If it's wanting to prevent forks you can forget it -- forks are only going to happen if your mod is excessively popular; forgive me but I don't see that being an issue with WQ3. If it's believing that keeping the source closed prevents cheating you can forget it -- the engine is open now so writing a cheat is more or less trivial.

[torhu]

If your "new" engine is simply Q3 without any changes it's definitely a grey area. If the mod requires features of the engine it's less grey (in favour of the GPL being required).

Our current plan is to have compatible mod and standalone versions. Which means that our custom exe won't have any custom features that the mod relies on, nor the other way around. Just generic bug fixes and enhancements. The mod part would be equal in both cases. The standalone would come with pk3 files to replace the vanilla q3 ones. But we're still debating this.

This way, we avoid the need for wq3 servers to use custom executables. And we allow people which own q3 to use wq3 as a regular mod, so they can use it with ASE, xfire etc, like before.

The reason I asked about keeping the mod part non-GPL is that we know there is a possibility of forking, even withing our small community.

[^misantropia^]

The GPL is viral. If you add a single line of GPL'ed code, you will need to open up your entire code base.