mickeymen

Yesterday I received update 2.10 and unfortunately I saw a complete disappointment in the changes in thermal vision. You can open reviews of SPOTREP #00105 in Steam and see a lot of dissatisfied with the new thermal system. Many reviewers would prefer the old system over the new one. I think thermal update is a complete failure/ Some of my personal notes here: 1. The main problem is the complete lack of binding to the current day time/current weather. This is complete mismatch. The game doesn't care if the sun is bright at noon or it's night and it's raining. Are the stones and buildings hot from the sun, or have they cooled down in the dead of night. No matter! For example, on a rough night we can see shining roads! They will burn as if heated by the sun at noon and will burn in deep night. Wow! No difference!? The player will see more or less shining objects regardless of any day time dependencies. The simplest test - Set in the editor the time multiplier in the as X12 put yourself on the map and go into spectator mode in your game. Switch to thermal vision and you will see, how over time, the thermal vision will not have a cooling in the evening/night and will not again warm up to the maximum at afternoon. Instead, you will see burning stones and roads at night! You will see randomly changing color grass! It just looks like uncontrollable chaos without reference to time of day without reference current temperature! All this does not look natural in places, even silly. 2. The thermal horizon will have clear ugly lines. New thermal view has problems with fog/haze and smoke FX. On the horizon where the haze will always be strange lines: The distant parts of the landscape will be divided into lines! What this in general? What lines? Also pay attention to the smoke from the engines/wheels/tracks of vehicles. It looks the same as haze horizon above, like it's without anti-aliasing, no blending, no gradient, too noisy: So the new thermal has problems with fog/haze/smoke. 3. The same landscape with the sea horizon can look completely different with NVG and with thermal vision. This is what the image looks like in NVG: The same angle on the same position but in Titan Launcher thermal will look like two completely different places: Why is this semi-island burning like a torch? Is he warm under the sun? In this screenshot a deep night, it should not glow, by night, this semi-island had already cooled down, for this reason he should not radiate heat, at least it should not be as maximum bright. 3. In the new thermal, the grass color is significantly lighter than the its ground color, but actual, within a gameplay this is one same surface Due to the fact that grass is a limited render distance from the player, we see light grass near us and in the distance we see a black strip of ground: In fact, dividing the same surface (grass) into two different colour lines, but in reality this imposible because it's the same surface whether the player sees the grass or not. Thus, land without grass should not differ from grass in terms of heat release. So way the player should not get two strupes with wild contrast for one surface. I hope that the developers will see this post and make thermal vision in Arma3 adequate. I would just take the image configs from the @A3 Thermal Improvement mod and bind them to the current time of day. The picture in this mod looks awesome, but they do not have turn on the engine, do not have cooling/heating vehicles and there is no other cooling/heating objects. I also noticed that their corpses cool down in 10 seconds, which looks stupid. Their mod needs some improvements. I sure, such formula - Image configs from @A3 Thermal Improvement + daytime binding + heating/cooling objects = Arma3 would get excellent thermal vision.

AI still can get stuck in rock even now (v2.08). I run into this problem all the time if I carelessly place AI units on the map. If one of the units will placed over the rock, then it will be spawned on the ground surface, under rock and stays there forever. Yet it seems to me very strange to me that BIS does not turn off the collision mesh for big stone, in which the AI can get stuck forever, but disable the collision mesh for houses and fences, which ai has a big chance to be passed. It would be great if someone from the modding community could turn on the collision mesh, blocking them from passing through wall/fence and create a some code, where the stuck AI could switched to special mode/path and could be abble move to the rescue markers, inside any building (for example near door portals).

Are you saying that the reason the AI goes through walls is because the quality of the houses is not enough? I often see this on Stratis and Altis, are the houses on these base maps really of poor quality? Doesn't look like the truth, because these are the oldest and exemplary quality maps from Arma3 developers. Throughout the life of Arma3, I have been worried about the problem of AI being able to pass through fences and walls of buildings. I still can't imagine why this shame is still present in Arma3? I don't think it's a problem of the lack of super ai-intelligence. The question arising before me - why is the Collision Mesh model unable to block their physical passage through, as it does with players? Yes, I've already heard that BIS gets rid of cases, where the AI would get stuck inside the building, but I would rather this option than the option where the enemy AI goes through the walls and shoots me in the back. In addition, AI still has a chance to get stuck in buildings, passing through walls and whistling in a swimmer's pose, which looks even more stupid, if AI just stayed indoors. Questions: * is it really so difficult to prescribe predefined paths for AI inside any buildings, so that they do not deviate from their paths and could not pass through the walls? * how can user explain the passage through the fences? There is no chance for the AI to get stuck forever, but the AI will still not have impact from fence Collision Mesh models. Сonclusion: I have not seen a single mod that can solve the problem of AI passing through physical barriers. Moreover, I use LAMBS Danger mod. It's a great mod, but I think it exacerbates the problem of AI going through walls. It happens more often. All this upsets me and I'm already losing faith, that someday in Arma3 AI will stop passing through walls. @pierremgi I would like to know what you think about it?

Hello GM team! Yesterday I installed the Global Mobilization DLC and I was surprised, how buggy the tracked vehicles are in this DLC. Just place a Shilka in an open field and control it. You will jump, jump, jump on the flat place and eventually even you will have a chance to do a somersault! How can a user shoot constantly while jumping? The player can't aim because he periodically jumps! This will annoy the player. I tried other tracked vehicles. Any tracked vehicles will bounce endlessly to varying degrees and roll over on level ground! Even after this flip, they will keep twitching and bouncing: I want to tell, that today and unfortunately, after three year life and support this DLC the tracked vehicles in the Global Mobilization DLC are completely unplayable content, while it's paid DLC! I don't understand how this happened? Can anyone tell me why, as of 2022 this still hasn't been fixed? Maybe after this post, someone will notice it? Yes, in Global Mobilization DLC, from utside, all tracked vehicles look on the highest level, but are functional, against the background of the vanilla quality of tracked vehicles, it looks as not playable. For comparison, I did tests with vanilla tracked vehicles in same Weferlingen map and it worked stably, without any problems. I checked hard it again and again, trying to see the any bug, but it didn't happen! I know that in the past, vanilla tracked vehicles could also sometimes bounce, but fortunately, I have not observed such bugs for a long time. Probably BIS still fixed this problem, also I use the Anti-Bounce System (ABS) mod (which smoothes but does not completely fix the problem) and I completely forgot about such a problem, for vanilla tracked vehicles! After what I saw, a purely spontaneous question arises - why don't you guys just copy the configs from the vanilla vehicles and paste them into the Global Mobilization DLC tracked vehicles? It seems to me that this would save your DLC from problems. GM team, I think you need to neutralize this problem, otherwise your beautifully modeled vehicles are simply not usable( What's the point of them if they can't be used without problems? I hope you take care of this problem since vanilla vehicles have already forgotten about this problem, this is a solvable question. If you don't believe me, then put on your map vanilla tanks vs your tanks and compare their stability.

Hi @lexx! Does the user have any chance to get some updates for this DLC or will there be no more updates? If updates are planned, then would be interested to know when approximately they will be and is it possible to hope for additional content(weapon/vehicles/map) ot it will be only bug fixes? I really liked Sefrou-Ramal map, but its main drawback is its small size. Essentially a desert - it not have many objects, for this reason, the current size of the map seems small. An additional larger map would be a great addition to this DLC. Do you have any plans to add a new map for this DLC as it was later added to Prarie Fire DLC?

No special steps needed. You have asked a good question. I decided to test this, because I had never tried it before. I placed in the editor on the military base one BLUFOR squad and gave to one soldier a radio-backpack. I also placed 4 BLUFOR squads at a great distance (>= 1 km), and also gave them radio-backpacks. This four support squads units were placed without waypoints. Next, I placed some OPFOR groups and gave them waypoints to the BLUFOR military base. I watched what was happening - after the fire contact, all four the distant BLUFOR squads moved towards the BLUFOR base and supported their allies, getting involved in the battle! LAMBS support works great! You can run your tests with or without diferent specific waypoints. I don't know if the current waypoints will influence the decision of the AI to advance towards the ally, but you can try this and tell us about your observations Try some like my test and you will see how it works.

Hi @zooloo75 ! Just some my notes about issues/wishes. I discovered that the setting - "Obliteration Triggering Ammo Class Names" has no obvious result. It just doesn't work. At first I wanted to exclude the hand grenade as a trigger for Obliteration and I removed 'GrenadeCore' from your list but that didn't work! Next, I turned off the entire list: ['MissileCore', 'RocketCore', 'TimeBombCore', 'GrenadeCore', 'ShellCore', 'BombCore'] as [] and I saw that even without your trigger list, the Obliteration would still occur! So exception/adding a obliteration trigger won't work. Next issue. If the player uses the Enable Blood Pooling setting, he will get a flickering texture every time. This looks strange, because vanilla blood not have any flickering problems. Also my notes about the bleedout effects. Two settings of your user are very much required: a) Dropped Blood scaling Your blood drops are too small and have a high spawn rate, which negatively impacts performance. If user will reduce the frequency for the drops, then he gets a performance gain but the blood is barely noticeable, because the drops are very small. If the player had the ability to scaling dropped blood texture, then any user can found better balance could be found - bleedout effect scaling/game performance. b) Checkbox for choose the vanilla blood texture. As for the vanilla texture, it looks better in my opinion, because it has some transparency. Transparency creates effect of absorption into the ground. And most importantly, vanilla blood does not have a flicker glitches. Please try fix issues and give to the player the above mentioned two setting, if this possible/ Thank you!

Good day @tpw I found a few issues with the BLEEDOUT module, Please fix these details if possible. 1) It looks like the damage model in your module is distorted. For example, if a unit gets bullet hit in the leg, then after a few seconds, its visual wound may disappear without any reasons. This looks strange at least and unnatural in general. In addition, after second hitting the leg, the hands are very often damaged also, and later without any reasons the head also gets damaged! I can assume, the bleeding in TPW damages all parts of the body, that visually does not look natural. Seems to me each wound should have its specific consequences, but not more - A hit in the leg should cause a slowdown and eventually lameness. Hitting the hand should increase weapon sway, so the player or NPC should be less accurate/effective. And of course hits to the limbs should not affect the head. Could you rethink bleeding systems so that it doesn't damage all head and torso, if only the limbs were injured? For example, instead of increasing damage to the entire body, wouldn't it be better to use a timer for blood loss, after which the character first slows down and then dies. 2) I use AI self-healing in settings. But this happen far from stable. I see a lot of tests, where the AI just dies from blood loss and does not even try to heal itself, despite the checkbox - "AI attampt to stop own bleeding". It seems to me that self-healing should depend on the mode the NPC is in. If he currently is in Safe, Aware, Stealth modes then he should treat wounds stable, with a small random delay (to avoid synchronization of animations for several NPC). While in combat mode, it should self-heal with a greater delay, since it can be attacked while healing itself. 3) If after falling into unconsciousness, the AI will fall on its stomach and after it rolls onto its back, its final animation will not match the position of the body in which it comes. The position that the AI comes to is a mirror copy of the position that is required in this case. All three points are demonstrated in my one video. time codes: disappearance of the wound and wrong damage model NPC will not self-heal wrong mirrored position after anim of turning on the ground

Good Day RHS team. I read the info from your site, in the Documentation/FAQ section Let me pour out just a few thoughts about... The fact is that I was always upset that there were no interiors for heavy armor in the RHS. Since this fact will always downplay the RHS quality, making it somewhat lower than the quality that a vanilla game is able to give the player. Yes, outwardly many RHS vehicles are superior in quality to vanilla game vehicles, but due to the lack of interiors they lack immersiveness and in some cases (damage to the rotating parts of the optics), even functionality. After all, it is very boring to look into a small black hole (here I meant most russian tanks) throughout the game if you are a tanker. Besides the player sees only 20-30% of the entire screen and can see just ahead/ I cannot agree that the tank interior is not functional, even if RHS don't use the modern dashboards. For example, every time when the gunner's turret or the commander's rotating optics are damaged, they sink to the ground and lose their ability to rotate. In this cases the tank becomes unusable for player on the commander and gunner places, due to the lack of opportunity to see something. While with the presence of the interior and damage to the rotating optics, it was still possible to monitor the situation/path by mean rotating your head to observe via observation windows! In general, I will not ask you to make interiors for all heavy armor, as I understand that this is a hell of a job. Other than that, at this point in Arma's 3 life, it's unlikely to happen... I just want to ask - why didn't you guys at least make black 3D interiors like they did in the Global Mobilization DLC? In this case, detailed modeling and texturing of the interior are not needed. What matters only is the shape of the cabin and its functional viewing windows. and thus the community would receive at least a partially functional interiors for heavy armored vehicles! It would look ten times better than what it is today. And modeling black 3D interiors would take a lot less time. I think such an addition would be great for the RHS. Just a question + food for thought...

Hi LAMBS developers! @diwako @nkenny Long time no news from you. I hope LAMBS danger is not dead. I discovered the one problem of Lambs AI. At first, I was sure it was a vanilla problem, but when I several times disabled LAMBS, I couldn't reproduce the problem. Please fix this! Problem description : Enemy AI of opfor side, will always knowsAbout of the player/other soldier of blufor side, who put the explosive, if enemy unit of opfor side will be explouded by this explosive. Or vice versa. I added factions to the description, to make it easier to understand me. Explosives can be anything. It could be a anti-personnel mine, C4, anti vehicle SLAM-Mine, etc. If this happens, then: 1) any detection trigger (by default or scripted) will be activated, even with such max values as knowsAbout > 3.8 (as far as I know the maximum value is 4.0) 2) enemy AI of explouded side, will always know the location of such soldier, even if the player currently was not visible for any enemy, even if the player is hiding behind buildings, terrain of other obstracles. 3) enemy AI commander will order to his subordinates attack such a hided soldier, and subordinates will go to the point of his location. In fact, after laying any explosive the player becomes visible to enemy AI! As far as I can guess, the AI treats an explosive attack in the same way as a firearm attack, in which the AI sees fire point and immediately detects the enemy. It seems to me that the AI does not understand the difference between this and the two attacks, so it reacts the same way and instantly detects the enemy. Unfortunately this will break any stealth mission, even if the mine/explosive was placed far from current the player's position. Expected AI behavior: - AI should not know about the enemy, whose mine it was detonated on. Repro here: 1. Place a player in an urban environment as an explosive specialist. 2. Place an enemy full squad - 8 soldiers. 3. Make sure that the enemy AI squad will not see the player. 4. Set a waypoints for the enemy AI patrol with a slow movement and safe behavior. 5. Start the game, so that the enemy AI patrol does not see the player. 6. Place a bouncing mine in the path of the patrol so that he does not detect you, better around the bend for patrol waypoint, the mine should not be visible to the patrol (can be behind the building corner) 7. Hide inside the remote building. 8. Switch to spectator mode and observe the AI patrol. 9. As soon as the patrol explodes on a mine, the survivors of this squad will order to attack the player and will move to his location. repro example on the Stratis:

I had simular problems with AI detection. After I deleted the lambs_range.pbo and set my AI level to 1.0 I was happy. I got strong yet realistic opponents. File lambs_range.pbo makes the AI incredibly sharp, it doesn't look natural especially at nights (using NVG)

Now, once again, I restarted the entire scenario from the beginning, and in the !first mission, my subordinate AI again failed. I want to say to the developers of Western Sahara DLC - The AI problem is simply impossible to play this DLC In singleplayer mode, ufortunatelly this is not playable content. Before I assumed it: but I was wrong. This time the AI issue occurred without switching the player. Subordinate AI freezes in one place, refuses to move or follow orders. This will happen first with one then with another unit, etc But I noticed the following - In most cases, my problem arose after the commands - "get into the vehicle" or "get out of the vehicle". Exactly - that moment, when I select ai-subordinate and point to the vehicle to enter. Or when, I select ai-subordinate and choose exit command (4/1 keys) Those. AI need to run and get into the vehicle - AI froze or AI need to get out of the vehicle - AI got out and froze In both cases, the AI subordinate can have a chance turned into a statue (freezing in place), unable to respond to the orders of the Player -commander. The problem does not seem to be a big one, but it is for this reason that I still (since the release) have not been able to complete this DLC! For me, the problem of immunity to damage is not the main one. Still, you can get back to the base and restart the task or start a new one. Much worse than paying the last money to hire an agent and when at the most crucial moment, such an agent will let you down during the mission. Maybe playing alone, without subordinate AI? It simply not possible. It seems to me that the main problem of the single player mode of DLC Sahara is a broken AI. I totally agree, It needs a cure I still hope that this DLC is not dead and the authors will fix its errors.

Alleluia! Finally, after 4 years problem solved. Better late, than never, thank you BIS!

Dear Devs! Please fix it finally a bug which was added after the release of Tanks DLC. The player wants to enjoy the gameplay, instead of annoyance, but when he come across this again and again, player want to break up monitor. This bug appeared after Tanks DLC and it is extremely annoying to the player! I checked the mods do not affect the problem. I have repeatedly reported this on feedback, but this is just infinitely ignored. Description: 1) Player shot from Launcher at enemy vehicle 2) Immediately after this shot, player want to save your virtual life from the enemy return fire (since after shooting from AT-launcher, the whole map sees you and wants to kill) and player press the prone-button, to lie on the ground. 3) After that, the player’s game character falls to the ground, but again automatically rises to its full height again and switching to launcher! After this - the last thing a player has time to see - it as dozen of bullets fly into his face! The problem occurs only with Titan-Launcher in the hands. In order to reproduce this bug Fire Mode from Titan Launcher must be ONLY TOP. I tried to reproduce this problem ten times in Direct mode but I never succeeded. As soon as I switch my launcher from Direct mode to Top mode, I reproduced it the first time! Direct mode is used by default, probably for this reason, many users cannot reproduce this problem at the run game. Note! Direct / Top modes were added to Tanks DLC As I said, the problem initially appeared in the release of Tanks DLC

Yes! Today I saw that fire modes for launchers are broken by update 2.08. I created a ticket on the feedback tracker, please support my ticket

I noticed a long time ago, that visually there is no significant difference between shooting in top mode and in direct mode. For the player there is no point at all in switching fire modes. In addition, shooting in top mode will create a auto-rising bug, Unfortunately the whole AT-missile system is working terribly.

When it will be DynaSound 3? Last updated 2 years ago... PS: I like the sound of this mod, but the mod doesn't seem to affect some units. @laxemann Please try to create a normal sound for Offroad-AT, today the shot itself and the sound of the projectile hit has a disgusting sound, like from a children's cartoon. It seems to me, this is vanilla sound, Dyna Sound 2 does not affect Offroad-AT weapon. Let the shot and hit from the SPG-9 at least sound like an RPG-7

Ok. I will only talk about the singleplayer experience. Somehow, gameplay of this DLC will break the AI of the player's subordinates. During the game process, sooner or later one of the player's AI-subordinates (hired agents for $500) will stop their movement and stop following any order. He will remain motionless and will refuse to follow any order! This can happen at the most inopportune moment - immediately after being hired, when the player paid the last money, for the damned agent or when the player arrived at the place of execution of the task and ordered the AI-subordinate to get out vehicle, or when the player team returned to base and got out of the car, in order to rearm, etc. This does not happen during combat. This happens when the situation is completely safe, such as when the agent has just been hired. He will go into the player's tent, where intelligence is collected, and never come out again. I tried restarting the mission. I tried restarting the the whole campaign and every time the same thing - at some point the AI-subordinate will stop moving anywhere. I could be wrong, but it seems to me that such a bug occur only after the player has been killed and he once switched to the surviving character in his squad. In this case, one AI-subordinate of the player will sooner or later stop any movements. It seems to me that the possibility of changing players somehow breaks the relationship in this squad between AI-units. In general, I abandoned the play of this DLC three times, only for this reason - the subordinate stops doing anything. Other annoying bug that I noticed. Part of the AI-sentries of the enemy, placed in the enemy camps, where player need to complete missions, will not take damage! They will also not react to bullets and shells falling nearby. It looks like it's running an ambient animation, that they can't get out of. They can be shot with any weapon, but this will not bring any result. They'll just keep standing like an unkillable statues/ I really hope you fix these bugs Should I create tickets on the feedback tracker?

@froggyluv thank you so much! Now it works for me. I decided to demonstrate this to all users: I also want to create these parts for stealth missions. However, I do not understand why it is "expensive"? Will such a trigger overload the system? It would be great if the LAMBS team could use #explosion, at least in limited cases

@diwako I have interesting information. I was sure, that before, I saw how the AI reacts to the near explosion and this is not related to LAMBS! I found out, why in my gameplay the AI not react to the near explosion, while the vanilla AI would react the explosion! I remembered dozens of times how AI was allert after explosion in the vanilla! There is a vanilla bug/feature - if any soldier( player or AI) will put any explosive and the enemy explodes on it, then all the allied side of the killed AI will know about the soldier who put this explosive, even if they do not see his location! AI treats this explosion as an attack with firearms. Maybe this is a trick from the BIS so that the AI reacts visually to the explosion. This annoyed me, on the one hand, but from another side it put all nearby opponents on alert and looked visually good. Recently I turned off the knowledge of AI about the enemy who laid the mine using this code: ALL_MINES_OWNER_REMOVED = []; Ibr_loop_check_all_mines = { private _all_mines = allMines; if (count _all_mines > 0) then { {[_x] call Ibr_fn_remove_mine_owner} forEach _all_mines; }; while {true} do { sleep 3; if (_all_mines isNotEqualTo allMines) then { _all_mines = allMines; {[_x] call Ibr_fn_remove_mine_owner} forEach _all_mines - ALL_MINES_OWNER_REMOVED; }; }; }; Ibr_fn_remove_mine_owner = { params ["_mine"]; _mine setShotParents [objNull, objNull]; ALL_MINES_OWNER_REMOVED = ALL_MINES_OWNER_REMOVED + [_mine]; }; [] spawn Ibr_loop_check_all_mines; Yes it works! Now the AI doesn't does not see through objects and obstacles the enemy who placed explosives - this is great, but it also has another side - at the same time, the AI will not come to alert near the explosion, because it does not will know about the enemy attacking it. Unfortunately, the AI logic in the armament does not react to the explosion itself, it reacts to the person, who placed this explosive as its own attacker. This is the reason why the AI doesn't react to nearby explosions. This does not apply to my video, in which I put a mine in the editor. It's about the gameplay itself. And now I have two choices. Or leave this code, which allows the AI not to see the player who plases the explosive, but this code will completely destroy visual AI reaction to the near explosion. Or remove this code, allowing visually the AI to react to near explosion, but at the same time return the "knowAbout" vanilla bug for the player who places the explosive. LAMBS Team, I ask you to consider this matter! The player would like the AI not to see through the objects of the enemy who placed the explosive and at the same time that the AI could react to the nearest explosions! I'm sure, if you want you can somehow smooth this issue

I've been playing this DLC since release and every time the same bug will break my whole game. I have restarted the game several times, but every time the same bug over and over again breaks the game! Where can I find the Bug Tracker of Western Sahara DLC?

It's a pity. This fact makes LAMBS waypoints disposable. The one-shot waypoint is very narrow in its application, but the worst thing is that after applying it, the vanilla AI will be broken... @diwako I hope someday your team will solve this issue!

Please give a Skip Waypoint also as next condition For several years I can not get the Fighters to leave their houses, after the garrison, so that they switch to the next vanilla waypoint I tried dozens of times and wrote to LAMBS team about this problem, but the AI never switches to vanilla waypoint!

Hi, thanks for answer if it's not possible to track every explosive, then maybe it's possible to create a limited number of explosion causes? Only large explosions. For example, only explosion of all vehicles (total destruction) , a big complex package of explosives, air bombing, can be are taken into AI account, while the other small explosion - mines, grenades, UGL (40mm) can be ignored. Please try to implement this, It's just that when the AI does not react to big explosions, it looks very stupid. Thank you for this awesome mod!

Hi LAMBS team! Hi to all! I would like to report a LAMBS issue, about Danger Eventhandlers module. In the mod settings "Enable Explosion Eventhandlers" tells the player, that the AI will react to the explosions, but in fact this does not happen. I watched this several times during the game, after that I made a this demo video. In this video AI patrols have a safe behavior for their waypoints, but safe behavior not will be changed after explosions near them! There is a powerful explosion of the mine and explosion vehicle , but the AI will not react to it all, as you can see the AI-patrols continues to walk around safely after a few explosions. Unfortunately, this behavior does not look natural. Expected behavior - after any explosion within < X meters, the AI should always switch from safe to aware/combat mode and look alarmed. It would be great if the LAMBS team would add AI response distance to the LAMBS Danger Eventhandlers settings, so that any player can customize it to their liking. Personally, I would like the AI to be able to react to any explosions within approximately 700-900 meters