Jump to content
Bohemia Interactive Forums

ImperialAlex

Member
 View Profile  See their activity

  • Content Count

    211

  • Joined

  • Last visited

  • Medals

Posts posted by ImperialAlex

  2. Posted · Edited by ImperialAlex

    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 :)

  3. Posted

    Fixed: BIS_fnc_diagAARRecord is no longer called automatically to avoid accidental profileNameSpace spam (scenario designers can still call it manually for debugging purposes)

    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?

  4. Posted · Edited by ImperialAlex

    Wow, that was a great read! Especially the script based randomization was something I would have probably never looked at otherwise :)

    EDIT:

    Headgear is usually inherited from the H_HelmetB class

    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 ;)

  5. Posted

    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.

  6. Posted

    Mmmm....I can't seem to make work the "not whitelisting equipped items". This is my line (more or less, I also use the whitelisting functions)

    ["AmmoboxInit",[_ammoBox,false,{true},"Abrir Arsenal",false]] spawn xla_fnc_arsenal;

    Using the feature is pretty simple, so I do not know what I may be doing wrong.

    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?

  7. Posted

    @author are u aware of the random button hack? Im not sure if bis has fixed it yet, but when using whitelist system the player can use the random button to get scopes that shouldnt be available. If this is still the case can u fix it?

    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.

  10. Posted

    BIS bug, see my notes here: http://feedback.arma3.com/view.php?id=23111

    Also it is no longer possible for me to fix since all modifications to official BIS functions are ignored since last patch.

    For any Arsenal issues you have to take the issue directly to the feedback tracker, I can no longer provide unofficial fixes.

    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?

  11. Posted

    Thats great to hear. Thanks a lot :) This mod has already become essential for our main TvT mission :)

    Thanks, nice to hear it's getting used!

    Edit: Btw is it possible to make TFAR radios loadable? Currently every time a player opens the fixed arsenal, the radio gets instantly removed and thus all set frequencies are gone with the wind too.

    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.

  14. Posted

    I get the following error:

    http://i.imgur.com/DSEnpUj.jpg

    Any idea which call must be changed?

    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

  15. Posted

    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 :)

  16. Posted

    so is this more 'liberating' or more 'restrictive' to the player?

    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.

  17. Posted

    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.

  18. Posted

    Furthermore, any movement input during the animation prevents it from finishing and you become stuck for that time.

    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.

  19. Posted

    Re-posting this now that dev's are back in the office:

    Fixed: For security reasons, it's no longer possible to overwrite the path of official BIS functions in CfgFunctions

    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.

  20. Posted

    I think it means you can't do this (pseudo code):

    class CfgFunctions {
 class A3_Bootcamp {
 	tag = "BIS";
 	class Conversations {
           file = "PATH\TO\MY\OWN\FILE\THAT\IS\NOT\LEGIT";
           class kbTellSync {
           	description = "Wolf in sheeps clothing";
           };
       };
};
};

    So the function name looks good, but the content is not what it's supposed to be.

    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.

  21. Posted · Edited by ImperialAlex

    So there's the answer for you...

    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.

  22. Posted

    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.

  23. Posted

    Fixed: For security reasons, it's no longer possible to overwrite the path of official BIS functions in CfgFunctions

    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.

  24. Posted

    @OnkelDisMaster: Mh, I guess it would be a nice feature to have. Do you know if @ACRE2 has something similar going on? What would the code need to look like to support ACRE, too?

    @R-o-x: Thanks, I'll try to dig into that a bit more next week but don't expect any sudden updates (from a first look, though, it would probably be reasonably easy to do this)

    I assume you only had one set of VAS allowed items (rather than several boxes with several different available equipment lists)?

  25. Posted

    I think it would be amazing if your mod would support having the VA script on the server side, userconfig. So that when one change is made to the script, all missions that use it will get the change. This way all our mission dev's can make missions with the same script without having to share different versions of it. We used this system for VAS and it was the best thing ever for our unit. In fact we still have that modified VAS system, we just don't use it now that VA works.. thanks to you.

    Oh, and maybe a way to limit the amount of any given item,mag,wep,ect.

    Mh, what do you mean by "having the VA script on the serverside"? Do you mean the 'setup' scripts (e.g. what you shared) or the actual 'xla_fnc_arsenal' functions?

    I've never played with userconfigs so if you had a link to your custom VAS I might better understand what you mean :)

    Limiting the amount of copies of a certain item: Do you mean per-player or per-crate? (I.e. each player can take 5 magazines vs there are 50 magazines in the box).

    The second one would probably be easier to implement (simply make the arsenal use the actual inventory of the box rather than 'virtual cargo') while the first one is probably more useful.

×