Hardcard

@Kappa The reason your initial code works is probably because you're using :FilterStart() in your set declaration (this starts a scheduler, if I'm not mistaken, so the set gets updated over time...although it doesn't always work). Since you're also spawning the late-activated groups using :SpawnScheduled(60,0), they are added to the database, then they're found and added to the set when the prefix filter runs again. I'd say that if you do one of the following things, your script will stop working because the set won't be able to find the unspawned groups: Remove :SpawnScheduled(60,0) and dump the set to dcs.log at the end of the script (I predict that it will be empty) Use :FilterOnce() instead of :FilterStart() in your set declaration, then dump the set to dcs.log at the end of the script (I predict that it will be empty) I understand that it's easier to just filter by prefixes and update the set automatically, but when working with late-activated units/groups, they need to be spawned first (unless ED has changed how this works in recent patches) While developing SWAPR, I tried to build sets of groups/units directly from the database, it only worked with clients, regular AI groups/units couldn't be found (regardless of the filter I used). In the script example that I posted, I made things really easy, you only need to provide the ME group names of the late-activated TEMPLATE groups. You don't have to provide the names of all the groups that will be spawned from those (that's handled automatically) For instance, you can have a single late-activated TEMPLATE group named 'RECCE-REAPER #001' in ME, from which you can spawn hundreds of copies using SPAWN class. In that case you'll only need to add 'RECCE-REAPER #001' to Groupname_Table, the script will take care of the hundreds of copies automatically. Happy new year, btw! :yay:

@Kappa Unless ED has changed the way this works, you can't form sets of unspawned groups/units (except for clients) Just think about it, RecceSet won't be populated until the late-activated groups are spawned, therefore, if you put the SPAWN object declaration inside the for loop (:ForEachGroup), nothing will be spawned. First you need to define the SPAWN object(s), then you need to spawn them, so they can be included in the set. Also, I think that prefix and coalition filters conflict with each other, I'd recommend getting rid of the coalition filter and adding an active filter instead. Like this: RecceSet = SET_GROUP:New():FilterActive(Active):FilterPrefixes('RECCE'):FilterOnce() You'll also need to put this set declaration inside a scheduler, though, otherwise it won't update as groups spawn and die. Anyway, all that jazz is just so you know how to work with sets... Truth is that you can achieve the behaviour you're looking for without using SET_GROUPs. Here, this script should have you covered (you just need to introduce the names of the late-activated group templates you're interested in, the location is marked in red):

I don't think that's the case. I'd say that most people are expreciencing a performance hit when compared with the old cockpit...but since they didn't monitor fps before the update (and their beastly rigs can brute-force through anything), they don't see the problem. In my case, the problem is clear as day: FC3 -> 60+fps Mi-8 -> 60+fps Huey -> 60+fps Old A10C cockpit -> 60+fps New A10C cockpit -> 30-40fps (under the same conditions, without tweaking) Tomcat -> 60+fps

Ok, looks like I've managed to salvage ~20fps by doing some gymnastics (note that no other module has ever required me to do all this). General changes 1- Shadows off (this new cockpit is way too shady... pun intended, but still true) 2- Cockpit global illumination off AMD specific changes 3- Delete any existing DCS profile and create a new one 4- Texture Filtering Quality -> Performance 5- Surface Format Optimization -> On 6- Radeon Anti-Lag -> On

Have you disabled sync, let DCS run at max fps and then compared performance between the two cockpits? If your pc is capable of running DCS at 100+fps and the new A10C cockpit runs at 60+fps, you're actually experiencing a pretty significant performance hit... without realizing it. @Dr_Arrow I have the same processor and an equivalent AMD card (R9 290), it's strange. Also, I repeat, I have no problems with the rest of FF modules I own, including the tomcat... this is A10C specific and it started happening when the new cockpit was introduced. @SkateZilla I haven't posted my specs before because I wanted to avoid "garbage" comments. Like I said, the rest of modules perform as expected, including the tomcat and the A10C before the cockpit update. Specs: Windows 10 Pro 64bit i7 2600k @ 4.2GHz 16GB DDR3-1600 R9 290 SSD Samsung 840 EVO 120GB (System SSD) SSD OCZ Vector 120GB (DCS SSD) Toshiba DT01AA300 3TB I've been monitoring data from the DCS service info (upper left corner) and the results are puzzling. The fps hit doesn't seem to be related to object count, as one would assume. If I look outside the cockpit (let's say to the right), get a boost of ~30fps, even though the object count is higher out there. If I then simply close the canopy (still looking to the right), performance starts getting affected, I lose 10+fps just for that. Also, If I zoom in when looking inside the cockpit, fps go back to normal. If I had to guess, I'd say that the problem has to do with the new textures / effects / layers used in the new A10C cockpit.

I've just installed and tested the tomcat, no performance hit. Looks like the problem is specific to the new A10C cockpit.

Duplicated thread

@ChuckIV There are several problems with your previous script (wrong syntax, wrong parameters, objects given instead of strings, incompatible objects, etc). Here you have a corrected and "simplified" version: local GP3_Table = {} local GP10_Table = {} local Spitfire_GP3_P9374 = SPAWN:New( "Spitfire GP3 P9374" ) :OnSpawnGroup( function(Spitfire_GP3) table.insert(GP3_Table , Spitfire_GP3) end ) local Spitfire_GP10_P9374 = SPAWN:New( "Spitfire GP10 P9374" ) :OnSpawnGroup( function(Spitfire_GP10) table.insert(GP10_Table , Spitfire_GP10) end ) [color="blue"]-- ***************************** DEFINE VEC3 POINT FOR FOLLOWING GROUPS *************************************************************** -- ******************************** FUNCTION FOR GROUP TO FOLLOW ANOTHER GROUP **********************************************************[/color] function GP_FOLLOW() for i, GP3 in ipairs(GP3_Table) do if GP3 and GP3:IsAlive() then local GP3_Position = GP3:GetPositionVec3() LARCL = { x = GP3_Position.x, y = GP3_Position.y , z = GP3_Position.z + 914.4 } [color="Blue"] -- Taking the position of GP3 as reference might not be necessary here...[/color] FollowedGP = GP3 else i = nil end end for k, GP10 in ipairs(GP10_Table) do if GP10 and GP10:IsAlive() and LARCL and FollowedGP then local FollowingGP = GP10 local GP_Task = GP10:TaskFollow( FollowedGP , LARCL) [color="blue"]-- According to the Hoggit Wiki documentation, the parameters lastWptIndexFlag and lastWptIndex must be given as well, but you can try without them, see what happens [/color] FollowingGP:SetTask( GP_Task, 1 ) else k = nil end end end [color="blue"]-- ******************************************** SPAWN GROUPS **************************************************************************** [/color] Spitfire_GP3_P9374:Spawn() Spitfire_GP10_P9374:Spawn() [color="blue"]-- **************************************** SET GROUPS TO FOLLOW ************************************************************************ [/color] GP_FOLLOW() If you want to repeat the process with newly spawned groups, simply run the following lines again (previously spawned groups must be dead, though): Spitfire_GP3_P9374:Spawn() Spitfire_GP10_P9374:Spawn() GP_FOLLOW()

@OzDeaDMeaT You can tweak the script I posted above, so it kicks specific players back to spectators whenever they choose slots that aren't reserved for them. Also, specific liveries can be assigned to specific units, if you combine this with player name checks, then you can assign them to specific players as well. You'll need to modify the group template table of the relevant units (also, you need to know the valid enumerator for each livery).

@Wrench From what I've seen, MOOSE sets aren't always updated when using :FilterStart() To work around this problem, I use :FilterOnce() instead, but that requires either placing the set variable inside a scheduler or inside functions that can be repeatedly called via F10 menu. Aside from this, that snippet that you posted doesn't have a filter defined, I think that you need to specify the filtering method first... I normally use a prefix filter, works fine.

@Sierra99 Thanks, I had already applied that registry change before starting this thread, I hoped that would solve the issue, but it made no difference. Hopefully the new cockpit will be optimized in the future, if not, I hope ED provides an option to revert back to the old cockpit... otherwise they just made a perfectly fine module unplayable for me.

@LittleTimmy Thanks for confirming the issue. Do you have an AMD gpu as well? I hope ED sorts this one out, or at least provides a way for us to revert back to the old cockpit. @Puma I know I won't be flying the warthog while this problem exists... and it's one of my favourite modules.

@draconus Using high gain NWS makes that tight turn possible on the fulcrum, but it's still pretty tight, those walls are still a pointless obstacle. On the frogfoot that turn is even tighter, since the plane doesn't have high gain NWS like the fulcrum does (also, the nosewheel on that thing is easily broken in tight turns). Making the turn on the frogfoot is possible, sure, but the problem shifts to the interior wingtip getting stuck on the hangar while making the turn... like I said, those walls are a pointless obstacle that make an easy thing hard.

At first glance, my guess would be that you didn't provide the required parameters for :TaskFollow UNIT/GROUP:TaskFollow(FollowControllable , [color="Red"]DCS Vec3[/color] , [color="Red"]LastWaypointIndex[/color]) Here's the Hoggit wiki article: https://wiki.hoggitworld.com/view/DCS_task_follow Also, you'd need to provide the specific spawning method for the AI group and the declaration for Spitfire_GP10_P9374 . If you're using MOOSE SPAWN class to do it, you might have problems with group naming as well.

@CougarFFW04 This is one of those things that should be easy to get... but it's a pita instead. The only way I know to do this is by accessing the group template table from the database. I do this using MOOSE in the following way (required field marked in red, don't remove quotation marks): local Group_Template_Table = _DATABASE:GetGroupTemplateFromUnitName("[color="Red"]name of the relevant unit in ME[/color]") local Template_Task = Group_Template_Table.task [color="Blue"]-- This should return a string containing the name of the task assigned to the group in ME[/color]

You just found a good reason to get into scripting.

@Dispatch Those build errors are normal. As long as you have intellisense working, everything will be fine. As for Java, I'm using 1.8.0_181, it works fine with LDT.

@Worrazen This thread is about performance problems with the new A10C cockpit, not about dual GPU implementation in DCS... If you want to talk about that, feel free to open your own thread.

@AeriaGloria Thanks for your input, the problem was that I always taxi with flaps down, so NWS doesn't work. The lock button seems to do the same as the NWS button... as long as flaps are up!

@BIGNEWY Alright, thanks for telling me. Is there any public list of reported issues we can check before reporting stuff? @AeriaGloria What do you mean by "lock button"? The brake lock? If you mean the NWS button, that doesn't seem to do anything when pressed, unlike the F15C... unless it's only meant to enable/disable NWS, like the flanker's NWS switch. EDIT: Alright, the NWS button does work...but only when flaps are up!!!:doh:

@twistking I always play without mirrors and delete fxo & metashaders folders after each update... those aren't the cause. Same mission, same locations, everything is the same but the cockpit... performance is consistently down by ~20fps when compared to the old cockpit. Also, the rest of my FF modules perform within expected parameters (40-60+ fps, depending on object count around me). Seems like this new A10C cockpit has optimization problems, at least with AMD cards.

J spots at Bandar Abbas airbase (north, inside hangars) seem to be inadequate for some aircraft (fulcrum, frogfoot, etc.) The hangars are walled, leaving only minimal room for turning... problem is that some aircraft are incapable of performing tight turns while taxiing (such as the fulcrum and the frogfoot). This is how close the wall is on spawn: This is the required turn: This is what the plane is capable of: Antenna gone: Aircraft quantum tunneling: Seems to me that those walls need to go...

Love the new cockpit, but not at the cost of ~20fps. Anyone else having performance issues with the new cockpit? Also, is it possible to revert back to the old cockpit?

@egami You might want to post the mission file + script + dcs.log As for C130_NORTHLASVEGAS_BLUE#001, this indexing is done automatically by DCS every time a new group / unit with an already existing name spawns. The rule of thumb here is to never use :FindByName() with late activated groups / units (at least in MOOSE). In order to work with such groups / units, you'll need to either store each object on spawn or include it in a set afterwards. :OnSpawnGroup() is your new friend, it will allow you to work with late activated groups / units. Here is an example of my latest use of :OnSpawnGroup(). I store the group objects in a table and task them to attack me as soon as they spawn. local Bandit_Table = {"Bandit_Tomcat_grp" , "Bandit_Hornet_grp", "Bandit_Eagle_grp", "Bandit_Viper_grp", "Bandit_Mirage_grp", "Bandit_Jeff_grp"} local SpawnGroup_Table = {} local RandomSpawnGroup = SPAWN:New(Bandit_Table[math.random(1,6)]) :OnSpawnGroup( [color="Blue"]-- It allows me to inject the function below[/color] function(SpawnGroup) [color="Blue"]-- SpawnGroup is the spawned group MOOSE object[/color] table.insert(SpawnGroup_Table, SpawnGroup) [color="Blue"]-- I insert the spawned group object in SpawnGroup_Table, for later use[/color] local Player_Attack = SpawnGroup:TaskAttackUnit(Client_Object,true) SpawnGroup:PushTask(Player_Attack) end [color="blue"]-- end of the injected function[/color] ) [color="Blue"]-- close :OnSpawnGroup parenthesis[/color] RandomSpawnGroup:Spawn()

@CougarFFW04 If by orientation you mean heading, you can get it using MOOSE. Alternatively, you can just use the same code MOOSE uses to calculate it: local Static_Object = StaticObject.getByName("Name of the static in ME") if Static_Object then local Position = Static_Object:getPosition() if Position then Static_Heading = math.atan2( Position.x.z, Position.x.x ) if Static_Heading < 0 then Static_Heading = Static_Heading + 2 * math.pi else Static_Heading = Static_Heading * 180 / math.pi end end end As for :getPosition(), it returns a table containing 4 subtables: - Position subtable (object coordinates relative to the map origin, using the map axes) p = {x = n, y = n, z = n} - Orientation subtable for the x axis of the object x = {x = n, y = n, z = n} - Orientation subtable for the y axis of the object y = {x = n, y = n, z = n} - Orientation subtable for the z axis of the object z = {x = n, y = n, z = n} I think that these three orientation subtables contain the results of 3x3 transform matrices, which DCS uses to turn objects around. Just remember that every object in DCS has its own x, y and z axes (used for orientation and vectoring of the object itself), which are separate from the map's x, y and z axes (used for reference and positioning of all objects). Perhaps I'm mistaken somewhere, but this is what I've been able to gather so far.