I guess I'm going to stick to my trusty "_player addScore (_newTotal - score _player)"...

I believe that addScore should never trigger HandleScore, or otherwise minimally have a boolean passed to the event code that says if it was triggered manually.

The most likely use for HandleScore is to cancel out all score changes done by the engine, so as to manage scores manually via addScore.

there was recent note on changelog, stating that HandleScore can now be triggered by script. This was added deliberately, addScore didnt trigger handlescore before.

Heres a vid of it doing it

https://www.youtube.com/watch?v=1I6mot5vr2M&feature=youtu.be

I suppose it depends on the damage that is done to the systems. Thanks for your support.

Not entirely, but there's only so much BIS can do in terms of damage models for such a simplified version. However, gauges... That's another story, maybe. I'll up vote to help the cause because I would like to see advancements in certain areas.

Wrong, when your instruments are destroyed, you are no longer able to recover warnings such as incoming missiles.

I didn't talk about missile warnings, but the instrument systems like the indicators and gauges. Having only missile warnings disabled when you've taken a direct hit to your helicopter's instruments is very unrealistic.

ups! tried to search for it but didn't succeed in finding the other report of the issue.

dublicate of http://feedback.arma3.com/view.php?id=21141

@Fireball,

1. Helicopter blows up.
2. Helicopter in fire.
3. You don't hear any explosion sound or sound of fire.
4. You hear only engine failure sound.
5. Engine failure sound plays twice in xH-9 crash.

To be honest, I found the old sound (which was way too loud and sounded like a unfinished sound loop) much more horrible and am happy for the change!

True, the short amount of time isn't work putting in effort to change the sounds when new ones will be here so soon.

Yeah I see your point but why should they change the sounds so short before the will be replaced anyhow? Either they want to try out the new samples before they are an official Part of their DLC or they want to keep them for the new Sound model. But however they need Feedback for this so they can see how the new sounds work. And even if I am totally wrong it can't be bad for them to know what the community thinks about their recent changes.

I hope they have volume sliders on helicopter sounds - to help with hearing TeamSpeak or in-game voice comms.

Probably, we will not see massive enhancement in sounds because heli DLC will be published in 20 days.

Edit: they are working on sounds, and you may notice a massive enhancement difference after the heli DLC.

Yes I know but right now it sounds unrealistic and I wanted them to know.

Yep this issue is fixed. Nice :)

Sorry, I forgot to crouch and then try to lower and raise the gun. My fault ;)

Duplicate http://feedback.arma3.com/view.php?id=20964

It's still possible to raise the weapon while crouched by pressing LMB, but I agree that you should be able to raise it by double-tapping LCtrl as well.

That issue is resolved in the latest dev branch 1.35.127847

Duplicate of http://feedback.arma3.com/view.php?id=21029

related to http://feedback.arma3.com/view.php?id=21144

@Koala

Tried it with the todays small patch, still bugged.

I can't reproduce the issue in the latest stable branch. Seems to be fixed.

Iceman, the campaign cheat would be solution if this was case only for some people, but I think that everyone have this problem. Take a look at this - http://forums.bistudio.com/showthread.php?184306-New-Update-Can-t-resume-campaign

You should hotfix this.

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.

Can you please create profile with unlocked campaigns in zip format and place a download link here?

I have the same problem with campaign reverting. But also after I reset campaign I can't restore mid-mission save with same "Cannot load campaign descriptions" error.

Thank's Iceman

I used the cheats to unlock all the campaign, restart the last mission and all ok now.
I cross my fingers !!!

@Iceman, there is no Numpad keyboard on my Macbook Pro, which is needed to enter cheat codes. Is there any other way to enter it?

Hello,
this looks like some compatibility issue. We did not encounter it during our testing (and we switch between branches really a lot). As a workaround, please use a campaign unlocking cheat and revert from the last mission you have played. Thank you.

https://community.bistudio.com/wiki/ArmA:_Cheats

Well, I tried to create a new profile and add activeKeys[]=
{
"M00",
"M01",
"M02",
"M03",
"M04",
"M05",
"M06",
"M07",
"M08",
"M09",
"M10",
"TT01",
"TT02",
"TT03",
"TT04",
"TT05",
"TT06"
};
but it doesn't help.

Also, I see that in my previous profile that array contains all missions I passed.
So, probably the problem with new update is that is ignores that array. Probably, it was replaced with something else.

Mine has reverted to Signal Lost aswell.

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.

Alright updated the wiki page

Same problem since update 1.32.127722:
cannot load campaign description from bank
Windows 8.1 64

That is because Firing from vehicles (as a feature) is present only on dev branch. It will be merged into Stable along with the Helicopters DLC release.

If identical, as Lachesis580 points out, then mods should probably close this one.

yeah, please close as DUP.

http://feedback.arma3.com/view.php?id=18341

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.

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

Will the fix be implemented in a hotfix for 1.32?

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

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.

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

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

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.

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?

Dont forget badmin and madmin :-)

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)

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!

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.

"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";
		};

}];
};

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.

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.

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". ;-)

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

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

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?

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.

related tickets:
http://feedback.arma3.com/view.php?id=19535
http://feedback.arma3.com/view.php?id=20009

It has been acknowledged and the dev team is aware of it.

Have you seen the Glitch fix video? http://youtu.be/kynv_woKPTo?t=1m54s
I think as a first iteration(hotfix) it would be enough.

Hey,
thanks for the report, I made it private already.