Grimes

Donno if that is pointed toward Grayflag, but the intention is to do it eventually. That said I think there is a difference between hosting a server and posting code that is compiled/redacted for anyone to use. One is trying to get people to join a server that has assorted costs with running it (and the exclusivity of that code) and the other is posting code with the intent for others to use. One of those is trying to extract a competitive advantage and other is kinda being a dick about it.

In general there have been some oddities with simply relying on checking Group.getByName to know if a group is actually dead. There is a mist function mist.groupIsDead that you can use that handles the exceptions to the rule. if mist.groupIsDead(groupName) == true then -- do code to respawn group or whatever. end

That I don't actually know. I honestly have never tested what statics do when placed on late activated ships. Yes their position as saved in the editor will be there either as the X, Y coords or as an offset table.

You can compile lua scripts as is and include them in the miz file. Some have done it for missions and mods. If you are really curious whats in the code there are ways to decompile it so it just protects against those who don't care enough to do that. IMO find an open source license that you like. Its a small community and people are generally pretty good about giving credit to any code they borrowed or took heavy inspiration from. https://opensource.org/licenses

There is no way for static objects to be "activated" outside of it not existing and then spawning it via script. As always if it is placed in the editor you can find where-ever an object starts at by searching for it in env.mission. Since it doesn't move there is no need for Object.getPoint() That said for groups that are set to late activation the group and unit objects are accessible before they get activated. There is a caveat where this is not the case with client groups/units or if you change the spawn probability. For both it is kind of the same principle where the objects simply don't exist. The difference being clients can spawn whenever they want.

Yes it works just fine.

https://github.com/ciribob/DCS-CTLD It is a script that handles troop transport that was created before ED added the functionality to DCS. You can have unlimited groups and it tasks the infantry to run to enemy forces automatically.

That is a bit of a headache to figure out. It would be almost better to just use CTLD to handle it for all rather than a combination of triggers/scripting for the mod aircraft and in game functionality for the rest. At least how you have the triggers setup this is where scripting becomes extremely powerful because it doesn't take much to get the same result with a small amount of code. local acTbl = {"Blue Client 23", "Blue Client 25"} local cargoLoaded = {} local troops = {} for i = 1, 10 do table.insert(troops, "Green 1 Inf " .. i) end local troopIndex = 0 local function disembark(vars) local unit = Unit.getByName(vars.unitName) if unit then if cargoLoaded[vars.unitName] then -- unit is alive and has cargo mist.teleportToPoint({groupName= cargoLoaded[vars.unitName], point= unit:getPoint() , action='teleport', radius = 20, innerRadius = 10}) cargoLoaded[vars.unitName] = nil -- deletes the cargo from the DB else -- Hey you don't have any cargo loaded, so do nothing or display a message to them. end end end local function embark(vars) -- this is really hacky toward how you have it setup. local loadedGroupName if troopIndex < #troops then troopIndex = troopIndex + 1 loadedGroupName = troops[troopIndex] end if loadedGroupName then cargoLoaded[vars.unitName] = loadedGroupName else -- no more groups. Warning message or whatever end end for i = 1, #acTbl do missionCommands.addCommandForGroup(mist.DBs.humansByName[acTbl[i]].groupId, "Embark Troops", nil, embark, {unitName = acTbl[i]}) missionCommands.addCommandForGroup(mist.DBs.humansByName[acTbl[i]].groupId, "Disembark Troops", nil, disembark, {unitName = acTbl[i]}) end

Internal cargo is added mass. If you used setUnitInternalCargo with the empty mass value then the total mass of the aircraft would be emptymass * 2 + weapon + fuel. So don't do that unless you want to make them super heavy. The values within getDesc are static and do not change. To answer your question you gotta keep track of it on your own. The value outright sets the mass, assuming each passenger weighs the same you do something like currentPassangers = currentPassangers + 1 trigger.action.setUnitInternalCargo("heli" , currentPassangers * passangerMass )

I've had mixed results with doing this with ships. In a small isolated test mission teleporting ships with client spawns seems to work well enough. In a much more complex mission, where perhaps I'm not doing it precisely the same way, clients spawn where the ship was originally at over the water and die. I have not tested this with static objects. I don't even recall exactly what happens when you try spawning a FARP with the exact same values. With units it replaces it entirely, but FARP objects are a bit special so it might not work.

I think its more of a norender launch isn't treated the same as a rendered one. The game won't let you launch multiple instances that are rendered, but you can have 1 rendered + X non-rendered. Its actually a fairly common suggestion for heavy missions to host it on a norender server and then connect as a client because you are offloading a lot of the processing to another CPU thread.

Its the same task, so yes it works no matter how the group executes it.

You can host a dedicated server from your full game install via launch commands. You are allowed to login twice on the same PC. Not that it matters since you can make a user account for free specifically for hosting dedicated servers anyway. I have a batch file in my install folder: bin\DCS.exe --server --norender -w DCS.DS_openbeta --server and --norender force it to run as a server. -w DCS.DS_openbeta defines the folder used in saved games. Its best to have this so it isn't trying to use the same folder twice.

Correct. Though you may have to declare it as a value first. Don't remember if it would like Group.destroy(...) local gp = ... gp:destroy()

No.

When it renders objects from top down it is using the actual .EDM (3d models and textures) for the object. There is no 2d rendered version of those available. So yeah its vector graphics because its a 3d asset but not in the sense you are thinking of. Suppose you can screenshot em and work from there. IMO place whichever object you care about at map 0,0 and figure out the offsets based on that.

Offsetting to map origin, which is where the bullseye is at, is the behavior if it doesn't think the link is valid. I think it might simply be ignoring the linking static ships to it. Perhaps other object types are also ignored.

DCS World\MissionEditor\data\NewMap\ for most of them.

It is already reported as of March 2021.

Meant the flag name.

trigger.action.setUserFlag("Whatever", true)

Search then engage is a task that they are allowed to do. It isn't actively forcing them to go there and do a search pattern or anything like that. The AI don't need to be flying in the target area to detect targets, but it certainly helps. Mostly its an aircraft and the sensors they have available issue, with the rest being the targets. You could have an F-15 flying an orbit with that task active, any enemy fighter that enters the zone will probably get engaged because: The F-15 has a good radar and as long as the zone isn't 200km away it could detect the enemy aircraft The enemy aircraft could have a radar emitting, which will show up on the F-15s RWR, thus the F-15 can know something is out there If a friendly AWACS, EWR, or other blue aircraft with datalink are in the mission and detect the enemy aircraft that info is transmitted to the F-15 A HIND is a bit different because it lacks radar and the optics don't have FLIR. So it needs to visually see the target, thus flying in the search area is advised. It seeing tracers or dust from enemy forces moving will help it engage.

For starters its just how tasks work. https://wiki.hoggitworld.com/view/DCS_editor_AITasking#Perform_Task_vs_Enroute_Task with anything from under the "Perform Task" category forces the AI to do only that task until it is complete. Enroute tasks allow AI to go do other tasks because their behavior is predicated on detecting the targets, but there still is a priority. That said 8 attack unit tasks with waypoint actions is the worst way to accomplish what it looks like what you are trying to do. 1. Triggered actions tab. These are actions that you can activate at any time via the trigger AI Task Push or AI Task Set. They can be called in any order at any time. null 2. Search then engage X. You could give the AI a task to search then engage in zone, in which case they will just attack players as they enter the area with priority on whichever they detect first. You can also tell em to engage unit, but as stated earlier with 8 search then engage tasks for each unit the AI can switch targets if a target higher in the list becomes detected. 3. Scripting. Its similar to triggered actions except you don't have to setup X number of tasks. You can just have a single task table and change the variables as needed. https://wiki.hoggitworld.com/view/DCS_task_attackUnit

Those are more of tags that just give basic info about the given task. IIRC -x disabled -a automatically created. Place a group sometimes there are tasks that are populated for you. -ref Reference. Seen with enroute tasks on waypoints after it was assigned. Basically a way of noting it is still active. -?/? Can show up as -/? and -?/. Means there are start or stop conditions.

Its been on the bug/feature tracker for several years as is. Gotta complain to a community manager about it.