You've hit the nail on the head, in my opinion, PiepMGI! BI were informed that the onDrag EH (CT_ListNBox) was broken in the development branch three weeks before the public release of 1.48 and failed to fix it. It is arguably the most important EH for that CT, I know of several missions and modifications that rely on it. Modifications were obviously made to the CT because there are references to them in the changelog, but instead of asking the developer who made the changes to take a quick look and see what could have broken it they decided to simply release the patch with the bug and throw the developers that rely on it into the wind. The development branch is there to avoid these exact issues from occurring. You cannot simply break, to the point of complete failure, previously working commands/features in the development branch and then ignore the reports (or assign them to developers and forget about them) and release them into the public domain. Community developers spend hundreds of hours of their own time developing missions/modifications for Arma 3 and it is completely unacceptable to ruin their work through pure laziness!

If something that was previously working breaks in the development branch then obviously a modification has caused this and it should be fixed BEFORE the public release. Contact the developer that was working on any related issues and ask them to take a look! It's common sense and basic professionalism!

Please fix this. It's one of the most commonly used control types and has been working since the alpha. You should have really fixed this bug before releasing 1.48, that's what the dev branch is for.

It's been functional for as long as I can remember. The "canDrag" config property is even supported for ListNBoxes so it seems to be intended behaviour. I've attached a mission demonstrating onLBDrag (via config) and LBDrag (via ctrlAddEventHandler) working for pre-1.47 builds. As soon as you move to a >=1.47 build it'll stop working.

• spawn LNB_fnc_openDialog;

Can this please be fixed? It's a really annoying oversight for complex dialogs...

I believe I explained a little incorrectly, I was referring to the scrollable overflow are rather than the actual controls group itself, but looking at those examples I see that the intended use is slightly different than I imagined. But I'll find a work around. Thank you for the reply.

The fact that onDrop doesn't fire on controls inside a controls group does need addressing though I think. I've made a mission and uploaded it to this bug report:

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

Ah ok, the extremely poor documentation was the cause of confusion. The wiki actually explicitly states that this EH shouldn't work the way it does...

I've tried every workaround I can think of and I can't see a way to accomplish this. Please add a dedicated command or fix magazinesAmmoFull so that the magazine loaded state only returns true for the selected throw object.

Hopefully BIS decide to reconsider fixing this issue because I've seen several mods that have simply had to stomach it and it really degrades the aesthetics of the engine.

Indeed. Either the attachTo needs to be fixed or there needs to be a way to control vehicle lightpoints by script or there needs to be a command that utilises the same method the vehicles use to "attach" lightpoints because that method seems stable.

I'll try that Killzone but when I tried manually setting the position before the result was much worse than attachTo.

Unfortunately that method seems less accurate.

Here's a video showing the lightpoint being elastic. It's a little difficult to see in that mission but the lightpoint does actually slowly move away from its attached position as well as appearing to be elastic (attaching it to a selection should let you see this more easily).

http://www.youtube.com/watch?v=YiNYBw6qT2o&feature=youtu.be

Make sure you're driving at >100-150km/h and then watch the lightpoint (it's much easier to see if you turn your camera so it's facing the side/top of the vehicle rather than from behind). I'll upload a video showing the issue tomorrow.

Surely there must be a method for achieving a stable effect because you're able to attach lightpoints in the vehicle cfg that don't have this warping issue?

Done, simply drive the offroad as fast as possible along the straight road.

There aren't any default ones but eventually I assume there will be and there may already be third party ones available. It seems like a problem waiting to happen for someone.

Yes, that's true. I assume that's the reason why the commands are currently missing.

Yes, I've mostly completed it now (the addons we use thankfully don't have any secondary weapon attachments but I can imagine that other's would have some serious issues without these commands being available).

Considering every other add command doesn't return an error with "" I'm not sure why this should be the exception? Simply remove the error.

The elastic "soft" version has obviously been implemented with the latest DLC but the ridged (fixed length with no elastic quality) one has not and is definitely required for ground vehicles! Please add it so we can finally create articulated vehicles!

I'll settle for these please, I'm recreating the A3 inventory system so these are really important and otherwise impossible...

removePrimaryWeaponMagazine player;
player addPrimaryWeaponMagazine ["Classname",AmmoCount];

removeHandgunMagazine player;
player addHandgunMagazine ["Classname",AmmoCount]

Plus, I know it's unlikely but...any chance of removePrimaryWeaponMagazine and addPrimaryWeaponMagazine ["classname",ammo count]...obviously for handgun as well...

Another thing that would be really useful because at the moment there's absolutely no way to do this as far as I can see...? Unless you can access player weapon containers (unlikely).

I just thought I'd keep this near the top of the list as much as I possibly can...only over 400 people want it implemented for A3 (so it shouldn't be a high priority)...

container addMagazineCargo ["Classname",Quantity,AmmoCount];
container addMagazineCargoGlobal ["Classname",Quantity,AmmoCount];

removePrimaryWeaponMagazine player;
player addPrimaryWeaponMagazine ["Classname",AmmoCount]

removeHandgunMagazine player;
player addHandgunMagazine ["Classname",AmmoCount]

Can we PLEASE have this? PLEASE japapatramtara! Not being able to add magazines with specific ammo counts to containers is really ridiculous and such a simple addition for you guys to make! I'm certain it would be really, really useful to a lot of developers!

That's the responsibility of the lead programmer at the end of the day.

To be honest I don't think them being marked as acknowledged or even assigned makes a big difference. Some reports have been marked as assigned since the alpha and are still not resolved and haven't even been worked on.

The project lead should be saying what are our assets and why are we popular and then focusing on those areas rather than saying let's focus on areas of the series that have never been popular. Arma is never going to have a better singleplayer than the AAA mainstream FPSs, they simply don't have the creativity or the resources. So why focus on it? There doesn't seem to be any direction for A3 at the moment. They launch a modification contest but don't actually listen to all the requests on the tracker for VITAL features/commands for the modification community. In my opinion someone who knows what they're doing needs to take command of the ship and actually lead.

We all live in hope :p.

The engine has the ability to add weapons/uniforms/etc to containers with items/attachments and magazines with ammo counts because you can do it through the inventory system. So it's certainly possible and already implemented, we simply need a command to be able to do it externally.

Quite frankly BIS's priorities are a little skewed. They're focusing on pointless modules/campaign episodes instead of working on what actually makes their game popular. Who plays the series for the campaign? Seriously. Whoever thought that was a good idea really should be looking for work.

They should be spending time adding comprehensive inventory commands, weather syncing, fixing severely broken actions, improving dedicated server efficiency, etc. Arma has two factors that make it popular and unique which are scale and its extensive modification focus. Two things BIS obviously aren't dedicating that much time to improving.

Exactly, AgentRev, I agree. It's obviously useful and I'd love to have those commands at my disposal but there are commands that are much more useful and should be a higher priority.

Keep it simple and we MAY actually get it. Obviously there's an "ideal" set of commands but let's get the ones so some things aren't impossible. Like adding weapons/uniforms/vests/backpacks to containers with items/attachments/magazines etc, adding magazines with specific ammo counts to containers, etc.

Please...PLEASE...add these commands! I'm having to do a workaround at the moment to add magazines with specific ammo counts to specific containers (uniform/vest/backpack/etc) that is truly painful and makes me want to cry.

Yes, exactly Outlawled!

There was a ridiculous number of suggestions in a ticket I saw a while ago but I'm failing to find it now. It had loads of comprehensive suggestions.

That's great japapatramtara, thank you. Being able to see the contents of containers is a good step forward. But we really need manipulation. All of the inventory/container manipulation suggests should really be given a high priority because their absence quite simply are holding back larger modifications.

Out of interest what issues are you trying to avoid in MP? The only issue I can see would be conflicting commands (i.e. players both requesting the same item at the same time) in which case all you need to do is pass the requests through the server.

Yes, it certainly would!

I have a question/suggestion related to the inventory system. Could actions please be added/fixed for the dropping of weapons and clothing because at the moment no such commands actually exist/work (DropWeapon/PutWeapon). Obviously a container can be created but you have to remove the attachments from the weapon or the items from the clothing in order to do that which is slightly annoying (by that I mean you have to create the vest and then add all the individual items/magazines but not associated with the vest).

Also, I'm not sure how this has been missed out for so long but there needs to be a command for adding magazines with a specific ammo count to uniform/vest/backpack AND/OR adding it to cargo containers. The latter only would be fine though since you could just use uniformContainer etc.

Once again, retaining the current functionality of removeAllWeapons is fine, it should be different but it's too late now. My point was that there should be a command to remove all magazines and remove all actual weapons.

The vast majority of missions developed for A2 wouldn't work in A3 anyway so I don't see it being that much of an issue. I don't particularly care but that command is essentially removeEverything and not removeAllWeapons. There should be commands for removeAllMagazines and removeAllActualWeapons.

Personally I would suggest also modifying "removeAllWeapons" to only remove actual weapons and then adding "removeAllMagazines". At the moment removeAllWeapons will remove all items, weapons and magazines from the player.

Killzone, there are many scenarios where you do not want to have to differentiate between the different types of item you are handling. A universal command to avoid having to do this is extremely useful and something I think many developers will agree has been lacking from the series for quite some time. Personally I am extremely pleased to see this being implemented as I won't have to implement 4 separate commands for adding and another 4 separate commands for listing, as well as any necessary type checking in between.

Basically, in this case, I think addItemTo has to include everything you are able to store in your uniform, vest and backpack. Otherwise you are essentially lacking addWeaponTo and addMagazineTo. And, quite frankly, having three versions of the commands in this case seems truly pointless. You would also have to add vestMagazines, etc etc.

So in this case I think the best option is to simply have addItemTo work for absolutely everything that can physically be in the uniform, vest and backpack containers normally. Basically everything that can be returned using vestItems, uniformItems, etc.

Great work. It's really nice to see the modification side of A3 getting focused on.

It seems this feature already exists in the "PUT" and "TAKE" EHs but they were both poorly documented and, at the time of writing, aren't consistent and need fixing.

Linebreaks are obviously supported within the engine for listboxes, tooltips, etc (the inventory dialog shows that) so can we please have them made available for us to use?

Doesn't look like it or any of the other twenty absolutely vital features are being worked on. Take On Mars and Zeus are much more important!

Yes, it definitely does work now. Thank you! Is there any chance of Killzone's suggestion being implemented?

player action ["Drop", weaponholder, inventory item, forceanimation];

So we are able to drop uniforms, vests, backpacks, weapons, etc?

I'm pretty sure most if not all developers would agree with Killzone's suggestion.

Does the action actually work now though?

The crash seems to be solved but the last time I checked the actual action wasn't working. When you executed the action nothing would happen instead of the crash.

I saw that a while ago actually Killzone, it's a pretty interesting workaround. But I've managed to find a different solution to that issue for what I'm doing at the moment. It'd simply be nice to remove the workaround.

Also, I know I've said this a handful of times already on the tracker but vehicleContainer and addMagazine with specific bullet counts for containers - please!

Yes, that would all be ideal! The weapon should only drop the single associated magazine and attachments.

I really wouldn't mind creating weapon holders manually, removing the items from the player and then adding them to the holder or visa versa...but we simply aren't able to do that. We aren't able to add magazines with specific ammo counts to containers, add items to vests/uniforms/backpacks while they're in a container, add weapon attachments/magazines to weapons in a container, etc. I don't particularly care which is implemented (ideally both) but one really...REALLY needs to be and quickly. Complete inventory manipulation is absolutely essential to any modification.

There needs to be a dropWeapon, dropUniform, dropVest and dropBackpack action and all of them should trigger the "Put" EH.

Almost a year....seriously? FIX IT! The internal command has to work properly for players to be able to drop their weapons so fix the bloody action command!

PLEASE fix this! The drop actions are ridiculously fundamental!

The pivot feature exists in VBS2 and has for quite some time. It would be nice if it was implemented in A3. I don't see a reason for it not to be considering it's already implemented in VBS2...?

That's like saying it should fire when you throw a grenade. It shouldn't.

Reloading really shouldn't fire this specific EH. That's not helpful though because items/clothing/equipment can be "taken" without the gear being open. I'm fine with there being a reloading EH but it shouldn't be part of the "Take" EH. The magazine is not changing container and isn't being taken or put by the player.

Yes but the vast majority of the time the magazine isn't depleted so you're just showing the switching of two magazines.

The "Take" EH fires when reloading. Could reloading please be ignored by the "Take" EH?

The fact that it doesn't return both the new and previous container is actually really irritating.

Thank you for taking the time to improve this EH, I think a lot of people will appreciate it.

In my opinion the EH should eventually return [unit,from container,to container,new item,old item].

from container - the slot/container the item was originally in
to container - the slot/container the item is now in
new item - the classname of the item moved
old item - if an item was replaced (ie a slot) then it returns the previous item's classname

Blocking the action with returning true/false would also be helpful.

Obviously these are simply ideas for the future when you have the time.

I don't think it's really a necessary feature for the EH. I scripted a 'restricted items' feature last night, it's really not that difficult.

Ideally it'd return the new classname and the previous classname as well.

There really should be a fully functional version for the community. Thank you for trying though, I think many developers will appreciate it. As long as it works in both cases for the main slots I think everyone will be happy.

The "PUT" EH fires for removing headgear but the "TAKE" EH doesn't fire for equipping it. There's quite a few situations I've found where either "PUT" or "TAKE" won't work but the other one will.

It would be really nice if this was resolved soon please.

I honestly can't believe this still hasn't been fixed! It's a pretty useful EH to a wide range of modifications. I can confirm the strange behaviour as well, it's not consistent at all.

It would also be nice if the EH returned the classname of the previous item as well as the new one.

This has always been a highly desired feature so I hope BIS actually does it this time.

Is this done passively or does one have to active it/place a module/etc?

Freeman_D my point wasn't to compare the two engines because you simply can't, they're entirely different. Plus this is a bug report/feature request relating specifically to weather so I obviously wasn't attempting to compare ballistics or player movement. The point I was trying to make is that weather should be relatively consistent for all clients in a commercial game of this nature.

Sorry, I simply had to jump on the wagon of pointless additions and add...

[end of discussion] :)

Of course I agree with you, ProGamer. But until that is implemented I would really be happy with even basic weather syncing for the time being.

It's a little disappointing. This should be a really high priority. You look at a game like Battlefield 4 and all the waves sync. It would be nice if the general weather settings as least synced in A3.

The only real issue with weather syncing is the overcast value because it takes time to simulate any changes due to the volumetric clouds. The rain, wind, lightning etc are really easy to set and are instant. Even using basic scripting you can advance the cloud simulation by using skipTime, if you were to use 86400 setOvercast 1 (making sure the overcast value will be 1 in 24 hours) and then skipTime 24 the overcast would successfully be at 1 and the time would be the same. Of course you would be one day ahead as well obviously, which isn't desired but that's fixable.

If you were to include a simulation "jump" to the current overcast value when joining the server and then simply update the forecast value and change interval time to the server's values and then instantly update the rain, lightning, wind, etc values every 60s then the syncing would be pretty decent. The environment would be almost identical on all clients. Obviously there would be variation in exactly where lightning struck or where exactly a cloud was but the playing conditions would be so similar that it wouldn't effect gameplay any more.

Simply a decent weather syncing feature so the conditions are identical. Keeping the overcast, fog, rain, lightning, wind, etc values consistent on all clients is enough.

There really isn't that much data to send though. Weather is an extremely important part of the environment and should be a high priority. It isn't superficial, it can impact gameplay drastically, especially in PvP. Plus the vast majority of mission designers will want weather synced so by not including the feature in the engine all they're doing is causing more work for community developers and an even less efficient system to be implemented.

You can actually see that command working in the txt file I attached. The forecast values change at different times.

Weather should always be synced by the engine. I can't think of any situation in any game where I, or any other developer, would want clients to have independent weather. It makes no sense. It's like saying the time and date shouldn't be synced so some clients can be playing at night and others during the day and others with a full moon and others with none.

I'm pretty curious as to who exactly decided that weather syncing wasn't a necessary feature in a multiplayer orientated game :p.

Plus don't get me started on the lack of documentation concerning weather. I spent a whole day simply experimenting to see what commands were still relevant. The fog, fogForecast and fogParams commands are amusing to get lost in :p.

I'm pretty sure the reason why that occurs is because when the client joins it uses the original mission values to begin with. But the values generated for the weather after this are completely random, I have tested this before in a MP environment. So if you both start the mission at the same time and the starting overcast value is 0.3 you will both begin with 0.3 but then your clients will independently generate forecast values randomly. So after 6 hours your client could have an overcast value of 0.9 and the other client could have 0.2. If a new client joins they will use the 0.3 default mission value and then randomly generate their own values.

Attached Weather.txt. You can see the values are simply generated independently, it's not a JIP/time issue.

Since the weather values are generated randomly the more clients on the server and the longer the duration of the mission the greater the chance of players having starkly different weather conditions. Occasionally one player may have 20m visibility because of fog and rain while another has blue sky and full visibility. That's creates ridiculous scenarios that should never be allowed to occur, especially in a military simulator! In the alpha or possibly even the beta this could be ignored or forgiven but not in the release version!

It's obviously possible to do this using scripting but it's simply ridiculous that it's not part of the engine. Plus it's just a lot more messy doing something this fundemental by scripting.

It's quite frankly a joke that it hasn't been fixed already. A multiplayer orientated game where all the clients can, and often do, have completely different weather. This has to be one of the most high priority bugs on the tracker. It effects gameplay drastically!

It is absolutely ridiculous that weather doesn't sync between all clients in multiplayer. The clients should always sync their weather with the server. It makes no sense having local weather in multiplayer, none at all! Seriously, get this fixed, it's beyond a major bug!

This really should be added soon. It's been three months and there are several other tracker requests for this.

The developers seem to be looking into this so I'd like to bring a couple of points to their attention.

PLEASE add appropriate config properties to allow community developers to specify whether they'd like to show the pistol or not and, if they would like to, the location of it on the character model!