Jump to content

Freghar

Member
  • Content Count

    142
  • Joined

  • Last visited

  • Medals

Everything posted by Freghar

  1. Freghar

    3CB Factions

    Something I noticed today, might be worth fixing - the UK3CB_RPK74_60rnd_545x39 magazine (and similar) seem to use ammo = "UK3CB_762x39_Ball_Red" which itself inherits caliber and "hit" value from B_762x51_Ball. Other than looking into the "caliber" and "hit" values (which should probably be less for 7.62x39 than for 7.62x51), the magazine is using the wrong CfgAmmo. It should probably use ammo = "UK3CB_545x39_Ball_Green".
  2. Freghar

    3CB Factions

    Hello, could you please pack configs and scripting in a separate pbo (like ie. RHS does) that wouldn't be obfuscated using Mikero's tools? We recently had an issue with randomized gear and suspect some of the UK3CB_* functions - looking at them, there are some more things that could conflict with other mods, but we cannot debug the issue when the functions/configs are obfuscated. I'd understand obfuscating assets (models, textures, etc.), even if you can export them un-obfuscated from the game if you know how, but it doesn't really make sense for configs/scripts. Thanks!
  3. Loosely inspired by FSF SacVentral and Zade's Backpack on Chest, this "mini mod" has a simple goal - to put your backpack on your belly, freeing the backpack slot for something more immediate, like a parachute. Features These are some of the features I missed in all other implementations and the reason why I wrote yet another such mod from scratch:preserving ammo counts in magazines during chest/back switch, no magazine-refill cheating preserving attachments/magazines of weapons in backpack during chest/back switch full Multiplayer compatibility, incl. Join-in-Progress (spawning new unit or taking control over existing one), Respawn, even TeamSwitch should work works with Zeus-controlled AI units To put a backpack on the chest, ACE-self-interact, Equipment, "Backpack on Chest". To do it the other way, "Chestpack on Back". If you have both a backpack and a chestpack, you can swap them using "Swap Chest/Back packs". While carrying a chestpack, the soldier is forced to walk (balancing reasons). Limitations The ammo/weapon preservation is possible due to the use of get/setUnitLoadout, as I found no way to store this metadata into an actual backpack (attached to chest or on the ground). The backpack you see on the chest is just a visual model, not a backpack you can access. This is also why I can't create ACE interaction on backpack objects to place them on the chest directly or an interaction to drop a chestpack on the ground. If you want to pick up / drop / access a chestpack, you need to do it manually from the backpack slot. To access the chestpack of a dead or unconscious (ACE medical) unit, you need to ACE-interact with it and move the pack onto the unit's back, then you can access it like a regular backpack on the ground / via ACE unconscious inventory. I also wanted to add the chestpack actions when swimming, but I was unable to figure out why exceptions[]={"isNotSwimming"} doesn't work on/inside ACE_Equipment - if you have a clue, I'm all ears. Vanilla Arma 3 compatibility There's none, but the actual logic uses vanilla functionality available even to just missions, so feel free to rip it out and create Action menu actions via addAction for your mod/mission. Just see the code, it's very simple. Download chestpack_v1_0.zip (2.3KB) This mod obviously depends on ACE_interact_menu from ACE3, so it's good to have it. Released under CC BY 4.0, https://creativecommons.org/licenses/by/4.0/ Enjoy! (And sorry for the slight visual glitches, I adjusted the chestpack position as best as I could, visually.)
  4. What exactly specifies when a class should be completely overwritten and when it should be changed? Consider class CfgVehicles { class B_Soldier_A_F { displayName = "some name"; }; }; versus class CfgVehicles { class B_Soldier_A_F { displayName = "some name"; class GunFire { size = 4; }; }; }; Why does the latter overwrite the class completely?(And I know the "fix" by inheriting the originally inherited class, B_Soldier_F, I just don't get why the double standards.) If it is due to me defining a subclass, why doesn't CfgVehicles get completely replaced when I define the B_Soldier_A_F subclass in it? It can't be Cfg* being special cases as the same works in many other subclasses, ie. in Cfg3DEN (class AttributeCategories). Maybe it's because CfgVehicles doesn't inherit anything? If so, then why class EventHandlers gets overwritten for second_soldier, even though it itself doesn't inherit anything at any point? class CfgVehicles { class B_Soldier_F; class first_soldier : B_Soldier_F { class EventHandlers { class one { init = "one"; } }; }; class second_soldier : first_soldier { class EventHandlers { class two { init = "two"; } }; }; }; (Again, I know that the solution is to class EventHandlers : EventHandlers, but I don't know why as it seems inconsistent with how other classes are defined and work.)I have a very wild guess of overwriting always being a thing when any inheritance in any parent class is in effect while at least one subclass being defined, but that seems like a very exotic definition. Thanks.
  5. Freghar

    AI Discussion (dev branch)

    Note that I may have found the culprit: https://community.bistudio.com/wiki/Arma_2:_FSM_Danger_Causes (The feature would make sense if it didn't propagate through building walls and instantaneously, even mid-burst-shot.) So I guess there's really no way to disable it via scripts/config if even custom scripted FSMs can't modify this.
  6. Freghar

    AI Discussion (dev branch)

    The problem is that while this could be scripted away for some scenarios (ie. artillery) by spawning an enemy unit on [0,0,0] and setting it as the shotParent (even though it would make AI look towards [0,0,0]), I can't think of a way to work around this for a "stealth mission". If I set shotParents to objNull or to a unit from the target's side, the AI obviously doesn't react. If I set it to somebody from the attacker's side, all units within 80 meters still get alerted (run around, go prone, etc.), even if I forgetTarget right after the unit being hit. Even if I was to construct some logic that can forgetTarget without causing an alert (by switching sides / using captive / CARELESS / etc.), I can't reliably tell between a situation where the AI should spot the shooter via its spotting capabilities (outlined in my post above) or if the target got spotted via "magical" bullet hit spotting. My issue is not necessarily the unit(s) knowing who shot the target, but that the fact that target was shot is broadcasted to other groups. Even though the two may be connected. Thanks.
  7. Freghar

    AI Discussion (dev branch)

    The only active mod is a tiny one that does the changes described in my post. And CBA that I forgot to disable for the video. I wouldn't be posting here if the issue wasn't reproducible on clean vanilla game (it is), it's just harder to provide such a nice demonstration of the issue with fully active AI spotting and engaging.
  8. Freghar

    AI Discussion (dev branch)

    Hello, I've been trying to debug AI soldiers "magically" reporting targets, when hit by a bullet, to any groups within exactly 80 meters, ruining any attempts at a "stealth mission", but so far no luck and I may need somebody with engine source access to confirm this. What happens: When a soldier is non-fatally hit, it instantly transmits the shooter info to any nearby groups When a soldier is instantly killed (headshot), this does not happen This does not affect non-soldier vehicles, AFAICT Soldier audibly shouting (or not) has no effect on this Soldier actively spotting shooter has no effect on this (only bullet hit) Inventory content (ie. ItemRadio) has no effect on this What I've tried to narrow this down: Set "audibleFire" and "visibleFire" for both the CfgAmmo and muzzle_snds_* to 0.0001 Set "camouflage" and "audible" for the shooter to 0.0001 Set "sensitivity" and "sensitivityEar" for all soldiers to 0.0001 Set all skills to 0, I even modified CfgAISkill to make sure skillFinal is 0 Used disableAI on all skills (not shown in video) Set "fsmDanger" and "fsmFormation" to empty string for all soldiers Experimented with "dangerRadiusBulletClose", "dangerRadiusHit", "visibleFireTime", etc. for the CfgAmmo Removed all possible runtime EventHandlers from the soldier and checked Config structure Searched thoroughly for any relevant keywords and numbers through all game PBOs None of this changed the "magical" spotting - the AI is dumb and cannot see/shoot me, but the "targets" lists of nearby groups still get updated with the shooter. If anyone (oukej?) can shed some light on this and whether the spotting can be disabled/reduced/delayed, I would love to know. Thanks!
  9. Any idea how would I assign "ctrl+alt" as a keybind? .. I used to have it for ACE door opening, but now nothing happens when I press it on the key-assignment screen. Is there some profile variable I can put the keycodes in? Thanks.
  10. Freghar

    Achilles

    (Even though the chances of this happening are slim, I'm going to at least ask.) Is there any chance of making the per-skill unit sliders inherit the range setting from the vanilla "Skill" control, instead of hardcoding _ctrlValue slidersetrange [2,10]; ? My community uses a customization that overrides the vanilla Skill control to have a full sliderRange[] = {0, 1} and it works for the base Eden/Zeus slider, but obviously not for Achilles. Looking at your code, I don't see an easy generic way of doing it, it seems that you have class RscAttributeSkill: RscControlsGroupNoScrollbars { onSetFocus = "[_this,""RscAttributeSkill"",'AresDisplays'] call (uinamespace getvariable ""Achilles_fnc_initCuratorAttribute"")"; }; and, as Arma doesn't support multiple inheritance, making it use an value from class Skill while keeping the NoScrollbars template would be impossible. One could just look into the config when getting the bounds for slidersetrange, but that feels a bit too ... arbitrary. Ie. vanilla would return getArray (configFile >> "Cfg3DEN" >> "Attributes" >> "Skill" >> "Controls" >> "Value" >> "sliderRange"); [0.2,1] getArray (configFile >> "Cfg3DEN" >> "Attributes" >> "Skill" >> "Controls" >> "Value" >> "sliderRange") apply { _x*10 }; [2,10] Would it be possible to include something like this or does it seem like going too far with compatibility? Thanks.
  11. Freghar

    AI Discussion (dev branch)

    Has anything changed recently with CfgAISkill? It seems to "work", but the interpolation is no longer based on a simple linear function, ie. with {0,0,1,1} I'm getting (which stays similar across different Y ranges, https://docs.google.com/spreadsheets/d/1GDzxZpVa1IDFP9GAeHUVrKIiGqKR5jv68qvE-0JhMQ0/pubhtml?gid=980503731&single=true ). The wiki ( https://community.bistudio.com/wiki/CfgAISkill ) also mentions however I was unable to figure out how, using ie. {0,0.5,1, 0,0.2,1} (extending the {w, x, y, z} example from the wiki) seems to produce spurious curves. Is there now any way to change the curve shape? Otherwise it doesn't seem possible to have skillFinal at skill 0.5 lower than 0.75 without reducing the maximum (at 1.0). Thanks. (Tested with skillAI=1 and precisionAI=1.)
  12. Freghar

    64-bit Executables Feedback

    I think the question was more about fixing/improving 64-bit side of things. For example my game still blackscreens and freezes randomly if I don't have a gigantic pagefile, despite me having 32GB of RAM and Arma using at most 9GB of it, it still needs pagefile for some weird reason, otherwise DX11 OOM error gets logged into RPT.
  13. Is it just me or are "External Apps" arguments ignored when launching bat files? When running a simple echo %* manually, I get C:\Users\user\Desktop>testme.bat 1 2 3 C:\Users\user\Desktop>echo 1 2 3 1 2 3 C:\Users\user\Desktop> whereas arma3sync starts it without arguments: C:\Program Files (x86)\ArmA3Sync>echo ECHO is on. C:\Program Files (x86)\ArmA3Sync> despite those being present in the GUI configuration. It also doesn't seem to run the script if it has a space in its path. Build v1.6.91. Thanks.
  14. Freghar

    Achilles

    (In case you're not aware, Github allows you to upload any files when making a "release" via their web interface, so you don't need to store binary PBOs in the repository itself while having only PBOs in the release - that's how ie. ACE3 does it.)
  15. Freghar

    Achilles

    Hello, it seems that Ares_fnc_ShowChooseDialog is corrupting private variables. This is nothing new (was in original Ares), but in Achilles, it also includes "_pos", which I quite commonly use for ie. [ "test", "test", { params ["_pos", "_unit"]; // _pos valid private _res = [...] call Ares_fnc_ShowChooseDialog; // _pos corrupted } ] call Ares_fnc_RegisterCustomModule; so I was wondering if you could please make the variables in Ares_fnc_ShowChooseDialog private, so the corruption/modification doesn't happen. Thanks!
  16. Freghar

    ASR AI 3

    I assume so, I haven't set it explicitly, but that's what they default to when under fire. I'm not sure if / how long they retain it after shooting stops, but the screenshots above were taken ~8 minutes after shooting stopped (they stuck together for about a minute and then went off like this). edit: Just tested it with disabled AUTOCOMBAT (so I could keep Aware/Combat a.k.a. YELLOW/RED consistent) and it seems to be happening for both YELLOW and RED.
  17. Freghar

    ASR AI 3

    Yes, I'm using 1.0. By "squad splitting" I mean situations like these - http://imgur.com/a/8o3eF which can get even worse when the group(s) are originally on a patrol path.
  18. Hello, I know there are Eden EventHandlers, https://community.bistudio.com/wiki/Arma_3:_Event_Handlers:_Eden_Editor , but they oddly seem to be missing the most basic EH I would think of - placing an object (unit). The page mentions "Object Event Handlers" and even the text for RegisteredToWorld3DEN seems promising, but I don't know how to add it to a non-existent object (which hasn't yet been placed) and passing RegisteredToWorld3DEN to add3DENEventHandler doesn't seem to do anything. Does anybody know how to execute a piece of code when (any) object/unit is placed in Eden, without having the object beforehand? Thanks.
  19. My current workaround is hooking onSelectionChange and setting a custom variable on each "processed" unit, ignoring them on next selection change. A global variable (list) would be more efficient, but it doesn't get reset on ie. loading a scenario, starting a new scenario, etc., so per-object variables are safer. The only downside is that on a scenario load, any first selection processes all units all over again - this is fine for my use case, but might be unwanted for others. Still, it would be great if there was an easier way (without using CBA XEHs, etc.).
  20. I know, that's how ie. Module_F does it (the second parameter the engine passes to init EH can apparently be ie. "init" or "attributesChanged3DEN" or "registeredToWorld3DEN", etc.), however that would still mean I need to modify each and every unit in each and every mod I use, adding my init EH everywhere. Is there really no way to do this without adding tens of thousands of EHs?
  21. Freghar

    ASR AI 3

    There are at least two ways to keep units on the spot, forceSpeed 0 or disableAI "PATH". The former is much older, so it was/is used by various garrisoning scripts. Both seem to work fine with the latest ASR AI. A bigger problem is what I call "capturing a base, the ASR AI way", have a fully occupied base, with patrols, waypoints, etc. go on a nearby hill shoot a few bullets at the base retreat, loop around the base wait 20-30 minutes walk into an empty base Where vanilla AI mostly stays in formations where you last put them, ASR AI is much more aggressive in pursuing the threat, splitting squads and running away from waypoints. I don't know what would "fix" it though, maybe some checking for GUARD waypoint type? Or whether a group has a set WP loop (CYCLE)? The squad splitting is also an issue, because it makes ie. a squad of 10 players encounter the enemies one-by-one, not presenting much challenge. Despite that, the positives still outweigh the above (for me).
  22. Hello, since attachTo seems to change the coordinate space for setVectorDirAndUp (at least) to be relative to the parent vehicle's direction/up (http://killzonekid.com/arma-scripting-tutorials-attachto-and-setvectordirandup/), how would one go about attaching an object, but keeping its direction/up unchanged w.r.t. global world dir/up? In other words, how to cancel out the dir/up rotation caused by attachTo? I tried something like /* target: object I'm attaching to, source: object I want to attach */ private _dir = (vectorDir _source vectorDiff vectorDir _target); private _up = (vectorUp _source vectorDiff vectorUp _target); _source attachTo [_target]; _source setVectorDirAndUp [_dir, _up]; the idea being that I can substract the target's absolute dir/up from the source's dir/up to get a relative dir/up between the target and the source, to be used after attachTo. However it doesn't seem to work as the source object just becomes flipped on its side, for some reason. Can anybody please see what I missed? Thanks.
  23. Freghar

    ASR AI 3

    This is IMO one of the biggest AI problems of Arma 3 - once an AI unit acquires a target, it can never let go. If you look at the "reveal" command, you cannot make a unit "forget" about enemy units/players ("knowsAbout" will always be >0), you cannot ever make it go back to SAFE and resume a previous patrol, the engine just doesn't allow it. Or is the state simply stored in an FSM? Even if you come up with a mix of disableAI commands that work (and I did break the AI completely using it in a specific algorithm, by deadlocking the FSM) and make a unit retreat away from the enemy, the knowledge never disappears and the unit always switches back to AWARE, unable to calmly patrol in SAFE. Anyway, probably not something ASR AI can fix.
  24. (I didn't want to release this as a mod because the change is too tiny, but the journey took some time.) Smoke grenades fired from the under-barrel grenade launcher are VERY bouncy, initial ground hit 200-300m away can bounce even beyond 1km (measured 1.4km max) under some circumstances. Considering these smoke grenades are often used for targeting, this is kind of bad. To tune this, the obvious way would be to go to CfgAmmo and find that G_40mm_Smoke inherits directly from SmokeShell, the hand grenade, and that there are "deflecting" and "deflectionSlowDown" parameters, both somewhat undocumented. CfgAmmo reference says on "deflecting" , commy2 expands on it a bit (thanks!), but it doesn't seem to work and neither does "deflectionSlowDown". The other options to reduce bounciness would be ie. "coefGravity" (doesn't work) or "airFriction" (does work, but the usable range goes down much faster than bounciness).If you look closely, however, you'll notice that SmokeShell has simulation="shotSmokeX" and so do all the inherited grenades. You'll also note that there's "shotSmoke" used by ie. mortar smoke shells and for that one, deflecting/deflectionSlowDown do work! Upon realizing that, the solution was straightforward: class CfgAmmo { class SmokeShell; class G_40mm_Smoke : SmokeShell { /* inherited from SmokeShell is shotSmokeX which ignores * "deflecting" and "deflectionSlowDown" parameters */ simulation = "shotSmoke"; /* multiplier; small bounce, on 400m flat ground shot ~10m bounce */ deflectionSlowDown = 0.3; }; }; Would be interesting to know how launched smoke grenades behave IRL to tune this, but the multiplier finally works.Hopefully this saves time for somebody trying to do the same.
  25. Freghar

    How much can this 64bit executable help?

    If "64bit" means switching from i386 to amd64 a.k.a. x86_64 (as an architecture) and assuming most of the engine is written in C/C++, there could be also microoptimization speedups, like ie. the Apache web server had (~10%) due to the extra CPU registers available. Even though you generally waste them on bigger addresses, modern compilers are smart enough to optimize some operations (using ie. 2x eax instead of 1x rax), resulting in less memory or even cache access. Add SIMD extensions to the mix and you can get some decent (~10%) speedup, even ignoring any memory-related benefits. It's questionable though, how well the limited compiler in MSVS (compared to llvm/clang or gcc) can do this. Of course, it's possible that the engine has been using this for years via hand-optimized assembly or that the code is too obscure and un-optimizable (ie. type punning), so we'll have to see.
×