You also need to prefix description.ext briefingName and overviewText with @ not $ if you use description.ext over 3DEN, see
https://community.bistudio.com/wiki/Description.ext#briefingName
https://community.bistudio.com/wiki/Description.ext#overviewText

Cannot confirm the Title, it works as intended in my test, overview text on the other hand doesnt. Are you sure you save and export mission every time you make changes to the scenario properties in the editor or description.ext?

Should be fixed with nexrt dev update, please retest

There was a problem with sending BE messages, they would get dropped if you had packet loss.
Last week on prof/dev we changed them to be retried on packet loss. That should fix packet loss related BE timeouts.

Its a bit risky in case of script functions that for example return object on success and nil on failure.
If such a script drops a particle effect on error, it might then return an object as if it was a success. But who would drop a particle in case of error.

Mh after fix, it seems the mission failure doesn't work.
After the failed screen, you go back and see your character lying unconscious on the ground.
But I don't know how that compares to the before, as before it was crashing so maybe it was always like that.
You have to press Esc once, to trigger the actual endmission stats screen.

Yeah can repro by just killing myself with grenade.

It's not only what the command loadAbs returns. The double mass also prevents adding new items in containers, acting like real mass in that sense.

drawLine3D can easily get width. Style no

nvm it's fixed

In T181080#2613835, @dedmen wrote:

Would it be enough for you if getPlayerVoNVolume returned zero, when the player is muted?

should be fixed in next data update

should be fixed in next data update

Having this issue still in 2024, the player has the collateral damage objective cancelled despite not even being remotely responsible for it failing, as the enemy AI just decides to run over some civilian and the game counts that as the player's fault.

Also would be great to have the revive healing loophole fixed where people go down in order to get fully healed by the end of the revive, instead only full healing if they're healed for the same conditions as a normal heal would reach you to 100%(being healed by a person with medic trait + medikit)

This was not done by design, it is presumed to be done by design by the BI Wiki Editor, don't misconstrue.
It either way does not make much sense to change this value only when revive is enabled, as it would largely cause the Medkit(and the medic trait) to lose about half its effectiveness on the field which is being able to full-heal units.

Class: 'SurvivorBase'
Entity name:'76561198266859115' id:3554605

As it turned out, this was done by design see https://discord.com/channels/105462288051380224/108187245529268224/1251158707107139694

Can confirm in current dev, as script repro use steps

1. enable revive system see steps to reproduce ↑↑
2. start scenario as MP
3. exec player setDamage 0.3
4. use first aid kit or exec player addItemToVest "FirstAidKit";player action ["HealSoldierSelf", player];
5. exec getDammage player
6. result → 0, expected 0.25
7. try again 1-5 steps in SP, result will 0.25

Having a Weapon Muzzle Config Event version of the SlotItemChanged event handler would allow you to focus on the attachment changes for a specific weapon as opposed to having to listen to every change on the unit in order to find the event you're looking for. This would be extremely useful in cases where weapon classes must change in order to provide new animations that fit with the attachments added, similar to how RHS does their foregrip system.

Having a Weapon Muzzle Config Event version of the Weapon Changed event handler could prove to be useful in specifying scripts to run only when a specific weapon's muzzles are switched between as opposed to having to listen to every change on a unit and filtering them out.

Actually nvm, wiki says ligthAttachObject is not suitable for use on moving objects.

Because actually we cannot read a sound or a video stored in a PBO with a DLL.

Thank you Nikko, closing.

+1 on reading a binary file.

That command isn't for that type of camera locking. It's for when something's been locked with lockCameraTo, which is a different system to the aircraft camera stabilisation system.

It seems that this eventhandler is currently not able to be given to a weapon class like reloaded or fired can. Here is what I was testing: