Hardcard

@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.

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):