Pikey

repeat trigger>condition 1 AND condition 2 etc> ACTION: message to all "That's all folks" PLAYSOUND "Jubilant trumpet.ogg" Conditions are limited to things like group destruction/damage, this would be the hard part. But without an example of what is required you are answering your own questions... what do I want to happen when something happens. I guarantee you dont want the mission to suddenly end, that is the worst feeling for a player unexpectedly.

There's no functions to intercept the menu butotns pressed. In scripting you have no idea what the player presses on the Comms menu unless you actually create a specific menu for a specific group and access it via the F10>Other menu. The only way to achieve this would be to create a complex attack command via a scripted menu, then you could trigger whatever you wanted like a flag or whatever. {EDIT} There is also no way to know what Tasks an AI currently have unless it was in the mission form the start. A much sought after requirement. Troubleshooting AI Task is really firing from the hip blind in scripting. i.e. you cannot tell what AI are doing by asking them.

This is a request on behalf of all the people forced into using scripting for some very basic randomisation effects. It's not something I need personally, but based on supporting new moose users for the last year or three I see a lot of the same requests again and again where people are getting either tied up with so many triggers and frustrated, or they are trying out scripting because they can't get what they want from the ME. So the request/wishlist item is on behalf of these people, rather than myself. TRIGGER ACTION Late activated in Zone Purpose is, when the group is activated it appears within a random place in an existing zone to start. This would very much nail a lot of randomisation requirements and improve mission editors time I believe. Randomise group template from list With a supplied list of multiple groups, the ME picks just one from the list at launch time. This changes around the unit types in the mission quite easily for replayability. ADVANCED WAYPOINT ACTION Randomise Route waypoint diameter Rather than flyover the point, or go directly to the point, a value in metres sets a random point for the group to head towards so they would have randomised routes very easily. GROUP CONTEXT Randomise diameter location Directly in the groups context menu near to the CONDITION % entry (which is the random % the group appears) could be a very simple 1 field for an integer to be, which if filled, made the group leader appear at any point in a random circle around the Groups original point at a diameter set my the input number in metres. Altitude range Rather than a specific altitude, a bracket that the AI chooses from. Thus randomising the altitude AI fly at. I'm sure that with just these you would end up with an ME that produces near randomised AI in random places, doing random routes and keep most of the new mission builders excited that they no longer know exactly where things are in their own missions, whilst giving replayability to everyone. It would probably put Moose out of business and cut down on the repeat questions in the ME forum too.

I augment RAT with normal spawns to get traffic already up there. I don't know if you need help with normal spawns, but it's a very established and useful class to know some of, for anyone (count how many posts are about making something random) If you need help on that Moose Discord or new post.

Not a MOOSE thing, it's a game thing. Fixed some time back after years of broken. Well according to change notes. Got used to not using them.

Yeah that particular bug has been present for years now. I thought it just didnt change colour at all. But it might be a multiplayer thing or just being funky, but it was absolutely not 100% working fine in the core game. Capturing itself has always worked and still does though.

The question wasn't comprehensible for me. The inbuilt ATC/Wingman commands are not part of the mission editor. All mission editor commands created are under F10>Other menu item. If you have a wingman then whatever you have access to tell them to do, will be under the wingman menu and if it's not, then, no, you do not have access to it.

Not to be funny, but I think it autofills by design from the front of the 4 places, so the answer is... "nozzles to reverse gear"!!!

No buddy, you do exactly what was suggested as the opening lines of Hardcards answer! :) "You need to monitor dcs.log when testing scripts, otherwise you'll never know what's going on." Let me explain why. Even if you didnt make any mistakes you can see, the logging DCS gives is very reliably the best way to find out what happened. People link code all the time and expect scripters to be able to read it and spot errors. In fact, computers are for reading code. I don't even bother checking mine, I run it and hey guess what, DCS tells me the line number I screwed up on! :D This is even before considering there is nothing wrong with your code. Honestly, I didn't read it, same as I don't read mine :) I glanced at the methods and I know you are using a SpawnAtAirbase() method which was notoriously screwed by ED's change to airbase ID's and also was announced as fixed internally, but the lesson here is how to improve your troubleshooting skills rather than be a victim of random changes to the game patch on patch :) Be Data driven.... don't guess, just know because it errors. :) :) You will become self sufficient, faster and use your time more effectively. Get a free log tailer, like "Baretail", (https://www.baremetalsoft.com/baretail/) open the dcs.log, set it to tail, put it on another screen, run the mission, and oh look, you see error messages in realtime which teaches you so much! All the mysteries now suddenly come without guesses and what is more you will learn to debug by making your own logging with env.info("whhhheeeeee, i'm a logging comment whizzing by!") And you now are empowered!

For just a random spawn location it's even easier. Remember you can mix and match these methods. [font=Arial][size=3]myZone = ZONE:New( "Zone1" ) SPAWN:New( "myLateActivatedGroupName" ):[/size][/font][font=Arial][size=3]SpawnInZone(myZone, true) [/size][/font] You now need a zone in your mission called "Zone1" and a late activated group called "myLateActivatedGroup" Remember with these, all the words and names are case sensitive. This will spawn your late activated group somewhere in the zone... somewhere. Hoenstly, spawn is the best of all the classes for simple randomisation.

The problem, everytime I see something that can done by scripting I think how the ME could have done these easier if it had a few more touches. What about random activation in zone, random waypoint routing in an area, random options... yes that's right, it randomly picks from some options like ROE ... all this just pushes people into using the unsupported SSE and then ED dont give that much love and people live in a world of mission design pain. Let's face it, they dont even like using scripting in their own DLC. What's being asked here is so easy in Moose, it only requires asking, or looking. In the mission editor create a plane called myLateActivatedGroup (late activated) which is the actual route. Then create a bunch of planes that are the same names as in the table, "planeTable". This is all group names, not unit names. Load moose.lua at mission start as a DO SCRIPT FILE Load this below as a DO SCRIPT and paste it in after moose loads planeTable= {"mig29a", "tomcat2ship", "mig29a", "f5", "f52", "jeff","frogfoot","fishbed"} SPAWN:New("myLateActivatedGroup"):InitRandomizeTemplate(planeTable):Spawn() What it will do is keep the plane that is late activated and activate it as normal but swap in the model randomly of the others.

https://forums.eagle.ru/showthread.php?p=4246662#post4246662 So... I'm very happy about this, it shows ED listen, understand, etc. That's a fairly significant thing. Give them love. I can stop whining and go back in my hole now :) Which is good for everyone.

OMG OMG OMG!!! TRUST REGAINED!!!! :D

Hi folks, Could I ask for your collective help on something fairly specific? I'd like to set the Tarawa's magazine for it's AV-8B detachment using the in game warehouse. I realise there is some flexibility, some secrecy about what it went on operations with, but as a ballpark I'd love to have a list of weapons available as I will create a persistent cruise with a new tool (the successor of DAWS). I went to another game with a well respected database and attached what it thought... it was fairly light on details as expected and realise flexibility was always built in, but a 1985-1992 magazine loadout of the Harriers from the Tarawa magazine would really be a useful list. Could anyone help guide me here? Thanks!

Interesting to wonder about the Gripen, did it come more Nato-ish for sales purpose? Or are software changes making this kind of thing irrelevant now? I've dealt with mixed units and Russian hardware, more common back in mig21 days though, everyone thinks that NATO standards are universal but there are so many occasions where in this game we can come off those rails. Whilst its nice to have strict processes, in this game you adjust to whatever you need.

Oh, on headsets I did a lot of research before going Reverb and I got better than expectations. The best single point clarity headset is the Reverb. It has the higest detail at the centre of vision and sits at 2/3rds of the Price of the Index. The reason anyone questions Reverb are because it has very clear limitations and downsides. If you want 'seat only' simulations and not interested in controllers, it's your go-to. From a vision perspective, doing a personal like for like on a CV1 versus a Reverb the difference is massive. The F-14 is the easiest to compare visual definition on. In CV1 most of the lettering is unreadable in the pit. The best part is the Ammo counter on the right. It is unreadable in CV1. If you zoom, it's actually still very hard to make out. On Reverb, you can just read the numbers without zoom, but you do need to look and stare at it. It's equivalent to a CV1 zoomed in, basically. Another good test is in the Viper. The radar scope bricks and altitudes are unreadable in the CV1, which is why I upgraded. You could just make out a hollow or full brick, you can't see the radar altitude (same as the Hornet) without zoom. On the Viper, you cannot discern close bricks together in RWS. Perfectly readable even at a glance in Reverb. As far as I know, the close definition isn't quite that level on the Index which costs another 3rd of the price. Given the price of 600 for Reverb and 450 for a new CV1 at launch, and 950 for Index, you can see that price per pixel definition, the Reverb smashes 2nd gen VR. Now the bad stuff, because there is, you can never have it all. The controllers... are awful. But they do actually do what you want. But the CV1 controllers were better and by all accounts all the others are better. The cord at the back is very stiff and to the point of being detracting. CV1 beat that. I'm sure it's not as uncomfortable as wearing a full flight suit etc, but it's just a comparison, I hate the cord. Lastly WMR. WMR is reasonable as long as you have good lighting, but the tracking is not as good as the CV1 which was crystal smooth - in fact the second editions came with dual cameras. Their head tracking was spot on, never one blip. The WMR on the Reverb though is subpar and can occasionally blip, even after the initial stutter of load. It is VERY load sensitive, so if you launch something, tab, look sharply on unloaded textures you will get an out of body experience for a short period. It's not godawful, but every now and then. [EDIT] Need to explain more on this. Low frames in CV1 still keeps 1:1 head tracking, if the low frames are caused by the app being bad or the GFX card not keeping up. Low frames in the WMR world can be caused by the app or generic load on the CPU and easily can knock into the head tracking depending on the cause. This basically means, that most of the time in CV1 you can look round smoothly even in a low frame environment because the tracking is decoupled. In WMR though, you can get your tracking knocked around during high load and THAT is a problem, so you must make sure you are not overextending the card and going over what can be performed on the CPU. It's way more fragile and can be a bit raw.[\EDIT] Lastly the WMR software. I find it less annoying than Occulus whom I hated with a passion at their silly music everytime the headset woke up and unhideable window. Steam VR is much better. It's unobtrusive, doesn't kill your headset to update, updates quickly and often without you knowing, using Steams servers, has sensible settings to configure and so far has never killed the service or stoped working yet (which the Rift regularly did). It also has OpenVR accessibility and more people writing tools for it, like addons to streamers and OBS plugins and the non DCS mirror window is more configurable. I like it anyway. Oculus... I used to run it as admin so the thing didnt come up and annoy me it was that bad. I did prefer Oculus' reaction to load though, with the egg timer. The tracking continued mostly but the display didnt stop tracking, just the application. Whereas WMR just completely falls over. Dependent on the cause of course. So given those pros and cons, the choice for me was spot on. I dont use hand controllers, I sit and play one game in VR, it gives me the best resolution for combat in DCS. An Index is very deluxe and better all rounder, especially for full room play, but I'd hate to mess with those camera boxes in a rented accommondation on the walls and the price for less resolution, albeit slight, is not worth it for me, to trade for a bit of uncomfort

My Reverb arrived on time last week, which was 2-3 days in the south of England. I expect the locality of distribution centres is an important part of this, but certainly didnt have an issue. I know a friend of mine in Belgium got his Index yesterday and they only opened sales of Indexes on that Monday a week ago due to limited stock. Possibly a lot of local variation. Anyone want a full priced stinky CV1 that smells of me? :D

It was at this point some years back I decided scripting was easier, and I'm still happy with the investment! Looking at posts like this with triggers and flags makes my head hurt! I still use TIME SINCE FLAG occasionally though and you can add that into some of your conditions to set delays.

I get something similar. got a lovely 45+ frames in a reverb on a 2080S on first run, then swapped aircraft and the frames went to 22. On my previous card this would have been 4-8FPS and killed it, but it can usually be solved by restarting DCS. Since I never monitor my hardware in VR I am usually clueless as to the cause. Trying the above link Mustang, you are always so good for these little tweaks buddy! thanks.

I wonder how many people complain about performance whilst their computers rebuild the shaders during play? Because maybe they updated, launch, headset on and have no idea the dcs.log is chuntering through all the shader compiles for the new lighting effects... see bad performance, try a different terrain and a different aircraft, get the same again, use up their alloted 2 hours of game time a week and log off, rant on the forums about performance and start downgrading to the previous version before the shaders finished? Not saying it's every case, but after I cleaned out my shaders, let DCS settle, run a few cockpits and terrains, patiently, then restarted my computer and ran DCS, it was absolutely fine, for me?

Portable Tacan and RSBN and other server sided beacons in the core game is the way to. You can do this with scripting, but TACAN is notoriously buggy in multiplayer and can just stop working. I'd vote for keep the real beacons first, as much as I miss my KSB.

The issue with SP/MP is that they are two different games right now. In SP you can do more with the aircraft, do interesting cockpit arguments, gates, things work, certain scripted elements are working. Unfortunately I have to AGREE with you, because MP was always from a "tacked on" perspective. But why should it not be the same? Why should a Single Player PvE player not go into a multiplayer server and have the same experience with humans flying around them? For example, for those that don't fly with friends, the first day everyone realises multiplayer is silly, is when they are flying with their friend for the first time through clouds and one person finds its raining and the other can see clearly right next to him. It chucks you out of the immersion seat, for sure and doesnt stop there. Traffic, you give a talk on in your TGP and stupidly refer to a car on the road, "red saloon". Your wingman cant see anything like that. And it doesn't just stop there. Far far worse, you are in the same plane, fire the same missile and it goes in TWO DIFFERENT DIRECTIONS for you each!! Datalink, the funky ridiculous magic mode 4 IFF, the deck slipping... Is this not the very basics of bringing people into multiplayer and creating a good experience?! :) There is no wonder you consider it a tack on in all honesty! And, there is the "hidden from sight". Ever wondered why certain things aren't found on MP servers? Like large front line battles, with hundreds of moving ground troops in decent persistent campaigns that a mainly Single player could log into, have some fun, maybe interact a little, feel immersed in a world? Then come back to the next day and found that what they did was still going and their contribution counted in some small way? Let me tell you ... I have worked with some of the finest minds, intellectuals with enough spare time to run several companies, coding seperately on DCS and yet no genius can fulfill this dream and simply do it for ED because Multiplayer is an absolute shit show when it comes to any moving units at scale. It destroys servers causes warping, just doesn't work. We have a full suite of tools in the unsupported Scripting engine that have so many breakages and bugs that at any particular point. We could create the most wonderful things for single and multiplayer but we all aim for the sky, the "persistent world". And we end up with servers running on the absolute edge of panic, tuned to hell, all kinds of trickery and spawning control to keep the game from falling over, battling memory leaks caused by hooks on carriers, bugs that send planes to the wrong airbases or cause helicopter AI to block your decks. We could give the single player hope and a fantastic experience if DCS can fulfill it's end of the bargain. Right now, people are just quitting because their work is trashed, things that ran for years just stopped on 2.5.6. ED said they were working on the CORE. They have. They touched it and made it substantially and noticeably worse (if you follow the under the hood changes) with the latest patch. I'm begining to regret asking for this for the last few years, I honestly am, it's destroyed the player base on my server, it's killed a few of my very useful scripts, it's killed my passion for Multiplayer and I'm just not playing as much, just watching and again, hoping...

It's just missing the crying children and the car alarms going off ;) But... absolutely!

Standby for the Friday the 13th sale, it's bound to spread like a ... oh. Cough.. "Disaster relief here, get your disaster relief here..." nah, it's just not easily marketable

Who said this!? Quote please. Not only is it designated as "military" on every airport information service I can find https://skyvector.com/airport/OOKB/Khasab-Airport , it's where No. 14 Squadron RAFO's NH-90 SAR use as a detched base of operations and there's plenty of military activity through the long standing Omani conenctions with the British RAF. Here's a Jaguar landing there:https://www.youtube.com/watch?v=yivDchZymOE Despite that, no record of a permanent TACAN that I can find. It would have made more sense on the ridgeline anyway, because that place is like a hole in a rock. There is a VOR DME about 40km south.