Grimes

Looking at the files I don't think the JTAC has any code to deal with naval units. Its possible it is an omission in the editor is letting you select naval groups.

Or give em the actually useful page https://wiki.hoggitworld.com/view/DCS_enum_weapon_flag Its a weird combo of the enum values are doubled and the combo values are effectively the original values added together. Outside that is just the categories that describe a given weapon. They aren't always the most complete definition. Quite a few show up as "other" under missile category. Most of the time it is good enough to get an idea, but you should probably have to make bespoke definitions for certain weapons that dont normally fit that criteria.

Pick your poison. https://wiki.hoggitworld.com/view/DCS_func_markupToAll and any other markup functions.

It isn't a message that is part of the game. The server likely has some files in \Saved Games\DCS\Scripts\Hooks\ and one of them is loading a user script for callbacks for whenever a player tries to connect to the server. Said script is returning false and that message on the tryConnect callback.

Most likely it is the check rate of the trigger, which is once every second, and the size of the zone. If the trigger zone is to small, speed of the aircraft is high enough, and a bit of luck then it is possible for the aircraft to enter and exit the trigger zone between the checks. Making the trigger zone larger or using scripting to check at a faster rate are the solutions.

Reported.

I did a thing. https://imgur.com/a/TLFegLW Unless the formation is specified to be within a few hundred meters of each other you should avoid using "Open" formations.

Just messing with it has made me look at some of the other formations and any issues that may occur with them. Formations with larger spreads appear to be the most problematic. Really makes me wish the AI could do Tactical Turns. Its a group of 4. Think of it as something similar to how you can command different units within your own flight to do different tasks as its the same premise. Via the editor everything is done via the "Group controller". Via scripting you have additional access to unit controllers, so it is possible to give individual orders to individual units. Unfortunately it only works with AI aircraft and helicopters while is non existent for ships and ground vehicles. In that example it generated 48 targets and assigned 12 to the group controller, then a different set of 12 to the unit controllers for 2, 3, and 4. I'd have to retest the specifics but there are some specific order to assigning tasks to get desired results due to which units follow each other.

It seems to be a multifaceted issue, though AI formation behavior appears to be the linchpin. If the AI are able to maintain their formation and are close to each other then it is possible for them to drop together as seen below. Its not perfect, but it was functional in getting the AI to attack within a 30 second window. The problem is that whenever the task is given the AI drastically get out of formation and some flight members seem to get stuck between wanting to climb and gain speed. Neither of which is achieved. The way tasking functions also plays a role. Chiefly the AI are trying to follow one another and each bombing task is effectively assigned one at a time. They aren't thinking about the next bombing task or the wingman knows when it is their turn to start bombing. A way to counter-act this is to assign bombing tasks individually via pushing a specific bombing task to each AI unit individually. I did that here: https://i.imgur.com/PyCC4tb.mp4 The other thing that can help substantially is the cause of the AI "shuffle" that occurred when the tasks are assigned. You see it in the video I posted. The altitude above parameter appears to be causing AI to maneuver like that when assigned the task. When not checked they will more gradually fly toward the target. In your mission the AI flight lead doing a 180 degree turn then another 180 degree turn all the while losing a ton of altitude in the process is what is messing up the formation.

This page should have the relevant information to answer your questions. https://wiki.hoggitworld.com/view/DCS_editor_carrier_spawns Spawn rules should be the same for the AI as it is for players. Things might be a tad different in MP as I think there is a little extra buffer applied which might result in the first F-14 spawning on elevator 2 and the 2nd F-14 spawning on elevator 3 instead of next to the first aircraft. Stennis was updated to the correct size and that also changed its parking behavior to match that of the SuperCarrier ships. The technical ramp limit should be 12 for Nimitz class, old Stennis was 6, and 8 for Forrestal. You can add 4 to both those values if you keep the mission paused at mission start and allow 4 players to spawn. This should place them in the six pack. And I suppose add 4 more if you want to do catapult spawns. On the SC I've certainly had 10+ aircraft spawn on the deck at the start, which now that the Stennis is corrected should apply to that ship as well. Our method usually required the F-14 players spawning first, get their RIOs in, and get the aircraft started enough that they had control to oversweep the wings. After that allow F-18s to spawn in.

Yes* NTTR has Death Valley which is below sea level and there were a few bugs that had to be fixed for negative altitude. What is unknown is whether or not it is possible to cut into the infinite plain that is the sea. With NTTR they could have just lowered it since there is no accessible sea on the map anyway.

The base near Azraq in Jordan is probably also just off the edge too.

For the larger WW2 aircraft this has been reported around the start of July. At the time I had checked the WW2 fighters and modern aircraft to see if it was occurring for them but thankfully their behavior seemed to be correct.

Well one is an MMO and the other isn't. The whole concept of a game between the two are vastly different. In the context of Star Citizen's Persistent Universe and server meshing the idea is for person A to be on one side of the galaxy while person B is on the other, each have their position, well everything about them really, saved in persistence on the same database, but their actions occur on different servers. There could be hundreds of servers all interacting with the same database. If player A attempts to travel to player B then as they transit different locations they will be migrated to different servers as needed. In DCS the state of the world is effectively an "instance" to borrow from MMO nomenclature. It isn't intended for the game to be a unified experience and world state. What is going on within a mission is only relevant to that mission. There is no persistence nor does DCS even feature a save/load functionality within a given mission. There are scripts that attempt persistence but the functionality is limited. Can't load current ammo state, object orientation, exact tasks, weapons that are already launched, unit damage state, etc.

I fixed that back in March: https://github.com/mrSkortch/MissionScriptingTools/commit/eb0d16b5568d77134f3e3aeddecb8f776ae848de

local gp = mist.getGroupTable("whatever") gp.uncontrolled = nil mist.dynAdd(gp) If you want to clone the group just add a gp.clone = true before mist.dynAdd.

Just use mist.respawnGroup(groupName, true) respawnInZone is meant for ground vehicles or airspawned aircraft to provide some semblance of randomness within the set area. With respawnGroup it should keep most of the parameters like livery, weapons, and uncontrolled the same.

Making them do a straight in approach is the most efficient way possible. The problem is if anything in the sequence interrupts the AI then they will enter the pattern behavior and will land seemingly disorganized. I think they need around 45 seconds of separation to land without entering the pattern. Placement of the last waypoint matters to the extent that the AI need to be able to make their approach safely/efficiently from that position. It is kind of like with the bombing tasks where there is an invisible line somewhere that the AI will first decide to extend or do whatever rather than directly moving toward their goal. Best to align the last waypoint with their approach and make it reasonably low altitude for the AI to directly enter their approach.

That is what the button that says "Save Debrief" does and then some. It also saves automatically but is temporary in your savedgames/DCS/logs/debrief.,log file.

It is entirely a factor of the small objects. Drop a large bomb over the beach and all of the beach chairs, umbrellas, and other objects also die because they have near 0 life. Much to my surprise several knickknacks that adorn buildings like air conditions are their own separate object. I don't think it should be considered a bug, because I'd prefer it if absolutely every object was detectable like this. However I do think filtering of objects would be useful and on Syria specifically I started an "ignore list" specifically for the road barriers, umbrellas, etc from being saved to the save state on the Grayflag server.

It was removed from being placed in the editor, but the files for it still exist in the game. If you load up a mission featuring the CVN-70 it should still exist. Though there seems to be a problem/functionality of the editor that if you select the unit it'll change to the first alphabetical ship type available since it doesn't think the CVN-70 is a valid unit.

I should probably mention that MGRS grids aren't perfectly aligned with the map origin and rectToAll cannot be rotated. The further away from map origin the more rotated the grids become as they are oriented to true north, while the maps are a "flat projection". As a result the two points would generate a shape similar to the screenshot. Which is why my example used quadToAll instead. I'll be adding an example of the MGRStoLL on the hoggit wiki shortly.

The easy way would be to draw the rectangle with a trigger zone similar to what you have done and to use the points created to define the shape. Though you should probably check for a specific zone name. The following code will draw every quad trigger zone. local mId = 0 local function id() mId = mId + 1 return mId end for iter, zData in pairs(env.mission.triggers.zones) do if zData.verticies then local tbl = {-1, id()} for i = 1, #zData.verticies do table.insert(tbl, {x = zData.verticies[i].x, y = 0, z = zData.verticies[i].y}) end table.insert(tbl, {0, 1, 0, .7} ) table.insert(tbl, {1, .5, 1, .3} ) table.insert(tbl, math.random(0, 6)) trigger.action.quadToAll(unpack(tbl)) end end A more precise way would be to feed coord.MGRStoLL the coordinates for each corner of the grid and convert those from LLtoLO via that function to get the exact point.

Lets try to simplify things a little. I've attached a mission that uses the scripting engine to draw a number of shapes. It is using quads, circles, polygons, text, and lines, all of which are shapes I use on the Grayflag server. Please open the mission file from your mission editor and launch it from there. After 1 second unpaused the script will draw the shapes. There should be a line of polygons with text from SA-3 to SA-15, where the number of sides of the polygon increases from 3 to 15. A circle of black lines is drawn where it iterates all 7 line types. Every 7th entry should be missing and it should be between a solid and a double dashed line. In the city there should be quad shapes drawn based on trigger zones. The below 2 screenshots are examples of what you should see on the F10 map. After running the test exit back to the editor and please advise if you see something like the following image. You may need to zoom in and out to see it. If you do see it then it should disappear if you zoom in enough when looking at the ILS and capture area circles defined at the given base. draw_samples.miz

A very basic explanation is that a lot of files may be different or missing from patch to patch and that difference will cause problems. For example the Mirage F-1 and door gun on the Mi-24 are in open beta but not release branch. What does your client see when either of those are present if you join a server featuring them? The game handles it to a degree but there would be some unforeseen consequences. Thus they try to keep versions with enough changes separated. Sometimes open beta patches and it is no longer compatible with the previous open beta patch.