TEMPEST.114

hahahahahhahaaaaa good one.

Re 1: You can. just not with the 'template' system on the left tool bar. Go to the menu bar and click EDIT and SAVE STATIC TEMPLATE. That should give you what you need. Re 2: You can multiselect. Use LHMB + LSHIFT. but you can't drag them all at once, and this will never happen in the current mission editor, it's virtually impossible without a huge amount of rewriting.

I'd love to but it was a squadron created set of 12 missions for our squadron - it was never public.

Sorry to disagree, but having been part of a large (20+) MP event of a series of missions we had CAP, SEAD, Strike and HELOs all in the mission, each having their own roles but working as a whole and supporting each other and it was amazing and worked really well. I think it's more an understanding of how and when to use what units and why than just saying they don't mix well. Just my 2p.

My idea would be that a 3rd party, like all of us scripters / mission creatives here, would be able to write a 'plug-in' that would add a new CONDITION or ACTION to DCS. These would be bundled with DCS in each update as new ones are submitted and vetted by ED. That way, new mission editor features would be available to all players and would no longer require the general user to learn lua. All that work will have been done by the plug-in author. They could have a different colour or an asterisks in front of them, telling users they are from a 3rd party not ED in case they only want to use vanilla CONDITIONS/ACTIONS. However if the 'plug-in' api and submission process was rigid and thorough enough then there could be no distinction between any of them. What this would allow is that rather than waiting decades for a new CONDITION i.e. Group's Altitude AGL above Limit, a scripter could write, using the DCS Scripting Engine code alone, the code for that, and then everyone can take advantage of it. It would negate the need and complexity of 3rd party super-scripts like MOOSE and MIST and the problems that come with them, because at the end of the day, everything any script can do, will be done via the DCS Scripting Language code. These 3rd party script libraries just obfuscate and work as facades for the DCS SL and add additional features by doing all the legwork for the end user's benefit. Having M.E. Trigger plug-ins would give EVERYONE the power of these scripts, in bite-size atomic CONDITIONS or ACTIONS and thusly relieving some of the pressure from the M.E. devs to add this stuff as they work on more larger and general improvements to DCS. What do you think? @Flappie Is there any way you could make sure the M.E. devs or people who do planning could see this please? I know it's a big ask, but this would radically expand the Mission Editor and mission capabilities for all players, without having to learn lua or scripting or use 3rd party libraries. Thanks.

As the title says. If I output the value for Unit.getByName(unitName):getID() it is surrounded by quotes and it's type is a string But if I do this: Unit.getGroup(Unit.getByName(unitName)):getID() It's type is number. So to make the first statement work I have to cast the return value 'tonumber'.

It seems at some point 'log' became it's own singleton; if you scrape all the .lua files in DCS World then they all do things like this: D:\DCS World\MissionEditor\modules\MeSettings.lua Line 4: local log = require('log') So I'm guessing this happened at some point after the unofficial documentation was made and it's out of date. I think I answered my own question. LOL

So I know the documentation, such that it is and unofficial etc, but here: https://wiki.hoggitworld.com/view/DCS_singleton_net It says that there are many functions, including 'log', in that singleton. However, when looking into it via Visual Studio Code (https://github.com/asherao/DCS-Scripting-Library), log and many of the others, is no longer inside 'net'. e.g. I understand these are a third party creation so they can't be relied to be The Truth. So, I did an investigation. I made a logging script with a logging function: function LogWrite(moduleString, level, message, ...) -- THIS FAILS net.log.write(moduleString, net.log[level:upper()], string.format(message, ...)) -- THIS WORKS log.write(moduleString, log[level:upper()], string.format(message, ...)) end If log is supposed to exist inside the 'net' singleton, then the first line should work, however it only works as it's own 'singleton' or a global function. Can we get some clarification on this please? @Grimes Do you have any thoughts or knowledge about why log breaks with net.log?

You can always make an otherwise empty mission on caucasus to just test this trigger stuff out and if that is exactly the same as your big mission and still not working, upload here and I and/or others will take a look for you.

Have you seen this? https://wiki.hoggitworld.com/view/JTAC#:~:text=Joint Terminal Attack Controllers (JTAC's,ground or in the air.

What is it that the built in JTAC controls via the mission editor don't give you that CTLD or whatever 3rd party script does give you? Genuine interest in the answer.

Here is an image about 1/3 zoom level that shows the starting point (top right) and finishing point (bottom left) of where the bottom left corner of the text box moves from and to as the zoom level decreases. It is *not* fixed at a map location or if it is, then as the zoom level changes the scaling amount of the zoom level/map is not equal to the scaling amount of the TEXT BOX's position. Here is a video. This shows the placement at a specific point at the maximum zoom level. Two yellow lines are drawn around the bottom left corner to indicate it's position which *should* be locked in place. As we zoom out, it slowly moves South-West until it obscures the yellow lines. As the zoom level decreases, you will notice that the TEXT BOX does not remain fixed at that specific map location, but instead starts moving South-West from that position, until it reaches the other yellow lines at full zoom out level. Hope this helps illustrated the point @Flappie If not, please let me know and I'll recreate it again in another way.

Would it help if I put a video on YouTube and created a new bug report or are you happy for me to add to this one, if what I'm reporting is different from the OP?

Here’s all the manual has to say about it: Can you please remind the devs we’re not mind readers, and labels should make things clearer, not more opaque. Even a tooltip explanation would have helped. Thanks

Oh. Well it would really help if the labels were clearer. Just ‘flag’ doesn’t say much does it?! Lol especially for it being so useful I.e. knowing which gates have been correctly passed! /smh i Never use the gates, but lots of others do and I wanted to try and help and that ‘flag’ field -being very unclear- seemed to be the fix.

In the last 3 minutes I've just been updating a mission of mine to use SOUND TO COALITION and it's working fine. Maybe it's a 3rd party script thing?

From your question, I assume you mean formation take-offs and landings - if you mean something else that that wasn't clear. So for formation take-offs believe it's only possible to use the Mission Editor to do a pairs take-off of AI units. If you have 3 or 4 units, they would do it in two pairs. Same for landing. If you want more complex take-off formations or landings, then no, not without some really heavy scripting.

Not at all, just think in basic logic and build up complexity using triggers and conditions, flags (variables) and actions. It's not hard, but it is intimidating/confusing at first. That's why the manual answers about 90%+ of all the questions asked on these forums; it's the last 10% where you really need to learn Lua and the DCS Scripting engine. I think your frustration is not helping you learn this. If you want more one-to-one help, DM me and we can talk about what you need and ways of making it work. One of the biggest problems the M.E. has is you can't copy/paste triggers/waypoint actions etc between units or between mission files/maps. That means there is A LOT of repetition every time you want to build a mission. Unless you manually hack the .miz lua file, but that can be dangerous if you don't really, really know what you're doing. As I said, I know it initially is frustrating that we're dealing with 90's tech here, but if you can get past that, you can still make great missions/campaigns, but the workload and frustration as you rub up against the tech and the limitations of the mission editor etc will still drive you nuts.

Whilst I completely agree with the sentiment, I can't agree with the conclusion. MOOSE is a bloated, overly complicated and poorly architectured piece of script (IMHO) and whilst MIST is better and smaller, like MOOSE, it's not beginner friendly and forces users to learn it's unique ins-and-outs and vagaries and learn lua scripting on top of that just to be able to use it. I'd much rather the entire DCS Scripting Engine was replaced (and with a replaced and modern Mission Editor Standalone application) and that the team doing this inside ED consulted with ALL mission creators and scripters - not just MIST and MOOSE teams - to ensure that anything and everything we could ever want to do had proper public API commands AND there was documentation for it. Ideally, we should get to a point there there is nothing you can do in script that you couldn't do just from the Mission Editor alone. There shouldn't be a need for anyone to learn lua. Look at the blueprints in Unity. Visual connection of lego bricks to form complex AI decisions or events. I feel a lot of people who create for DCS, like ED are stuck in the 90's way of doing things; things have progressed significantly - it's time we all caught up and thought about the MISSION EDITOR USERS more than the technical challenge of scripting.

Yes the AI really is that dumb. You have to plan for everything. Have a look at my post in the first page of this forum for the Mission Editor Manual. You will find several SET OPTIONS that you can set on AI Units, that might help you, but other than those, then yes, you will have to create your own behaviour with a combination of triggers, trigger zones and waypoints, waypoint actions and triggered actions. E.G.

Okay, firstly can you upload a demo of the mission for us to see how you're trying to do it? Secondly, what is their last waypoint? If their last waypoint is to land at the base you want them to (and it should be) then you could set that as their new task with the AI TASK SET/PUSH *(you do know the difference between PUSH and SET right? If not check out my post on the 1st page of the Mission Editor forum about the Mission Editor manual). Do you know about 'TRIGGERED ACTIONS' - that's exactly what this situation calls for. Have it set to PERFORM COMMAND -> SWITCH WAYPOINT to the landing at the base waypoint, and then when you have the right conditions, AI TASK SET this TRIGGERED ACTION.

What is the harm in pinning this? Over the last week I've pointed four people (I think) to this link and NONE of them knew about the manual (either on their hard drive or existing) and found it helpful. Is it really too much to ask to pin it here?

This doesn't (thankfully) happen when changing the CONDITION -> 'FLAG IS FALSE' to 'FLAG IS TRUE' and vice versa. Seems to be localised to the ACTION only.

Right, so the mission I was trying to make is impossible. I wanted B2's dropping from 50k but there's an artificial limit for 25k apx?! This is where I was going wrong. Thanks so much! Very cool little mission. Nice to see a red base go boom!