Taosenai

Hi all, Has TMR been completely superseded by other mods at this point? I would assume most functionality from TMR was worked into the Marksman update (which I haven't played with) or has been duplicated or ported into AGM or the like. If there are still things relevant, I will update to the new CBA keybinding system and release a minimal version of the mod. Please let me know. I don't have much time to actually improve anything from here.

Updated to 2.7.0. Now uses latest CBA_fnc_addKeybind. Glad the CBA team fixed my mess. Requires latest CBA. Get it from the OP post. Lightly tested (at best).

Just checking in to verify that I'm still alive. After mid-September I should have some time to really work on this again. I would like to do more 2D optics. I have a few ideas about how to improve the system, too. (I should also write documentation for how to do it yourself!) Nefron: The R3F weapons don't have TMR config values, so they can't use its bipod system. You might be able to attach the Bipod item from TMR to them, then you'll be able to use the bipod rest.

I've just pasted the following into my Debug Console, which is what you had: test_flex = { [ ["Testing", "test", "popup"], [ [ "Test", {hint "Hello World"; true}, "", "", [], 0x12, true, true ] ] ]; }; ["Test Mod", "Open Menu", ["player", [], -100, "_this call test_flex"], [0x30,false,false,false]] call CBA_fnc_registerKeybindToFleximenu; When I execute this and press 'B', the menu appears and works. Can you give me more details? You might also try clearing your keybind registry with the following debug console command (perhaps a misformed call messed it up somehow): profileNamespace setVariable ["cba_keybinding_registry", []]; saveProfileNamespace; then restart the mission and try again.

Caiden, I've just copied your first script into an SQF file and it ran perfectly for me with no changes. Can you test it in an empty mission file and try to duplicate again?

The code is in here: https://github.com/Taosenai/tmr/tree/master/tmr_ai Due to some oddity with BI's firing modes, there are two identical files for machine guns, one that uses 'manual' for full auto and one that uses 'FullAuto' (I'll workaround this with some macro tricks soon hopefully). Make sure you change both. 'burst' is the size of the burst, and 'aiRateOfFire' is the time between bursts. The AI should already resupply out of backpacks of members in their team who are carrying ammo as part of their vanilla behavior. (ONE, RESUPPLY AT, THAT MAN)

Quick barely-tested release to get some of these major issues sorted out. (By putting alpha at the end I allow myself to do this!) 0.5alpha3 - Requires CBA 1.0.8.14023 RC3. - Changed: ai - Machine gun bursts are shorter to better reflect a 6-9 round length. More adjustments are needed. - Fixed: ai - TAR-21 now has correct firing modes. - Fixed: hiteffects - Hilarious falldown slide when hit in a vehicle or turret removed. - Added: hiteffects - Will disable the TMR falldown when tpwfall is loaded and enabled. There is also a CSO build for 0.5alpha3, though I have not had a chance to test it at all. http://ryanschultz.org/arma3/@tmr-0.5alpha3.zip http://ryanschultz.org/arma3/@tmr-cso-0.5alpha3.zip

2.6.1 is released, which requires CBA 1.0.8.14023 RC3. Added support for several new BI and community maps. Thanks to Gundy! See OP for download.

Thanks Viper. I have just updated the keybinding documentation to reflect the new ability to specify { code } rather than "functionName". Note that the old behavior is still supported but is considered deprecated (you will receive a warning in your rpt file.)

I'll continue to consider and adjust the recoil. It does seem a bit difficult to control when prone and deployed on the Zafir. As for the falling, I'm going for a somewhat different effect -- I don't want them to be incapacitated at all, simply (occasionally!) dropped to the ground or on their butt in response to shock or something like that. Incapacitation effects should be left to a a real medical system, I think. TPW is clever and thoughtfully provided a global variable I can check to determine if his system is on or not. If it is, I disable mine -- easy as that. I would like to do this but currently the tmr_ai module actually does depend on tmr_smallarms being loaded, because it changes the firing modes, and tmr_smallarms adds some additional modes. (E.g., smallarms adds a single fire mode to the Mk200, which must then be disabled as an AI-usable firing mode in tmr_ai). I can think about making a standalone version of tmr_ai later, though -- it's only a few small changes. And yes, currently tmr_core is not used by tmr_ai. Just playing it safe with that dependency, since I consider anything in tmr_core to be always available to me for use (such as the savegame reload watchdog functions). Feel free to make changes as you like. Confirmed. Something was going wrong with inheritance and the config array += operator. Fixed in next release. Unfortunately the thermal shader is totally engine-side and can't be tinkered with via a mod like this. Confirmed. I made a silly mistake. I'm sort of surprised those guys can experience animations, though. I don't think they could in A2. Hmhm. Fixed in next release.

It's currently impossible or at least impractical, because added mouse click or wheel event handlers cannot prevent the game from executing whatever behavior is bound at an engine level. For example, if you do: (findDisplay 46) displayAddEventHandler ["onMouseButtonDown", {hint 'Override'; true}] and then click your left or right mouse button, you will find that your gun still fires and your sights still come up. According to https://community.bistudio.com/wiki/displayAddEventHandler, "Returning true in EH code will override default engine handling for keyboard events." This isn't true for mouse buttons, though, and has been a long requested feature since more than 4 years ago: https://dev.withsix.com/issues/8212 This doesn't apply when you use the "Use Action XX" binds, since they are handled at the engine level. In other news, I've just committed code to make it possible to specify "KeyDown" or "KeyUp". The function definition has also been changed to a { code } block, just like cba_fnc_addKeyHandler. (The old behavior of passing a string "yourmod_fnc_functionName" will still work but is considered deprecated.) It'll be like this once released: ["your_mod", "your_action", {_this call your_mod_fnc_openMenu}, [15, true, true, true], false, "KeyUp"] call cba_fnc_registerKeybind; I hope this will fit your needs L-H. I should have implemented it this way to begin with.

THe absence of the possibility to bind separate KeyUp/KeyDown handlers was definitely an oversight on my part. Should be a straightforward addition, though, as an extra optional parameter. It should also be possible to make the necessary internal changes to allow myfnc_fnc_functionName, "myfnc_fnc_functionName" and a { [0] call myfnc_fnc_ } parameters to be passed and executed. In fact, it should have been implemented that way from the very start. The current implementation is a result of this code's legacy in an older (unreleased) TMR system that used a DLL to save stuff to a text file, rather than using saveProfileNamespace to pickle it and save it in the game profile. I will aim to resolve both issues by the next release. https://dev.withsix.com/issues/74856 https://dev.withsix.com/issues/74855

Shouldn't be possible, not really. It directs fragments at objects like buildings, too, and also the ground. I suppose an extremely astute observer, throwing a grenade in just the right way, could possibly use it this way. But some random shrapnel is directed in all directions no matter what. It simply focuses additional shrapnel 'cones' where there are objects. Using any other mods? Can you post your rpt? I can't duplicate this. The fragment system is aggressively conservative right now. As it gets more testing, especially in multiplayer, I hope to dial it up a bit. You should still hear the fragments hitting around, though. Take a look here to see what weapons currently have fragmentation enabled on them: https://github.com/Taosenai/tmr/blob/master/tmr_blastfrag/config.cpp I'll look into the issue with 40mm grenades. There could definitely be a bug that would cause that intermittently. I haven't experienced it myself, though, I don't think. Of course, I should have thought of that in the first place. I'll detect if tpwfall is loaded and disable my falling function if so. No problem. That's why TMR is modular, but the LBV plate is a carefully considered change. Many normal (not recon) CSAT dudes wear the LBV Harness and its variations, and it would make their army much worse than the AAF and NATO forces if I didn't make it plate equivalent. As it is, the armies are all pretty evenly armored. Which MG? The MX LSW still has considerable recoil even when deployed since it is a lightweight IAR-type weapon, rather than a true LMG, but both the Zafir and the Mk200 should be effective against point targets out to about 600m when used prone and deployed. If they're not, I'll look into it. There are two levels of ear ringing right now -- one for a very close, probably damaging explosion and one that you were just on the edge of the blast from it. I'll check the volume. They may be too loud relative to other game sounds. I think they can add immersion (especially if they don't last all that long), but they certainly should not add pain or annoyance. P.S. The final 0.5 release should hopefully include the a final version of Cambam's overheating system from his TMR fork. I am trying to figure out how I can make the 'heat distortion' particle effect appear over the barrel when the player aims with an overheating weapon. (There's no reliable way to 'find' the barrel's position in the world.) There should also be some very small chance of jamming at extreme heat levels.

Public Alpha 0.5alpha2 New modules --------------------- tmr_ai An ambitious AI overhaul based on tweaking engine values rather than using performance-hungry and often unreliable scripting techniques. Includes the usual adjustments to AI skills and accuracy, carefully tuned to create a dangerous and fast-reacting foe in CQB which does not turn into an aimbot at longer ranges. The most exciting feature is a complete rewrite of the AI weapon engagement patterns for most small arms (more to come). The AI will now fire bursts with their LMGs of varying lengths depending on the engagement range, slow their firing rate at longer ranges, and more. AI employment of fragmentation grenades and underbarrel grenade launchers is both more aggressive and less 'laser guided.' The AI will occasionally deploy smoke (again, no scripts). They will also engage at greater ranges more aggressively but less accurately. tmr_blastfrag Complete fragmentation simulation system for explosives. Most are implemented. Frag velocity calculated using real data and the Gurney equations where available. Uses an intelligent fragment generation system which only directs fragments where they will hit something (object, person, vehicle) in order to allow for considerable fragmentation effects without creating network desync or latency (even w/ 40mm AGL systems). Dramatically increases the lethality of hand and UGL grenades. Predictive fragmentation system inspired by the video released by Nou showcasing his (more sophisticated) system. tmr_bodyarmor Reworks all uniform and body armor values to provide a consistent gameplay experience. All uniforms now provide exactly the same degree of protection -- very little, seeing that fabric does not stop bullets. All tactical vests and chestrigs with armor plates modeled provide additional armor to the torso only. In order to maintain game balance and realism, the CSAT LBV Harnesses also provide plate equivalent armor (imagine that the plates are included with the LBV and insert directly into the advanced CSAT uniform). All armored helmets now provide equivalent protection. Note that this system still uses the BI hitpoints system, so don't expect miracles. Three chest shots with a 6.5mm rifle will reliably drop a man wearing plate-equivalent armor. Two pistol shots to the head will kill a man with a kevlar helmet, but plate armor considerably reduces pistol damage to the chest. Rifle headshots and shots against unarmored chests reliably kill in a single hit with 6.5mm. The overarching goal of this modification was to restore the time-to-kill/shots-to-kill feel of Arma 2, and to remove the inconsistent, unpredictable, and unfun armoring intentionally implemented by BI. (Grenadier vests provide double (!!) the armor by default. Why?) tmr_hiteffects Implements several new features relating to taking damage. Increases the intensity of the red flash when shot. Causes character to vocalize when hit (don't worry, it's subtle and uses existing game sounds). Damaging grenade and explosive blasts will cause temporary ear ringing. Characters who sustain considerable damage from a gunshot or explosion have a chance to fall down, either into a tactical prone position (if standing) or onto their butt (if crouching), to reflect the result of sudden shock, blood pressure loss, and fear (not 'knockdown power'). Inspired by the implementation in tpwmod. tmr_particletweaks Currently increases the volume and duration of a smoke grenades. Should have no noticeable performance effect. tmr_physxtweaks Attempts to reduce/eliminate the character 'knockback' jerk animation thing when shot. May or may not have any effect at all. tmr_reloadspeedtweaks Slightly slows the reload speeds of some weapons to better match their associated sounds (implementation is incomplete). Reduces the reload speed of the underbarrel grenade launcher to prevent excessively rapid fire. Reduces the reload speed of launchers to prevent excessively (!!) rapid fire, especially of Titan missiles against aircraft by AI. Reloading a launcher is a bit of a time commitment, so be careful... tmr_smallarms_grenades Increases blast and damage radius of all grenades, including 40mm underbarrel grenades, which are quite weak by default. Maintains realistic kill and casualty radius. Changelog ---------------------------------- Added: Field Manual entries for many mods. Added: autorest - Configurable keybinds using latest CBA Keybinding module. Removed: aimsway -- learn to love the Bootcamp sway. Changed: smallarms_recoil -- across the board increase to recoil. Resting more important than ever. Fixed: nlaw -- Use correct keyname. DOWNLOAD @tmr-0.5alpha2.zip This is considered an Alpha release. Some features are not complete and others may have bugs, serious or otherwise. This has been tested in multiplayer. I consider the new AI to be an appropriately fun challenge on 'Normal' (aipresetlevel=1). Note that vehicle AI behaviors have not been tuned (not that thermal sight 30mm cannons will ever yield a fun gameplay experience, no matter how much tweaking is done). Excited for your feedback and bug reports. Be sure you are using the very latest CBA.

The discussion is not over, because your implication that using CBA forces projects to be licensed under the GPL is both false and dangerous to the Arma modding community. First, and fundamentally, Nou is correct. The CBA Team and the authors of its components control the licensing of CBA and the initial enforcement of those licenses, which are given legal weight via copyright and contract law. The author of a work -- the copyright owner -- gives you, the user/modder, a set of rights to use that work under a license (a contract). If you violate that contract, the author could choose to pursue legal action or have your work taken down if it is publically distributed. The right to do that rests entirely with the copyright holder. Furthermore, if the CBA team or a representative of it states that you can call CBA's functions and use CBA's features such as XEH without licensing your work under the GPL, then we are granting that right together with the rights granted by the GPL, regardless of what the GPL says or how you choose to interpret it. Second, if we take a look at the GPLv2, we find that not only is it a perfectly appropriate license for Arma mods, your interpretation is incorrect even in the absence of our clear statements about the permissibility of using CBA-added features/functions in non-GPL addons. The GPLv2 has only 11 terms and conditions. Term 0 states: "The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language." This is the crux of the so-called viral nature of the GPL. A modification that uses CBA by making calls to its functions, which are globally defined by the CBA addon in the Arma 3 scripting namespace, does not include CBA or any portion of it. No code from CBA is distributed together with such a mod. In fact, the only things which can be associated with CBA are the function names themselves, such as "CBA_fnc_registerKeybind". Therefore, such a mod is clearly not a derivative work of CBA itself. This is not at all analogous to static linking. During compilation, a statically linked library is copied into the executable image of the program being built. This means that the resultant program "contains the Program or a portion of it" and would have to be licensed under the GPL. Static linking does not occur in Arma modding in any form whatsoever. This is also not dynamic linking. "Linking" has a meaning in computer science, and you are not free to reinterpret that willy-nilly as you like. The process of 'binarizing' an Arma addon does not specifically map the CBA functions to it, and the addon can run with or without CBA. In fact, an author can simply write his own functions with the same names and SQF will use them if CBA is not loaded, since it's just looking for a variable with that name in the namespace. This is not at all how dynamic linking functions. In interpreting the GPL, the FSF specifically states in their FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program." I hope my technical descriptions above have made clear that the communication between CBA and addons which call its functions certainly satisfies the requirement that it be "at arms length" and that any addon which calls CBA-defined functions need not be free software. Only if you are directly including GPLed CBA code in your addon's binarized PBO or redistributing a modified version of CBA itself would your work be considered derivative and therefore be legally required to be released under the terms of the GPL. (And there's no reason to ever do either of these.) Because SQF does not include any form of 'linking' or anything which could be considered analogous to static or dynamic linking, there is effectively no difference between the GPL and LGPL for SQF scripts. Using the LGPL simply adds technical confusion. Consequently, anyone attempting to argue that a mod which uses CBA functions/features is virally forced to be licensed under the GPL is wrong. Period. That is Nou's stance as a CBA dev, my stance as a CBA dev, and that is the proper interpretation of the GNU GPL v2 when applied to Arma SQF and config.cpp files. More importantly, on topic, and tl;dr: there are no grounds for arguing that a mod which calls CBA functions is virally covered under the GPL, period.