-
Posts
1080 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Hardcard
-
-
@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.
-
This is a tad silly.
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:
Your argument over it functioning in single player and not something else is more or less arguing over the different ways to skin a cat.
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.
For starters the actual outText function you use is kind of irrelevant because in single player by definition only the player will see the message.AI get nothing out of a sound or text displayed for them. In the instance of playing a multiplayer mission in singleplayer with multiple aircraft as a choice, it is simply a matter of detecting which aircraft is used to display whatever customized message you have.
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).
In multiplayer to achieve the "toUnit" functionality you have to have each client as their own group because trigger.action.outTextForUnit isn't currently a function. I sure hope it gets added someday though.
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.
For one reason or another you seemed to take it as a personal insult when no such comment was made. In fact the only depreciation to your knowledge was self made with the "moose noob" comment. Additionally you question if I had actually tested it, without you testing it either.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.
-
Best guess is that it is checking for the first client unit to exist in order to display the message.
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...
If you did it in MP with both slots occupied then both clients will see the message.
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
-
I instantly imagined the pilot honking like crazy and cursing when I saw that :D
I'm finally starting to feel at ease within the Editor ... its almost as much fun as sim-flying.
Cheers!
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:
-
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...
-
I see... But IS there actually a way to play a soundfile to a unit (player/client) rather than a group? And how would the code be?
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:
YourClient = CLIENT:FindByName("Name of the client UNIT in ME") --This tells MOOSE which client to look for. Remember, it must be the client's unit name defined in ME, quotes are required --
MESSAGE:New("content of the text message", 10):ToClient(YourClient) --Creates a new 10 second text message and sends it to the client object defined above (YourClient). Quotes are required--
USERSOUND:New( "FULL name of the sound file with its extension included" ):ToClient(YourClient) --Plays the sound file for the client object defined above (YourClient). Quotes and file extension are required--
--Btw, remember that Lua is case sensitive, if you make syntax mistakes, the script won't work. Also, you'll need to download Moose.lua and run it at mission start (using a "do script file" action).--
-
@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).
-
TX. OK, I see. Seems you used function:
function MyPlane:OnEventCrash() SpawnGroup:Destroy(true) end
as the argument (?), but why no comma separating the argument function, per the documentation? Is the subfunction really an argument?.
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)
-
Can anyone illuminate how arguments might prove useful in the :OnSpawnGroup (or any other illustrative) method?
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.
-
I want to spawn (diffrent) SAM-sites. So I jump in the pit and activate my favortie threat. When I shot down, SAM deactivate, I will jump in the next pit and would like the have the same SAM-sites available as the beginning of the mission.
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?
-
Hi Guys, I just arrived here and don`t know where to start, but very excited to begin to create complex missions for DCS. What do you guys suggest me to read or see first?
Thanks!
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.
Here you'll find documentation about pretty much every functionality within MOOSE.
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.
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.)
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!
-
HI, is there a way to have a time delay in a trigger?
meaning that if you could set a trigger to activate, say 5 minutes after it was "triggered"? ie, a scramble flight is activated 5 min after opfor has entered an area... if that makes sense...
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.
-
Ran that snippets of code that you just posted. It seemed to have worked all great and well, but then as soon as I re-opened DCS, I got the usual crash... :( I have tried, repairing, deleting graphic DLLs that DCS were complaining about, re-booted the PC, checked drivers, checked Windows 10 version for an update, and yet I am still not sure why but will not work.
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.
-
Also seeing an increase in the number of crashes related to C0000005 ACCESS_VIOLATIONs from various DLL's. D3D11.DLL being on of them as well as EDTERRAIN4.DLL and others.
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
MOOSE - Mission Object Oriented Scripting Framework
in Scripting Tips, Tricks & Issues
Posted · Edited by 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!