Hardcard

@Darcaem As far as I know, late activated units spawned via MOOSE script can't be found using UNIT:FindByName or GROUP:FindByName, since it appears their name changes with respect to ME when MOOSE spawns them (might be wrong, though, not 100% sure). Delta's solution (OnSpawnGroup) has worked for me in the past, definitely give it a try. Alternatively, perhaps you could even include the Cessna and the RAT aircraft in a SET_GROUP, then use iterators to run functions specifically directed at them later on (you should have no trouble finding those units then). This is what I do when OnSpawnGroup() is just too tricky to implement in my scripts (too many late activated units/groups to handle individually). As for MOOSE documentation, there's this other source that I use. (Here's the RAT section) I might be wrong, but I think it's an updated version of the site that you linked. Don't take my word for it, though! Hope this helps!

@feefifofum Right, I see the problem now, I totally thought this was possible, my bad. (I'll try it anyway, just for the heck of it, not that I don't trust what you're saying :thumbup:) As for me expecting people to walk on eggshells, it's not that. I'm fine with other people telling me how I'm wrong and why... The problem wasn't what Grimes said, the problem was how he said it (dismissive single liners just don't work for noobs like myself :cry:. They are likely to cause confusion and not clarify much). Now I understand that Grimes was thinking about MP environment only, since he already knew that doing this in SP is pointless... I just didn't know. That's why I think it's always better when things are explained, rather than "thrown around". I would've said something like: "That might seem to work in SP, but here's what happens when you try to run that kind of thing in MP...(examples) Also, your test mission has two clients in the same group, why would you want to do that, exactly?". I don't know, maybe it's just the way my brain works...(or doesn't, :doh:) Thanks to you all guys for your clarifications, including Grimes, of course.

That's the kind of thing that leads to misunderstandings. Didn't I just apologize to you? Twice? Yet you opened with a hostile statement. :huh: I was simply showing the OP how to target specific clients in SP. I did, you didn't seem to like it, I honestly didn't get what you meant, I misunderstood, I admitted it, I apologized. End of the story. I didn't come to this thread to start an argument with you, Grimes, believe it or not. And I don't like where this is going, tbh. Again, hostile attitude... that doesn't help clarify anything, mate. I already know that the AI won't receive messages, only the player... (Btw, that kind of insinuation could be very easily understood as: "See, Hardcard? You're a fool!", in case you didn't realize). Now, you said that the method is irrelevant in SP, I honestly don't see it that way, precisely because it's meant to be used in the kind of instance you described: SP mission with multiple aircraft choices for the player. In that scenario, sure, you can always create single client groups and just target those (which is what I do, believe it or not). But just imagine that I wanted to create a separate set of messages for client group leaders and their wingmen (the mission would allow the player to choose between leader or wingman slots). The AI would take control of the clients not chosen by the player (I'm assuming this can be done, btw). What then? Would the script be irrelevant in that case? Well, that's the kind of scenario I had in mind when I posted it for the OP. Now, if the AI can't take control of the remaining clients in a given group, then sure, I guess the script is pointless :megalol: (but note that I'm not aware of that, since I've had the AI take control of abandoned client slots just a couple of months ago). I didn't know that, thanks for explaining. I will definitely take your word for it, since you obviously know far more scripting stuff than I do. The problem before was that your dismissal didn't seem to match the results I was getting in my SP tests. That's the only reason I doubted you, really. PS: Please don't be hostile in any further responses, THAT would be pointless. I already apologized, and in fact, I apologize again. If I'm wrong about something (which I'm sure it'll happen many times), you can always explain the why and the how without the need for any kind of hostility. A good explanation is often all it takes. I do thank you for pointing out the limitations of the script, I just wish you would've done it differently, is all.

Hi Grimes. Let's see if we can cool this down. I took it rather personally because, out of the blue, you quoted my response to the OP (which didn't involve you in any way) and then dismissed my script example without even explaining. Call me crazy, but it's not that hard to take that kind of thing "personally" over the internet. It wouldn't be the first time I meet a major ahole online (I'm not saying you are, I actually admire your work with the wiki and helpful comments in this forum, that's why I was cool in my first response. After your second dismissal, however, I got pissed, not gonna lie). Keep in mind that I was only contemplating SP environment, where the script...works? That's why your dismissal didn't make any sense to me. I mean, put yourself in my shoes. You have a script that seems to successfully target individual clients in SP, then you see a guy over the ED forums who's asking for a script that does precisely this. You make the effort to create a script example for him, then another guy comes around and shits on it without even explaining, when the script actually seems to work when you test it... What gives? :huh: I don't think it's that hard to understand, tbh. Anyway, the thing is that I hadn't tested the script in multiplayer because I have no way of doing that. I had only tested it in SP, which was its intended usage (to my mind), and it worked all the time, so I didn't get why you were so keen on denying it. To anyone else reading the thread, it would've seemed that I was lying or something, and I didn't like that one bit, since the script freaking worked in SP, I wasn't making it up. I can see your point now, MP is tricky, I didn't know that, I was wrong to get pissed, I apologize for that. Although, in my defence, I'll say that you saw that the script works as I described in SP, and yet you decided to ignore that and focus on the fact that it doesn't work in MP. :( Also, I just said that I don't like being called a liar or a fool, which is true, and your posts seemed to point towards that direction (albeit accidentally, I'm sure). You are free to post dismissive one liners without giving any real explanation, of course, but it might lead to misunderstanding, like it happened here. Again, I apologize for getting pissed at you Grimes, please don't take it badly. PS: I can depreciate myself as much as I want, but when somebody else does it, that's different. It's like a white guy using the "n" word to refer to a black person, it just sounds wrong.

You mean at database level? Because this doesn't seem to be the case in the test mission itself. Have you tried the test mission I provided? It doesn't look like you have, mate. If you have, then you must've seen how wingman NEVER receives the text message, not even when it's the first active unit in the mission. Leader, on the other hand, ALWAYS receives the message, even if it's the last to spawn. If I use wingman's unit name in my script instead, the opposite happens. Actually, I've gone ahead and created 3 test examples, same mission, same method: -In the first example, ONLY Leader will receive the message, regardless of activation order. -In the second example, ONLY Wingman will receive the message, regardless of activation order. -In the third example, both Leader and Wingman will receive their own custom messages, regardless of activation order. Now, please provide a logical explanation for this, assuming I'm wrong... I don't see how having both clients spawned would change the behavior I already described. PS: I don't like being called a liar or a fool, Grimes, that's why I'm insisting... I'm sure you understand. Leader gets message_Wingman is ignored.miz Wingman gets message_Leader is ignored.miz Leader and Wingman get their own messages.miz

I instantly imagined the pilot honking like crazy and cursing when I saw that :D If you are having fun with the cumbersome ME, you'll definitely love scripting. But we are getting ahead of ourselves, one thing at a time... you still haven't seen the ME's dark side :smilewink:

You can use Audacity. It's free and it allows for wav, ogg and mp3 format conversion (through the "export" functionality).

Hi there Grimes! Yes, if you open the declaration for that script bit, it does look like the message should be sent to groups, not individual clients. However, in reality, if you try to use the client's group name in YourClient instead of its unit name, the message won't be sent. In other words, CLIENT:FindByName ONLY accepts client unit names, it really does target only individual clients in practice. If you need proof, just try the attached test mission, which runs the script I posted above. Two client J11As on ramp, leader and wingman, both belong to the same group. Leader will receive the text message every second, wingman will be ignored all the time. Just switch slots and see for yourself. Now, I'm still a MOOSE noob and couldn't tell you how this all works "under the hood"... All I know is that it does, somehow :thumbup: Client test.miz

Yes, definitely use ogg rather than wav. Otherwise your miz file will become absurdly large. As for mission sharing locations, I guess you can upload them here

Google text-to-speech is actually decent (English voices only, though, the rest of voices are quite terrible) I use NaturalReader14 myself, but it's not free...

Yes, there is. I'm gonna show you a way of doing this in MOOSE. Send a text message + sound message to a specific client:

@Delta Thanks Delta, That definitely explains why the documentation model is written like that. I'll be applying this technique in my scripts from now on! @rassy7 Sorry mate, I don't know how to do that either, but, tbh, I'd also be interested in learning how to do that. Handling group/unit tables is the next item in my "to learn" list.

I'm also quite clueless about arguments and parameters, to be honest. In any case, seems like the confusion is dispelled by simply forgetting about those SpawnFunctionArguments. For practical purposes, simply consider the model to be: SPAWN:OnSpawnGroup( SpawnCallBackFunction(SpawnGroup) ) The method should work (as long as SpawnGroup is passed as an argument/parameter of the SpawnCallBackFunction).

Nope, I don't think that function acted like an argument. The argument was SpawnGroup, first introduced between brackets, line 10. Let's paste the documentation model here, so we're on the same page: SPAWN:OnSpawnGroup(SpawnCallBackFunction, SpawnFunctionArguments, ...) Yes...now I see how those commas can be misleading :megalol: Check the script again. Actually, let me write the :OnSpawnGroup bit in a single line too, see if it's clearer that way... SPAWN:OnSpawnGroup(function( SpawnGroup --THIS IS THE ARGUMENT--)functionMyPlane:OnEventCrash()SpawnGroup:Destroy(true)end end) The way I see it, you must forget about the first and last parenthesis, ok? Act as if they weren't there at all. If you do that, you'll see quite clearly that this is a typical function layout. Namely: function(argument) --sub--function OnEventCrash --do subfunction stuff-- end end The confusing bit is that it's all inside a huge parenthesis, and the documentation can be quite misleading. I don't think any of those SpawnFunctionArguments are given in my script, it's just a huge SpawnCallBackFunction(which has a subfunction in it) between brackets, that's why there are no commas. Again, I could be 100% wrong in my assumptions, but, to be honest, the function example in the MOOSE documentation makes no sense to me otherwise... It just looks like a SpawnCallBackFunction between brackets, without any SpawnFunctionArguments given. Basically, it's as if the actual model were: SPAWN:OnSpawnGroup(SpawnCallBackFunction)

Hi there Habu! As it happens, I also struggled with this problem for the last couple of days, and Delta helped me out over the MOOSE Discord channel. I just discovered the :OnSpawnGroup method yesterday (because Delta mentioned it), but I think I can provide an example where an argument is crucial for a function to do its job properly. Here you have an example of the script that solved my problems. The argument is given in line 10 and it's required in line 12, I think it's necessary for the last "subfunction" to actually do its job. Hope this helps.

Well, this is certainly possible in MOOSE. Here's a working MOOSE script (with helpful comments) that triggers the spawn of an enemy SAM group (4 avengers, set to late activation in ME) EVERY time the client/player aircraft takes off... it also triggers the SAM group's removal/destruction EVERY time that client/player aircraft crashes. Here's a MOOSE demonstration mission I've set up for you (don't need MOOSE to try it out, since it's already included and properly set up in the mission file) Here's the MOOSE mission lua file, which contains the script shown in the first link (it's already included in the mission file, just providing it separately for convenience). It makes the magic happen. This script can, of course, be modified to incorporate new SAM groups, which would be spawned and removed on certain events / conditions happening. The spawning and removal of the SAM groups could also be triggered at will via F10 Menu commands, which would be more convenient than using takeoff and crash triggers, imho.

I must be missing something here, because I honestly don't see where the problem is :huh: Can't you simply set the mission time at 8? Add your plane to any airport of your choosing, set it to cold start, take control when the mission begins, do your things, take off when you are ready... If you need to be somewhere in time for some specific events, make sure that those events aren't triggered before you get there. Just assess the amount of preparation/travel time you need and add it as a condition for those events to happen? What else do you need?

Bookmark the following pages (If you haven't done it already) 1-Simulator Scripting Engine Documentation Here you'll find documentation about different kinds of functions, events, enumerators, etc. built within the DCS scripting engine. Examples are found in the "Lists" section. 2- MOOSE documentation Here you'll find documentation about pretty much every functionality within MOOSE. 3- FlightControl YT channel Here you'll find different kinds of MOOSE related videos. I recommend that you start with the " " video series, then continue with the " " video series. After watching and applying what all those videos teach, you should be able to start doing basic stuff with MOOSE. From that point on, it's just a matter of making all sorts of mistakes and then learning from them :doh: So you'll eventually be able to understand and apply what the more advanced videos teach. 4- MOOSE Demo Missions Here you'll find example missions for most MOOSE functionalities. Each folder contains both the DCS mission file and the MOOSE lua script that runs it. At first, chances are that you won't understand half of the code (in most cases) :huh:. But as you keep practicing and getting acquainted with MOOSE, the amount of code that you don't understand will keep decreasing. If you put in the effort, you'll eventually understand it all. As an example, I just started using MOOSE (and scripting in LUA) 3 weeks ago. During this time, I've gone from not understanding anything to being able to script elaborated functions (which include logic checks, triggers, event handlers, timers, "subfunctions",etc.) 5- MOOSE Discord channel I also recommend that you join the MOOSE Discord channel. It's a great way to get help and check out what other users have been able to do with MOOSE. Also, if you read through the message history in the right sections of the channel, you might even find workarounds and solutions for the problems that you'll likely encounter along the way.

The whole cargo/artillery management and message clearing functionalities sound sick! I haven't tried this 2.4 pre-release yet, only because I don't know if it's going to be compatible with MOOSE 2.3.1 based scripts/missions. Is there a specific procedure in order to update MOOSE or it's simply a matter of replacing Moose.lua both in Eclipse and ME? Btw, I watched a FlightControl MOOSE video on YT where Sven mentioned that there's some kind of update functionality built within MOOSE. Is that still a thing or should I ignore it? Thanks!

I guess you could use a scheduleFunction singleton to do this. Combine it with a zone condition check/flag and with activateGroup function That's one of the ways I'd do it, I guess.

Check your drive. In my case it was the freaking SSD partition that gave me grief. Problems didn't get sorted until I performed a wipe and created a new NTFS partition, as I mentioned. AMD drivers also seem to conflict with DCS, btw. Don't include DCS.exe to AMD gaming profiles, otherwise it'll give a d3d11.dll access violation (at least that's what happens when I do it).

:doh: My bad, I didn't realize it's a Strait of Hormuz mission (I don't own the map), that's probably why I don't see it :megalol: Looks like I can't be of any help then, good luck fixing the issue.

I'm using DCS 2.5.2 open beta... The Hercules Down mission just fails to appear when I look for it in the "Missions" folder (where I put it). I can see and open the rest of my missions, though (which are located in the very same folder)... Looks like Hercules Down isn't compatible with 2.5.2 open beta, can you confirm this?

Sedlo, is the Hercules Down mission compatible with DCS 2.5? I've downloaded it from here and my DCS 2.5.2 doesn't even see it.

I was getting lots of access violations too, which caused DCS to either crash or fail to launch, especially the edterrain4.dll one (although I remember getting the D3D11.dll error too at some point). Fully reinstalled DCS several times, but files were constantly getting corrupted during installation. Turns out that the last Windows 10 update had apparently messed up my windows installation, I had to repair it by running the following commands in cmd (admin): DISM.exe /Online /Cleanup-image /Restorehealth ...and then run: sfc /scannow Also, the NTFS partition in my gaming SSD (which contained DCS) was apparently causing trouble, which didn't disappear by simply formatting it. I had to perform a wipe (secure erase) of my SSD, reflash firmware and create a brand new NTFS partition (this new partition didn't use all the available SSD space, I left 3GB out of it). I then installed DCS World 2.5.2 open beta again and I've had no more trouble since. Btw, I also removed all antispyware software from my system (don't trust exclusion lists, tbh) and made sure that I had full permissions for DCS folders. Also, I made sure that I had ALL the VC++ Redist packages installed (from 2005 to 2017, both 32 and 64 bit versions.) I hope this helps