Grimes

Not the same thing as the other reports you posted on.

Think about the process involved with some of this stuff. Someone that matters has to see it, think it is a good idea, and add it to a list of features to implement. Someone that makes scheduling decisions assigns devs to it or assertive dev decides to do it on their own Development time which may or may not require other people/teams to contribute to the feature. For example a trigger can be added by a UI developer but the actual functionality needs to be done by someone else. Feature is implemented but needs to be merged to the next patch. Sometimes that can be the next patch after its implemented, or the one after that, or it could depend on something else and has to wait until that gets done first. This goes for all wishlist sections and from small changes to stuff that might take years to complete.

For anything using custom liveries that aren't installed locally that player simply sees whatever is the default livery for that country. Ever play online and see an F-18 with VFA-37 livery that has literally every single location for a tail number being used? That person is using a livery you don't have. The Green camo missing texture only shows up if absolutely no textures are found or the textures for the loaded livery can't be found. Hence its for missing textures.

No just scenery objects that are part of the map. It would be nice if some of the great scenery objects made for maps could be placed as static objects but so far nobody has added any. On Syria these are the most common with the 2nd most common being the larger revetment on the other side of the taxiway. These are world objects and what is great is that world.searchObjects can find them. With some scripting you can find the objects for the revetment and then dynamically place units at the correct location and orientation easily enough. However! There are also examples of the terrain itself being molded to create something similar. On Syria there are the larger revetments and berms like the ones screenshot below. Neither of these are detectable via scripting, which is weird for the revetment because it looks like an object is there but it really isn't.

Gonna have to also have to modify me_aircraft.lua then. Looks to be the function starting at line 512 and anywhere its forcing the value to be: e_callsignUnitNum:setText(unitId)

Events are generated by DCS and represent things that happen. You don't set any value with them, but you can run other code to get information about the event or for reference purposes. Every single event has an id and time value telling you what the event is and when it happened. From there the additional contents of the event depend on what it is. Most will have an initiator value which corresponds to the unit that caused the event. initiator, target, place, and weapon are all going to be objects and have access to whichever sub-class of objects they are. Check the example provided for the shot event. https://wiki.hoggitworld.com/view/DCS_event_shot It directly uses the initiator and weapon from the event table to get information about it. Then adds that information to a table entry which is ultimately a fancy way to concatenate text.

Anything in GUI callbacks is local to that PC. It won't have data on the actions of anyone else.

There was a point in time where we could edit that digit IIRC, but the change was reverted. However I think you can modify me_aircraft_group.dlg and find the "readOnly" entry for e_callsignUnitNum, which should be at line 1085. Change that value from false to true. The change should be reflected in the mission file. Though whenever the game updates it will restore the file to default state. To go more in depth with western callsigns it is saved as a table of 3 digits and a string. The value at index 1 acts as an enumerator for the callsigns. I do think it is a little suboptimal that the value depends on the actual aircraft type rather than each callsign being a unique value, but it is the system ED has opted to use. For example 1 is for Enfield, Overlord, or Texaco. The actual callsign name depends on the type of unit with tankers, awacs, and JTAC having their own sets of callsigns starting at 1. Then you have the common list with Enfield, but aircraft like B-1, B-52, cargo planes, A-10, F-16, and F-18 have additional callsigns that get appended to the end of the list. ["callsign"] = { [1] = 1, [2] = 1, [3] = 1, ["name"] = "Enfield11", }, -- end of ["callsign"] Wiki is down but I have a list of the enumerator values there.

Was more referring to that its been reported on the internal tracker, but here is the thread.

You can also sort the units list by module if you need to find a problem unit. Works with mods also. null

Possibly. I think there is a self defense aspect to it where they do prioritize attacking the bombers, but then become under threat, or at least decide they are under threat, and effectively give up on attacking the bombers. Though I'm not the best authority on WW2 AI behavior as I've only done light testing on the subject and almost all of my plane AI testing involves modern aircraft.

Most likely this is referring to the already reported bug of Unit.getGroup failing on death related events.

The error is on line 32 which is if Unit.getController(Unit.getByName(enemy)) then Basically Unit.getByName(enemy) is returning nil and then you are passing that to Unit.getController(nil), thus the error. There are a few things you can do to make it more efficient. local function isPlayerDetected(enemy) local con = Unit.getController(enemy) if con then local target = Unit.getByName("Player") -- define as this if not target then -- if nil then get the other unit target = Unit.getByName("PlayerTest") end local m = {} -- could add an if statement for target ; if target then for det, enum in pairs(Controller.Detection) do if con:isTargetDetected(target, enum) == true then trigger.action.outText("You have been spotted by " .. enemy .. ". Method : " .. det, 10) return true end end end return false end if enemyZone ~= nil then for _, object in pairs(enemyZone) do if object:isExist() == true then -- this checks to make sure the object exists if isPlayerDetected(object) == true then -- you were getting the name of the object, from the object, and then using Unit.getByName to get the object again trigger.action.setUserFlag("6", true) end end end end

It wasn't that the initial waypoint was to far away, its where they got assigned the task was to close to the B-17s when the task was assigned. Think of it in modern aircraft terms like an F-14 armed with phoenixes. They wouldn't have been allowed to attack the bombers until they were within 10km, thus negating the advantage of using that missile and also giving little time to react and prepare to attack. Adding an orbit would help because if they found nothing or lose track of targets they will just RTB. Whenever you have a search then engage group/unit there is still a priority based on the order they were assigned in the tasking. Leaving it as search then engage bombers should work about the same. In either case the AI will get focused on a given target. Using the group/unit task would be beneficial when dealing with multiple flights and you want them to target as many targets as possible. Essentially AI communicates within their own group who they are attacking but not with any other group, thus it is common for multiple flights to attack the same target if allowed. For example if you had 2 groups of 6 vehicles in the same area and wanted 2 A-10s armed with 6 Mavericks each to attack. If both a-10s were both in the same group then they'd split up the targets equally. If each a-10 was in their own group were able to attack at the same time, there is a really good chance that they would end up sending missiles to the same targets at the same time. If you used search then engage group and reversed the priority they'd each attack their own group.

I had only opened it up in the mission editor to have a look around since it is often enough to look at assigned AI tasks to get an idea of what to expect or find problems there. Edit. Ok track didn't have anything spawn. Most likely you had spawned into an aircraft I don't have installed and things don't work from there. But anyway with the added description of checking for a group with the CAP task I was able to find the AI in question and just have them spawn normally to test it. Which is the ideal way to show an AI problem. Looks like the AI are getting into a defensive behavior and self defense is taking priority over attacking the B-17s. Also the timing/positioning of the group when the task gets assigned doesn't leave much room for them to decide to attack the B-17s. Meanwhile the escorts have already broken off and begun to engage because their task has been assigned from the start. You might get better results moving the search then engage bombers task to the initial waypoint.

Many of the AI groups still have the "Fighter Sweep" main task enabled. Delete it. https://wiki.hoggitworld.com/view/DCS_editor_FAQ#Why_do_AI_aircraft_keep_attacking_before_I_want_them_to.3F

The warehouse is empty. When you spawn aircraft on the ramp it pulls the aircraft from the warehouse, but it doesn't when spawning on the ground. If nothing is available then the unit won't spawn. nullIf you were using the warehouse before then it might be best to set to unlimited, save mission, turn unlimited off, and then adjust the values as you desire. Warehouses still get a bit corrupted after objects get added to the game or with mods, so its best to "reset" the values from time to time.

The game really doesn't make it easy to do that. With the threat rings it is a question of whether or not the hiddenOnMFD is checked and when the group spawns relative to the player spawning. Group spawns with hiddenOnMFD, then player spawns, that player shouldn't see the threat ring. Same if the player spawns and then the group spawns with any setting. By those rules you just need what you want the player to be seen when the player spawns and then add/change whatever after the player spawns. To make things much easier you can always spawn the player later. This would be the easiest way to do it with just triggers. Force the player to start at 2 seconds into the mission. At mission start set a flag to whatever value. Once time less than 10 seconds, so it runs first thing after mission start occurs, for each sam if my flag is false then group deactivate. Now player spawns. After player spawns then you can activate a group that had hiddenOnMFD checked and deactivate the sam representing the threat ring. However to utilize the lua condition is a little on the annoying side. The only thing that runs before it is the initialization script found on the trigger panel. You can add something like this to every sam you want to conditionally exist. if tbl["Ground-1"] then return true end Then in the initialization script you need to define tbl and add the groups you want to add to it. tbl = {} local choices = {"Ground-1", "Ground-2","Ground-3","Ground-4","Ground-5"} local rnd = math.random(#choices) tbl[choices[rnd]] = true What this is doing is the initialization code creates the table and adds the group name as a key that gets checked by the condition. Then the condition checks to see if their respective group name is found in the table, if it is then spawn the group. This would be a whole lot easier if we could just draw a threat ring on the MFD and ignore the units. But we can't yet, so here we are.

The condition and percentage values are both used to determine if the group exists in the mission. In the .miz file this entry is labeled as "probability". Condition is just a lua condition that you might want to hook into other code and uses return true or return false to define the spawn rules. I underlined "group exists" above because that is an important distinction from using late activate. If the percentage is 0 then think of it as the trigger Group Deactivate, also the scripting function of destroy(), is always being run on the group. If its any other percentage then its whatever RNG you set to determine if that happens. Anyway that group won't exist and you can't use group activate to spawn it* at a later point in time if you wanted to like you can with late activating groups. On the face of it this is an easy triggerless way to get some basic unit randomization. Instead of creating a dozen Mission Start>Random X>Group Activate triggers and also setting late activate for the relevant groups, you just set whatever percentage value you want in the probability value to get the same basic result. * I heavily use this as a property with the bubble spawning script used on the Grayflag server. Anything with probability == 0 means that group can be controlled by the bubble script. The group doesn't exist but the group table within the mission file still does, thus it gets used as a template of sorts being passed to coalition.addGroup when the bubble spawner decides to spawn the group. Since the game automatically despawns these groups on mission load I don't have to manually remove them as the mission starts.

That is an oddity that occurs from how the train is formed. Each component isn't a unit, rather they are more like entities attached to the unit. It has been a while since I last tested scripting functionality on trains and I seem to remember making a few bug reports on the odd values returned by group and unit functions. null

That isn't an "outside script" as you say. It is using world.searchObjects which is part of the scripting engine. This issue has been reported since Oct 2021. In general the issue occurs on all maps with a plethora of different objects throughout. The common types are what can be considered "knickknacks" or "doodads" on the map. Meaning they are usually objects on the small side of things, only render at close distances, or spice up a scene somehow. It is usually in the form of walls, fences, parked cars, debris, and things of that nature. But there are instances of larger objects that are simply not returned for one reason or another. Best guess is that it is a map issue where the objects need to be given a tag of some sort for the function to detect and return the objects. If I dropped a bomb on them it'll give me the objects via hit/dead events, so they functionally do exist. I have mixed feelings with it because every object on the map is an object and should be accessible. On the other hand broad filters are nice because returning absolutely everything in a given area could double or more the objects returned. Chances are you don't care about the 200 fence objects that are in the area, but those are still objects you'd have to iterate through. The inconsistency does bother me though. See the screenshots attached, the parked scenery ships don't return but apparently the 20+ objects on a ship do on Caucuses. Meanwhile on Syria the containers are returned, but ships, cargo cranes, fences, and lightpoles are not.

It has to be passed a specific group that you want to spawn in that zone. You can randomize it before hand with something as simple as. local z = {'Spawn-1', 'Spawn-2', 'Spawn-3'} local g = {'Ground-1', 'Ground-2', 'Ground-3'} mist.respawnInZone(g[math.random(#g)], z) So what that does is its using the size of the g table as the max value for math.random. Thus it'll pick a random number between 1 and 3. Think of it as g[2] for example, which means it is passing the value at index 2 of the g table, which is "Ground-2".

So just like the actual event handler? local h = {} function h:onEvent(event) trigger.action.outText("AN EVENT OCCURRED", 3600) end world.addEventHandler(h)

MigCtrl1:setCommand(Start) The AI controller and tasks are split into 3 main categories of tasks, commands, and options. You need to use setTask* or pushTask for anything listed in main tasks and enroute tasks. setCommand for commands, and setOption for any option. *it is a bad idea to use setTask for anything other than main tasks. Basically setTask erases every task assigned, including the route the AI is following, and assigns whatever was set. Enroute tasks get executed as the AI follow their route... which would have just been erased. Commands and Options get executed immediately. So what would happen is the AI would RTB once the task that was set was completed. If you setTask on an attackUnit then the AI does that until the target unit is dead. I try to just use setTask on mission tasks that have waypoints assigned to it. pushTask pushes the assigned task to the top of the queue and then resumes with the route or whatever else is left to do.

https://wiki.hoggitworld.com/view/DCS_editor_triggerBasics#Once and https://wiki.hoggitworld.com/view/DCS_editor_Randomization#Triggers_2 might be helpful to understand random in the context of trigger conditions. The type defines how a trigger is allowed to do a given action. Basically all of them get continuously evaluated unless you set an event and mission start, which is also an event in itself. Start conditions for tasks should only check the conditions once upon arrival at a given waypoint though. So if that is evaluating multiple times then it is a bug. IIRC that has been a problem in the past.