ImperialAlex

Yeah, that's always an option, but if we can somehow trick the engine into using an optic as a binocular that'd be a much smoother and cooler experience.

That's weird! The recent arma update (1.42) changed it so that you can no longer override bis_fnc_... functions. If adding "recompile=1" circumvents those new protections, they'll probably patch that workaround away in the next release. If they don't, then what's the point behind the change in the first place? I wish BI would just communicate their reasoning a bit more.

What is the if/Else for? the "in" already returns bool so (unless there's some arma weirdness here) the following would be equivalent: AGM_Present = ("agm_core" in activatedAddons);

Mh, modeling the javelin is a tough issue. Modelling the CLU as an optic means you can't use it without carrying a launch tube assembly. (In real-life, the CLU is apparently used as a recon tool because of it's high-power magnification and thermals + light weight construction). However, modelling it as an optic allows you to easily deal with spent tubes: You just make the tube a "disposable" (@AGM feature) launcher, and then you can take of the CLU and drop the "empty tube" (fake launcher that can't reload) onto the ground. That way the second guy in the javelin team (Who carries a LTA but not CLU) can simply grab a javelin without CLU and it's very simple to use. Modelling the CLU as a weapon is closer to how it works in real-life. With the CLU as weapon, you can use it for recon + you don't have to worry about people using the LTA without a CLU attached. Problems with this approach: The second guy wouldn't be able to carry the LTA (now a "magazine" type item) in his launcher slot, at least not without some creative workarounds. Also, the 'spent' LTA's tube would just vanish once you shoot. Not ideal either. I'm sure there's a really elegant way to implement it to get the best of both worlds but I can't see it xD EDIT: I wonder if something in the engine prevents one from making a single class both a binocular and an optic. AllowedSlots should make it possible to at least put an optic into the inventories bino slot. If we could somehow Frankenstein together a CfgWeapons class that is both a binocular and an optic, that would probably provide the needed features. However I'm not sure if you can trick the engine into interpreting the same model/config one as a binocular and once as an optic. PS: Hi there! Came across this thread randomly and then realized it was yours :)

Wait, are those functions that allow us to create "after action reports"/recordings/replays? The wiki doesn't seem to have much documentation on that :( Can anybody elaborate?

Wow, that was a great read! Especially the script based randomization was something I would have probably never looked at otherwise :) EDIT: That's obviously a true statement...but why? Pretty much all other equipment has nice 'trees' of abstraction. (i.e. arifle_MX_base_F as a common 'abstract' superclass of all MXs). Why are Helmets (and vests, iirc) such a 'flat' hierachy? Mods that e.g. want to modify armor/passthrough values would have a much easier time if there was a base class for each 'type/category' of helmet ;)

Sorry for the bug with allowEquipped :( Since allowEquipped = 'false' is the recommended setting I neglected testing of the function with allowEquipped = 'true'. I'll make sure that the next version has it working as intended :) Since the way "allowEquipped" and white/blacklisting in general are handled internally will change a lot with the next update, I'm going to focus on shipping the next update rather than hot-fixing the allowEquipped system right now.

Mh, I'm going to see if I can reproduce that tonight. Just to check: You're sure the items you're wearing aren't whitelisted anyway? If you DON'T run any of the whitelisting functions and just run your line, does it still give you your equipped items in the list?

That's a bit annoying, I'll look into fixing that but it's going to be lower priority until the performance update and a few other features are completed. You'll be able to follow the progress (if any) with that issue here: https://github.com/ImperialAlex/XLA_FixedArsenal/issues/19 I'm currently working on a way to make the arsenal perform MUCH faster in whitelisted mode. Somebody made a rather clever comment that, in hindsight, is so obviously better that I'm surprised it wasn't done that way in the vanilla arsenal in the first place. Opening the "LOAD/SAVE" dialogue will still have some serious delay (depending on the number of loadouts you have and the length of your whitelist) but general arsenal actions (i.e. selecting guns, switching uniforms, etc) should no longer suffer from delays.

Thanks for updating! I totally forgot that I can now use the website to submit updates, I'll do that for the next version :)

New release: https://github.com/ImperialAlex/XLA_FixedArsenal/releases/download/v2.1.0/XLA_FixedArsenal_v2.1.0.zip Support for #bipods (merged 1.42 vanilla improvments) Fix small error in sample mission additional optional parameter for xla_fnc_removeVirtual... functions For more details, see the github release post.

I see you still included a function "asdg_fnc_compatibleItems" -- if one were to port the arsenal to a different function name, e.g. xla_fnc_arsenal ;) , could the arsenal call asdg_fnc_compatibleItems instead of the bis one? Does it give the right 'type' of output?

Thanks, nice to hear it's getting used! It's possible to allow it, however you need to be aware of the associated issues with non-unique radio ID's. If you know what you're doing and want to accept that risk, you can 'simply' add all the tfar_anprc155_123 style classnames to your whitelist. It'll add a couple thousand entries to your whitelist (not great for performance ;) ) but it should work. If you don't want to manually type thousands of entries, there's an old script in the earlier pages of this thread that will generate the classnames (trivial sqf for loop). The next 'real' release (i.e. after 1.42-compat.) will stop removing radios and instead replace them with baseclass classnames (or, rather, introduce a way for people to define such overrides). This will probably be what most people want, however it'll still cause the frequencies to reset.

Yes, it most definitively will :) I'm currently still on holidays, but I'll be back on sunday and try to get an update out ASAP.

Thank you for finding that bug :)

Oopsies. Is that in my sample mission? I thought I fixed that in there...maybe I missed one. You (or I, if it's my sample mission) have an error in the arsenal function call. If it's the AmmoboxInit variety, it should look something like this: ["AmmoboxInit",[this,true,{true},"<t color='#45B6EA'>Open Arsenal")]] spawn xla_fnc_arsenal; See how their's an entry {true}? That's because the addAction condition needs to be 'code' (i.e. {true}) rather than a value of type bool You can find documentation on all these parameters in the function call here: https://community.bistudio.com/wiki/User:ImperialAlex/FixedArsenal#Restricted_Arsenal

It's great to see a unification of efforts! Especially one that is open-source! Given that @AGM and @CSE seemed to be happy to occasionally re-invent the wheel, I'm really impressed (and honestly surprised) by their willingness to give up their own mods and work together in something new. Whoever got this collaboration together deserves some serious recognition! I'm looking forward to seeing more :)

Sorry, what do you mean? If this is specific to the new patch, there's nothing really changing, it's just some advanced (previously undocumented) features that are now working correctly. If you mean the entire mod: My mod is just a slightly "pimped" version of the vanilla arsenal. It's not one of these "arsenal everywhere" things. It's simply a more refined version of the arsenal that gives mission makes easier ways to control things. This is intended to be used mostly in the arsenal's "restricted/whitelisted" mode, however it is considerably easier to work with than the vanilla arsenal's "restrictive" mode since whitelisting means that having a non-whitelisted item in an outfitisn't as big a deal as it is in vanilla.

I've released a small patch: @XLA_FixedArsenal v2.0.3 The new update fixes the behaviour of the "%ALL" tag, also (hopefully) improves handling of composite weapons. I've also had time to write some documentation which describes more advanced use cases: https://community.bistudio.com/wiki/User:ImperialAlex/FixedArsenal The next "real" release (i.e. new features) will probably take another few weeks/month+, I want to wait and see what the marskman DLC brings and how that affects the arsenal.

Undeploying, not least because of this bug, is my least favourite part of the the current system. I can't count how many times that has already gotten me killed during testing. I would prefer instant undeployment, with the gameplay balance coming from e.g. a large sway penalty instead.

Re-posting this now that dev's are back in the office: What exactly does this mean? If this means that we can no longer override the bis functions than I'm very concerned about this change. If it is that, would it need to be true both for description.ext as well as addon configs? I've overwritten bis functions before in a mod, as has e.g. ASDG JR and I consider this ability essential for modding.

That's exactly my worry!! This is an important feature for modding! It's of incredible importance to ASDG, for example. I've also used this for similar things...it has plenty of "good" applications. And since only addons and missions (i.e. config.cpp and description.ext) can do anything with CfgFunctions, I don't see the security issue. If I'm writing a malicious addon or mission I can do plenty of horrible things without using CfgFunctions.

Thanks, though you did leave out the relevant part of that changelog: Your quote comes from the "DATA" section, so I guess there's at least some config side things. Does anybody know what the parameters currently are and what's hard-coded in engine? It's always nice to have a few parameters to tweak but I guess the question is: How much can we mod and how fine grained are the controls? EDIT: I poked around the bipod's classes in the config browser and while I see a few things that look familiar from weapons/muzzles (sway, etc) but I couldn't find anything that would let me e.g. configure the angle that one can turn with the bipod.

It's nice to see a proper bipod slot + animated bipods. I've noticed that when I use WASD while deployed, it will trigger the bipod-fold-up animation but I'll still be deployed afterwards, just with a floating weapon. Also, why do I have to wait for the bipod 'animation' (not that there's a player animation to go with it) to re-fold to be able to take cover? It feels like a 'gamey' holdup-- if I'm getting shot at, I will drag myself and my gun behind cover and I'll worry about the bipod later. The weird moment when you're trying to get out of deployment but it doesn't 'let you' get out of it feels like those horrible moments when you're stuck in a vaulting loop on an obstacle. Moments were you feel like your character isn't doing what you're telling him to do aren't exactly awesome :( EDIT: Will the sway/recoil reduction factor on bipods be config-able? It would be great to be able to give individual bipods and/or guns different properties.

What exactly does this mean? If this means that we can no longer override the bis functions than I'm very concerned about this change. If it is that, would it need to be true both for description.ext as well as addon configs? I've overwritten bis functions before in a mod, as has e.g. ASDG JR* and I consider this ability essential for modding.