Hardcard

Depends. You can use moving landing zones in ME, combined with altitude checks... but this is quite unreliable. If you're not afraid of scripting, then you can use the script examples below. If it's a carrier / warship, you can use landing event handlers, like so: https://forums.eagle.ru/showpost.php?p=3754920&postcount=2 If it's a cargo ship, it's trickier, but can still be done: https://forums.eagle.ru/showpost.php?p=3763018&postcount=16

@Grimes Yup, somehow I managed to forget that the variable already contained the position subtable, :doh: Thanks bud!

@Grimes To make sure the explosion happens at sea level, shouldn't we set the y value from the position subtable, rather than the orientation subtable? pelican42_vector.[b]p[/b].y = 0

@Neon Please provide the mission file. Also, in case it was running on a dedicated server, provide the server hook and the dcs.log from that session as well. I'll look into it, but, from your description, looks like replacements aren't being removed when clients spawn (possible scripting error along the way)

@ghashpl That snippet will only target a single unit... the moment you switch clients, it'll stop working. I think this MOOSE script will serve you better (required fields marked in red, don't remove any quotation marks): local function Get_Player_Unit(Player_Name) local Client_SET = SET_CLIENT:New():FilterActive(Active):FilterOnce() Client_SET:ForEachClient( function(Client) if Client:GetPlayerName() then if Client:GetPlayerName() == Player_Name then trigger.action.outText(Client:GetName().." is controlled by player "..Player_Name, 10) local MOOSE_Object = UNIT:FindByName( Client:GetName() ) local DCS_Object = Unit.getByName( Client:GetName() ) return MOOSE_Object , DCS_Object end end end ) end [color="blue"]-- The following variable will contain the unit that the specified player is controlling (if any). MOOSE_Unit is the MOOSE unit object, DCS_Unit is the standard DCS unit object[/color] local MOOSE_Unit , DCS_Unit = Get_Player_Unit("[color="Red"]Player name[/color]") [color="Blue"]-- Then we use another function to get the distance between the player and a specified object on demand[/color] local function Get_Distance(Player , Object_Name) if Player and UNIT:FindByName(Object_Name) then local Object_2_Measure = UNIT:FindByName(Object_Name) local Object_Coord = Object_2_Measure:GetCoordinate() local Player_Coord = Player:GetCoordinate() local Distance = Player_Coord:Get2DDistance(Object_Coord) trigger.action.outText(Object_Name.." distance to player (meters) = "..Distance, 10) return Distance end end Get_Distance(MOOSE_Unit , "[color="red"]Name of the unit whose distance you want to know[/color]") [color="Blue"]-- This will return distance in meters between the player's unit and the specified object[/color] Remember, you'll need to load Moose.lua first, otherwise this script won't work

Last time I checked, scenery could only be removed via ME (using SCENERY REMOVE OBJECTS ZONE) I tried to remove scenery objects via scripting, to no avail. The most I could do was detect certain scenery objects... :destroy() didn't work on them.

If you want to apply custom loadout restrictions to different planes, I'm afraid you'll have to script it.

Custom flag names can be assigned as long as they are scripted. But, anyway, even if you're working with ME flags (which have a number as name), the server script I posted would still work...just give the ME flag number as name. The only thing that's missing in the script are the specific slot checks (in case the user is only interested in blocking specific slots when the base is captured)

@Markeebo The first error suggests that either the string value you provided is invalid or the folder doesn't exist. I recommend that you contact Funkyfranky over the MOOSE Discord channel, he wrote AIRBOSS.

@remus77 I think it would be simpler to write your own dedicated server script. Keep in mind that the server can only communicate with the mission environment via user flags (well, at least that's the simplest approach). First off, you need a way to signal when the base has been captured, I'd use a flag for this (handled by either ME trigger or script, your choice). You could then have the dedicated server script check the value of said flag... if the flag has an arbitrary "base captured" value, kick the joining player back to spectators. Here's the idea (required fields marked in red, do not remove any quotation marks): local Callback_Table = {} [color="blue"]-- A callback table is required for the script to work[/color] function Callback_Table.onGameEvent(eventName, playerID, slotID) [color="blue"]-- This function will be called every time a server event happens[/color] if eventName == "change_slot" and slotID ~= nil and slotID ~= '' and playerID ~= nil then [color="blue"]-- Check whether a player has changed slot, check whether it's a spectator slot, also, check for nil values[/color] if net.dostring_in('server', " return trigger.misc.getUserFlag(\"[color="Red"]Flag name[/color]\"); ") ~= nil then local CaptureFlag = net.dostring_in('server', " return trigger.misc.getUserFlag(\"[color="Red"]Flag name[/color]\"); ") [color="blue"]-- Makes the server return the value of a mission environment flag[/color] if CaptureFlag == "[color="Red"]Flag value when base is captured[/color]" then [color="Blue"]-- Checks whether the flag has the "base captured" value[/color] local Player_List = net.get_player_list() for PlayerIDIndex, playerId in pairs( Player_List ) do local Player_Info = net.get_player_info( playerId ) if Player_Info.slot == slotID and playerID == playerId then net.force_player_slot(playerId, 0, '') [color="Blue"]-- This forces the player attempting to enter the blocked slot back to spectators[/color] net.send_chat_to(Unit_Name.." DISABLED!", playerId) net.send_chat_to("CHOOSE ANOTHER SLOT!", playerId) end end end end end end DCS.setUserCallbacks(Callback_Table ) Btw, this dedicated server script must be placed in C:\Users\Your Username\Saved Games\DCS.openbeta\Scripts\Hooks

That's weird :huh: I think it's just a matter of including this in missionConfig.lua local alertLevel = "HIGH" function getAlertLevel() return alertLevel end As long as missionConfig.lua is loaded in the mission, I think you should be able to call getAlertLevel() from any other script and get the string value as return getAlertLevel() I don't see why it shouldn't work... as I understand it, this is what frameworks like MIST and MOOSE do all the time.

Please, post your mission file here. Also, did this happen in a MP environment? If so, were you hosting or connecting to a dedicated server? Also, did you get scripting errors in dcs.log? If so, could you post dcs.log as well?

Alright, that's both weird and potentially useful. So, in the end, the answer is to combine isActive and isExist, right? units[i]:isActive() and units[i]:isExist() I'll need to keep this one in mind, thanks for the info! :thumbup:

@SkipperSMG Did you get any errors in dcs.log? Also, could you post the mission file here? Sorry for the late reply.

This is weird ... :huh: What about getPosition() ? Does it actually return numeric values if you do something like: if Group.getByName(group) then local grp = Group.getByName(group) local grpunit = grp:getUnit(1) local pos_1 = grpunit:getPosition() Wrench_Log:msg(pos_1.x.x) Wrench_Log:msg(pos_1.x.y) Wrench_Log:msg(pos_1.x.z) Wrench_Log:msg(pos_1.y.x) Wrench_Log:msg(pos_1.y.y) Wrench_Log:msg(pos_1.y.z) Wrench_Log:msg(pos_1.z.x) Wrench_Log:msg(pos_1.z.y) Wrench_Log:msg(pos_1.z.z) end I mean, if it returns orientation values for units that haven't been spawned, it won't make any sense to me :cry:

Welcome to DCS ;) Learning to script may be a pita at first, but it's definitely worth the effort. I found myself in a similar situation last year (ME had all sorts of limitations I simply couldn't accept), so I decided to learn some Lua and MOOSE instead of wasting my time with ME. In hindsight, it was undoubtedly the right decision. MOOSE is easier to learn than MIST, since it's much better documented. Here, check out this post, it contains useful links. Also, here's a Lua tutorial it'll help you learn the basics of Lua.

@BoneDust The dcs.log errors that you posted here clearly referenced pretty large script files of, at least, 20k - 90k lines... the temporary script file that you uploaded isn't any of those. Aren't you getting those errors anymore? Could you please post your dcs.log (so we can see the errors you're getting) + all the temporary script files referenced in those errors? If you have changed the script now and you're not longer getting errors, please post your new script file as well, so we can see the differences.

@BoneDust Please, get the temporary script file(s) referenced in the dcs.log error(s) (following the steps I explained) and upload it/them here. It might very well be that you have the wrong Moose.lua file loaded in your mission.

@Wrench What you report is both weird and disturbing. Have you tried using Unit class instead of Group class? This works for me (apparently, at least): if Unit.getByName(unitname) == nil or Unit:isExist() == false then [color="Blue"]-- Respawn the unit because it's dead[/color] end Also, in case you absolutely must use Group class and none of the stuff Grimes proposed really works, I guess you could try silly stuff like: local function Group_Alive_Check(GroupName) local Group_2_Check = Group.getByName(GroupName) local Initial_Size = Group_2_Check:getInitialSize() Ded_Count = 0 for i , unit in pairs (Group_2_Check:getUnits()) do [color="Blue"]-- Here I'm assuming that [i][b]getUnits[/b][/i] will return a table containing all units in the group, regardless of whether they're dead[/color] if unit:getPoint() == nil then Ded_Count = Ded_Count + 1 end end if Ded_Count == Initial_Size then [color="Blue"] -- The group is definitely dead[/color] end end

@BoneDust You're getting different kinds of errors there (they might have a common cause, though). I'd say that the script that's erroring is probably Moose.lua, but I can't be sure. Go to C:\Users\dwigh\AppData\Local\Temp\DCS.openbeta and see if you can find the temporary lua file called ~mis00001EAF.lua (Btw, the folder AppData is hidden by default in Windows, you'll need to make it visible by checking "Hidden items") If you find it, make a copy of it and post it here. However, it's quite likely that the temporary lua file ~mis00001EAF.lua has been automatically removed from your pc at this point, but you can always rerun your script in DCS while checking dcs.log, you'll get the errors again and new temporary lua files will be generated in that same folder (make a copy of the referenced lua file(s) BEFORE closing DCS). When you check the errors in dcs.log, pay attention to the following info: Simply post a copy of the temporary script file referenced in the error(s). On another note, after a quick look at your script, I've noticed some potential issues (I might be wrong, ofc):

@BoneDust Post the script file that's erroring (should be specified in the dcs.log error, along with the line)

@Rudel_chw :D

Hi there DCS people! A couple months ago I started working on this nice little project, which has grown into a pretty interesting addition to DCS (I think). I'm creating this thread over here to let you know about it and keep you posted on future changes. SWAPR (SWeet Automatic Player Replacement) is a script I wrote for DCS, here's a list of features: SWAPR automatically generates replacements for any number of chosen clients SWAPR handles dynamic spawning and removal of replacements as players enter and leave their respective client slots SWAPR offers several customization options, so users can adapt the script to their specific needs As of version 1.2, SWAPR also includes an optional slot block feature for MP, which will block client slots if their respective replacements are destroyed (this unlocks a ton of cool gameplay possibilities in MP) SWAPR works in all DCS maps SWAPR supports all flyable airframes SWAPR will work with clients based on: Airbases FARPs Open terrain Kuznetsov carrier Carl Vinson carrier Moskva cruiser Type 054A frigate Type 052B destroyer Type 052C destroyer Ticonderoga cruiser Oliver Hazard Perry frigate SWAPR can be integrated in existing missions SWAPR is pretty easy to set up and use Demo video: Slot Block demo video: You'll find all the relevant information, notes and download links here ---> Official SWAPR thread

@Everyone Alright boys and girls... SWAPR 1.2 is finally here and it brings slot block with it! :cheer3nc: :drunk: :yay: OP updated with new videos, timestamps, notes, changelog and links [b]Changes:[/b] [list] [*][b]09-20-2019[/b] [list] [*]SWAPR PnP Hybrid v1.2 released! [list] [*]Slot block implemented! (MP only, definitely check it out!) [*]Fixed a problem which caused static replacements to miss the original client's heading on spawn [*]Fixed the problem of helo replacements spawning half-buried on FARPs [*]Fixed the problem of harrier replacements spawning half-buried in airbase areas (but not on FARPs... it's DCS' fault!!! :cry:) [*]Fixed weird issue of single helipads being incorrectly identified as ship airbase objects [*]Improved replacement checks [/list] [/list] [/list] Big thanks to Funkyfranky for the great idea and to Ciribob, Pikes, Wingthor, Rudel, etc. for their invaluable help! :thumbup:

If ME doesn't allow you to select naval groups when trying to set an AFAC, you'll need to use a script instead. I wrote one such script a while ago, you might find it helpful, it's attached below. It's a MOOSE script, though, so you'll need to load Moose.lua first, otherwise it won't work. You'll need to set it up as well (fields marked in red are required, do not remove any quotation marks): Now, this script will only work for a single AFAC unit, if you lose it, game over (also, the AFAC unit must be alive when you run the script, otherwise it won't work). It's all handled via F10 menu, all clients in the same coalition as the AFAC unit should have access to it. Universal Buddy Lasing script test (event BIRTH).lua