Freghar

"Open Door" on a keybind. Please. Pretty please. ACE3 has it and it's such a joy to use when clearing buildings.

For anyone interested, there's remoteExecCall that is actually able to execute code in an unscheduled environment even when run from scheduled. The downside is that it produces network traffic (even if the object is local / this client's ID is specified, tested by packet capture) and doesn't pause the scheduled execution nor does it provide any handle to wait on. It would still be great to have a way of executing unscheduled code from scheduled execution, waiting for it to complete. This could be used to implement mutexes where necessary (independently spawned scripts needing to modify one object and do so in a specific sequential fashion, ie. hierarchical loadout modification).

(As the feedback tracker is still down, this seems an appropriate section for a feature request.) Please add a Mission Event Handler that would run CODE when any entity is initialized, similarly to the "init" Event Handler, which can (unfortunately) be used only from a mod (config). This would work very much like existing EntityKilled / EntityRespawned Mission Event Handlers (https://community.bistudio.com/wiki/Arma_3:_Event_Handlers/addMissionEventHandler). The idea is to execute an arbitrary CODE on Curator spawn, createVehicle, etc., but also for each editor-placed unit if the Mission Event Handler is registered from a preInit function, avoiding the need for a separate "allUnits" loop. I'm not aware of any existing non-modded way to achieve something similar (only CBA), if there is, please mention it, thanks.

(Since this thread is still active, I'll at least reference one of the controversies surrounding GameWorks in general. I know Arma 3 is already using some features and I don't have a good reason for/against, .. just please be very mindful of the political implications and hidden agendas the "helpful" support from NVidia has. There are many ways, most of them considered "unethical" and "manipulative" which could be in effect and if NVidia marketing is clever enough, these are in effect. I would hate to see Arma 3 being primarily an NVidia game, with AMD "just on the side".) In a popularized video form: https://www.youtube.com/watch?v=ZcF36_qMd8M.

"+1" I know Arma3 tends to go the simplified route and automate things away from the player, but doing it like described above is also very easy to use (and realistic?) - both for zeroing in and leading moving targets. I believe it was AGM that had a working implementation some months ago. It probably wouldn't work well for leading targets in an aircraft, wouldn't work well with fixed 100m-based range increments in vehicles, would need a different indicator, .. ah well, I tried. :)

Sorry, I didn't mean to exaggerate, I've also been playing this game since initial OPFL launch and I know the general mod-friendly nature of the community, but the entire point of this topic was to see if there's any actual legal protection for modders / mission makers besides the "promise". I never stated or wanted to state that "no addon should have been released", again - the point here was not to get "practical" answers, but legally correct answers. From the perspective of game modding scene, it may come across as a bit harsh, but in the software development scene (and specially OSS), these things matter quite a lot and I simply wanted to know what's the case regarding Arma 3.

Hello, a simple question - are we allowed to re-use scripts from the official content (ie. Arma 3 campaigns) in our missions/mods, without having to ask Bohemia Interactive for an explicit licensing permission? If so, under what conditions? Based on my findings, this is not possible - BI does provide APL(-ish) licensed sample packages, but the official content still seems to fall under EULA, which quite clearly covers modification/reuse/distribution in section 3. The Licenses page says that however it doesn't further clarify what "publicly available" exactly means or under what license(s) the official game data are distributed. Can you please point me to some official sources? Thank you.

However this doesn't grant you any legal power to modify the game, in fact the EULA seems to outright forbid it, The fact that BI chooses not to exercise its rights doesn't make the action itself legal. Not matter how many decades it's being going on. What is the difference again? Where does modding end and redistribution begin? The EULA doesn't allow either and as far as I know (hence this topic), the files were not released under APL or any other license. I guess I just don't see it in the EULA. It says "You are entitled to use the Program for your own use", but again - would modding be considered "use"? I guess it could be, but it's a gray area at best (especially considering taking scripts from the campaign, "copying parts of the Program"). While this could aid clarification of the "use" clause, it still remains too vague. Actions of the company don't substitute the license in the legal sense. So I guess it's "just do whatever seems reasonable and hope BI won't use it against you"? (As far as I know, that's how game modding works in general.)

Sure, but where to draw the line? A jury would draw one for sure, but it would be useful to know roughly where it is before a legal action is taken. For example - can I re-use the Zeus (MP) Training mission scripts for my own training mission, which would be essentially a copy of the old one with changed location and some extra scripts on top? Why? How is this different from adding a few "hints" to the campaign and releasing it as a "better campaign edition"? The copyright around the world generally doesn't allow modification/re-distribution unless the license allows it, even as far as derivative works go ("fair use" is a US-only thing and even that covers very little of derivation).

Do you please have any source to back it up? .. Because this would allow me to ie. re-release the official campaign (or anything that comes with Apex) for free under APL, which doesn't seem like something that should be possible.

If anything, too much Starobahno. :P (You can never completely get rid of it.)

The issue is that SQF is currently unable to achieve race-free design without mutexes and at all if the code conflicts with what any existing mutex-less code does.An example, written in pseudocode, if (player-has-binoculars) { remove-rocket-launcher; } on the start of a mission, to remove all rocket launchers from "officers".The condition might match in a completely different environment than the action is executed in: missions starts condition matches, player has binoculars execution gets suspended player drops the rocket launcher execution resumes code tries to remove rocket launcher, nothing to remove, finishes player picks up the rocket launcher There's currently no way to "fix" that (in a scheduled environment).

Are you sure you know what you want? The @12 is a "standard" (commonly used on Windows) C symbol decorator, nr. of bytes used as arguments (3*4=12). Even the GNU GCC uses it when building code for Windows (mingw). The same thing is AFAIK used by Borland. For C++, this would be much bigger (compiler-specific) mess due to fuctions with the same name, namespaces, etc., which is why you use the extern "C" thing. If you're 100% sure Boland C++ doesn't add the decorator, there will probably be a #pragma for it to rename the symbol manually. See https://community.bistudio.com/wiki/Extensions . Unfortunately not for everyone (no Linux support as far as I can tell). Nice experiment, though.

Hello, can I somehow perform a piece of code whenever a new vehicle (unit, non-agent preferably) is created, either via the Curator or as createVehicle? The use case is to be able to add a Killed EH for the unit, to add the hideBody menu action, as there's apparently no universal Killed EH that would trigger for any vehicle without prior registration for that vehicle. Reading the wiki, I found https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#Init, but I seem to be unable to register any EHs from description.ext, so I presume this is limited to addons. I also found https://forums.bistudio.com/topic/185201-apply-onkilledsqf-to-ai-spawned-from-a-module/ , where people suggest looping all units, which is certainly doable, although very inefficient, has to be performed repeatedly and creates a race condition (vehicle killed before the Killed EH is added). Also, I don't have any way of checking if that Killed EH is already registered for a vehicle. Any ideas, please? Can I use CBA's XEH for this somehow? Some of them seem to be usable from description.ext, although they seem to be limited to mission start. Thank you.

Thanks, I missed that - it seems these (Killed/Respawned) are fairly new (1.55), cool. :)

For anyone interested, it turns out there was actually a XEH for when any (from editor, Curator, createVehicle, ..) unit is killed, class Extended_Killed_Eventhandlers { class CAManBase { class XEH_HideBodyAction { killed = "(_this select 0) call your_fnc_hidebody;" }; }; }; params ["_corpse"]; _corpse addAction [ "Hide Body", { params ["_target", "_caller"]; hideBody _target; _caller playActionNow "MedicOther"; }, nil, 0.1, true, true, "", "(_target distance _this) < 2" ]; Too bad attachTo doesn't work on corpses, that would have been much better for hiding bodies away.Thanks for helping anyway, I appreciate it. :)

This unfortunately doesn't help me with mods which use createVehicle directly (and which I don't want to / can not edit). Needless to say, the XEH I posted does exactly what I wanted - it even triggers for crew in a Curator-spawned vehicle, which is awesome.

Thanks, I kind of started investigating the XEH idea as soon as I wrote it and it turns out to be pretty simple: class Extended_Init_Eventhandlers { class CAManBase { class XEH_MyOwnXEHTest { init = "0 = (_this select 0) spawn { sleep 5; deleteVehicle _this; }"; }; }; }; I wonder, though, if this could be done without CBA.

Good to know, thanks. If Arma is indeed RAM-intensive, a large eDRAM cache can certainly do that. The question is whether it makes sense to buy a "better" mainstream for premium price or go for the "enthusiast" segment with quad-channel memory and bigger L2/L3 caches. (Currently waiting for Broadwell-E vs AMD Zen.) :) edit: Are you sure they used dedicated (discrete) graphics for the test? .. Integrated (APUs) hugely benefit from higher RAM speeds as they essentially use RAM as their VRAM (and DDR3 is pathetic compared to GDDR5). The other benchmarks of integrated graphics make me wonder.

I would hereby like to thank you for the provided humor, it was indeed entertaining and enlightening. For example, Everybody knows (I think) it's the other way around - https://en.wikipedia.org/wiki/Space–time_tradeoff. (Or just from the other referenced thread.) Measurements seem to disagree - during runtime, reads peak around ~300 IOPS with rotational HDD doing ~110 random IOPS and a regular SSD ~80000. Most of the time, however, the IO pattern is not random and doesn't go above 30 IOPS. Again, not true, measurements easily confirm it. Although popular belief, not exactly true - http://www.crucial.com/usa/en/memory-performance-speed-latency. Yes, higher throughput = better, lower latency = better, but comparing the two against each other on a theoretical level is nonsense. Especially given how DRAM actually works - prefetching, pipelines, etc. And that DDR4 catches up on higher frequencies in latency. Not to mention the relative unimportance of RAM speeds with discrete graphics these days (lots of L2/L3 cache) for most applications - few still benefit, would be nice to see Arma benchmarks. This is completely false. Don't take my word for it, measure it. SSD helps for terrain that changes quickly, but single-thread (CPU) is still the main bottleneck to the point where OC'ing my i5 turbo from 3.7GHz to 4.0GHz gives me 6FPS extra in a busy firefight where HDD/SSD activity is negligible. Ah, another "troll", right? Nope, measurements showed no correlation, it's the reads that are visible. Confusing throughput with latency. 500MB/s is much more than enough. Mhm. Not true again, Arma doesn't load the entire island into RAM and data are indeed loaded from the HDD - even the same data multiple times. In ideal world, it would not be, but that's not what the stats show. By the way, a bit inconsistent with your previous "facts". Again with the firm declarations - any references to sources? If you in fact read the JEDEC standard and the previous ones, you see that DDR4 is just another small evolution over DDR3, adjusting throughput, power consumption, adding 3D stacked die, adjusting the signalling, ... few bits and bobs, not a whole new architecture. That's why DDR4 wasn't here in 2013 - nobody wants it because there are no practical benefits that would justify the cost (currently, this will change with higher freqs). I'm just going to leave that without additional comment as the last paragraph is the punchline. You should perhaps reconsider your life philosophy, the current one seems to be around making things up out of thin air and declaring them as facts, which makes you look knowledgeable, but when it backfires, you have to use the lalala-I-dont-hear-you-troll technique, which kind of discredits you. You have unfortunately chosen the wrong area - in science/technology, things can be objectively right (facts) and wrong and when you state something as fact, it can be proven true or false, objectively, with no subjective bias of opinion. References are a big part of that - when I'm wrong, I can usually point to where I got the original info from and blame/fix that source. When I'm right, it only backs up my claims. So .. perhaps marketing would suit you better? If not, please don't mix basic knowledge together, the mix doesn't produce deep knowledge, even if it might confuse and trick the less knowledgeable. When you make assumptions, mark them as such ("I think this means ..."), not as facts. Indeed. PS: Since you seem to be using "virtual memory" incorrectly in a consistent fashion, you might want to read about virtual memory.

Okay, thanks, too bad.One also cannot disable the global channel for the logged in admin player (or the host), which isn't an issue for most dedicated servers, though it's good to know. Yes, I use something similar as a workaround.

As a wild possibility, the system could keep multiple files/ranges loaded even if Arma is not using them due to how the memory-mapped files API seems to work (according to the documentation). There seems to be a two-layer approach of opening the file itself and mapping parts ("views") of it into the virtual memory. Now, if Arma doesn't close the files during runtime of a mission, but only unmaps the views from VM, the system could theoretically hold the files open / mapped. When the mission ends, Arma closes the files, which makes Windows release the resources. If Arma did close the file(s) on unmap, it would use much less RAM, but at the expense of disk traffic, assuming the OS doesn't cache memory-mapped files. Very wild guess, although it makes at least some sense (come on). :) To reiterate - the "used" RAM isn't really "used", it could be easily purged as all the data are stored on the disk in files - this is normally what Linux would do with a low swappiness value and when under memory pressure. Windows might prefer paging out active memory. :(

The crazy part is that this shouldn't be needed. Memory-mapped files are a simple concept that has nothing to do with pagefiles - actually, a pagefile is a memory-mapped file, by the kernel. :) The concept itself is really simple - you just let the page fault handling routine do all the work. That's why the relation to pagefile is baffling as, traditionally, memory-mapped files cannot be "paged out" to pagefile as they're at the same "level". I mean - it would make sense with anonymous (not file-backed) memory - if the system was low on RAM, the memory could be paged out to make room for other memory-mapped content. This is in fact what might be happening with multiple GPUs and not enough RAM. As I try to understand memory management on Windows more, I find it pretty complex and somewhat stupid, compared to Linux memory management. Windows doesn't even have a decent page (disk) cache, you have to use external software like this to get the basic functionality. It also apparently divides memory (even with win7+) into multiple non-overlapping areas for fs cache and "programs" at least, instead of sharing the space. On top of that, it seems to have poor page eviction policies (that are impossible to tune?), paging out running programs to make room for more cache, to the point that a separate DynCache service is apparently needed to stop this madness. I would like to properly answer some of what Arma does, but I really can't as Windows memory management is just freaking weird. And not documented! My theory so far (based on some sources) that memory-mapped files on Windows bypass the "Cache Manager" and - by extension - the page cache. That's maybe why I can see disk activity when loading textures upon returning to a specific place multiple times (which shouldn't happen as the cache should kick in). Or maybe the 50MB of cache the kernel is reporting is really it, which obviously isn't enough. Increasing the minimum working set (sysinternals CacheSet / DynCache linked above) doesn't really help. Read the previous posts - I explained that unfortunately I see difference with/without pagefile (on a ramdisk or not) and I indeed did the last set of benchmarks without pagefile (highlighted in bold).

To repeat the main point again - it's not about seeing a big "RAM: 12345 MB" number, screaming "TOO MUCH!!!", it's about understanding what that number refers to, what it actually measures. If it is even correct in the first place. You would do that by using some other system performance measurement tools that tell you know where your RAM is spent. Aside from perfmon, I was able to quickly google out http://www.microsoft.com/whdc/DevTools/Debugging/default.mspxand http://www.microsoft.com/whdc/DevTools/tools/DrvVerifier.mspx , for example. If you just keep pointing to the big obvious number, you'll get nowhere.

Were you able to solve this? .. I'm currently facing a similar issue - { _x enableChannel false; } forEach [0,1,2,3,4]; I can disable Side, Command and Vehicle, but not Global or Group despite the wiki claiming it to be possible.