gammadust

Synthesis: (27/09/2013) (OP updated) (thanks kju for suggesting this and other alive threads to be moved from beta forum) Another alternative idea that came to me during the discussion and the recurring theme of "keep it donation based", further reinforced by this thread: Bohemia/Community could support a web platform where modders could submit any of their mods to, and following the Kickstarter model, a funding/deadline goal could be estabilshed (from modest to more ambitious ones), which upon being reached would give way to the release of the mod. The focus would be not so much in assuring a modder in getting funding, but would serve as an incentive to players/users to actually contribute donations, hinting them also of the likelyhood of the goals being reached depending on popularity. Example - 100€ by January 2014 - 20 people contributing 5€ would "kickstart" the project (released openly to everyone) - those contributing would estabilish a previledged relation with the author and benefit from further support for it). A modder would estabilish a threshold from which his dedication would be properly compensated from his pov, but similarly to the kickstarter model, the goals could absolutely be surpassed. Donations would be shared between the modder and the host of the crowfunding platform. This could be done out of any Steam/Steamworks complications. Imo cooperation with Steam to support such a thing is as outlandish as "Steam providing a Paypal Donation button" on their own platform (or is it?)

I'm skeptical of Mantle purpose as an alternative to DirectX, afawk it will stay exclusive to AMD cards... I never understood why OpenGL, given it being both software and hardware platform agnostic, never got more adopted by developers. Even considering the feature set against DirectX. (am i willingly being naive?)

I looked for them with near overcast weather (below 50% - before global sunlight is reduced) and did not see them. I would like to keep my hopes up for those and maybe even cloud shadows too (it appears to be a screenspace effect and the intersection of those rays with the depth buffer could be not too far from provinding an approximation of ground shadows). In any case they give a lot of atmosphere in woods. Love them. It exists already ;) hint, hint... i do need to update the effects strength now.

Known issue: addGoggles - Place Goggles in Ammocrates?. please vote it. You can directly add those to the player (or other units) {player addGoggles "<Goggles Class>"}. But i do think VAS author was able to find a more complete workaround.

this blog, via RockPaperShotgun I don't really think AMD's Mantle is related. If indeed purports to serve an alternative to DirectX, there is OpenGL to consider still, which is already used for Mac compatible Steam titles. I don't think OpenGL is to be let go anytime soon, and rightly so imo. I would prefer seeing AMD and NVIDIA joining Steam's efforts to dethrone the exclusivity of DirectX. Edit: i also think of how steep would be the learning curve of the new API. For how long is Frostbite engine being adjusted to support it from next december?

Not following my own advice unfortunately... let me put it another way: it is of as much consequence to you as any other feedback. I kept it generalized since the derrailing of the thread came from both "camps", there was a pointless exchange offtopic (out of object of feedback and response). If you think the only way for Bohemia to keep you satisfied is countering the petition/letter/feedback/organized-opinion, just do it. You must choose to trust Bohemia to make the right decision either way, if nothing else because it is their prerrogative alone. It's if like assuming Bohemia is childish in their decision process in regards to satisfying their customer base (veteran, current and future) otherwise.

Great feedback letter, gratz CiA. Some very good points in there. Great dev response, gratz DnA. Let's keep the spirit up for the upcomming challenges. PS: There is simply no object for the heated exchange going around. Why oh why do some people have the urge to discuss certain stuff of no consequence to them or anyone else losing their posture in the process. Agree/disagree with the letter, agree/disagree with the reponse, please stop with the meta. Really!

you may also try to give a suitable waypoint type - Seek & Destroy mentions "A leader on foot will rarely search more than 50m from the waypoint". Haven't actually tested to vouch for its reliability though.

@froggyluv "we use zoom and the AI should also have that benefit yet I don't believe we see the effect." Disagree. AI does not have issues with resolution or how big is the screen area occupied by a unit. In fact i believe this to be the very reason it is hard to simulate visual perception in AI terms. Zooming helps a player identify a target only because there are more pixels to find. This is not the issue with AI (i suppose). I suspect AI follows a threshold upon which given a "spotDistance" and a "spotTime" it detects or not a threat in a very binary fashion (these are not alone: fov, camuflage are to be expected also). This as opposed to a very human like "fuzzy detection": "that looks like an enemy but may be a civillian or a simple bush", "that is most likely an enemy", "that is certainly an enemy" and so on. With this i mean that AI is not exacly in a disavantage in regards to detection, i say this mostly experiencing AI with no mods and at regular skill level. "The other is that we can use camera angle (3rd person) as well as incremental stance which the AI can't so that somewhat evens it out." Mind: 3rd person where able... but still i don't really think these differences actually even out. Not so much because is not possible to win against AI overall (we can indeed) but because there are very specific instances where it is absolutely unbalanced in favour of AI and/or vice-versa. Maybe globally it evens out (given some settings and actual human players skill) yet the effort towards balance in more discreet circumstances should be pushed forward.

^^ +1

Re: AI retains maximum knowledge of target position/movement even when totally obscured (i.e., can kill through bushes) i added LOS cover checks to the repros to better inform conclusions. Please vote it.

^^ AI don't keep up, and do not respond well to "move" or "get in" commands when in "danger" mode. (dupes: "Just do it" AI Command / Retreat Option for AI Squad) vote it :)

Those commands are returning the correct string. They will only change if you specifically setWaypointFormation and setWaypointBehaviour. You should use formation and behaviour to access current values. This way you can still have AI defined behaviours while able to overide them with waypoints.

^^ fortunately not, there are surprising detections out of expected fov and maybe los but not that worrisome :) Those red and blue lines are returns from assignedTarget (blue for blufor units / red for opfor units). BF13_8 has OF13_4 (bottom right) as an assigned target. Coverage script which would show LOS is deactivated at that point in time. Lines in that case are colored Red (unobstructed / out-of-cover) and Green (obstructed / in-cover)

v1.1 by gamma Description: - Implements lens tinting to available Goggles and Glasses - Celebrating my 3rd year in BI's Forum - Appreciation for Bohemia's sandbox and this community's dedication (or how much of a fanboy i am) Install: Mod version: - Copy folders "@GAM" and "userconfig" inside zip to your MAIN Arma 3 directory - Add "-mod=@GAM" to your Arma 3 shortcut - Open "userconfig\GAM\GAM_PPEG.hpp" to customize your options Mission version: - Copy 'GAM_ppEffectsGoggles.sqf' to the mission folder - Include the following code in your mission "init.sqf": // makes sure it is not already running as a mod if (isNil {GAM_ppEffectsGoggles}) then {GAM_ppEffectsGoggles = compile preProcessFileLineNumbers 'GAM_ppEffectsGoggles.sqf'; GAM_ppEffectsGogglesInit = [true, false, 10] spawn GAM_ppEffectsGoggles}; //[_withmenu, _enableExternal, _eyeAdapt] //[boolean, boolean, number (seconds)] Usage: - Access the menu to change goggles/glasses This is to facilitate experimentation since it is hard to fill an ammo crate with the available glasses/goggles (can be disabled) Features: - Affects the colouring of the screen depending on the lens used by the Goggles/Glasses - Detects removal and disables the effect - The effect is disabled on 3rd Person views - Simulates (exaggerates) the effect of eye adaptation when wearing and removing (10 seconds) - Includes key Observations: - Script runs client side only - Script runs in a tight loop, waiting for an event based solution when able currently "take" and "put" EHs are insufficient for all functionality - Goggles removal colour settings are mostly wip **** LICENSE CC BY-NC-SA 3.0 **** Creative Commons Attribution-Non-Commercial-Share Alike 3.0 License Download: Dropbox link gamma's Sandbox (temporarily down)

As a workaround to get rid of the message just remove the file: "C:\ARMA3\SteamApps\common\Arma 3\@GAM\mod.cpp" I verified the distribution zip and the folder structure should be correct. Still i would recomend a complete removal of @GAM folder and proceed with a reinstall, make sure you have downloaded v1.1 from OP.

I won't be back for a week, but check link for an experimental MP version (some notes for usage here)

Ok an update that some of you may like. I am going on vacation for a week tomorrow (sunbeach time came a little late for me this year), so i decided to make a limited release of this project for those interested be able to experiment in my absence. Download link It is currently so experimental that despite open source so that anyone can take a good look at it, i am for that reason limiting derivative works. Feel free to inspire on it, but for now no modifications are to be distributed (this is under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License). When i am content with it's development the license shall be updated to a Creative Commons Attribution-Non-Commercial-Share Alike The zip includes: - Modified AI addon affecting only OPFOR units and dangerFSM debugging colored spheres (this makes units stop when threathened as in default but staying still until no threats are in sight) - Hardcoded - Demo AI vs AI Contest mission (which puts up the different AI against each other for a number of times swaping sides) (neither of which very different from those in the videos, just some minor updates and adaptation for current Dev build, should work on Release branch too) Some notes on usage: - Objectives and Spawn markers can be moved anywhere (explore different combat places) - see Markers (F6) - A lot of AI settings are available (check GAM_setupScene function to play with those) - Take a look towards the end of init.sqf to set some contest params (number of repeats and round timeout) - Recommend going to spectator mode to observe it has dependent functionality: press L to declutter the tags press J to hide everything - There is some additional functionality that i was exploring namely FSM execution Point at unit + Press CTRL+SHIFT+Left Mouse Click to select a unit Point at place + Press CTRL+Left Mouse Click to order it to move where you want - This is all quite experimental might be easy to break I should have some minimal access to the forum while away, but won't be able to give much support if at all until i'm back in a week or so. So hope you enjoy AI experiments as much as i do (it is also interesting to remove my addon and just test different AI settings against each other - requires some scripting knowledge to edit affected AI).

init.sqf processing is automatic, you just need to have the file in the main mission folder. (also try adding parenthesis in the condition) _unit = _this select 0; // carefull with the scope of this if((typeOf _unit) == "O_Soldier_F") then // notice the (typeOf _unit) making sure _unit == "O_Soldier_F" is not being tested before { removeallweapons _unit; removeheadgear _unit; removevest _unit; removebackpack _unit; removeUniform _unit; _unit unassignItem "NVGoggles"; _unit removeItem "NVGoggles"; }; but your isse may be the: _unit = _this select 0; // this should be empty at point in time, unless you did something else beyond what you have shown Just name the unit in the 2D Editor with something like "AI1" and use that instead in the init.sqf _unit = AI1; //... rest of the code Edit: ninja'ed and by an even more direct way

^^ The community is so wide, and even spending entire weekends in the forums, you miss so much good stuff. I've joined your group, at the very least to check out (though i'm not a moddeller and the project appears inclined that way) If the concerns here are related with an eventual "badge"/"seal", i can't speak for the OP and his thinking on that, but personaly I wouldn't object. I do believe use of Standards has merits in itself, not requiring a visible certificate.

I was exacly suggesting we should approach this effort avoiding that (see bullets 7/8), in any case this would be the decision of the modder to adopt these recommendations, chosing also between a strict approach or a loose approach or even in it's extreme use them as a mere reference ("No, no, i won't do it this way, it complicates this, this and that. Better do it so..."). Even in this latter case is useful. Oh dear... Why do you say "inevitably force"? (it's a real question, is there a reason? maybe i don't see it) Adherence shall always be voluntary (the same way you pick a tutorial and you collect from it what you find useful). But in this case with the advantage (enabled by those Collection of Recommendations) that it's creation already took into account the broader picture of modding. Example: even if one just wants to create an Asset (consulting the relevant leaflet), the process followed has the potential to avoid common pitfalls, benefit from certain compatibility considerations which were already taken care of. Load is taken away from the modder in two ways, those aware of pitfalls don't have to constantly remind themselves of such, and those unware benefit silently. All in a more cohesive manner. Not in a one-size-fits-all, which would be impossible, but through a common denominator between very disparate possibilities. The latter would automatically imply a very basic level of depthness in the information as opposed to long and extensive how-to's. At the very least recommendations would be using commonly accepted language to refer to anything, facilitating the search for alternative avenues of creation to the non-adopter. Even questions/issues popping up in the forums have the potential to be of a more informed level, and easier to address. Aside - In my country there is and was a very big issue with language. Government decided to change the language by decree. It did not work, it is not working (after 1 decade+). Culture follows it's own steps. Adoption in schools is limited by the understanding of new orthography rules by the very theachers, there's an awful lot of ambiguity - imagine correction of exams. Full blown foundations/institutions repel it. Why do i think this can be diferent? Because the point is not to enforce anything, higher adoption will come about in a measure of success and merit of the very recomendations. Maybe we should not even call it recomendations, if it runs the risk of carrying that negative weight, and maybe find an alternative wording for it: "Modding Good-Practices" / "Modding Common-Practices" / "Modding Topics" Really the point is absolutely NOT to force anything on anyone. Recommendations are not Rules (see bullet 6). They're not even minimum thresholds for quality. I am at least personaly trying to push it away from there.

@suprememodder dynamic event driven scripting is totaly possible for that and any other purposes, it depends on creativity though.

There is a ticket for that here BUT... I disagree here, while group sharing of threats is expected naturaly, i would only see this as a default behaviour if some sort of chain-of-command is actually present. Specially since information sharing even between the group has issues. Not until the latter is attended. In the current state and if implemented as an option, I wouldn't find issue if this was functionality provided by "High Command" module.

Class name and condition look correct, and assuming the rest also, just try typeOf in the condition instead of isClass (which serves to check config returns). // make sure you keep track of the spawned unit for the variable "_unit" to work if(typeOf _unit == "O_Soldier_F") then { removeallweapons _unit; removeheadgear _unit; removevest _unit; removebackpack _unit; removeUniform _unit; _unit unassignItem "NVGoggles"; _unit removeItem "NVGoggles"; };

I am actually recovering the idea of antoineflemming, could actually help us start out because it is a good analogy. Let's make ourselves Editors / Contributing Authors of a Leaflet* Collection on "Modding for Arma 3", titles follow: The leaflets could be an ongoing effort and versioned (say to keep it relatively stable, every 6 months a revision is made, apart from the first version which may require a more flexible time to be created) Stressing that an outline of the purposes of the collection of leaflets should be set before actual creation People contribute on a voluntary basis, preferably focusing on a leaflet topic, a review for accuracy would be swell from knowledgeable members which we have (a CaMSO could wrap it up). Quality would not come from the preference of a method over another that someone can contribute (if there are two good methods, include them both as alternatives) Quality would be inherent to the project due to the overall accuracy of the information and the safety net it provides to anyone which adheres to it. The better and solid the information the more merit it will have and higher the adoption. The possibility of a modder adopting certain visual/presentation recommendation, should never go pass that: a recommendation. In fact the whole thing is exacly that a nothing more: A Collection of Recommendations Attribution of a "Seal of Quality/Compliace" is a matter that I suggest we keep parallel to this effort and not tied to it. Imo this should be taken not so much as a serious Industry-Standard-General-Assembly-Sub-Commission-for-Proper-Addons but as a modest effort to facilitate the modding scene. We don't need to publish all the leaflets at once This facilitates finding volunteers to contribute and begin on an availbility basis Just the [1 - General Creation of an Addon and Logistics] and [2 - Mission Creation] would already make a significant difference, and are actually the most pressing because of the Steam Workshop current ability to share them wide be them seasoned mission makers be them the very player base(certain issues do not show their ugly head here) Edit: some additional stuff that came to mind. Also, i offer myself straight away to compile anything we can come up with in the end in a tidy and good looking PDF.