euly

I'm assuming the AI will pop smoke, which seems to be a norm, but flares would be really nice for night missions. I like how flares wash out IR, which can make spotting units at night very difficult. I haven't found an AI mod that does uses flares, maybe because they need to be added the units inventory?

In concept, how do the AI units learn? Does the script analyze where they were engaged and compare to where they died? How does this work, in terms of the AI's amnesia from changing Previews in the editor? Also, what limitations will the physical data files have in the directory? If the AI can learn without limitation, will these files (or file) eventually be gigabytes in size? I ask because I'll probably run this thing off a persistent map with missions using Rydygier's HAL.

Seems like a situation where you hope for the best and prepare for the worst, so maybe you can do some preliminary things to start coding in C++? I don't know how to code, but it's a suggestion from experience of facing ridiculous technical tasks.

Keep up the good work. I'm really looking forward to using your script/addon.

Will this be multiplayer compatible and if so, will there be a way to move the data another ArmA installation. I ask because I do a lot of testing on my PC, but I have a dedicated server that I would want to prepare so it wouldn't need to learn. Also, is there a limitation to how much the AI can learn? I really like what you are doing here, but I'm not an expert on AI, so I'm concerned. For example, If I play an ambush mission many times with similar tactics, is the AI going to eventually exploit potential weaknesses in my offensive?

Squad name: Tild1-1 All - Return to formation! Timezone/location : North America Gamemode preference: CO-OP Website address: http://steamcommunity.com/groups/TILD11 Short description: Small group of friends that have been making missions/playing since OFP. We're looking for more friends to organize with ArmA 3. Minimum age requirement: 25. Invite only. Language: English

You rock. Thank you F3k Sel.

Hi, I'm trying to make a mp recon mission in which a group must visually identify the location of an enemy unit or object. I've searched the forums, but I haven't found much of anything close to what I need to do. I was thinking I probably need to create a trigger that is activated by the cursortarget being on the unit or object, but I don't know. I was hoping this would be as simple setting the trigger condition to reveal target name, which would set the set the sync'd ModuleTaskState to Succeeded. Can anyone help me?

I believe you, as the leader, need to select the unit (whichever F-key he is), then press 6, and look for his AT launcher in the menu on the top left. Keep selecting "more" till you see it. You should be seeing other actions, such as "take weapon x" (weapons on the ground) or "heal x." I'll confirm this as soon as I can play tonight.

I'm not an expert on the Headless/Dedicated Client, but I spent a lot of time trying to learn how to get it working for HAL, which is a system of scripts by Rydygier that manage AI units on the map like a multi-sided Chess game. From what I have found, the HC can be set up on the same server and use delegated cores/threads. I don't know how to do that, but I remember seeing conversations about HC on the same system while I as scouring over these forums and other ArmA forums. I don't know the definitive benefit of providing the HC it's own set of cores on the same CPU running the game, but up untill recently, ArmA 3 (and predecessors in the franchise) only used a single core, so employing unused cores/threads to handle the AI could be a substantial benefit with hundreds or thousands of units on the map, if it weren't for HC needing its own valid license key. An exclusive CPU dedicated to managing the AI would be ideal, but that also requires latency less than 2ms and unlimited bandwidth, which means the HC can only be used in a LAN environment. Even on very high-end PC's, 1000's of units on the map slows the game's performance down to a crawl. This problem is side-stepped by scripts and the Simulation Manager module that cache units outside the player's vicinity, so my theory is (and sorry for the speculation) the Headless Client is probably a feature that was created in the development of the VBS system and carried over to ArmA 2, and now 3. I think this because caching units is effective for a number of players that are relatively close in proximity, but for a substantial number of players all over the map, caching would be pointless. It would be logical to have a network of computers (such as in a military training simulation) that can act as Headless Clients (as far as I can tell, there can probably be more than one HC) to a server supporting 100+ players, so it might be possible to simulate 10,000 or more units on the map (regiment and division size), so long as the AI can be offloaded and processed independently. But that's all speculation from just another guy on the internet, no tinfoil hat, though.

A visual check would be universally bad, even if it is plausible. Leader units would often miss each other because of visual obstructions, and when they would meet, the encounter would almost always be one spotting another first, which would mean that leader's units are spawned/uncached first and briefly outnumber the other leader. If both group's are spawned simultaneously to be fair, then the visual check is pointless and it should just be a proximity check. Regardless of the method, what would happen after the encounter? Would the group continue on its waypoints as a whole group or would the group be re-cached down to the leader (who may be injured)?

So they spawn when they are in proximity of another group or do they spawn when the leader has sight of the other leader?

I don't think I have said thank you, Genesis. VCom is excellent. I'm looking forward to using the addon version on my dedicated server.

I really like Alive and the performance gains it has over HAL, but Alive seems too much like a total conversion mod that aims to change the fundamental nature of how the game is played. If HAL could be improved to tax the CPU less or somehow offload its processing to another computer, it would be superior in its simplicity.

This may sound ignorant, but in the init.sqf, does G_isDedicated = true if it is a dedicated server?

Euly is what I use everywhere else. There is no direct connection, aside from the inspiration of the band.

I really wish we could choose aliases on here, like Steam, but it doesn't really matter. I joined the BIS forums a couple months after the release of OFP when I finally had broadband installed. I chose my username because I was heavily into the band Tool at that time, which reflected my thinking of eyes and the outlook on life. I started a silly little clan back in 2002 and chose the username "Euly" (short for Eulogy), which I have used ever since. Many people in that group (including me) were too lazy to pronounce "Eulogy" completely, so Euly stuck. In 2004, my best friend that I grew up with was killed in a hit-and-run incident, so my username became permanent. Though, I don't associate the song with my friend, just why he died. To this day, even my fiance calls me Euly when she's talking to my friends. I choose this avatar because life is a lot like Wile E. Coyote, sometimes, things just don't go according to plan. ;) A bit of humor, I used to have a better avatar. Back when Flashpoint was their sole game, some of the BIS moderators were using an avatar of a post-Vietnam era U.S. soldier. The soldier had a serious look on his face and his helmet had "Born to Kill" inscribed on the side, imitating Full Metal Jacket. At the time, I lurked the forums a lot and noticed that the moderators were quick to close threads for petty reasons, such as thinly veiled criticism. I see their valid reasoning, now, but ten years ago I was in my 20's and a little more anti-authoritative, so I pulled that avatar into Photoshop and used a drooping filter to make his eyes and mouth look like he had Down Syndrome and then replaced the text with "Born to Close." It was the best avatar ever. I had that on my profile for about a year before a moderator removed it. When I messaged the mod to ask what happened, he said something to the effect of "We saw the image when you uploaded it. We thought it was clever, so we allowed it, but now we're getting copycats, and we can't have that." I don't remember if they had the infraction system in place like they do now, but I agreed not do anything like that again. It was funny, though.

Hey, I'm not selling snake oil here. If you can prove me wrong, definitively, I would greatly appreciate it. If you have better suggestions that apply to whole-map warfare with HAL, we're all ears. The opinion I hold has formed from thousands of hours of mission making over more than decade, you can see my join date. I obviously do more trials and playing than posting. That doesn't make me an expert with scripts or code, but I do tend to notice subtle differences in how the game responds to different configurations on the map. To your credit, though, I haven't noticed the performance hit as much after I built this system with an SSD, but it was prominent in Alpha with standard 7200rpm drives (16mb cache). I still maintain the habit, though, but I disagree that it's a waste of time, considering it's a habit that doesn't add excess lines of code in, opposed to laboriously removing lines of code. The performance hit is not throughout the playtime of the mission, but historically, the game's engine takes longer to recover from the initial read, which can be a few minutes, affecting other tasks. That is what I meant by it bleeding into the mission. Personally, I would rather see the mission perform optimally immediately, rather than hope it smooths out. I believe the mission.sqm is partially read prior to the briefing and suspended at the briefing screen, which explains the absence of activity and why only addon related errors display on the briefing screen because those are listed at the top. Unit related errors display once the mission is continued, indicating that the game resumes reading the mission.sqm and executing all commands, such as unit placement, direction, etc..

So HAL will recognize newly spawned units mid game, or are you talking about delaying the start of HAL after units have been spawned? BIS has made a lot of improvements to the engine, so the problem was more pronounced in A2 and prior, but I still believe that placing units in a default fashion is good practice in combination of other methods to help HAL.

I discovered this playing OFP years ago while using scripts such as the first GroupLink, Improved AI by Bremmer, and others like USPMON. I realize that my suggestion does sound like BS, but the way the game works with what seems like Page Filing, the read time on the mission.sqm is significant because the initial read bleeds into following performance, which is why spawning units on an empty map has less of an impact on performance than loading those units from the mission.sqm, but we can't do that with HAL. This is why best piece of hardware to improve overall performance in ArmA is an Solid State hard drive or a ram drive (a virtual hard drive loaded to memory). If this were not the case, then all that would be needed would be a better CPU, GPU, and more memory, but it's not because the game is constantly going back to read the drive, which is the bottleneck. The game may only read the mission.sqm once, but for whatever reason, tens of thousands of lines and hundreds of thousands of characters in a mission.sqm drastically affect load time, which overlaps into everything else. Like I said, with smaller mission.sqm's (or without HAL), this is all irrelevant.

I have a number of whole-island missions that I'm always working on for just myself to play. I actually built a third computer to act as a server just to play singleplayer ArmA3/HAL missions. I figured out how to get my girlfriend's PC to be a Headless/Dedicated Client (off-loads AI calculations to another computer) and connect to my new server, so I have sort of isolated the performance issue to rule out HAL as solely responsible. Even with three computers on a LAN sharing various tasks, I still had performance issues related to ArmA 3 simply just not being fully optimized. 200 units seems to be around ArmA 3's performance ceiling. ArmA 2 OA could handle around 500 units, so we can see where BI's focus was this time around. With more than 200 units, performance drives off a cliff. The grade of the cliff depends on system specs, but frame-rate always tells the truth. The biggest complication to whole island warfare, besides performance, is HAL working at a slow, methodical pace, without regard to problems compounded by time and distance. I set up my dedicated server so I could leave it running HAL missions for 5, 10, or even 20+ hours. The vast majority of that time is an absence of activity and agonizing performance. The units often become too far apart to to support each other effectively, or at least, aesthetically. Helicopter transportation is the only practical solution, but HAL is not always responsible with available transportation, so picking the island and area of operation becomes important. HAL works well on Stratis, but Altis is a different story. HAC had trouble with oddly shaped islands and water, so the best islands to use were symmetrical without rivers or lakes. I don't believe HAL is fundamentally different from HAC, so Altis must be limited to the larger land masses on the west and east sides. If you tried to use the entire island, you probably would not see a performance decrease, but HAL may not function properly, which would break the mission. Part of understanding how to help performance is how to best prevent HAL from wasting time and resources. What I've found is that units must be placed very strategically to maximize their effectiveness in cooperation with the leader. I think that only having two leaders (with RydHQ_SubAll = true) should minimize the HAL workload, but I'm not sure. Rydygier can clarify. Placing units in the field, rather than at a starting location, facilitates HAL's recognition of unit placement. I prefer to place recon units and snipers far out into the map in places I hope HAL will utilize them, but HAL can often decide to just send them home or to locations that will not matter. That happens regardless of the leaders HAL personality, which is annoying. Units can sometimes take a very long time, such as hours, to finally be useful to HAL, so having convenient logistical support is vital, such as transport, ammo, and repair trucks tucked away in semi-safe places on the map (I place them under vehicle camo nets and hope for the best). Be careful of adding too many support/transport units, or you will have many trucks and helicopters sitting, wasting resources while HAL has them assigned as excess reserves. Each unit group is part of HAL's cycling process, so even if the group is not doing anything, the group is involved in HAL's matrix of processing. Support is one of HAL's weaknesses, though, so I'm hoping that with the upcoming Helicopter DLC and sling loading feature, Rydygier will incorporate helo transport/support truck delivery. As for technical suggestions, one trick that works well is to minimize the mission.sqm file size by eliminating as much clutter as possible. This helps the game speed up the initial read time and following frame-rates. A lot of people don't know or care about this and it doesn't really matter for smaller missions, but with large missions with hundreds of units on the map, the game slows down dramatically when it has to take time to process every bit of detail for all those units. Here are my tips: Reduce or remove unnecessary objects and triggers from the map. Many people use triggers for things that can be added to the init.sqf, such as turning the grass off (setTerrainGrid 50). All units must be facing north (0 degrees), have little or nothing in their init lines, and not be sync'd (so use RydHQ_SubAll = true, RydHQb_SubAll = true for the two leaders). This is what a typical unit looks like in the mission.sqm: position[]={11209.946,38.736324,11755.095}; id=10; side="WEST"; vehicle="B_soldier_AT_F"; leader=1; rank="CAPTAIN"; When a unit is placed on the map, the unit's information in the mission.sqm is minimal because the game acknowledges defaults and only lists differing information. For example, by default, the units azimuth is 0 (the direction the unit is facing), but that is not listed in the mission.sqm because the game already knows some default information, so that is likely a component of optimization. If you change the direction the unit is facing, that information is added to the unit's details. HAL does not care about unit azimuth, so changing the direction units face is pointless unless a unit is static or has a purpose dependant on initial line of sight. For example, in a mission which every unit is facing a non-default direction, has a non-default skill, is set to not be in formation, is sync'd to a commander, and has added info to their init lines, they would look like this in the mission.sqm: position[]={11209.946,38.736324,11755.095}; azimut=123.456789; special="NONE"; id=10; side="WEST"; vehicle="B_soldier_AT_F"; leader=1; rank="CAPTAIN"; skill=0.60000002; syncId=2; synchronizations[]={0}; init="[group this,getPos this,210] call BIS_fnc_taskPatrol"; This doesn't look like much, but those six extra lines become multiplied over hundreds of units, which causes the game to take longer to read and respond and allow HAL to process. Other tips: When you are in game and you must change the direction of a unit, type in integer numbers for the unit's direction. If you rotate the unit with your mouse, you'll likely end up with a float (number with a decimal), which adds extra characters to the mission.sqm. The same issue affects skill too, but unfortunately, the slider bar is difficult to land on a whole number, so editing the mission.sqm may be necessary if you have modified skills at all. Let me know if that helps.

Hey Norrin, I'm having some strange behavior with the convoy script. With six wheeled vehicles traveling a long distance, the rear vehicles tend to drive a little faster and they'll eventually attempt to pass the other vehicles, almost like they are trying to reform the formation. Do you have any ideas? I figured out the problem. It was related to another script I was using. This convoy script is excellent. Thank you Norrin.

I'm not sure if I'm missing something, but is there a way to get the units to behave in safe mode while following waypoints?

Well done Rydygier.

Does anyone have an example mission?