Hardcard

{} need to be used, since it's a table. Tbh, it looks weird to me too, since I'm used to functions relying on () for parameters... but then again, I'm pretty lost when it comes to MIST :cry: @ENO Contact Grimes, he'll have the answer for you. Wild (perhaps even foolish) idea... have you tried this? I've seen that the MIST documentation examples use {} only, so I don't think () are required... but there's no harm in trying. (Also, triple check that all your unit names are correct, like feefifofum suggested) Do you absolutely need to use MIST for this, though? I'm not familiar with MIST, but I know my way around MOOSE. If all you need are zone checks for specific client units, this can done with MOOSE.

@Tonmeister Off the top of my head (without having actually tested it), I'd start by doing the following: In Mission Editor: - Create a bunch of late activated AI CAP groups (4 units each). If you want to, give them waypoints and tasks as well. - Give all relevant clients a common prefix in their unit names (EDIT: No need to do this, just ignore it) In the MOOSE script: - Define a set that targets all relevant clients (you can use a prefix filter for this). - Define the AI CAP groups as SPAWN objects - You can then use a scheduler to periodically check the number of relevant clients that are currently active - Create a scheduled spawn logic for the AI CAP groups, based on number of active clients - You can use :InitLimit() in order to limit the number of AI CAP units spawned (it can also be used to make them respawn) - Decide how do you want to trigger the scheduler (for instance, you could use a coalition F10 menu for this) Script example: As I said, this is just off the top of my head, there might be simpler/better ways of achieving the same goal (using AI dispatchers, for instance)... also, it's pretty raw, you'd need to polish it. EDIT: After some testing, looks like the prefix filter is causing problems with the unit count, so use the active filter only (it seems to work fine). Also, use SET_CLIENT instead of SET_UNIT.

It's the Hoggit discord channel (scripting section) https://discordapp.com/invite/hoggit

We all get those internal error messages, just ignore them. The important thing is that you get intellisense working.

Lua is a scripting language, MOOSE is just a scripting framework for DCS, which is built on Lua.

Guys, that is the link. Moose.lua = include version of MOOSE that you'll need to add to every mission (if you plan on using MOOSE scripts in it) Source code (zip) = files needed to set up MOOSE in LDT (the zip contains a different Moose.lua, which is NOT meant to be included in your missions) Watch to set it up in LDT. In fact, I recommend that you watch the entire YT series.

I don't think there's such task for ground units, however, there are ways to work around this problem. For instance, if the other unit is an aircraft, you could make the ground unit adopt a red alarm state only when that aircraft is in zone. The problem, of course, would be that any other valid target would be attacked as well in that instant. There might be other (better) ways of doing this, mind you, I simply ignore them :D If the other unit is a ground unit / ship, however, it can be individually targeted using :fireAtPoint . Get the vec2 of the target unit and use it as the point value within the task table, push the task after that and you're done. Keep in mind that ground units won't attack other units unless they're within LOS and range.

One of the perks of scripting is that it allows you to work with sets of clients, units, groups, statics, zones, etc. Another perk is that script snippets can be copy-pasted in a blink, so you can use them in other missions without having to start from scratch. Scripting is an accumulative activity, so to speak, every script you write becomes part of your personal "scripting toolbox". The more you script, the better your "toolbox" becomes... script for long enough and you'll end up having code snippets for pretty much every situation. Regarding fuel/chaff/flare amount, I don't know of a way to set them using scripts, I think they need to be set using ME. Regarding orbit tasks, ROE and Alert states, those can be set using scripts, for whole sets of units/groups at a time.

In other words, you want to trace DCS scripting engine activity. I've only used tracing in MOOSE scripts, so I have no idea if/how DCS scripting engine processes can be traced. Anyway, even if you could trace it all and find the problems, there's little you could do about them in ME (sure, you could try finding workarounds within ME, that's about it). The problems you described are the sort of thing that make people learn scripting (myself included). Regarding the troop pickup problem, the ME trigger might be capped or maybe there's a trigger conflict somewhere. Regarding the runway bombing task, it requires unguided bombs and you also need to specify attack quantity. If the attacking plane(s) don't have compatible weapons (unguided bombs), they'll simply RTB. Regarding wingman behaviour, it's often problematic in DCS. Sometimes wingmen will RTB even if all task requirements are met... in such situations, I try to use individual unit tasking instead. In any case, scripting cures many ME ailments, sometimes it's better to just avoid ME functionality and script stuff instead.

Flag is the last index in the table, if a comma is added after it, I think the Lua interpreter will expect to find another index/value... if it doesn't find anything, I think the script will crash. I could be wrong about this, ofc. ENO, have you tried asking on the MIST discord channel?

@xvii-Dietrich As Majinbot mentioned, I think the simplest solution is to use a LAND event, combined with a simple landing zone check (perhaps you don't even need the zone check). EDIT: I've attached a scripted version of your test mission + script file. I've simply modified the unit name of the gazelle client and the name of the FARP. The script I've written will detect any landing event from the gazelle client, then send you a landing message ONLY when it lands on that FARP (I didn't need the trigger zone in the end): FARP-Landing-Scripted.miz FARP landing detection test.lua

Units can't be teleported AFAIK.

Unfortunately, DCS doesn't allow for messages to be sent to single units/clients (not even with scripts), group messages is the best you can do. The most popular workaround is putting each client in a separate group.

You got lucky there ;) Nicely done! :thumbup:

If by that you mean making the Mi-8 more sluggish as cargo is added, then sure, it's a bummer. But if you mean limiting cargo/troop capacity based on weight values, that can be done. Unfortunately, I don't think these problems will be fixed any time soon, which is why I mentioned scripts. PS: Scripts are simply the community's reaction to already existing problems, not the source of those problems. I mean, I don't think ED & co refuse to fix problems simply because there are scripts out there that solve those problems. I think it's more complicated than that.

You'll need to load all the relevant Mi-8 cockpit textures (gauge textures included) to see them in Model Viewer. In order to do that, you'll need to copy/paste the files from gamedir to Model Viewer installation folder (using the same folder structure). You'll likely find that the Mi-8's cockpit has thousands of arguments, it'll take you a while to find the arguments for the temperature gauges. But, as I said, if you can't make those cockpit arguments work with ME triggers, it's all kind of pointless. I attempted the same kind of thing last year (using the variometer of the F15C), but it didn't work. Perhaps it'll work with a clickable cockpit module, I hope it does. Good luck! :thumbup:

Well, in the meantime you can use transport scripts, it's all I'm saying :thumbup:

Guys, have you tried scripting it instead? If you give me the mission requirements (the mission file would be helpful too), I can try to write you a transport script, which will hopefully put an end to the nonsense you're describing.

I have bad news for you, I'm afraid. Cockpit elements aren't accessible via scripting, only via ME triggers. If you can't access the temperature gauge via ME cockpit argument, I'm afraid it can't be done.

MOOSE documentation: https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/ RAT section in MOOSE documentation: https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Functional.Rat.html https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Functional.Rat.html##(RAT).ActivateUncontrolled

@Majinbot If you want to get the LL DDM coordinates of the static building, add the following lines to the script: If you want to get the LL DMS coordinates of the static building, add the following lines to the script:

@Habu_69 Afaik, ME JTACs can't designate statics, they only designate groups. As for CTLD, I've never used it, but according to the documentation, it can't be used to lase buildings (I assumed it meant any building, statics included). That's why I wrote the MOOSE script :thumbup:

@Habu_69 Well, I took it from there. ;) Does it matter, though? If it were me, I wouldn't mind using a static building from the structures list instead of a map building... it's still better than the infantry unit workaround, imho. :D

I've managed to make a predator drone "buddy lase" a static building (garage) for a Su-25T client, using MOOSE. The script includes a simple F10 menu to call for laser designation and to check designation status... the lasing time is randomized, btw. I don't see why it shouldn't work with other aircraft, provided the correct laser frequency code is used. Test mission + script file attached. If you find problems with it (or need further explanation), let me know :thumbup: Here's the raw script, btw: Building Lasing test.miz Building Lasing test.lua

This thread might prove useful as well: https://forums.eagle.ru/showthread.php?t=238619