Branli

Any clue? Or are instructions not clear / can't reproduce?

You can do this manually with scripting if you know the point of origin. Pick a random point within a radius of point of origin and with the condition that the next shell needs to be at a minimum spacing distance between the previous shell. Use trigger.explosion to imitate a shell explosion https://wiki.hoggitworld.com/view/DCS_func_explosion

Point 1: Best way to check how damage values behave is just testing it out by trail and error. 50 to much? Try 25. 25 to much? Try 12.5. 12.5 almost no effect? Try 20 etc. etc. Its a simple fifty / fifty approach and off course some guess work is involved. Eventually you get a feel how numbers correlates to your desired effect. Point 2: Their are many options you can do this. The most realistic way in my opinion is: - Calculate the distance between the target and the artillery. - A shell has a velocity moving from Point A - B - A shell has a parabolic behavior from point A - B ( for example y = 100 - (1/100) *x^2 ) https://www.desmos.com/calculator/t9utbi5yhf?lang=nl - To calculate the time of impact from firing until impact you start a virtual timer - Based on the velocity of the shell you simulate when the shell should impact. - Add some random deviation between 1 and 0.8 to make it less predictable. Another, easier option is and (less CPU intensive): - Calculate the distance between the target and the artillery. - Multiply the distance with a factor (for example a shell should travel 0.8nm per second) if a distance is 20nm, shell should hit a target after 16 seconds. - Add a random deviation lets say give a random number between 1 and 0.8. And multiply the time with a number between 1 to 0.8. (16 - 12.8 seconds) Hope it helps

Maybe try, as a temporary workaround, using the Mission Editor Mission Start Event and trigger a function in your script to execute your larger script? I'am also programming a large mission but i use the ME to load my custom modules, once the script is loaded, it executes itself only once. That way you are more flexible using both options.

In the Mission Editor and MIST: Search then engage in zone not working on moving targets. After long testing and testing, i finally came to the conclusion that CAS airplanes are not attacking moving targets. As soon as vehicles stand still CAS airplanes will engage and destroy the static targets. Can you please fix this bug? Attached my Testing Mission. Instructions: - Get in the F15E - Open Command Menu (\) - Select "Other" Command (F11) - Select "Launch Operation Spearhead" Command (F1) MIST Groups will now also spawn I named the vehicles in the ME so you can easily identify which ones are added via the ME or MIST. Observed behavior: - CAS Airplanes will first attack the static target within the zone - CAS Airplanes will circle / go in to pattern while tanks / units are moving - CAS Airplanes will engage tanks / units as soon as they've stopped moving Note: I think many people don't know this and reported allot of issues without investigating / testing with static vs moving targets. Even as an experienced programmer and mission maker I also assumed moving targets shouldn't matter in the behavior of CAS, scanning targets a the zone should also return moving targets. No enemy will stand still while CAS is going to do a BRRRT or fire a rocket barrage. UPDATE 11-04: After some double checking and extra testing it also might be that the JF-17 doesn't seem to attack moving targets. When i switch the planes for a MiG-29S with rockets, they perfectly attack also the moving targets. CAS - Example - 4.miz

Bumping this thread. Issues are still there.

Thanks for the reply, any chance this might be implemented with the upgrade to Vulkan API? FSR 3.1 will support this in the upcoming update, source: https://community.amd.com/t5/gaming/amd-fsr-3-1-announced-at-gdc-2024-fsr-3-available-and-upcoming/ba-p/674027 https://www.phoronix.com/news/AMD-FSR-3.1-Announced

I am curious if DCS implementation of FSR 3.0 / 3.1 is planned to upgrade from FSR 2.2. It will reduce allot of issues with Temporal AA and ghosting / shimmering. AMD just announced their new FSR 3.1 and might be released somewhere this year. Any plans to update the current implementation?

I reduced my pagefile to 8 GB's per drive. Also i noticed some events in the windows event viewer, but i couldn't make any conclusions what it might be. So far i don't experience any crashes (fingers crossed).

My PC just reboots. I removed my shaders again just in case and I'll try slow repair and check my pagefile.

After the 2.9 update i experience allot of crashes lately with MT. Mostly Crash Reboot. The game runs fine at start, but suddenly without notice its crash reboots. I had this today at least 3 times within 2 days. I play mostly my own missions. Its just a debug mission (for coding purpose) with nothing fancy in it. I'm testing the AH-64D and checking some events it generates like S_EVENT_HIT / S_EVENT_SHOT. Lasing - AI CAS .miz dcs.log

I agree, there should be civilians (preferred animated idle / walking civilians) , or add some static props like a market which you can add in the mission editor. It really fits to have markets like in the Syria / Persian Gulf / Sinai maps. If it is against ED's policy to have civilians, at least have them non-destructible so its harder to spot enemies / insurgents because they are in a crowd.

You never wanted to recreate / reenact the mission of Black Hawk Down? I would love to do this it adds much more realism. Its a SIM, not a arcade game. I already find it boring to create an insurgent mission because we have so little assets to work with, no crowded civilians which you don't want to harm. It adds emersion and its adds purpose to a mission to save civilians from threats, just like Black Hawk Down clearly shows the ethical aspects. Want to help the helpless people but not able to because rules of engagements, only fire when fired upon etc. I'm glad Eight Ball created some civilian vehicles. But we need some more civilians to make it more believable, not everyone drives in a car all day long at some point they have to pee ;).

Is it not moved to 'Bazar/shaders/grass/grass.fx'? I remember i tweaked the lenght / height of the grass there. #define radiusMin lodRadiusGrassDiameterSize.x //������ �������� ���� #define radiusMax lodRadiusGrassDiameterSize.y //������ �������� ���� #define grassDiameter lodRadiusGrassDiameterSize.z //������� ����� �����, � ������ #define quadSize lodRadiusGrassDiameterSize.w //������ ������ ����� #define grassHalfWidth grassBladeParams.x //�������� ������ ��������, � #define grassHeight grassBladeParams.y //����������� ������� ������ ��������, � #define bendDistMax grassBladeParams.z //������������ �������� ������� �������� � �������, � #define pointSpread grassBladeParams.w //������� �������� ����� ������, ��� �� ����� #define lodsCount intParams.x //���������� ����� #define heightMapSize intParams.y //������ ����� ����� � �������� #define time origin.w #define windSpeed wind.z #define windOffset gridOffset.zw You can tinker with some settings and create a formula from the input of the game variables. How it works is the shader takes the pixel color of the terrain texture and creates a gradient. This gradient "Texture" is applied to the color of the grass. The grass is merly a simple vertex with some additional bending points for animating the wind and create a curve in the grass blade. Btw i didn't check if it breaks IC, i tweaked it in 2.7 i think. Don't know if this still works with 2.9

Hey, i did some long research and was able to reverse-engineer the DCS World Dialog system. Its not that straight forward but there is some logic into it. The .dlg files are meant to set the layout and colors of the dialog, just like HTML and CSS. My plan is to create a parser which can convert this to .dlg files. You can help me if you like to create a WindowManager tool to export and import DCS World Dialogs. When i'm back from work i can send you an example. Im working on a large Arcade Gameplay mod for DCS World. Already got much stuff in place.

Yes you can. If you can program a bit. FireAtPoint task for artillery requires target.x and target.y (ingame coordinates). You just need to translate from lat / long to in game coordinates. MIST can do these transformations. I created my own script which does exactly that (only without jtac and the coordinate transformations) but its not very much different when it comes to logic. Here is a snapshot on what i'm working on at the moment. For reference look at: https://wiki.hoggitworld.com/view/DCS_task_fireAtPoint -- ARTILLERY OVERWATCH -- --[[ -- Requirements: -- Artillery group > AI-BOT-RED-WATCH-C-1 ) (WATCH = type) (C = zone) (1 = index) -- Capture Zone timer function execute each 10 seconds if enemy group enters zone C then for units end ]] function setArtilleryOverwatch(_zone, _coalitionId, _targetCoalitionId) local coalitionTypeName = getCoalitionSideTypeName(_coalitionId) local groupName = "AI-BOT-"..coalitionTypeName.."-WATCH-".._zone.."-1" local group = Group.getByName(groupName) local unitsInZone = getUnitsInZone("ZONE-".._zone, _targetCoalitionId) --trigger.action.outText("setArtilleryOverwatch: "..groupName, 30) if group and unitsInZone then if #unitsInZone > 0 then local unit = unitsInZone[1] local unitPos = getPosXY(unit) -- SET FIRE MISSION -- local target = {} target.x = unitPos.x --trigger.misc.getZone('killzone').point.x target.y = unitPos.y --trigger.misc.getZone('killzone').point.z target.radius = 0 --trigger.misc.getZone('killzone').radius target.expendQty = 24 target.expendQtyEnabled = true local fire = { id = 'FireAtPoint', params = target } --trigger.action.outText("FIRE MISSION: "..target.x.." "..target.y, 30) group:getController():pushTask(fire) else --trigger.action.outText("NO UNITS IN THE AREA", 30) end else --trigger.action.outText("OVERWATCH DENIED", 30) end end Note: Sorry thought this was a modding request. But i agree, it would be nice to have some more love for artillery.

I agree, i would expect at least Spring / Summer / Autumn / Winter textures, same like Caucasus. They are a major difference in real life.

Probably because a fixed wings inherit velocity will help, also its easier to maintain a proper AoA to fire rockets in a fixed wing. In a helicopter you mostly stay at the same altitude and your pitch angle is only between 10 - 20 degrees so you have less time to aim.

I have to say, aiming the S-24B is pretty hard, especially because the velocity of the rocket is very low and there is a small delay when the rocket will be released. I'm glad you guys found tables for this. Its almost as hard as aiming rockets from a WWII plane.

I tried to do CCIP with S-24B rockets, but it seems the CCIP won't work. Is this intended behavior that the rocket mount cant pitch its angle and that the CCIP won't work? I've put the ranging on Auto. It works fine when you use the S8-KOM rocketpod.

Thanks for the Tip! For the time being i created an elaborate workaround to check what kind of unit it is, naming the group something like "AI-TANK-01" "AI-PLANE-01" and extract the category data from the group name, but this makes it much easier.

Also noticed here missing road connection in Tripoli Lebanon. Sadly cant upload the screenshot due max size within this post. Grid YD61. The textures there are also broken on the terrain, you can see a clear line between 2 texture tiles on the hill there.

I also noticed this is missing when you want to drive into Damascus. Its blocked by a train track. Also i noticed Tunnels are broken in Beirut and are filled with water. Ground units will drive over the tunnel instead of being inside the tunnel.

Is this even going to be fixed? It really limits the verifying and conditional options in Mission Scripting / Mission Building...

@Mustang Did you maybe also figure out how to increase the clutter distance of the grass higher then 1500? I can't find a way to change it in the grass2.fx or other settings. You have a clue?