Stupid Questions: AllowCommand vs. CommandFallBack

[Argh]

Meh... some stupid questions:

1. What is the difference between the two things, in terms of how Spring handles them?

2. Why is it that CommandFallBack is required for stuff that you want to be queue-able?

3. What do the return parameters mean, and in what contexts should they be used (talking in particular about "return true, true;" etc. here)?

[KDR_11k]

again...

AllowCommand is called when the command is given, before the unit's queue is altered. The return value is whether it should be let into the queue (I think it blocks it if any gadget returns false and doesn't ask others after that). The queue remains untouched when a command is blocked, whether it would be queued or replace the queue.

CommandFallback is called when the unit reaches an unknown command in its queue (i.e. one not handled by the engine). It returns the two values used and finished, if no gadget returns used as true the command is dropped since it seems noone knows it, if a gadget returns true,true the command is removed because it's done, with true,false it's kept in the queue and CommandFallback gets called again on the next slowupdate.

[Argh]

All right... makes sense. So AllowCommand's where we should evaluate whether to run a given command, and CommandFallBack is where we should put the operations done when it is allowed.

So, for example, if you want to require that before running a command called CMD_PEANUT_BUTTER a given Unit runs a function, in this case "memberJellyGroup"...

Code: Select all

function gadget:AllowCommand(unitID, unitDef, team, command, parameters, options)
	if command == CMD_PEANUT_BUTTER then
		if memberJellyGroup(unitID) then 
			return true 
		end
	end
return false
end

Which would then, if true, allow for our custom command to do some game logic:

Code: Select all

function gadget:CommandFallBack(unitID, unitDef, team, command, parameters, options)
	if command == CMD_PEANUT_BUTTER then
		DoSomethingNiftyHere()
		return true, true;
	end
return false
end

And yes, I apologize if it seems like this has been explained before, but I got bits and pieces from you and from jK, and it wasn't terribly clear. Meh, I got it all working, but I like knowing why it's working. Although I must say that... it almost appears there's no reason to use AllowCommand at all- you could simply have a logical branch between evaluated states, one leading to a given result, one returning true, true and posting an error to the user, or waiting for the next SlowUpdate.

[imbaczek]

there's a reason - AllowCommand intercepts all commands; CommandFallback only receives unknown ones. Use the first one to check whether targets are valid, etc, and the second to do the stuff it's supposed to. Also, AllowCommand happens on the exact moment a command is given; CommandFallback, as you noticed, only when the command it tried to be executed. If a command is invalid and you don't check for that in AllowedCommand, it'll show up in the queue, which will confuse players.

[Argh]

By "unknown ones", you mean anything that's not defined in the Spring executable, correct?

[imbaczek]

aye.

btw, by "invalid", I also have "inserted by LuaUI in a way that causes buggy, exploitable behaviour intentionally" in mind, e.g. placing attack orders in midair to extend range of some weapons. custom commands must carefully check for such conditions.

[KDR_11k]

Or using two parameters to a CMD_TYPE.ICON_UNIT_OR_MAP command that only checks for the second parameter to decide if it's a unit or a map position...