ImperialAlex

I'm currently working on something loadout save/restore related. As part of that I've come across the issue that there aren't any script commands to add weapons with (custom) attachments into containers. I.e. you can add "arifle_MX_F" or "arifle_MX_ACO_F" into a container but there's no way (as far as I can see) of adding weaponItems to a weapon in a container. As a workaround for that, I've written a little function that "constructs" a weapon with custom attachments on a unit and then uses the "putWeapon" action to move it into a container. The script can be seen here ( http://hastebin.com/lenulafafe.md ). [N.B: It doesn't do custom ammo-counts in the gun's magazine. Not needed for my application] It works great when I pass in an ammo-crate as the "object" but when I pass in (unitBackpack _unit) the "dropWeapon" part freezes the game. (Tried this by just executing a dropWeapon with unit player, into "unitBackpack player" and that freezes the game, too). It seems like dropWeapon into the unit's own backpack doesn't work. What would be possible workarounds? Apart from the obvious "BI implements "vehicleName addWeaponCargoGlobal [weaponName, count, weaponItems]"" ;) I've thought about doing putBag, then putWeapon into the backpack on the ground, then addBag but it can't figure out how to putWeapon into a backpack on the ground. (I can't find a way to reference the backpack...do I need to look through the nearby objects?) Any help on this would be highly appreciated :)

Wow, that's unexpected but very welcome! @Jakub BXBX Horyna is the hero we didn't deserve but really really needed! Now where do we send the beer? BIS HQ?

EDIT: Updated to v3.1.2 Download (*.zip) Play with Six Source Code (Github) Steam Workshop This mod improves the way the virtual arsenal works when using 'whitelisting' mode. The 'white listing' feature of the (vanilla) arsenal allows scripters to determine what items are or are not available. However, the vanilla white-listing has a few issues. E.g. by default, saved outfits that contain non-whitelisted equipment cannot be loaded. This mod introduces partial loading, i.e. loading all whitelisted parts of a saved outfit. It also includes fixes and improvements related to the white-listing feature. Partial Loading Partial Loading means that outfits that contain non-whitelisted or non-existing (classname not found) items can still be loaded, but any item that is non-whitelisted/not found will be skipped. If the non-whitelisted item is a uniform, backpack or vest, the currently equipped uniform,backpack or vest (respectively) will be kept. Outfits that contain non-available (either due to classname-not-found or non-whitelisted) will be greyed out in the virtual arsenal's "load" view. Optional Semantics Change In the vanilla arsenal, any item currently equipped by the soldier is automatically available in the arsenal. (Effectively, the white-list was computed as the white list + any current equipment the soldier had). This has two effects: Firstly, it allows players to duplicate items like grenades even if they are not part of the white-list. Secondly, it makes it hard for players and mission designers to predict what items will be available when a certain player visits the arsenal. With v2 of FixedArsenal you can enable or disable this. Disabling is highly recommended since it makes the semantics of loadouts much easier to understand. Usage If you don't want to use any of the 'advanced' features, I recommend that you simply substitute "bis_fnc_arsenal" with "xla_fnc_arsenal" and "bis_fnc_get/add/removeVirtual[...]Cargo" with "xla_fnc_get/add/removeVirtual[...]Cargo" in your scripts. Be aware that this might require the mod to be present on your server, depending on how you initialize ammocrates. (It's recommended to run the mod serverside, too, in order to avoid headaches with function locality). The 'advanced' features (blacklisting, "sidelisting", custom arsenal text, optional semantics toggle) are best understood by reading the xla_fnc_arsenal header and exploring the included showcase mission's scripts. Showcase This mod includes a simple showcase and debugging mission under Play -> Showcases -> XLA | Arsenal Showcase. Feedback Feedback is welcome either here in this thread and there's also the issue tracker over on the github page.

This mod has been updated to v3.1.2 (see first page for updated links). Steam/PwS have been updated :) * CBA_MiscItem is now supported (e.g. ACE items in newer versions of ACE3) Thanks for your patience and thanks to Willard (@TheNiner on GitHub) for submitting the fix for this issue!

I've tried making it script-only but I don't understand enough of the UI-scripting/config/etc to port it to a script-only system. The official documentation for dialogs/UI is, quite frankly, garbage. There are some helpful tutorials out there but nothing that really helps me 'grok' how UI works in Arma. If somebody has some UI expertise, they're more than welcome to try their hand at porting this to a script: https://github.com/ImperialAlex/XLA_FixedArsenal

@topden I just noticed some helpful person has already fixed this issue and submitted the fix on github, I just completely missed it because my github notifications for that account didn't go to my main email. I'll release a fixed version tomorrow :)

Thanks guys! I've been made aware of this, if I remember correctly CBA does 'something' to make their items work in the vanilla arsenal, I will have to check what that is. Earliest possible date for a fix would be this weekend though :( As a temporary workaround, try using the force-add feature that's already a part of the mod. I know some Bundeswehr mod items had similar issues and using force-add worked for those...

YES!!!! FINALLY!!!!

@fn_Quiksilver Do you (or any of the other experienced mission designers around here) have a follow-up review of dynamic simulation? It seems, as usual, to be sort of semi-finished and I guess my big question would be if it's actually in a decent enough state to be worth using.

Yes, you can use this mod to filter what things you want to appear. As a matter of fact, even the vanilla arsenal can do this, my mod just improves a few areas where the vanilla arsenal is a bit annoying to deal with. There's sadly no real easy way to get a good whitelist (=list of classnames of things you want to allow), but you can start with this list (example script that's part of the addon) but it's now over two years old so maybe somebody else can help you with a more up-to-date list :)

I really enjoyed "Remnants of War", it honestly blew me away that it was even possible to do this in the arma engine! Great job team Orange!! The campaign is incredibly well paced, thought-stimulating (even more so than SpecOps: The Line, imho) and the technical execution is simply brilliant. This is definitively taking playable (narrative) content to new levels! I'd also pay good money/be willing to donate to ICRC/throw money at my screen/etc for a write-up or video of how this was accomplished on the technical side - what was your workflow? How did you make the memories so incredibly smooth? How did you make the persistence between different scenarios work so nicely? I've got a pretty good idea ( at least I think so) of how it's done, but it would be really awesome to see an in-depth post that goes into some of these things :)

I've got a bit of experience with weird arsenal issues but I can't see anything obvious. What's your *.rpt file look like when you're opening the arsenal for the first time? Maybe bis_fnc_arsenal is giving some useful debug output. One additional note: You've got a DLC = Aegis line, do you have a valid CfgMods entry for that? If not the full arsenal will probably choke on that when trying to add your weapon to the list.

Coming back to actual AI Driving: It sure would be nice to get an update from a BIS dev on how much additional work we can expect to see on AI driving (if any at all). It's a very different scenario for e.g. potential modders to know that a feature will be revisited in 2-3 updates compared to a feature that BIS considers "done" which might stay stable for long periods of time.

Tweaked: The "Fire at that medic" radio protocol sentence replaced with a more generic sentence (e.g. "Fire at that soldier.") was removed due to unexpected sandbox issues I'm curious, will we ever get to know about those unexpected sandbox issues?

It sounds like you can. From what I've read so far each machine has the Dynamic Simulation code present, however the whole grid/etc logic is only activated once an entity is assigned to the system. The entities probably have to be local (just think disableAI - that needs a local entity, too) and I'd assume that units assigned to different dynamic simulations (i.e. different machines) won't necessarily play nicely together with regards to "waking" each other up. I don't currently have the time to test this, but oh boy does DynSim make me excited to go back and finally try my hand at a caching system.

I can't believe that this wasn't always done this way. What was the previous behaviour? (Non-object) view distance as a limit?

Looks good enough, had to be done and nothing too big blew up as far as I can tell The upgrade made me realise that forums.bistudio.com has been around for a very, very long time and has mostly managed to keep old content readable, accessible and even available at the original link. That's not a trivial achievement so a very sincere thanks to the web team for not-screwing-it-up (which, at least in IT, is a lot harder than doing something flashy every now and then)

Created a feature request to add a toggle to make an AI unit have the same wake-up-all behaviour that players have. https://feedback.bistudio.com/T121849

Just wanted to quickly say thanks for all the AI improvements in the last few months! Along with #AIDriving (yay!!!) there've been some really nice "minor-but-oh-my-god-so-annoying" bugs that got fixed (dodgy target switching, vehicle guns preferring north, etc). Really loving the current bug-fixing focus :)

Great work, the documentation is well written and the system looks like it should have massive performance improvements over scripted systems that used distance checks! Sure, lots of people will expect this to magically make their lag-fest, badly-scripted, 5-million-unit mission blazingly fast and will then be dissapointed ;) but for those of us who've been using similar scripted systems this is an incredible improvement. Being part of the vanilla game and integrated with Eden should also make it easier for newer mission designers to use caching. Thanks to everybody involved! I wouldn't want to clutter the UI with another toggle but could we get a script toggle (command or an object variable that we can set) that switches a non-player unit/group to the wake-up-all behavior that players have? Possible use cases would be "support" units (tanks, aircraft) that players can send in to deal with threats: Let's say I have west and east AI units fighting an ambient battle. All units are set to non-wake-up since we don't want that battle to waste resources when players aren't close enough to notice. We now allow the player to send a friendly AI support element (e.g. an armed vehicle) into that battle. We set the tank to "wake up units" since we want to allow stuff like the player sending an AI support unit ahead to clear an objective. This works as intended as long as the player is in range but as soon as he goes out of range the poor support unit is left all alone, waking up all his enemies but none of his friendlies....the poor support unit is now outgunned pretty badly. The alternative would be to keep the support unit in "non-wake-up" state, too, in which case the player wouldn't be able to use the support unit on objectives outside his current "wake up radius" which requires the player to be aware of the ranges. That just feels 'wrong', too. Oh, one more question: What's the interaction with Zeus-controlled units? Are they treated according to the underlying AI unit or are they treated as a "player"?

I remember reading a comment from KillzoneKid that for various reasons, we might never see a "unit ragdoll" script command. Are those reasons still there? If yes, I'd love to learn a bit about them and if not then would it be possible to look at a ragdoll script command again? :)

It honestly sounds like you're having an issue with the antistasi mod rather than my mod. If you can reproduce your issue in vanilla + XLA then I'm happy to have a look, otherwise I'd recommend talking to the antistasi mod authors (I'm happy to help them with integrating my mod, I think I've got one of them on steam, iirc)

I'm no longer actively developing new versions of the mod (at least as long as the current one keeps working) but I'm happy to assist :) What exactly is your issue? Plenty of people are using the mod with TFAR backpacks and rangefinders showing up fine, so I'd need more information about the error you're getting and the whitelists your're using. Remember that some items in arma are sorted into funny categories. The long range backpack radios are, unsurprisingly backpacks rather than items and therefore need to be added to the backpack whitelist. The rangefinder might be a weapon rather than an item. If in doubt, add it to both the item as well as the weapons whitelist. Have a look at this sample script which shows TFAR radios being handled properly, among other things.

Could somebody on DEV maybe make a short showcase video? It would be greatly appreciated! (Don't have the space for two installs right now & via <40Mbps Wifi it's not fun to switch back and forth between branches)

Did you ever publish this? I was really looking forward to trying this out :)