esb77

On page 194 of the manual, English language version: "Moving the TDC over the target brick and pressing the SCS in the direction of the MPCD will command acquisition of the target. Releasing the SCS will command track. The radar mode will change to Ground Moving Target Track (GMTT) and additional target information will be displayed: " This is incorrect. To select GMTT one must move the TDC over the target brick and press the SCS in "out of cockpit" direction. Left if on the left DDI, right if on the right DDI, and down/aft if on the MPCD.

Combined arms vehicles driven by players appear to have changed their handling behavior significantly. They handle as if the spring rate is much softer, spring travel is longer, and damping is greatly decreased. Coefficient of friction on most terrain also appears to be significantly reduced. These are parameters that probably needed to be adjusted in those directions somewhat, but the current iteration appears to be excessive. The results are often quite comical, but it should probably be dialed back a little bit.

When a player in a JTAC slot is controlling a Tunguska in the driver or gunner slots the radar display does not show airborne targets.

So I was not super satisfied with previous suggestions, including my own, and set out to try to do a decent way to seed math.randomseed() in the DCS Scripting Environment. The TLDR that surprised me a bit is: "Don't worry, be happy. math.randomseed() appears to be broken in the DCS scripting engine because it has been replaced by something custom behind the scenes. If LUA scares you use the trigger system ACTION FLAG SET RANDOM VALUE (min, max) to generate a random number between min and max (inclusive), or if you are comfortable with LUA just use math.random() because it is pre-seeded, and math.randomseed() is broken so you can't use a custom seed anyway. Trying to get a good seed for math.randomseed() appears to be totally irrelevant in the DCS Simulation Scripting Environment, because as far as I can tell math.randomseed() is broken there. If you pass it either an integer variable, or even just an integer number, it throws an error saying that randomseed is a field with a nil value. I did some test code, and what works in standard LUA doesn't work in DCS, and what works in DCS doesn't work in standard LUA. It appears that math.randomseed has been replaced by something custom in DCS, so what you need to do is either use a Flag Set Random Value to get a random number, or just use math.random without math.randomseed in LUA code for DCS. This seedNumber = 1426 math.randomseed(seedNumber) print(math.random()) seedNumber = 2753 math.randomseed(seedNumber) print(math.random()) seedNumber = 2753 math.randomseed(seedNumber) print("Seed Number 2753 results:") print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) seedNumber = 1426 print("Seed Number 1426 results:") math.randomseed(seedNumber) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) Produces this in LUA 0.11670539583512 0.50927697496681 Seed Number 2753 results: 7 4 5 Seed Number 1426 results: 5 6 5 1 3 3 3 5 7 7 9 math.randomseed(integerVariable) works as expected. In DCS this -- Random seeder, requires on mission start triggers that --1: Use an action set random flag to set a flag called seedPickFLat to a default of zero **deprecated you can just use step 2 --2: Use a Flag Set Random Value action to set seedPickFlag to a range from 1 to 16 randomLookUp16 = {1426, 2753, 6999, 9779, 5702, 6384, 9497, 2072, 7419, 1545, 1302, 6354, 4985, 1997, 4395, 3717} --table of 16 theoretically truly random numbers seedPick = (trigger.misc.getUserFlag("seedPickFlag")) --gets a random number from the flag and assigns it to a variable to pick a key from the lookup table trigger.action.outText( "seedPick is " .. seedPick, 20, false) --test message, comment out after validation seedNumber = randomLookUp16[seedPick] --sets seedNumber equal to the value for the selected key in the lookup table trigger.action.outText("seed Number is: " .. seedNumber, 20, false) --test message, shows contents of seedNumber variable, comment out after validation math.randomseed(seedNumber) -- intended to seed random number generator, Actual effect is to throw error: randomseed is a nil field. Works in that using a Flag Set Random Value (1, 16) will generate a random key, and select a number from the lookup table of seed numbers, but when you try to use that number assigned to a variable math.randomseed(integerVariable) throws an error saying randomseed is a nil field. Literally cutting and pasting working code from a LUA compiler gives that result. Valid input causes an error. Cut and paste that input from DCS to LUA and then math.randomseed() works as expected. My conclusion therefore is that if math.randomseed() from LUA still exists in DCS it is now behind the wall and cannot be accessed by normal users. It doesn't matter though, because they appear to have set things up so that math.randomseed( os.time() ) or something equivalent gets run automatically before math.random(), so all your random numbers in DCS scripts are correctly seeded, whether you want them to be or not. So we get convenience and security in one tidy little package. I'm not sure if I should feel happy or insulted that they idiot-proofed it so much that even I can't mess it up.

Thanks for posting this. I'm not to the point where most of my scripts would run afoul of this (I think) in terms of script complexity, but it's very valuable to start getting an outline of where minefields of new bugs might arise from the dynamic slots. Of course, I'll probably forget and run face first into some avoidable dynamic slot bugs anyway, but maybe when that happens after I've spent a few hours of frustration I'll remember your post and get myself unstuck. That's how it usually works for me, "Why couldn't I have remembered this earlier?"

F-15 E latest update triggered Norton antivirus on my machine and it helpfully removed ARF.dll from the F-15 module with bothering to ask me. Cited the threat as Trojan.Gen.MBT

If making a multiplayer mission with a client delayed activation group, if you call .activateGroup it can't activate the client group because the group table doesn't exist yet. There are workarounds, but the amount of workaround needed to perform a fairly basic mission function, spawning a player controlled group at a specified time or condition, is pretty ridiculous. If you're asking a mission maker, "What's a fairly challenging scripting task," I would argue that, "Spawning a player controlled unit in a multiplayer mission," should absolutely not be an answer to that question. Ideally, .activateGroup would just work when fed from Group.getByName(groupname) with no other intermediate steps needed, but there are legitimate reasons one might not want to create a group table for a group that may never be occupied. A method to look up a delayed activation unit placed in the Mission Editor and take its name to generate a group table that .activateGroup can take as input would be a reasonable intermediate solution. More generally, the biggest criticism I have of the Mission Editor and DCS Scripting Environment is inconsistent behavior across single player and multiplayer missions, and limitations of methods where the limitations are obscure and difficult to figure out. Using delayed activation and .activate as examples, if they were called SinglePlayerAI_UnitDelayedActivation and .activateSPDelayedGroup, then I'd have less of a problem with them. They'd then consistently and reliably do what they say they do, and instead of generating grumpy mission coders wondering "Why does this method not work," you'd instead get requests along the line of, "Hey, that's a nice function, do you think you could make a multiplayer version too?" I know that there's good reason not to change names of existing methods to avoid, so making an effort to upgrade existing methods that aren't general in how they act across SP an MP to be general would be good, and then going forward, if new limited use methods are created, reflect that in the naming. Then if they are later upgraded the upgraded version can be named without an indication that it's limited scope.

So in scouring for more info I found a solution: migGroupFromTable = migGroupsToActivate[1] nextMigGroup = Group.getByName(migGroupFromTable) nextMigGroup:activate() That does what I want, grabs a value from a table, and activates the group with that name. But I still don't understand why the general structure of: trigger.action.activateGroup("groupName") --or trigger.action.activateGroup(stringVariable) -- where stringVariable == "groupName" doesn't do basically the same thing. I'll look into it some more, because if trigger.action.activateGroup(Group) actually wants the group mission ID number, or the GUID number of the group and not the name, then I'm doing my most frequent ME script bug of wrong format of input into a function. I probably also need to go back and look up the difference between . and : in LUA, which I looked up two days ago and have already forgotten. Something about functions that pass self as the first parameter I think. I'll update if I manage to un-confuse myself. I managed to get it to work with this --Modifying it again, trying trigger.action: trigger.action.outText("testing activate method", 20, false) migGroupFromTable = migGroupsToActivate[1] trigger.action.outText(migGroupFromTable, 20, false) nextMigGroup = Group.getByName(migGroupFromTable) trigger.action.activateGroup(nextMigGroup) trigger.action.outText("Group getbyname got: " .. nextMigGroup, 20, false) which throws and error on the final outText and I think reveals my problem. trigger.action.activateGroup wants the Group object table, not the Group name string. Using .getByName gets the right input, and with that it works.

I've got a mission I'm working on where I'm trying to have delayed activation client aircraft. I've done missions before where I've used the ME triggers to do this successfully, but the conditions are more complicated, and ideally I'd like to spawn in up to 60 or so units and therefore I'd rather do the activation with a script, instead of creating a massive amount of triggers in ME. So my approach so far as been: Create a table of groups to spawn in a ONCE At Mission Start trigger. --migSpawn Test code -- objective: assuming that a global variable named mig29ActivationIndex has been initialized with a value of zero at mission start -- have a reapeating trigger activate a series of delayed start groups in response to a specific condition -- and display a counter of how many groups have been activated so far. --Create an integer indexed table with the names of the groups that are to be spawned, note for performance reasons this probably shouldn't be in a reapeating trigger in the actual mission, create the table in an initialization trigger and make the table global migGroupsToActivate = {} --table with names of mig groups to activate. local groupRootName = "Mig " local numbGroupsInTable = 5 -- enter how many groups of migs are to be delayed activated in the mission local groupIndexStart = 1 local indexValue = 1 --if the table values are Root_i this is the value of the current subscript for increment = groupIndexStart, numbGroupsInTable, 1 do -- starting at the index start, stopping when the index is equal to numbGroupsInTable with a step size of one table.insert(migGroupsToActivate, groupRootName .. indexValue) -- in table migGroupsToActivate for the next integer key enter the value groupRootName concatenated with the current indexValue indexValue = indexValue + 1 end local tableValueTest = migGroupsToActivate[4] trigger.action.outText(tableValueTest, 20, false) --checking that the table of mig groups exists and has valid value fields This part seems to be working. I get returns from the outText action that look like what I expect them to. Then in a separate trigger I have an if then structure to examine a global variable, and if true, advance a counter that starts at 0, and then activate the group from the table of group names along with a message to let me (and eventually players in the mission) know that the unit has been activated and is available. if speedViolation > 1 then --if a speeder was detected in the speed monitoring section mig29ActivationIndex = mig29ActivationIndex + 1 --increment the global variable that counts the index of how many mig groups have been activated. trigger.action.outText("Activation index = " .. mig29ActivationIndex, 20, false) --debugging line, test that index is advancing properly local nextMigGroup = migGroupsToActivate[mig29ActivationIndex] --use the mig index as an input to find the i th group in the mig groups table trigger.action.outText(nextMigGroup, 20, false) --debugging did I capture the value from the groups table trigger.action.activateGroup(nextMigGroup) --activate that group trigger.action.outText("Mig 29 unit: " .. mig29ActivationIndex .. " activated.", 20, false) --message players that the group has been activated. speedViolation = 0 -- reset the speed violation variable for the next monitoring loop. end It didn't work of course, which is how all my lines of code normally start out. I have debugged as far as trigger.action.activateGroup(nextMigGroup) and everything up to there seems to be working as I expect. I didn't entirely understand the error message: So I made a new mission, set up a ONCE trigger, TIME MORE (10) condition, and Do Script trigger.action.activateGroup("Aerial-1") to have the simplest possible version of the activate script, and I get this So having tried to simplify this as much as possible, it looks to me like when I use trigger.action and append .activateGroup to it, DCS looks for a method called "activate" and can't find it? So the questions are: Am I interpreting that error correctly? and How do I help the scripting environment find the activateGroup method? I'm getting reasonably good at figuring out how my incorrect input types make script functions not work (I get lots of practice), but not being able to call a script function is a first for me, and I'm not quite sure how to approach debugging that. I'm working off of https://wiki.hoggitworld.com/view/DCS_func_activateGroup this as documentation for activateGroups.

This is how it works for me. I'm starting to get to the point where I can feel those first four slices shrinking though. Also to the point where I can start doing things the canned scripts in the ME either can't do, or can do but would be tedious beyond belief to create triggers for every unit instead of just using a loop in a custom script.

System failures in MP would indeed be lovely. Having more parts of the systems/damage models hooked up would be nice too. Things like broken rudders, flaps, ailerons, airbrakes, etc. There are lots of things you can break with bad flying or from weapon hits that the failures system doesn't capture.

Does anyone know how exactly this reads the file structure for loading the misison? I.e. static or relative? Trying to figure out if there are going to be issues loading with this trigger if the mission is moved between computers with different file structures. If the target file in the ME trigger action dialogue box is: SampleReloadMission.miz will changes in the bolded section below cause problems? C:\Users\Myusername\Saved Games\DCS.openbeta\Missions\NewMP_MissionsTestFolder\SampleReloadMission.miz It's going from my personal computer to someone else's dedicated server, so some differences in the file hierarchy are likely, for example they won't have the mess of folders where I sort different new, old, and under construction, MP, and SP mission files,

Did you change it from a single player mission with the plane controller designated as Player to a multiplayer mission with the plane controller designated as Client at some point? The AI not shooting at you below a certain hitpoint threshold is a known issue in multiplayer missions. I haven't checked recently to see if it's working that way in single player too right now.

Hm, well I'm not sure if the server in question will have SSB or not, so I was thinking of primarily solutions that could be implemented in the .miz. I didn't know that the hook scripts were a separate category that needed to be implemented in .lua files in a particular spot in the server's install directory in order to be loaded and used. Thank you very, very much for pointing that out Dangerzone and cfrag, it's a huge minefield that would have had me very frustrated at, "why is all this cool stuff not working for me." In checking out hooks and a brief overview of how they work, I stumbled across documentation for the DCS Singleton net. Which has the force slot script. Apparently added in 2.7.6, so pretty new. So option 3, or a 2 & 3 hybrid look doable even stand-alone. Just need to make sure I follow the Singleton documentation, and not the Hook documentation, though I'm not sure if there's actually any difference. I'm sure SSB is the quickest, easiest and most reliable approach, and that'll be my backup plan, but I think I'll have a go at seeing if I can get the behavior I want from inside .miz file. At this point, even when I try things that fail, I'm learning so much from each failure that it's sort of worth it, and I fail enough that an extra failure or two doesn't really slow me down much because I'm already so slow. I'll try to remember to post an update here once I've got results of some sort. Thanks for taking a look, and for the advice.

I think it can be done, probably in multiple ways, but I don't know enough to tell the difference between good ways and bad ways. Desired behavior in a MP mission: On no-fly-zone violation (any of coalitionA in zone), for each violation v1, v2, . . . ,vn, spawn one Coalition B fighter client slot, parking hot, with a specific payload. If one of these client fighters dies or lands, it should not be able to respawn/rearm. Basically I want a single-use player controlled aircraft slot to spawn based on a trigger, and become unavailable again once the player is done with it. I'm considering 3 different approaches to solving this, and if anyone has good advice on one of them being obviously better than the others, or all being terrible compared to option 4 that I've never heard of, I'd appreciate any guidance. I'm only about 10 days into the script/LUA rabbit hole, an I'm still not sure I've found a complete set of documentation yet (have Grimes's wiki and learned about script/Hooks docs in DCS install from looking at Ciribob's SSB mod). Oh, and of course the LUA project wiki. Approach 1 Base all the desired units at one airfield and increment warehouse weapon amounts on each violation. This just controls missile numbers, doesn't worry about number of planes or whether they can respawn, but unarmed sorties aren't that effective so it should have the same effect more or less. Haven't yet found any DCSscripts that look like they can be easily combined into a LUA script to increment/set the number of available rounds of a specific weapon as a trigger action. Possible workaround, spawn AI units on short final and hope they despawn correctly after landing so that DCS increments their payload into the warehouse. Sources have mixed reports on if this works, I haven't tested yet. Approach 2 Activate - deactivate groups. CoalitionA unit entering zone sets flag v_i, i=1,2,3,... Switched condition Flag v_i activates delayed activation group g_i with single unit with desired payload. Switched conditon Flag g_i monitors, death, crash, or landing and deactivates group g_i if Flag g_i = true. Activation works for me, deactivation is very inconsistent, not sure why, though single player, fly option from Mission Editor, and MP server all seem to behave differently maybe? Need to test more, but I have problems where I'm able to spawn back into a group that should be deactivated. Also having a player in the plane seems to prevent deactivation. Sure, explode unit can solve that, but it's not an elegant solution in terms of wreckage on taxiways/runways. Approach 3 Steal from the last few lines of Ciribob's- Simple Slot Blocking, ie. use the net.force_player_slot(playerID, sideID, slotID) -> boolean to force kick to spectator in MP, to just boot players out of the slot with a message explaining it's unavailable if flags monitoring whether or not the aircraft has been used are true and the death/landing/despawn flag(s) are also true. Using the kick function from 3 also seems like it might be an option for making 2 work more consistently. Any thoughts?