Hardcard

@Frederf Weird, the rest of modern fighters in DCS have a PRF setting, even the JF-17 (which is supposed to be very similar to the F-16)... Does the real F-16C block 50 also lack a PRF setting for the pilot or is this just the DCS module being incomplete?

@Vinci You were doing it wrong... the proper way of bringing down a Ka-50 with a huey is to charge in and ram it. :D I've done this in MP, trust me, it works :megalol:

Some of the vanilla textures for this plane are disproportionately heavy, it almost seems like they haven't been properly compressed. These, along with some of the vanilla liveries for the tomcat (and other planes) make the DCS folder considerably heavier than it needs to be (TB SSDs aren't that cheap yet, every GB counts). Could the dev team compress those ~500MB liveries down to a reasonable size, pretty please? ;)

Whatever the reason is, it's keeping potential buyers like me from actually making the purchase, just saying...

I've been searching all over the place for information, but I haven't found a single mention of this. I can't seem to find the pulse repetition frequency setting for the F-16 radar. AFAIK, the F-16C block 50 uses pulse-doppler radar ( AN/APG-68 V(5) ), so I'm assuming there must be a PRF setting somewhere. Does the AN/APG-68 V(5) have a PRF setting? Is it implemented? Is it set to the equivalent of "Interleaved"/"Auto" by default?

@marginal I already added ALARMs when I partially fixed the old MOOSE code, I think you're using an obsolete version of Moose.lua, make sure you're using the one included in the latest release. The new check looks like this: if SEADWeaponName == "weapons.missiles.X_58" [color=blue]--Kh-58U anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.Kh25MP_PRGS1VP" [color=blue]--Kh-25MP anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.X_25MP" [color=blue]--Kh-25MPU anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.X_28" [color=blue]--Kh-28 anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.X_31P" [color=blue]--Kh-31P anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.AGM_45A" [color=blue]--AGM-45A anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.AGM_45" [color=blue]--AGM-45B anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.AGM_88" [color=blue]--AGM-88C anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.AGM_122" [color=blue]--AGM-122 Sidearm anti-radiation missiles fired[/color] or SEADWeaponName == "weapons.missiles.ALARM" [color=Blue]--ALARM anti-radiation missiles fired[/color] Now that I think of it, I made this list before the JF-17 came out, so the LD-10 isn't included. I don't know if we should include it, though, since it can be fired in passive mode...

@FALT691 Check the MOOSE documentation. You'll need a scheduler , the coordinates of the moving unit, the orbit task and a task execution command These are the basic pieces of the puzzle, try to put them together in a script, this is a great way of learning.

This is a known DCS bug that affects the A-10C, it has nothing to do with MOOSE. In order to fix it, you need to open the mission file with winrar/winzip/7zip or similar, delete the DSMS folder inside and save. This problem will appear every time that you modify an existing payload profile and run the mission using "PREPARE MISSION" instead of "FLY MISSION". So, in order to avoid it, don't modify existing payload profiles, create new ones instead. Also, run the mission using "FLY MISSION".

@teqqra Looks like an FSM error, you'll have a much better chance of finding a solution in MOOSE Discord. @FALT691 You should be able to get the coordinates of the moving units periodically, then task the drone to orbit there.

@Ozone1 I don't think it's possible @SpikeGondorff Static objects can be spawned after mission start (not on ships, though). To do so, you need to define a static group template, then use coalition.addStaticObject() Keep in mind that some static units/buildings are broken, they won't work properly.

@xxMustangxx @Guzzo Pikes made a great video tutorial explaining this, check it out:

@Guzzo You can load scripts dynamically by defining the script path. For instance, let's say that you want to dynamically load both Moose.lua and a script that you're working on. Create a new ME trigger, give it a DO SCRIPT action, declare the script path and then run assert for both script files: missionScriptPath = "C:\\Users\\My_Username\\Desktop\\My_Mission\\" [color="Blue"]-- Files are located in Desktop, inside "My_Mission" folder. Don't forget to use \\[/color] assert(loadfile(missionScriptPath.."[color="Red"]Moose.lua[/color]"))() assert(loadfile(missionScriptPath.."[color="red"]My_Script.lua[/color]"))() Any changes made to Moose.lua or My_Script.lua, will be applied every time you run that code, no need to load the files manually.

@marginal The script checks the weapon type used in SHOT events. If it's an anti-radiation missile and the target belongs to a specified SAM site, the following randomizer kicks in, which generates a random chance of evasion, from 1 to 100: local _evade = math.random (1,[color="Red"]100[/color]) [color="Blue"]--If you want to reduce the chance of evasion, set the second number to a value lower than 100[/color] Mavericks aren't anti-radiation missiles, so the script will ignore them.

I might create another quick video covering the basics.

@marginal I see that your mission is based on an old MOOSE demo mission. Old MOOSE demo missions use an old version of MOOSE, where SAM evasion code is broken, that's the cause of your problem. Make sure that you're using updated MOOSE demo missions for your tests. Updated versions can be downloaded here Alternatively, you can download a more recent version of Moose.lua here

@marginal The SEAD evasion code was broken, other members and myself contributed to a fix last year. Could very well be that changes introduced by DCS 2.5.6 broke it again. I'll run some tests, see if I can come up with a fix. To answer your question, it's all about tracing and monitoring dcs.log for errors. UPDATE: I've run a test mission and looks like everything is working as intended. Provide the mission file and script that you're using, the problem is probably there.

@To anyone interested DCS Open Beta 2.5.6.47224 has rendered this mod obsolete. It no longer works and it's no longer needed!

@Pikey I get your point. Yes, many people simply want code snippets to do specific stuff (I've actually received some requests of this kind via PM), they're not interested in writing their own scripts, so Notepad++ is enough. You didn't say anything about the shared account + new MOOSE thread suggestion, though. What do you think? Guys, we can talk about it on the Discord MOOSE contributor channel, if you want. The new MOOSE thread could offer those 3 paths Pikey mentioned, with updated links and documentation: - Casual users who only want snippets - Users who want to learn MOOSE / Lua - Developers

Intellisense was essential for me to learn MOOSE as quickly as I did, I wouldn't have been able to understand Lua / MOOSE nearly as fast without the automatic method suggestions, syntax / structure checks, etc. Notepad++ offers no assistance whatsoever, it lets newbies use invalid syntax and structures without warning them in any way, resulting in invalid scripts that will keep erroring due to the simplest mistakes... That's much more of a turnoff than having to install and set up LDT, which takes 10 minutes. I agree 1000%. Since Sven is no longer around, can't we just create a new MOOSE thread that all MOOSE devs have control over? For instance, create a joint MOOSE account here, so all MOOSE devs will be able to update any threads created under it as required, and pass on the torch to new devs in the future. This new thread would contain essential links (Hoggit Wiki, MOOSE documentation, setup videos, Discord) and FAQs, no more links to obsolete Github documentation, obsolete MOOSE versions, etc.

@HawkeyeDavid @xXMustangXx @boo_n_817 Here guys, I put together a quick LDT + MOOSE setup video, should help you solve your issues:

You copy-pasted the "Installation of tools and sync the MOOSE repository" from here , that's not explaining anything. That Github documentation is old and probably obsolete (at least partially), given the myriad of changes that have been made over the years. It was written by FC over two years ago, and I think he's the only one who has permissions to edit it... like I said, he left, so I doubt it'll be updated. A lot of the stuff written on Github you can disregard, follow the instead (2, 3 and 4, specifically, which I'm guessing you missed) Those steps have always worked for me, to this day. Remember the positive mindset that I mentioned in my previous post? Looks like you need some of that too. You're focusing on the negative, blowing it out of proportion, letting it bring you down, don't do that. I learned MOOSE in a matter of weeks/months, without previous coding experience, using the same resources that are available today, so no, it's not impossible by any stretch. Sure, ED sometimes makes changes that affect scripting frameworks like MOOSE, it's unfortunate but that's how things move forward, expand and evolve. In any case, that doesn't happen nearly as often and it isn't nearly as severe as you're implying, so if that's what's stopping you, don't let it. Besides, you can trust that 99% of the methods that you will find in the MOOSE documentation work as intended, regardless. Anyway, bugs, snippets of obsolete/invalid code, etc. can teach you more about scripting than working code, since they force you to find solutions and alternative methods that you wouldn't learn otherwise. I know I've learned plenty of "hidden" stuff thanks to this, so I recommend that you embrace bugs, errors, etc. instead of fearing them. This isn't Middle Earth, Sauron/Melkor aren't around, there's no ring, nobody is doomed.

@Majinbot Alright, I see now, thanks. I haven't tried the new ME functionality yet, seems pretty useful. @HawkeyeDavid The main MOOSE developer left the project and dedicated members like Franky and Pikes took over... sacrificing their own free time (nobody is making any money here, and there's a colossal amount of work being done). Tantrums, rants and negativity in general are neither welcome nor fair. Also, if failing to install LDT + MOOSE already triggers you, I agree with Franky that MOOSE and DCS scripting in general might not be suitable for you... You'll find plenty of complex problems when scripting, you'll spend most of the time figuring things out by yourself, trying to make stuff work, fixing bugs, etc., a positive, supportive and self-reliant approach is mandatory. Sure, you can find assistance here, in the documentation, in the MOOSE Discord channel, etc, but those are secondary resources... the main resource must be your resolve, resourcefulness and patience. Now, ask again politely, explain the problem and we'll go from there.

That's not how SCENERY:GetName() works, think of it as UNIT:GetName(), the object needs to be defined first for it to work... and that's precisely the problem with scenery objects, you can't simply find them by name / id. Again, I don't know of any direct way to get information from specific scenery objects, the volume search workaround is the best alternative I've found so far. Now that's a surprise, I seem to recall that scenery objects wouldn't return a name (or it was invalid) back when I tested all this stuff. Again, how are you getting the name/id of the scenery object? Did you perform a volume search beforehand to find out the correct values?

@Majinbot What method are you using to find the ID of the scenery object? AFAIK, :getID() won't work on them and I don't think they can be found in the mission database either :huh: Also, I don't know of any direct method to find specific scenery objects based on ID/Type/Name, etc. Anyway, to get the coordinates of scenery objects (be it vec3 or LL DMS), I use world.searchObjects based on a zone (can be a moving zone), combined with a type filter (yes, type name must be known beforehand)... and pray there aren't other scenery objects of the same type around :lol: local Scan_Zone = ZONE:New("ScanZone") local Search_Area = {id = world.VolumeType.SPHERE, params = {point = Scan_Zone:GetVec3(0) , radius = 2000}}[color="Blue"] -- Radius must be at least 500 meters (~1600 feet) for the volume search to work!!![/color] local function Evaluate_Zone(Scenery_Object) if Scenery_Object then if Scenery_Object:getPoint() and Scenery_Object:getTypeName() then if Scenery_Object:getTypeName() == "[color="Green"]Type of interest[/color]" then Scenery_Point = Scenery_Object:getPoint() Scenery_Coordinate = COORDINATE:NewFromVec3(Scenery_Point) Scenery_LLDMS = Scenery_Coordinate:ToStringLLDMS() end end end end world.searchObjects(Object.Category.SCENERY, Search_Area, Evaluate_Zone)