Page MenuHomeFeedback Tracker

ServerCommandAvailable "#kick" (or more attributes) not returning true/false correctly anymore
Closed, ResolvedPublic

Description

ServerCommandAvailable "#kick" (or more attributes) not returning true/false correct anymore.

Engine is returning false regardless if the admin is logged and the command is called/spawned via init.sqf or UI.

This will potentially break many missions/mods/addons that had to rely on these checks as there currently is no command like isAdmin, isVotedAdmin, isLoggedinAdmin.

Details

Legacy ID
3360347798
Severity
None
Resolution
Fixed
Reproducibility
Always
Category
Engine
Steps To Reproduce

//////

  1. Put in init.sqf of any mission:

diag_log format["player object %1 | serverCommand #kick" %2 | isMultiPlayer %3",player,serverCommandAvailable "#kick",isMultiPlayer];

  1. Login as admin on a dedicated server and run mission
  1. See client RPT after mission start, it returns:

"player object B Alpha 1-1:1 (Sepp) | serverCommand #kick false | isMultiPlayer true"

//////
Funnily if the command is called via Debug console main window ("execute", local) it returns the correct value (true) to RPT for servercommandavailable "#kick". If the same command is run in the same console but in a variable watcher line (Watch:), its returning returning false.

Event Timeline

highhead edited Steps To Reproduce. (Show Details)Oct 14 2014, 1:32 PM
highhead edited Additional Information. (Show Details)
highhead set Category to Engine.
highhead set Reproducibility to Always.
highhead set Severity to None.
highhead set Resolution to Fixed.
highhead set Legacy ID to 3360347798.May 7 2016, 7:36 PM
highhead edited a custom field.

It is now truly returns whether or not server command is available. If it says false, this means executing serverCommand "kick" will also not work, where as before it was saying true, while serverCommand "kick" was also not working.

However as it happens, none of the server commands can be executed for real and servercommandavailable always returns false correctly.

Perhaps some server commands should be made available to admins only, this will solve the admin detection as well as make it possible to use those commands in scripts by admins.

It seems to work still in some cases, like executing it in debug console.
Or in conditions of CBA FlexiMenu.

is there another way to detect admins now?

Actually just managed to make both commands work, so don't panic. Hold on while I wrap it in some script solution.

We found a way with addDisplayEventhandler too, but its hacky

zx64 added a subscriber: zx64.May 7 2016, 7:36 PM
zx64 added a comment.Oct 14 2014, 5:55 PM

The underlying issue is wanting to know if a user is the server admin (either by voting or by logging in).

For the future, it might be more robust to have a specific, more discoverable feature (e.g. isAdmin) for this rather than being another "one weird trick". ;-)

Yep, the good news is you can execute admin commands kick, lock etc, which work when executed from UI event handler, i.e. button push, UI load etc. So one can make own admin interface available to anyone, but only logged in admin can use it.

here is my "hacky" way to execute those commands:

with uiNamespace do {
ctrl = findDisplay 46 ctrlCreate ["RscMapControlEmpty", -1];
ctrl ctrlsetposition [0,0,0,0];
ctrl ctrlCommit 0;
eh = ctrl ctrlAddEventHandler [

		"Draw",
		{
			with uiNamespace do {
				hint str servercommandavailable "#logout"; 
				ctrl ctrlRemoveEventHandler ["Draw", eh]; 
				0 = ctrl spawn {
					disableserialization; 
					ctrlDelete _this
				};
			}
		}

];
};

but as zx64 suggested, isAdmin might be a good solution for simplicity

You still cannot use #kick playerID or #kick playerName.
So I fail to see how it would help for an Admin UI.

Posting the result of your ui event handler to a variable defeats the purpose of having an engine command that you cannot tamper with.

Your solution is clever though and the only way I currently see to fix all the scripts relying on serverCommandAvailable.
Thanks for sharing and being so responsive.

The issue remains though that you want your scripts to react on whether you're an admin or not.

"You still cannot use #kick playerID or #kick playerName."

Yes you can

pressing the kick button on the map will kick you by uid:

with uiNamespace do {
ctrl = findDisplay 12 ctrlCreate ["RscButton", -1];
ctrl ctrlSetPosition [0,0,0.5,0.1];
ctrl ctrlCommit 0;
ctrl ctrlSetText "Kick";
ctrl ctrlAddEventHandler ["ButtonDown",
{

		if (serverCommandAvailable "#kick") then {
			serverCommand format ["#kick %1", getplayeruid player];
		} else {
			hint "You need to be logged in as admin to do this";
		};

}];
};

Whereas this code can be used to hint/print if a servercommand is available when simulation runs, or a button is pressed it cannot be used in a regular function, that just checks the adminstate... The first also throws all kind of deserialization errors if wrapped in a function or called in debug console on dedi.

Also when trying to use that code snippet in a function with a global var beeing set when the EH fires just fails, as obv. the draw EH doesnt fire at the same time when the function is called...

To be clear:
What is now broken/disabled and desperatly needed is a similar functionality like serverCommandAvailable "#kick" was, that determines if a client is the admin.

ergo...
_isAdmin = serverCommandAvailable "#kick"
_isAdmin = call fnc_isServerAdmin
_isAdmin = isAdmin (future)

Of course I am happy if someone in here manages to write such a function with the workarounds stated above.

Nice, I had tried directly in the code of the dialog, using the "action" property and it didn't give any result.

Good to know it'll work that way.

@highhead

Well, the draw event can be used to refresh the content of a variable "isAdmin" which you can use in a high_fnc_isAdmin function while waiting for a better solution. At least that's what I'm planning on doing.
I think it's the CBA which used a hidden map object to trigger code on each redraw. I'd do the same with the snippet above.

yeah i figured out that much, putting a loop/EH on a player that gets setvariabled each frame or each userInput :)

It's working for me until we find something better.
At least I have less refactoring with that solution.

Thanks again to Killzone for those useful informations!

Happy it works in your case, Tyrghen! I will share anything for the situation in here, as soon as I find it!

@highhead you can make it call back the function you need after check. But yea isAdmin is needed, I see Iceman is on the case!

isAdmin isn't optimal as there are two different admin types (logged-in vs voted-in)
so more like command returning the type (not admin, someadmin, anotheradmin)

Dont forget badmin and madmin :-)

Anton added a subscriber: Anton.May 7 2016, 7:36 PM
Anton added a comment.Oct 15 2014, 6:37 PM

Is this just a case of waiting for some period and then the serverCommandAvailable function works to detect if you're an admin again, or does it have to be called from a UI handler?

I'm trying to work around http://feedback.arma3.com/view.php?id=21163 by detecting if the unit is an admin in script without any UI necessary and only allowing Zeus in that case - I was planning to do use the serverCommandAvailable command to detect admins (of any type) by whether they could #kick.

Is there a pure-script workaround for this?

SINE added a subscriber: SINE.May 7 2016, 7:36 PM
SINE added a comment.Oct 16 2014, 3:15 AM

Thanks Anton, I hope to receive the answer, too.

This broke #adminLogged, which was used for the Zeus module f.e.

Hey, the command will be reverted and should function as before on Steam Dev rev. 127800 and higher. Could you please confirm that it works as it is supposed to? Thank you.

Thank you, working again in DEV! If there is an alternative (and usable) method for admin-checks/actions im sure serverCommand/Available can be removed fully. Thanks again! And I would really appreciate if deploy an hotfix so this gets to stable.

PS: You also fixed ZEUS #adminLogged with it ;)
http://feedback.arma3.com/view.php?id=21163

dazhbog added a subscriber: dazhbog.May 7 2016, 7:36 PM

serverCommandAvailable now behaves as it did before and a new command serverCommandExecutable has been created that can be used to check if a command can be executed via serverCommand (https://community.bistudio.com/wiki/serverCommandExecutable).

Will the fix be implemented in a hotfix for 1.32?

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.