Hardcard

I have to agree with Grimes, using obfuscated code in a public DCS script is pretty silly...if you combine it with lfs and io activation, then it becomes suspicious (sure, you can always leave them sanitized, but still). No community members who create scripts for DCS obfuscate their code and you obviously know this... unless you want to tell us how you magically stumbled upon these... I'm sure you didn't check Grimes' Hoggit Wiki even once... ;) Look, I found this thread by accident, I wasn't going to post... until I read your "explanations". You made a deliberate effort to obfuscate the code, instead of releasing it straight, like everyone else does (as you obviously know). You know perfectly well how code is usually released 'round these parts, you know perfectly well that other community members might use parts of your script for their own projects, which will be publicly released as well (that's kind of the point)... Instead of lecturing you on the value of open source, I'm just going to illustrate the practical side of all this: You benefited from code publicly available to the DCS community in order to create your script Then you decided to obfuscate your code, so the same community that gave you the tools to create it, won't be able to access it... effectively cutting the feedback cycle. Now consider what would happen if the rest of coders in the DCS community decided to obfuscate their code as well (including Grimes and the whole Hoggit Wiki). That would put an end to the possibility of people like you coming in, learning how to script stuff for DCS (from the community) and creating scripts like this one. Do you value the knowledge you gained from the community? If you don't want to get negative reactions from the coders in the community, don't pull this kind of crap and don't use cheap excuses... it's silly, it's misguided and it's disrespectful. Instead of telling people stuff like "I suggest you check out the features and the value this LSO Script offers to the community" , maybe you should stop for a second and think about how you were able to create this script precisely because other people don't go around obfuscating their code... Cheers! :thumbup:

They must be set to late activation and you must make sure that the provided group name matches exactly (do not remove the quotation marks in the script, btw). Also, you must load Moose.lua before running the script, ofc, otherwise it won't work. If the group contains 4 units, then you must adjust InitLimit's first parameter accordingly: Spawn_Object = SPAWN:New("[color="Red"]Name of the late activated group in ME[/color]") :InitLimit( [color="red"]4[/color] , 20 ) :SpawnScheduled( 60, 0 ) If it's still not working, check your dcs.log, you're probably getting a scripting error

@BaD CrC I've never encountered disappearing ships, I've only seen this with carrier-based units (when getting up close with the external camera). I think it has to do with the carrier moving and turning and the units not being properly "grounded" on the deck.

@CHPL DCS automatically moves AI units and clients around if they're based on the Tarawa or the Stennis. Just make sure that your AI units are set on different PRK numbers, if that doesn't work, then it's probably a bug. ED apparently changed some related code in the last openbeta update (according to the patch notes)... SSE. Coalition.addStaticObject unable to spawn objects on ships - fixed Also, regarding the issue of carrier-based units disappearing when getting up close, I've encountered it too, it's definitely a DCS bug.

It won't work with statics, only with late activated AI planes and helicopters (as it's written). If you want it to work with ground units as well, you need to remove the last line, so it looks like this: Spawn_Object = SPAWN:New("[color="Red"]Name of the late activated group in ME[/color]") :InitLimit( 1, 20 ) :SpawnScheduled( 60, 0 ) If you want to create this kind of SPAWN object for 10 groups, you can either copy / paste the code 9 more times (changing the group name each time) or you can use sets and for loops. If you don't know lua, I recommend that you simply copy / paste the code and change group names as you go, it's simpler.

Your code isn't sloppy, it's just unformatted, which makes it a pita to read ;) Use the CODE wrap next time, it should keep the original format. Like I said, I'll probably take a deeper look some other time, but so far here is my main suspect: I don't think this is a valid way to check whether a table is empty if recentTargetedZones == nil then [color="Blue"]-- check to see if the table is empty[/color] I don't see how recentTargetedZones would be nil, since it's a table (an empty table, sure, but a table nonetheless) If you run this simple test code in a lua environment, you'll see how table isn't nil (you'll get the second message): local table = {} if table == nil then print("table is nil!") elseif table ~= nil then print("table isn't nil!") end I'd use a for loop with pairs, check all indices within the table, see if they are paired with a nil value (if they are, that means the table is effectively empty) If there are no indices in the table, that would also indicate it's empty, ofc. In that case, this should do the trick: if next(recentTargetedZones) == nil then

@shnicklefritz Please, format your code properly next time. I might take a deeper look later, but at first glance there might be an issue with the grp variable. local grp = Unit.getGroup(event.initiator) [color="Blue"]-- This isn't how you get the group from the event initiator (it's not the typical way)[/color] [color="blue"]-- This is how I'd do it:[/color] local grp = event.initiator:getGroup() Regarding that for loop, I'd do what Richard Dastardly suggested, use either pairs or ipairs (ipairs only works with numeric indices, keep it in mind) If you aren't getting the messages, either the conditions aren't being met or there's a scripting error along the way (chances are that you won't see it in dcs.log) .

Because ED invests its resources with profits in mind (that's what companies do). Fixing AI problems won't increase their revenue, but adding eye-catching stuff and creating new modules will attract people, which translates into cash. If you want ED to fix fundamental problems in DCS, you need to give them an economic incentive... otherwise you'll need to cross your fingers and wait, see if they get around to fixing this stuff..eventually. ... Or you can create scripts in order to work around the existing issues, your choice. Sure, the situation is far from ideal, but it's how the world works.

I'd push the tasks independently from the Mission1 table, in order to identify and isolate the problem: PlaneController:pushTask(Mission1.params.route.points[1].task) [color="Blue"] -- This should direct pushTask to the EngageTargetsInZone task table[/color] PlaneController:pushTask(Mission1.params.route.points[2].task) [color="Blue"] -- This should direct pushTask to the Orbit task table[/color] If these tasks run on their own, means that your problem is somewhere inside the Mission1 table. Also, PlaneController might need to be the controller of the AI group, not the individual AI units... try it both ways, see what happens. Also, it might also be that you're missing some required parameters or that some of the parameters have invalid values.

Rudel_chw I think I've managed to solve the spawn heading issue for statics in the last develop version. The buried harrier issue, though... that's pretty weird, can you send me the mission in which the problem is occurring? EDIT: Looks like I've been able to solve the "buried harrier" issue as well, the fix will be included in the upcoming v1.2 @Everyone SWAPR PnP Hybrid v1.2 will be out in the coming days, it'll include fixes for the issues reported above as well as an early iteration of slot block for MP (thanks to Funkyfranky for suggesting the idea a while back :thumbup:)

Statics cause the same performance hit as uncontrolled AI, I'm afraid there's no noticeable difference. An easy way of minimizing performance hit is to place some of the clients inside sheltered spots (if you're using Caucasus map) and then set Sheltered_Replacements to false, so SWAPR won't generate any replacements for them. It's either that or editing the PILOT names of several clients, so they won't use the SWAPR prefix / suffix.

@Everyone After several hours of painstaking work, troubleshooting and testing, looks like I've managed to increase SWAPR's tweakability quite a bit SWAPR PnP Hybrid v1.1 is out! :clap: Changes: As I said, I've tested it quite thoroughly, but haven't tried it on a dedicated server (it should work, just like v1.0). Please report any issues you find! :thumbup:

If you're using MOOSE, this is will give you the names of the missiles (it's available for SHOT events): EventData.WeaponName

Don't use the same variable name for all three groups, otherwise DCS won't know the difference. In this case, this won't work for what you want to accomplish, even if you give the variables different names... it's just a general scripting tip. Now, if you want the group menus to be automatically created for the three groups, you'll need to use a table and a for loop. local function setFlags(v) trigger.action.setUserFlag(v.flag, v.val) end local Group_Name_Table = {"BVR_Blue_F18_1", "BVR_Blue_F18_2", "BVR_Blue_F18_3"} [color="Blue"]-- Include all the relevant group names in this table (string format, separated by commas)[/color] for i , GroupName in pairs( Group_Name_Table ) do [color="Blue"]-- This is the for loop. i stands for the table index value, which in this case would be either 1, 2 or 3 (since there are 3 elements in the table above). GroupName stands for the values inside the table (in this case, the string names of the 3 groups)[/color] if Group.getByName(GroupName) ~= nil then local Group_ID = Group.getByName(GroupName):getID() local spawn1 = missionCommands.addSubMenuForGroup(Group_ID,"Spawn PVE") local spawn2 = missionCommands.addSubMenuForGroup(Group_ID,"Mig-29s",spawn1) local spawn3 = missionCommands.addSubMenuForGroup(Group_ID,"SU-33s",spawn1) local spawn4 = missionCommands.addSubMenuForGroup(Group_ID,"F-14s",spawn1) local spawn5 = missionCommands.addSubMenuForGroup(Group_ID,"F-18s",spawn1) local spawn6 = missionCommands.addSubMenuForGroup(Group_ID,"F-15s",spawn1) local spawn7 = missionCommands.addSubMenuForGroup(Group_ID,"J-11As",spawn1) local spawn8 = missionCommands.addSubMenuForGroup(Group_ID,"F-5Es",spawn1) local spawn9 = missionCommands.addSubMenuForGroup(Group_ID,"FW-190s",spawn1) local spawn10 = missionCommands.addSubMenuForGroup(Group_ID,"F-16Cs",spawn1) local spawn11 = missionCommands.addSubMenuForGroup(Group_ID,"F-4Es",spawn1) missionCommands.addCommandForGroup(Group_ID, "Mig 29 1 Ship", spawn2, setFlags, {flag=123, val=true}) missionCommands.addCommandForGroup(Group_ID, "Mig 29 2 Ship", spawn2, setFlags, {flag=184, val=true}) missionCommands.addCommandForGroup(Group_ID, "Su-33 1 Ship", spawn3, setFlags, {flag=124, val=true}) missionCommands.addCommandForGroup(Group_ID, "Su-33 2 Ship", spawn3, setFlags, {flag=185, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-14 1 Ship", spawn4, setFlags, {flag=125, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-14 2 Ship", spawn4, setFlags, {flag=182, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-18 1 Ship", spawn5, setFlags, {flag=126, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-18 2 Ship", spawn5, setFlags, {flag=183, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-15 1 Ship", spawn6, setFlags, {flag=127, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-15 2 Ship", spawn6, setFlags, {flag=186, val=true}) missionCommands.addCommandForGroup(Group_ID, "J=11A 1 Ship", spawn7, setFlags, {flag=130, val=true}) missionCommands.addCommandForGroup(Group_ID, "J=11A 2 Ship", spawn7, setFlags, {flag=190, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-5E 1 Ship", spawn8, setFlags, {flag=131, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-5E 2 Ship", spawn8, setFlags, {flag=189, val=true}) missionCommands.addCommandForGroup(Group_ID, "FW-190 1 Ship", spawn9, setFlags, {flag=132, val=true}) missionCommands.addCommandForGroup(Group_ID, "FW-190 2 Ship", spawn9, setFlags, {flag=191, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-16C 1 Ship", spawn10, setFlags, {flag=133, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-16C 2 Ship", spawn10, setFlags, {flag=187, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-4E 1 Ship", spawn11, setFlags, {flag=146, val=true}) missionCommands.addCommandForGroup(Group_ID, "F-4E 2 Ship", spawn11, setFlags, {flag=188, val=true}) end end

That flag will keep the last given value, so yup, it'll stay true unless you reset it. Here, you're looking for something like this: local function Scheduler_Function() local target = Group.getByName('player') if Group.getByName('RED1'):getController():isTargetDetected(target, 'RWR') == true then trigger.action.setUserFlag("1", true) elseif Group.getByName('RED1'):getController():isTargetDetected(target, 'RWR') ~= true then trigger.action.setUserFlag("1", 0) end return timer.getTime() + 5 end timer.scheduleFunction(Scheduler_Function, nil, timer.getTime() + 5)

You're missing the groupID (the first parameter must be the groupID, not the group object or name) I don't know how BVR_Blue_F18_1 is declared in your script, but if that's the name of the group in ME, you need to do something like this: local Group_ID = Group.getByName("BVR_Blue_F18_1"):getID() local spawn1 = missionCommands.addSubMenuForGroup(Group_ID ,"Spawn PVE") [color="Blue"]-- Maybe make this variable global? In case you want to remove this root submenu later on[/color] local spawn2 = missionCommands.addSubMenuForGroup(Group_ID ,"Mig-29s",spawn1) [color="Blue"]-- Maybe make this variable global? In case you want to remove this root submenu later on[/color] missionCommands.addCommandForGroup(Group_ID , "Mig 29 1 Ship", spawn2, setFlags, {flag=123, val=true}) missionCommands.addCommandForGroup(Group_ID , "Mig 29 2 Ship", spawn2, setFlags, {flag=184, val=true})

Sorry, I was half asleep when I replied, for some reason I automatically associated "crew chief" with "deck chief", so I assumed you were talking about static spawning on carriers (I guess I'm kind of traumatized by this :megalol: ) If you just want to spawn statics on the map (land, not sea or carriers) then it's totally doable. Keep in mind that static infantry (M4 soldier, in this case) is problematic, you won't be able to give it a custom name or mess around with its template parameters (much). It's one of the static types in my "black list". I seem to recall that MANPAD statics didn't give me such trouble... but perhaps I'm recalling it wrong, they might be a pita too :doh: (stay away from static infantry... use AI infantry instead) Many static ground vehicles, planes, helicopters and structures work (though there are exceptions as well). As for statics spawning at the origin of the map, that's probably because you aren't giving the custom static template the proper parameters. I can see that you're giving the p.y value to the y coordinate, that's wrong... give it the p.z value instead (2D y value is actually the 3D z value in DCS). Here, this custom static template table + DCS method worked for me: In any case, if the statics you're interested in spawning refuse to work with this method, you can always spawn uncontrolled units instead, using a custom group template (it's pretty much the same kind of method... but the template table is different). Because the Position3 table is actually made of several subtables, it looks like this:

Yes, S_EVENT_BIRTH definitely works. If you're trying to spawn a static on the deck of a carrier (I guess this is the case, since I see that you're using mist.dynAddStatic), I'm afraid I have bad news. I tried to do this sort of stuff while developing SWAPR, but I just couldn't make it work. Statics were spawned either at the bottom of the sea or not at all (even when linking the static to the carrier unit, forcing fixation and setting the offsets & angle via scripting). Unfortunately, looks like the only way of making statics appear on a carrier's deck is by using the ME interface (link unit and OFFSET FIXATION)... for now, looks like we have to accept this limitation in DCS. :cry: Helicopters and carrier-based planes (units) can be made to spawn via scripting (which is what SWAPR does, basically), but only if they are linked to specific parking spots on deck (sometimes it's trickier than that). As for infantry units (and ground vehicles), they can't be placed on the sea, so DCS won't even allow you to put them on a ship's deck. Even if you modify ground unit scripts ( gamedir\Scripts\Database\chassis ) to make them deployable on sea, they still won't be placed on the carrier's deck... they'll appear on the surface of the sea instead. And even if you modify some parameters to make these ground units appear ~20 meters above sea level (which is about the height of a carrier deck in DCS), they'll still clip through the carrier model, as if it weren't there. Also, this offset will apply to ALL ground units of the same type in the mission, which is pretty bad. Bottom line, I've already gone down this particular rabbit hole before... it led me to frustration and despair :badmood: Since we're talking about carriers (which move along the X and Z axes and change their heading), you'll need to use a transformation matrix. If you open the file Matrix33.lua ( gamedir\Scripts ), you'll see the transformation functions that DCS uses. I was looking into this stuff back in January and, fortunately, I didn't come out empty-handed ;) https://forums.eagle.ru/showpost.php?p=3764379&postcount=20 Funkyfranky ended up turning the script into a MOOSE method for POSITIONABLE class. If you're using MOOSE, the method is :GetOffsetCoordinate(x,y,z) (you'll need to use a relatively recent develop version of MOOSE, older versions don't include it). If you aren't using MOOSE, the script can be turned into standard DCS code quite easily. Also, if you're only interested in using it on ships, you can skip the Y axis transform altogether (that would be the rotation along the Z axis). EDIT: Grimes' method seems easier to work with, now that I've seen it. If it successfully transforms X and Y (which is actually Z in 3D space) based on bearing, that might be a simpler solution Sure, if you're only interested in knowing whether the birth unit is a player, you can use :getPlayerName() . If it returns nil, the initiator isn't a client / player, if not, then it must be a client.

I think that REL QTY is only meant to work for unguided weapons. I don't think amraams are meant to be fired in pairs.

@hancerPL If you want this to work with clients spawning at some point after mission start, you'll need to either use a scheduler or a birth event handler (I'd use the birth event handler if I were you)

Check that the given names are valid and also check dcs.log. You might be getting nil errors if the groups you're referencing in the script don't exist in the mission when the script runs. Also, keep in mind that flag 1100 is being set to 0 (when false) and to 1 (when true)

@hancerPL You need to create a for loop, which will iterate through that table. This is basic lua, here, you'll find these quite helpful: https://www.tutorialspoint.com/lua/lua_for_loop.htm http://lua-users.org/wiki/TablesTutorial Also check out Nicol Bolas' answer here (last example): https://stackoverflow.com/questions/7616260/for-loop-on-lua ZoneA = ZONE:New( "Zone A") GroupTable = { "MED #1", "MED #2", "MED #3" ,"MED #4" } for i, name in ipairs(GroupTable) do if GROUP:FindByName(name) ~= nil then if GROUP:FindByName(name):IsCompletelyInZone( ZoneA ) then Blu:Activate() Blu:FlareGreen() end end end

@Everyone The new version of SWAPR is officially out! New setup and demo videos in the OP! This new version brings important fixes, expanded support and new features to the table! [b]Changes:[/b] [list] [*]Fixed client spawn collisions (in both SP an MP) [*]Added support for multi-client groups [*]Hybrid design (script can be set to either "SP" or "MP" mode) [*]Added "Deck Cleanup" F10 menu for carrier-based clients [/list] [list] [*]Added support for clients based on the following vessels: [list] [*]Kuznetsov carrier (Su-33 & helos. PRK 1,2,3) [*]Vinson carrier (F-18C, F-14B, Harrier & helos. PRK 1,2,3,4 "Takeoff from runway" only) [*]Moskva cruiser (all helos, except for the Mi-8) [*]Type 054A frigate (all helos, except for the Mi-8) [*]Type 052B destroyer (all helos, except for the Mi-8) [*]Type 052C destroyer (all helos, except for the Mi-8) [*]Ticonderoga cruiser (all helos, except for the Mi-8) [*]Oliver Hazard Perry frigate (all helos, except for the Mi-8) [/list] [/list]

Whenever you need a fuel reading for the specified aircraft, just run the script using a trigger (Do script should take care of this).

@mono6020 I wouldn't trust that SET_GROUP ( OPFOR_EWRGroupB ) to update. I'd put it in a scheduler and make sure it's global, also, I'd use :FilterOnce() instead of FilterStart()...you might need to put everything in a scheduler, actually. Also, how are you spawning them? The spawning code doesn't seem to be included in the snippet (unless I'm missing something).