Matthew10_28

I believe the answers can be simpler than what even I originally had in mind, but forums aren't conducive to developing something like this now that it's being refined. Even part of this thread, I refined much of the decision making to be done by the player and not the AI. The player would basically instruct the AI to execute a specific battle drill with the required inputs. Anyway, at this stage it requires much more of a natural conversation. Are you interested in discussing this further via something like google hangouts?

I admit I was intentionally sparse with my description. I didn't want to scare anyone away with academic fluff. I honestly didn't think there was anyone remotely interested in this sort of thing but not posting it would leave me guessing. Your response has me refining my intent. Having been exposed to and taught the EDM, often what the physical "what do we do now" answer amounts too is relatively simple. Now that there is a dialogue going, perhaps we can continue the discussion as to what this actually means (or can mean) for ArmA. What I had envisioned was the commander being the player. That takes the brunt off of AI to do the cognitive modeling. You are entirely correct in that there is too much about OCOKA and METT-TC and experience with each that you'd have to model before being able to model EDM. The attached AI would wait for player input and respond accordingly. After he gives his decision to (attack, defend, or withdrawal). What those end up looking like should be well rehearsed battle drills that are fairly simple sequences. It's my belief that without a well behaved AI carrying out the results of the players decision, the success of the EDM (at least in ArmA) can't be verified. Basically, the current AI is too "dumb" to be relied on for basic attack, defend, and withdraw functions. I've never seen AI in game do anything remotely close to any of those battle drills. I've seen some decent flanking, but nothing consistently "correct". In its most basic, albeit oversimplified form, the EDM looks like this in practical terms. Step 1 is "always" a React to Contact battle drill. Everyone gets on line and orients towards the threat detected. This allows the commander to make his decision and have his forces correctly postured to take any action. If the answer is attack, then there is a Hasty Attack battle drill. Basically an "L" shape with a base of fire team and a flanking team. Sweep across the objective to the established Limit of Advance. If the answer is defend, then you set up an area defense appropriately scaled for the size of your forces. Make a lazy "W" line shape using natural cover and concealment. It might take more of the form of a patrol base, which in this case would be by definition established by using the "occupy by force" method. If the answer is withdraw, then you use the Break Contact battle drill. Of course we can get more sophisticated. e.g., what you do on a raid (a form of attack) is different than on and ambush (also a form of attack). But not too terribly different. Would it be reasonable to build AI for these three battle drills: React to Contact, Hasty Attack, and Break Contact? I think this is a better description of what I was envisioning. Per my above, if each battle drill is essentially a script, then its just a matter if giving the player control of when and what battle drills get executed. I think this is more doable, yes? If I can do a little vision casting here, I never intend for subordinate AI units to have to make these type of decisions. Even the most complex task to pull off for an infantry squad (which I'll argue is the raid) is really just plugging in variables of locations, signals for sequence, and conditions upon which to act and what to do as actions. Ultimately, all of those are too complex for an AI system to try and understand, let alone take action by setting those variables itself. It might not be realistic for the player to take on that cognitive load entirely by him/her self, but that's balanced by the fact that they are sitting in a chair in front of a PC not carrying 60 lbs of crap on them and having not just hiked for 10 KM with all that stuff on.

I'm looking for someone who would be willing to take on the programming and scripting necessary to create an AI mod for ArmA 3 that follows a specific decision making process flow. I've been peripherally involved with recent research involving cognitive dominance for the infantry squad by way of the Engagement Decision Matrix (EDM). I'd like to be able to model the EDM through an AI mod to ArmA as a way of testing and/or verifying the validity of the EDM. This person should already be familiar with how the AI in ArmA works and should be able to use that basis of knowledge to build a working EDM model on. See the links listed on the following website for more info on the EDM: http://warnerds.com/?page_id=474

Thanks. I guess since it was a new model, I didn't think to check the EULA again. My bad. I hope to see an official solid color re-texture of that uniform pattern in the future sometime. Atlanco TruSpec makes the T.R.U. (Tactical Response Uniform) and Propper makes the TAC.U in solid colors. Its the same fabric pattern as the ACU.

Oh man I missed that part. I don't wan to step on those toes. Abort. Abort. Abort. For my own understanding, where did I miss that so I don't try to do something similar in the future?

I was able to change the various textures of the subject uniform via setObjectTexture, but when I went to make it part of our mod pack like I have before, its not working. It shows another uniform in our mod pack. I've stared at this long enough, I've got to be missing something simple. At first, I thought this would be more simple, as my ultimate goal is to fix the overly shiny rvmat & smdi textures - they are really throwing off any solid color variant of this uniform pattern. Here is the relevant code: class 1S_OD_UNI : rhs_uniform_acu_ucp { author = "Matthew10_28"; scope = 2; scopeCurator =2; scopeArsenal = 2; displayName = "1S OPFOR UNI (OD)"; hiddenSelections[] = {"camo1","camo2","camo3","identity","insignia"}; hiddenSelectionsTextures[] = {"One_Shepherd\data\pics\rhsusf_uniform_TRU_01_OD_co.paa","One_Shepherd\data\pics\rhsusf_uniform_TRU_02_OD_co.paa","One_Shepherd\data\pics\rhsusf_uniform_TRU_03_OD_co.paa","",""}; class ItemInfo : UniformItem { uniformClass = "1S_OPFOR"; //unit that wears it containerClass = "Supply20"; //how much it can carry mass = 40; //how much it weights hiddenSelections[] = {"camo1","camo2","camo3","identity","insignia"}; hiddenSelectionsTextures[] = {"One_Shepherd\data\pics\rhsusf_uniform_TRU_01_OD_co.paa","One_Shepherd\data\pics\rhsusf_uniform_TRU_02_OD_co.paa","One_Shepherd\data\pics\rhsusf_uniform_TRU_03_OD_co.paa","",""}; }; };

I guess I'm missing the obvious. How do I use hiddenSelectionMaterial to point to my altered SMDI texture? Yest it can. I see the icon in your sig line but the ACU has 5 hiddenSelections. 0 is the blouse, 1 is the trousers, 2 is the boots, 3 is the name tapes and rank, 4 is the shoulder insignia. I've actually re-textured everything but the rank and insignia so far. Granted I don't like what I've done, hence the original question. http://www.rhsmods.org/w/acu hiddenSelections[] = { "camo1", "camo2", "camo3", "identity", "insignia" };

I was struggling with getting the color right on a uniform retexture I was doing on the ACU included in RHS. I realized the SMDI layer was way too glossy and shiny and was complicating things. The Green layer was at 30 and the Blue was at 255. From my understanding, there shouldn't be any Green (metallic gloss) and the Blue values are the opposite of a matte finish. I was changing textures with the setObjectTexture command in game so I could quickly iterate changes as I alt-tabed back and forth tweaking colors. I found the setObjectMaterial command but in reading the Wiki, I assume it only works with the rvmat layer. Is there a command to quickly set the smdi layer? When setting up my uniform class in my mod and I inherit everything but the CO texture and SMDI, how do I point it to the alternate SMDI? hiddenSelections[]? hiddenSelectionMaterials[]? How do I know what position in the array the SMDI sits at in those?

I was referred to this from here: I don't have as strong of a development background as I need to understand this and run with it. Would someone be willing to walk me through how I might be able to use this for my purposes?

Just reading that description seems very promising. I barely understand it though. Have you seen any examples of this you can point me to so I can dissect? I tend to learn best by picking apart examples and rewiring them.

So you have a few options as I see it. Look into a mod that universally gives you more storage and stamina (which you've already done it sounds like). You could also produce your own mod that does nothing more that inherit all the assets you want but reduces their mass to nothing. This is very tedious work. In reality, I think you need to look at the arsenal. You can look into ways of using it, but basically you'll have every item and weapon available to you at any time. This only works in single player campaigns you create or in multiplayer missions you make. If you use a mod called Ares, you can have arsenal during campaign modes too, but it will be implemented a bit differently.

I've been trying to learn more about Extensions. When I research what I'm trying to accomplish, they keep coming up, but I'm wondering if there is another way. Basically I want to be able to pull values from ArmA 3 and pass them outside the game for use elsewhere. From what I'm reading on extensions, it looks like they are a two way path. I really only need a one way path at this point as it doesn't need to wait for a value to return. Examples always help. I ran across Logitech ARX control and an applet that pulls flight indicator data from the game War Thunder and displays it on an android or iOS device. Turns out they were just using this and hooked it up to Logitechs ARX. https://github.com/sebmatton/jQuery-Flight-Indicators In general, I'd like to be able to pull any sort of live value: altitude, airspeed, heading, player grid position, in game time, ammo count, etc. Basically anything that can be obtained through existing in game functions and scripting. It only needs to be passed one way, outside of the game for handling else where like the jQuery flight indicators. Even an Arduino display might be cool to always have your grid coordinates without it taking up valuable screen real estate. If .dll's written in C are the only way to go for ArmA 3, then I really need to pick apart the code examples I'm seeing. It looks so confusing to me right now.

Is there any way to get the MFD display to work on a second & third monitor? Are their any plans for this? The screen is quickly filling up with overlays and allowing this type of data to be viewed on another monitor would go a long way in minimizing the UI for non-critical or "glanced at" information like this. I imagine most users are going to leave these on all the time which eats screen space. The ultimate desire would be to push this portion of the display to a smaller set of monitors along with Thrustmaster MFD Cougar sitting over each.

Now that we have a more robust set of MFD's, single monitors are quickly getting crowded. We've had targeting pod camera displays available for some time, but I'm curious to know if there is any method to grab these video displays/moving textures and display them on a second monitor. The desired end state is to have small usb monitors with Thrustmaster MFD Cougars.

As a method of near-character identification and to add a sense community through personalization, I have retextured uniforms to add branch and name tapes to uniforms. I have also retextured backpacks to add custom name tapes. Basically, new members get their name on a uniform, but this adds to the file size of our small modpack by about 5 meg for every new player. I've found this method which uses a separate name tape object and the attachTo method, but it appears it has a major limitation of not staying properly oriented to the parent object. https://forums.bistudio.com/topic/160703-attachto-object-to-backpack/ The only reasonable idea I've come up with is creating "hiddentexture" zones around the uniform model/texture we use. Then I'd only have to have a small (in filesize) image of the name tape or patch to be associated with that zone. I could see this happening to the uniform and maybe a couple backpacks we typically use. This would easily reduce the file size burden. If you are curious, the branch nametape goes across the left chest and the persons name goes across the right chest as well as the right side thigh pocket flap. Any other ideas? How do I go about modifying an existing model/texture to add in a named hidden texture zone I can use later? I haven't run across anything on how to do that.