Elphaba

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!

Thank you again. May I ask a few questions; I'm an A2A girl, so bombing and setting up bombers isn't something I do a lot but I've noticed that if I change the altitude then this all breaks. Also, is it key where you put the final waypoint PRIOR to bombing? Like, do you have to know where to start dropping the bombs for them to hit, or does the AI Pilots automatically do this and therefore the distance of this waypoint to the target area is irrelevant? Finally, is there any way for these to carpet bomb from above an altitude that would mean most SAMS can't touch them? I tried doing this exact same mission with the B2 up really high and nothing happened, it just turned away from the target area before it reached it but never dropped anything. Is this related to my second question? Thanks again @H60MTI

Did you search user files? What is missing from the provided ones?

OvGME is your friend.

Thank you. I have all the maps, that's not a problem. Nice to see someone using Nevada. It's a fun little map.

Thanks but I get told about this with EVERY post I make about the M.E. Their hype and publicity machine is really working for them. So, yes, I'm aware of it. But Web Apps have never been a good solution for anything. And it's 3rd party; which means when DCS changes the .miz structure or does some behind the scenes - not mentioned in the release notes - this will break and people will be stuck waiting for an update. It will be at the mercy of those who built it to maintain it; we've all seen historically and recently what happens when they lose interest or get frustrated with ED/DCS... So 3rd party isn't the solution. If it was, then all the amazing mods that add SO MUCH to DCS wouldn't be ignored by most creators as too much of a headache to enforce compliance or worry about changes to DCS breaking the game because 3rd party mods were enabled. So this project is not the solution; not unless ED buy it and take it over. All this project is doing, aside from raising a large amount of monthly cash for it's devs and causing potential compatibility issues in the future - is demonstrating to ED that if they won't do what needs to be done, they never have to because frustrated people will take matters into their own hands, even if it's a poor-persons solution. We shouldn't be telling ED that they don't need to address the mission editor and the scripting environment; we need to be putting pressure on them to rewrite the darn thing and do it properly in-house - or let a talented team of C++ / Lua tool engineers do it and sell it to them.

You are most welcome; I hope that fixes everything and you can continue building your mission. Let me know if you have any other questions about this or have problems with my test mission. Check this one out too: https://www.digitalcombatsimulator.com/upload/iblock/4d8/5gdqjpoo0xuag41yxpwhoueev5lpsqno/DCS_Supercarrier_Operations_Guide_EN.pdf And be very cautious with YT tutorials; just like all social media, there is a lot of misinformation out there disguised as real information; it's hard for non-experts to discern the difference. Just the other day someone was copying a well known YouTuber on mission creation and was using UNIT INSIDE MOVING ZONE so completely wrong that it didn't even make logical sense, but that's what the YouTuber said, so it must be right, right? Always go to the source's books to start with. Good lesson for real life too I suppose.

Actually, unless we're at crossed purposes that's not the issue at all. It's not that the font doesn't correctly remain the same (like all labels). It's that the box's position remain in a fixed position - it moves all over the map! Here is where I placed it at high zoom IN levels. Notice the Top left of the label is near a point on the border and also over ground. Here it is, zoomed OUT about halfway between close and maximum: Notice now that the position has not scaled with the zoom level and the label is in a completely different location on the map? It's now almost starting in the water and completely covering parts of the border - this is NOT where I placed it. Finally, here it is at max zoom OUT: Totally in the wrong place, despite the font remaining the same size on all three of these snapshots (which isn't a problem) but the placement of where this is, is now so utterly wrong its obscuring much of the area of the map that the route will go. THIS is the problem with scaling/zooming - it's the position floating about, not the size of the font in the label. This is a very similar problem to the issue I recently raised about the 'grab point' on a drawing object being wrong for polygons etc.. The fixed point on the map isn't actually fixed... lol. Hence it moves about with zoom level. To fix this, it would be ideal if you would allow the creators to be able to specify the location of where the 'fixed point' on the label actually is. Of course, the 'quick fix' is always top left, but there are many times where we would need it top right. Which is chosen will depend on where the mission creator places it and with reference to which side of the label needs to not be obscured.

I've explained where you've gone wrong in your newer post and given you an example mission of how to get it working correctly; hope that helps.

Also, take a look at this manual, it explains the ME and the tasks in detail:

I'm looking at it now, but just to warn you, if you upload a mission that has mods required - mention it in your post or remove them from a cut down version you share. As you're having a problem with just the recovery tanker then they shouldn't cause an issue; If I find something I'll post. ETA: Okay, you've been confused by the nomenclature. 1. You've added a 'Refuelling "REFUEL"' task - this tells the taker that it needs to refuel ITSELF from another tanker. As there isn't one, it's not doing anything. Needless to say, that's a completely different task. Normally purely for fighters. 2. You're completely missing the instruction to tell it to BE a tanker. 3. You're also completely missing the instruction to tell it to BE a RECOVERY tanker - that's it's own dedicated task. It's here you specify the alt and speed AND the carrier it's supporting. This means it will continually follow and circle over the boat even as the boat moves about. I've attached a demo mission that should show you how to set it up correctly. It has the F14B in the client spot, but change that if you don't have the "best module in the sim". Recovery Tanker Working.miz

How far away from the carrier are you? You have to be less than 50nm from the boat. Have you read the Supercarrier manual? https://www.digitalcombatsimulator.com/upload/iblock/4d8/5gdqjpoo0xuag41yxpwhoueev5lpsqno/DCS_Supercarrier_Operations_Guide_EN.pdf

DXGui is a flavour of ImAGui for DirectX I believe after a bit more poking about. I know NOTHING about DX programming - windows graphics apis are a dark art and I have nowhere near enough chickens... I've spent over a day looking at the code. Trying to shoe-horn in any form of undo/redo/group selection/group edit is impossible without such a significant re-write and re-architecture that you'd be better off starting again and doing it properly. I've made a few comments / posts about what would need to change and why but fundamentally there is no understanding of atomic operations and collective operations between multiple units. It's just not possible with how all of this has been engineered to insert any form of 'group' editing. Unless ED decide to do the right thing - throw this primitive ME away and build one for the 21st Century using sound engineering principles, by people who know how to build game engine TOOLS - then this is never going to happen. Which means it will never happen. None of the text boxes or dialogs are capable of being 'trimmed down' to common editable fields based on a number of units being selected at once and what should be editable for a 'group' vs 'single unit'. And UNDO/REDO manager would have largely similar issues too because of the way there is no way to capture the context of the change and reapply it.

I know; it's not what I was pitching or needing.

So that’s how new harriers are made.

Would you be willing to share the .miz file? I cannot get modern bombers to carpet bomb no matter what I try, so I’d like to see where I’m going wrong. Thanks.

You were able to get B2's to do carpet bombing? Did you use the B2's from the Military Aircraft Mod? If you use the B1B from core DCS are you able to get that to carpet bomb, because I'm not able to do that - either the B1B or the B2.

Yes, I've wished listed that and bugged it several times. The way around it (and it's complicated) is a lot of scripting, but there is still an issue in the DCS backend that the C pointers are getting trashed.