Matthew10_28

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'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

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.

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 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?

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.

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.

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.

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.

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.

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.

The problem is this: If you have items in your backpack and you access Arsenal (via virtual arsenal in the main menu, self hosting a mission with arsenal attached to an object, etc) those items duplicate. It doesn't matter what the item type or mod of origin. If you check inventory before accessing, then access Arsenal and look at your contents of the backpack there, the items are doubled. i.e. if you have 2 epi pens before accessing arsenal, you will have 4 the moment its triggered. It can be any object type (hats, magazines, ace items, etc) The effect is accumulative every time you re-access arsenal. 2 becomes 4 which becomes 8, etc. I've got 13 mods technically in play (rhs, tfar, shacktac, etc) but I've recently narrowed it down to a problem with my own mod. When I turn it off, the problem stops. Someone in our group said my server was the only place he'd ever had the Arsenal problem, so I narrowed it down to my mod and it doesn't even have to be associated with a server so JIP and desync issues are ruled out. Before I go posting my 1500+ line config.cpp, are their any ideas as to what would cause this? My mod is pretty simple in that it adds a few custom uniform textures, backpack textures, custom faction definitions, unit loadouts, weapon config to pre-group accesories & attachments, pre-filled backpack definitions, etc. It's all inherited class stuff. I can't imagine what in my config.cpp would cause this strange behavior.

My forum search-fu is weak. If I'm understanding that, I think the solution is to allow players to establish their loadouts specific to their backpacks via Arsenal. The only time you would pre-define a backpacks contents is for friendly AI use or to have a "go-bag" of something like medical supplies that can be loaded into a vehicle or crate inventory. Basically, if the backpack is predefined as being loaded with goodies, make sure a player never wears it while accessing the arsenal right?

These two should help. https://community.bistudio.com/wiki/speed https://community.bistudio.com/wiki/animateDoor I'm not certain of your use case, but I'd somehow put in a sleep to only open the door after the vehicle has been stopped for a period of time. Maybe 3-5 seconds. Pseudo code: if (this speed == 0; sleep 5; this speed == 0;) then {open the doors}

I was able to accomplish this effect to pause/resume the flash effect. In my case, I wanted the ability to "black out" the base I had them at. You just have to "press the button" when they are lit in your case. I called the function via the helicopters. fnc_HeliPadLightToggle = { missionNamespace setVariable [ "HeliPadLightSwitch", !(missionNamespace getVariable ["HeliPadLightSwitch", true]), true ]; if (HeliPadLightSwitch) exitWith { _HeliPadLampList = nearestObjects[BaseCargoHouse, [ "Land_PortableHelipadLight_01_F","FloatingStructure_F" ], 600]; { _x enableSimulationGlobal true; } forEach _HeliPadLampList; }; _HeliPadLampList = nearestObjects[BaseCargoHouse, [ "Land_PortableHelipadLight_01_F","FloatingStructure_F" ], 600]; { _x enableSimulationGlobal false; } forEach _HeliPadLampList; };

Thanks to Killzone Kid I've discovered functions. fnc_lightToggle won't work on a dedicated server while fnc_HeliPadLightToggle does. As you can see its functionally identical. What am I missing? Light toggle is called via an add action: this addAction ["Base Lights On/Off", {remoteExec ["fnc_lightToggle", 2]}]; HeliPadLightToggle is also done via an add action: this addAction ["Pause/Resume Heli Pad Lights", {remoteExec ["fnc_HeliPadLightToggle", 2]}]; init.sqf enableSaving[false,false]; //TFAR Settings\\ TF_give_personal_radio_to_regular_soldier = true; tf_no_auto_long_range_radio = true; TF_give_microdagr_to_soldier = false; waituntil {!isnil "bis_fnc_init"}; [] execVM "scripts\Functions.sqf"; Functions.sqf fnc_lightToggle = { missionNamespace setVariable [ "LightSwitch", !(missionNamespace getVariable ["LightSwitch", true]), true ]; if (LightSwitch) exitWith { _LampList = nearestObjects[BaseCargoHouse, [ "Lamps_base_F", "PowerLines_base_F", "PowerLines_Small_base_F" ], 600]; { _x setHit ["light_1_hitpoint", 0]; _x setHit ["light_2_hitpoint", 0]; _x setHit ["light_3_hitpoint", 0]; _x setHit ["light_4_hitpoint", 0]; } forEach _LampList; }; _LampList = nearestObjects[BaseCargoHouse, [ "Lamps_base_F", "PowerLines_base_F", "PowerLines_Small_base_F" ], 600]; { _x setHit ["light_1_hitpoint", 0.97]; _x setHit ["light_2_hitpoint", 0.97]; _x setHit ["light_3_hitpoint", 0.97]; _x setHit ["light_4_hitpoint", 0.97]; } forEach _LampList; }; fnc_HeliPadLightToggle = { missionNamespace setVariable [ "HeliPadLightSwitch", !(missionNamespace getVariable ["HeliPadLightSwitch", true]), true ]; if (HeliPadLightSwitch) exitWith { _HeliPadLampList = nearestObjects[BaseCargoHouse, [ "Land_PortableHelipadLight_01_F","FloatingStructure_F" ], 600]; { _x enableSimulationGlobal true; } forEach _HeliPadLampList; }; _HeliPadLampList = nearestObjects[BaseCargoHouse, [ "Land_PortableHelipadLight_01_F","FloatingStructure_F" ], 600]; { _x enableSimulationGlobal false; } forEach _HeliPadLampList; };

In an effort to edify my own understanding, allow me to restate what you've just presented. I understand you've modified some basic framework of my code to get it to be more accommodating with JIP. The "LightsOn" variable is globally stored and accessible to everyone. Within the addAction before it gets passed to the remoteExec, you get the variable or assign it if it doesn't already exist. Then you pass that Parameter to the function using remoteExec and you're storing "BaseLights" as a JIP "message" (perhaps thought of as an ad hoc, slip streamed, variable). That message being the last parameter somone ran through remoteExec so they get the correct state upon startup. Rather than calling a seperate functions library within Init.sqf, we just allow the init.sqf to be the functions library for reasons of compactness & perhaps code optimization with respect to timing. We set the global variable state of the lights based on what got passed to it within the addAction, which almost seems like a circular reference but its really not. We generate the _LampList as before. Then we fix/damage the lights in a more compact manner based on the internally used _lightsOn variable which is basically the current global state of the "LightsOn" global variable stored within the BaseCargoHouse object. If there is anything not precisely correct about my understanding, please let me know.

Arg. It's always the simple things. Here I was looking for goofy syntax. I'm a little fuzzy on how this will work for joining players. From reading the wiki on remoteExec, I'm not sure if I need to use JIP or if the current state of the lights damage will be picked up when a new player joins.

Depending on how accurately you need to simulate it, spawning a trigger of appropriate size around the spike strip should serve to set off your code. The spike strip just becomes decorative in a sense. The trigger would set damage to the wheel of any object that enters it.

I've written several scripts to do various things, and I've recognized the need to simplify things a bit, but I can't envision an equally simply control structure. For example, I have a script that turn on and off the halogen lights at base via nearestObjects and setHit. I'm doing that through two separate add actions to execVM the code. One passes the "on" and the other "off". I want a single "on/off" addAction/execVM, but I what I'm envisioning seems too involved for such a simple action. Do I setPublicVariable for _switch, and then branch the code depending on that stored value for future interactions? Do I just not pass it a "_switch" value and let it run pure code that sorts its self out? More generically for a simple "one addAction" toggle, wouldn't I have to test for whatever is set in setPublicVariable before executing the core of the code? As in, one cannot assume the lamps (or whatver) are on or off. How do you test for something that seems to be defined after you want to test for it. I can't not have some form of if or switch/case statement right? I'm just not seeing the forest through the trees. private ["_switch"]; _switch = _this select 0; _hitpoint = 0; _LampList = nearestObjects[BaseCargoHouse, [ "Lamps_base_F", "PowerLines_base_F", "PowerLines_Small_base_F" ], 600]; if (_switch == 0) then {_hitpoint = 0.97}; if (_switch == 1) then {_hitpoint = 0}; { _x setHit ["light_1_hitpoint", _hitpoint]; _x setHit ["light_2_hitpoint", _hitpoint]; _x setHit ["light_3_hitpoint", _hitpoint]; _x setHit ["light_4_hitpoint", _hitpoint]; } forEach _LampList; ETA: how do you get the "spoiler" functionality to work on these forums?

Had to stare at this one for a while but I think I understand it. It works if you change that line to _switch = missionNamespace getVariable ["Lamp_var_OnOff",0]; Looks like you forgot that part right? Odd thing is, once I stopped passing the script a parameter it no longer needed it stopped working. I must have goofed up the syntax. See comments above. In any case I couldn't fudge it to work so I'm lacking comprehension on the guidance there. Elegant. Made me read about inline functions which is good. I'm having a hard time commenting my way through what is going on in the noted section above. Specific to my usage, are you implying that my nearestObjects scan would take place outside of that function?