lordheart

It is possible to copy the settings (I.E. frequency from one radio to another) via the ctrl + p menu, which was done specifically for this.

userconfig folder will go in the root of A3 install, there should already be a userconfig folder there.

If you could send me the mission that would help me discover what the issue is.

Looking into it now. ---------- Post added at 19:26 ---------- Previous post was at 18:38 ---------- I have done some changes which I hope fixes that. I did a couple of tests and confirm that it is working as expected but getting feedback will help ensure that is true. Also fixed the optional pbo not working properly. Version 1.1.1 Changelog: Fixed optional crate pbo not loading correctly Fixed dead gunner in weapon being dragged with weapon Fixed required addons, fixes being unable to drag placed items.

@pergor, the next version allows setting of default value for tf_no_auto_long_range_radio in the user config on the server. This should help in that regard.

http://feedback.arma3.com/view.php?id=3028 http://feedback.arma3.com/view.php?id=1726 Are the open duplicates of those issues

@nsnipe, https://github.com/michail-nikolaev/task-force-arma-3-radio/issues/513#issuecomment-40549772 I am however unsure of how to verify Game Cache of a server.

It would appear that this issue is similar to https://github.com/michail-nikolaev/task-force-arma-3-radio/issues/513 could you perhaps try to verify Game Cache for the server? I will look at the code in the specified area to see what could be causing it if it isn't due to some corrupt data file but I will only be able to do so in a couple hours.

The file must be in the userconfig folder located in the root of your Arma install. Similar to this: D:\Steam\Arma 3\userconfig\LHM\LHM_glasses.hpp

If you don't mind, what is the modline used for the server?

If you take a ItemRadio or Radio (it is under items) it will automatically convert it to the correct radio for your side.

The known duplicated ID issue, is when 2 players end up with (to the mod) the same exact radio. It's hard to tell if this has happened without actually checking if players have the same ID (the ID is a part of the radio name, so that's how you know which ID you have). It would cause issues if one person changes their radio frequency, channel, etc. it will be replicated on the other player's side as well. It's possible to avoid this by ensuring that you get new radios from crates, using VAS and passing on radios from there usually results in duplicated radios (unless you take care to take a new Radio and not simply loading a loadout).

@clawHammer, have you ensured it is not the duplicated ID known error? It will help us to focus our scope on the bug. If you could pass along the RPT file when this happens it could help us to discovering what is the cause.

Are you saying that the pbo's aren't on the server just keys for it? The server needs the whole mod on it

I will ensure to make it more clear. Let me know if you come across any issues.

It doesn't add glasses, it enhances the glasses and gives them an actual function in game.

A big thank you to Foxhound for hosting. Everyone else be sure to check their video on LHM Glasses

@Corporal_Lib, I have not yet. However, support can be added from either side. It was designed to be modder friendly to allow other modders to add visual effects so they don't have to go through the process of setting it all up and accounting for various factors. @Sonsalt6, thanks for updating it on PWS.

For the crates you listed, support is added added with the optional PBO, I did run a dedicated server on my pc to test to ensure everything was working. To turn on the optional PBO, simply move it and the bisign file to the addons folder of @LHM_staticdrag. I hope this helps.

Update 2.2.1 Changelog: Reduced and adjusted various glasses colour Fixed dust appearing on screen for seemingly no reason Adjusted the handler for when to remove the effects when killed Made changes to how dusty surfaces are calculated should work across the board now. Dust in eyes has degrees of effects

Well you will be happy to know. Update 1.1.0 Changelog: Russian translations (thanks NKey) Spanish translations (thanks Kavinsky) Added weight restriction to dragging of objects (prep for crates) Renamed functions to be more agnostic as to what is dragable. LHM_Static_MaxWeight variable added (default 800) for dragging weight. Locking of static weapons when dragging to disallow players to enter it (reverts back to old lock status when dragging stopped) Disassembling weapon will stop drag. Added mortar support (might be fragile to changes by BIS) Added an optional PBO (LHM_StaticDrag_Crates.pbo) that allows dragging of Box_XXX_AmmoVeh_F, XXX_supplyCrate_F crates. Added support for dragging of smaller crates limited by "weight" Fixed dragging and lowering/raising of height on a dedicated server. (I hope) Added variable "LHM_DisableDrag" checking if an object can be dragged or not. example usage: crate1 setVariable ["LHM_DisableDrag", false, true];

There will almost certainly be an update before Wednesday, whether that includes crate dragging as part of it remains to be seen however it will be possible to enable crates to be dragged by calling: this call LHM_Static_fnc_InitialiseWeapon; In the crates init, at the very least.

@SpanishSurfer, I have made improvements to the system, so it should work on ammoboxes, I won't include direct support for ammo boxes at least not in the current method of doing it. Very often mission makers and the like do not wish for ammo boxes to be moved so by enabling it by default forces them to have to work around it. I will take another look into the mortar thing and see what is possible.

@Gundy not currently but it should be in 0.9.0 which is currently in development.

@kgino1045 Correct