Wizard1393

Pressing FCS Reset button does not remove the caution "ADV-RSET" and there are not X's anywhere on the FCS page. But sounded like it could have worked.

Hopefully

Ok! So thats what it is then probably thanks! I've got a warthog too and never ever had to use any deadzones on it. Can anyone from ED or other knowledgable person comment on whether the AP BALT/RALT should require absolute zero stick input?

I'm confused by this AP. I've had BALT and RALT to work a few times, don't know how, but most of the time, it won't kick in. It starts the AP, showing the A/P notice in the HSI, but it does not engage any kind of alt hold and is not marked with the colon on the UFC. Am I missing something? I also get a warning/attention message in the HSI saying "AUTO PILOT". Are there certain criteria to have BALT working? Also, If the attitude selector switch is set to STBY as in using the Standby Attitude Indicator, I get a master caution saying "INS ATT". Liddle help here plz? :) EDIT: Also, once when I had BALT working and engaged at about a 1000ft, I switched to RALT and the plane violently pitched down causing a blackout and when I came to, I was in a ~20 deg dive and 100 feet to go to the ground.

Mine started downloading but stopped downloading at ~70% :( :(

That was it thanks. Had forgotten I reset the options recently.

Didnt this mod use to include english HUD symbology also? Currently getting engligh cockpit but cyrillic HUD on latest open beta.

On my MiST wishlist: When calling mist.respawnGroup, if the group to be respawned is set to late activation in the mission editor, it would be good if mist.respawnGroup removed the late activation attribute from the new cloned group. It causes several issues that attribute ["lateActivation"] seems to remain on a respawned (cloned) group.

Or, if you know how to use a command prompt: Start a command prompt. Navigate to DCS install directory and then into the folder "bin". Run command "DCS_updater.exe update @openbeta". Finished!

Q: Is it possible to modify the "Hidden"-property on existing units/groups via scripting? Or is that read-only and only definable on unit/group spawn?

I've set ctld.JTAC_lock = 'vehicle' but the JTAC Unit still targets troops sometimes seemingly if a troops group are closer than a group containing vehicles. Is this by design or something not working correctly? JTAC status states it has visual on ATMZ-5 which is a truck in another group, but lasing Soldier AK.

Here is the unofficial tutorial on DCS Lua Scripting

Hey Ciribob, if I haven't said it already, thanks for this magnificent script. Bugreport (I think): CTLD won't register a JTAC which has been respawned with mist.respawngroup. Looks like line 4935 "if _jtacGroup == nil or #_jtacGroup == 0 then" in fact returns nil or 0.

Yes there is: http://wiki.hoggit.us/view/DCS_event_takeoff EDIT: Well if you use the scripting engine. Not inside the ME no.

Hey Grimes, found a bug in mist. Function mist.getAvgGroupPos contains a loop with an erroneous # reference. for i = 1, #groupName:getSize() do table.insert(units, groupName.getUnit(i):getName()) end Should be: for i = 1, groupName:getSize() do table.insert(units, groupName.getUnit(i):getName()) end or for i = 1, #groupName:getUnits() do table.insert(units, groupName.getUnit(i):getName()) end Isnt it? However changing it to either one throws a "parameter #self missed" error though by the line table.insert(units, groupName.getUnit(i):getName()) Which I suppose should be: table.insert(units, groupName:getUnit(i):getName())

Thanks man! That did the trick! rikkles rep +10 :)

So I have this idea of a simple BDA check and I put destroyed unitTypeName in a table but I cant get the iteration to work right. What I want is a result like: Shilka: 2 Strela: 2 But I only get the last added table entry to display: Strela: 2 Below is my sample script. Extra outtexts in sample for checking that the adding to table works in game, and it does seem to. But what am I doing wrong with the iteration (last threee lines?) local BDA = {} local unitTypeName = 'Shilka' if not BDA[unitTypeName] then BDA = {[unitTypeName]=1} trigger.action.outText('Added new unittype ' .. unitTypeName .. ' to BDA count',3) else BDA = {[unitTypeName]=BDA[unitTypeName]+1} trigger.action.outText('Added existing unittype ' .. unitTypeName .. ' to BDA count',3) end if not BDA[unitTypeName] then BDA = {[unitTypeName]=1} trigger.action.outText('Added new unittype ' .. unitTypeName .. ' to BDA count',3) else BDA = {[unitTypeName]=BDA[unitTypeName]+1} trigger.action.outText('Added existing unittype ' .. unitTypeName .. ' to BDA count',3) end unitTypeName = 'Strela' if not BDA[unitTypeName] then BDA = {[unitTypeName]=1} trigger.action.outText('Added new unittype ' .. unitTypeName .. ' to BDA count',3) else BDA = {[unitTypeName]=BDA[unitTypeName]+1} trigger.action.outText('Added existing unittype ' .. unitTypeName .. ' to BDA count',3) end if not BDA[unitTypeName] then BDA = {[unitTypeName]=1} trigger.action.outText('Added new unittype ' .. unitTypeName .. ' to BDA count',3) else BDA = {[unitTypeName]=BDA[unitTypeName]+1} trigger.action.outText('Added existing unittype ' .. unitTypeName .. ' to BDA count',3) end for k,v in pairs(BDA) do trigger.action.outText(k .. ': ' .. v,5) end

I dont think uncontrolled aircraft use much CPU at all. The proposed performance drop you see is more likely attributed to the fact that you have spawned close to many visible aircraft. Even though they are uncontrolled, many models are quite detailed and require a lot of GPU processing to draw if they are in substantial numbers.

Ok thanks for info. I tried adding the eventhandler in a separate Initialization Script, hoping it would load the event handler before the player enters the unit, but it seems like Init scrips are still not working/executing, is this correct?

Don't know if it's a bug or if this event is aimed only at MP. Scenario: SP mission Multiple player roles/aircraft to choose from, set to "Client" in the ME. On mission load, the player is presented with slot selection screen. Player chooses any playable slot and world.event.S_EVENT_PLAYER_ENTER_UNIT is not fired. It fires if thereafter the player changes slot, or if the spectator slot is chosen first and then change to a playable slot.

Awesome, thanks. Good to know.

Bumpitty :)

I want to implement a menu command that orders an AI aircraft (not in player group) basically to RTB by switching waypoint to the one before landing. I have a SwitchWaypoint Waypoint Action in the ME on WPT 3 that switches waypoint to 2 so there's basically a racetrack orbit between 3 and 2. So heres my code: local uziUnit local uziController uziController = Unit.getByName(unitName):getController() local SwitchWaypoint = { id = 'SwitchWaypoint', params = { fromWaypointIndex = 4, goToWaypointIndex = 5, } } uziController:setCommand(SwitchWaypoint) As i understand it, the aircraft should end up at waypoint 5 and the continue following route to landing. However, nothing happens at all. Anyone know what's what?

Which way is better to work with event handlers? Performance wise? One Event Handler with many iterations of if Event.id == this_event then do this elseif Event.id == that_event then do that end or e.g. one event handler / event? Landing_Event_Handler = {} world.addEventHandler(Landing_Event_Handler) Takeoff_Event_Handler = {} world.addEventHandler(Takeoff_Event_Handler) and then not having to have so many "if" iterations...?

I had just reached the target, fired rockets, was beginning turn off target, then crash. Attached crash log. Track removed because 30MB. Can supply on request. EDIT 1: Another crash. Same mission. Fired rockets at bridge, off target, burn for home for ~1 minute, got shot down by SAM, then crash. Almost exactly same error in log, referring to EdCore.dll. See log 210033. Track removed because 30MB. Can supply on request. dcs.log-20180501-194034.zip dcs.log-20180501-210033.zip