Hardcard

Perhaps the devs know things you don't... crazy, right? ;)

Post the track

It can be calculated, provided you have access to the object's orientation subtable along the x axis. local My_Unit = Unit.getByName("name of the unit in ME") local Unit_Position = My_Unit:getPosition() Heading_radians = math.atan2( Unit_Position.x.z, Unit_Position.x.x ) if Heading_radians < 0 then Heading_radians = Heading_radians + 2 * math.pi end local Heading_degrees = Heading_radians * 180 / math.pi [color="Blue"]-- Unit's heading in degrees[/color] Alternatively, you can use the MOOSE method :GetHeading(), which runs the code I posted above, pretty much.

Ok, so the problem is that you're having trouble getting dynamically spawned statics to cooperate, right? By "cooperate" I mean stuff like returning health, name, position coordinates, etc. Right now I can't remember if dynamically spawned statics actually worked with the methods you mentioned... but I do know that they yield basic info. For instance, they should be detected by birth events, event.initiator and event.initiator:getCategory() (perhaps even :getPoint() and others as well) should work, IIRC. You can also try event.initiator:getDesc(), see if you get a basic description table with some useful info in it. If not, you can always access the parameters within the template table you used for coalition.addStaticObject(). It should contain x and y coordinates at the very least (that should be enough to get zone checks working), and you can always customize it, adding all the parameters you'll need (sort of a custom description table).

@LineAxe The functions listed in Hoggit Wiki should work. Yes, StaticObject.getByName("name of the static in ME") should work, just like STATIC:FindByName("name of the static in ME") . Keep in mind, however, that some static objects won't cooperate (such as static soldiers, IIRC). Still, you should be able to work with most static types. What do you mean by "properties"? Position coordinates? Could you be more specific?

@zaelu I've continued working on the new SWAPR 1.3 version and I'm happy to say that all the problems you reported seem to be fixed now (fingers crossed). There were some nasty issues in your mission, which took me a while to figure out: Some clients were using duplicated unit names, Mission Editor seems to allow this if the units belong to different coalitions (yet another reason to name all clients properly). There were a couple hidden harriers at Sochi, which explains why 4+ harriers were spawning, instead of just 2. Those 2 harrier clients at Sochi were moving on their own because of the wind (I think). The problem disappeared when I positioned them perpendicularly. Some of the airborne clients at Roma FARP (A-10C, viggen, etc.) required a waypoint type reset, since the mission code still had them set to "takeoff from ground hot"... really weird issue, first time I've encountered it. I've attached a modified version of your mission, it uses the revised SWAPR 1.3 version. Test it thoroughly and report back, please. It's set to run in MP, btw, if you want to test it in SP, you'll need to open SWAPR 1_3_1 and set Game_Mode to "SP". I made some minor changes to the ME trigger order and delay (Moose.lua runs at mission start, SWAPR is loaded 3 seconds later, MIST is loaded 10 seconds later and so on). You can now set clients to "takeoff from ground hot" (chopper replacements will still be forced to start cold), no more Ka-50 ejections, huey clicking or rotors turning. Due to this change, chopper replacements might spawn half-buried in MP...we can't have it both ways, I'm afraid. Airborne clients will be automatically ignored, you should be able to use "Pilot" prefix without issues (although I don't recommend it). Make sure to wait at least 10 seconds before joining a client slot (plenty of stuff being loaded/running in the first 10-15 seconds, so give it time). SWPR_MercInc Training Caucasus 2020 Mai No MODS No WW2 asst (test).miz

You can always set fuel quantity at 0% (and make sure they aren't carrying external fuel tanks), they won't move that way. But I agree, AI planes should stay put.

@Lineaxe Have you joined MOOSE Discord? Please do if you haven't.

@zaelu Sure, it's possible to assign specific static templates to client replacements and spawn everything together. It's also possible to add coordinate offsets to those templates, so everything spawns where you want it. I've done this sort of stuff in the past (to spawn small base/outpost templates)... however, I foresee that adding such a mechanic to SWAPR would be a nightmare, given the problematic nature of scripted replacement spawning. I mean, all those issues you reported above are just child's play when compared to the host of issues that such a feature would introduce. Don't get me wrong, it's a nice idea that would allow mission creators to populate airbases / FARPs automatically (ground crews, equipment, etc)... but right now I don't want to bite off more than I can chew. First I need to figure out this harrier/warbird nonsense (still baffled), then we'll see.

Yes, I'm always using the latest OB. Your cockpit script files stopped working when 2.5.6 came out... cockpit becomes invisible. If you can provide some guidance, I can try to help you find a way to make it work again...

In bygone eras there was no DCS, no game developers, no computers... people were busy growing their own food and trying to survive in a very hostile environment (rampant disease, atrocious rates of childbirth/infant mortality, wars that lasted for centuries, religious/political persecution, genocide, etc.). Also, people had no rights in the modern sense, they were at the mercy of lords and religious authorities, who made the laws and enforced them as they saw fit. People at the bottom were held accountable, those on top...not so much. There wasn't much peasants could do about it (other than starting rebellions). The notion of people in the past having more "honor" or being more trustworthy than people nowadays is just ridiculous. Remember that it was customary for people to exchange/take hostages... that's how trustworthy and honorable they were ("sure, sure, we've signed this treaty now...but I'll still take your kid." :D) Ruling elites regularly stabbed each other in the back, even kings had to look over their shoulders, often becoming paranoid. When kings/lords died, that was the best part, since it could very well lead to familicide and war. As for most people (aka peasants), they were forced into servitude by authority figures, under threat of banishment, torture, death and/or eternal damnation... so please, don't pretend you'd rather live in such times. Finally, people on top didn't open their own bellies with blunt short swords... they were the ones compelling their subjects/potential rivals to do such things, in order to secure their hold on power.

Can't use "Pilot" as prefix, since that encompasses pretty much all aircraft in the mission. Ship-based clients and clients starting in the air are not supported by SWAPR, if you try to target them using the generic "Pilot" prefix, you'll experience problems. I'm working on a new version of SWAPR, it should automatically ignore clients that start in the air (regardless of prefix). Initial testing has been successful so far, fingers crossed. The harrier issue is quite baffling, though... I still have no idea of what's causing it. Will need to review the spawn mechanic from SWAPR, but, for now, make those Sochi harriers start from ramp instead of the ground. As for the KA50 pilots ejecting and the endlessly clicking hueys, that's due to SWAPR forcing them to start hot with no fuel, so the AI keeps trying to start the engine... I could revert back to forcing static replacements for all choppers... but then they'd spawn half-buried in the ground...again :cry: Perhaps I can come up with another workaround, we'll see. I'll keep you posted.

@Metal 121 Remember that the class name isn't A2ADispatcher, but AI_A2A_DISPATCHER Also, the method :SetSquadronRefuelThreshold() doesn't seem to exist (I see it referenced in the MOOSE documentation, hence it'll appear in the IntelliSense description as well, but I think it's either obsolete code or some sort of typo). :SetSquadronFuelThreshold(), on the other hand, does exist, use it.

What about wind conditions? Doesn't wind affect their accuracy?

DCS SD10 is still considerably better than all amraam types, when it's supposed to be on par IRL. Funny how you call people names, not realizing that perhaps you have more in common with those "kids" than you know. DCS SD10 and amraam will eventually be on par, not because of balance, but because that's how it's supposed to be.

@Metal 121 [color=RoyalBlue]-- Incorrect syntax[/color] DetectionSetGroup:[color=Red]Filterstart()[/color] [color=royalblue]-- Correct syntax[/color] DetectionSetGroup:[color=SeaGreen]FilterStart()[/color] IntelliSense will help you spot these mistakes, you only need to hover the mouse cursor over any MOOSE method... if no info is given, you've more than likely written it wrong. Alternatively, just write colon after the class and use autocomplete, that's always the correct syntax.

That's a new one, I think I know what's going on, could be tricky to fix. By "ships" do you mean planes or actual vessels? SWAPR 1.3 doesn't support ship-based clients, due to changes introduced in DCS 2.5.6+. Even if you're using SWAPR 1.2, it might not work properly with ship-based clients if you're using 2.5.6+ Harriers and WW2 planes shouldn't move, since they're supposed to spawn with no fuel. As for hueys having pilots inside and engines hot on spawn, that's normal. I had to do this as a workaround, otherwise they'd spawn half-buried in FARPs and other places (old DCS problem) I'll look into the Ka-50, harrier and WW2 problems, see if I can come up with a fix / workaround. Could you please provide the mission file? It would help speed things up. Thanks for the report! :thumbup:

SP is supposed to guide the HARM towards the highest threat. TOO allows you to choose between different radar sources.

@Golf2 Remove LDT, start from scratch following this video: Btw, download the source code from the latest MOOSE 2.5.0 release, ignore the two pre-release versions: https://github.com/FlightControl-Master/MOOSE/releases

Would be a great way of boring them to death and making them disconnect, more like :D (That's if you're lucky... I'm already imagining the trolls/clueless players getting bored/frustrated and shooting at random stuff, depleting ammo and giving your position away, then giving you the "chill, it's just a game" attitude) I play Red Orchestra 2 from time to time... there are multicrew slots for T34 and Panzer IV in some servers... suffice to say that all experienced tank commanders disable those multicrew slots as a rule. Providing multicrew slots to newbies in games like Red Orchestra 2 is already a terrible idea... imagine how much worse it would be in a hardcore sim like DCS :cry: Sure, some people enjoy being gunners in WW2 bombers and the like... but that's a minority within an already small minority. Personally, I don't think the huey is fun/complex enough to be enjoyable in multicrew, but even if it were, I would still want to have control over who gets in my chopper.

@Spirit X I'd try three different approaches: 1- F-pole 2- Climb 40+k, stay supersonic, give them a couple lofting amraams from 30+nm, then go defensive (recommit as soon as you defeat their fox1s). The flankers won't press you if they have incoming fox3s. 3- Hide behind terrain, wait for the flankers to get closer, ambush them. Always use tws in bvr and pop flares when you go defensive, in case there are ETs coming your way.

"the new A10C will replace the old one going forward from there" This is how. For clarification, can you then confirm that the current A10C module will coexist with the new one in the future? Thanks

@Catweedle Thanks for sharing! :thumbup:

@FALT691 Good news, I ran some tests using a buddylasing script I wrote some time ago, looks like it is indeed possible to refresh lasing coordinates for moving targets and still hit them. I've configured my buddylasing script to work with your mission and added a hornet client armed with laser mavs and gbu12s, so you can test it (mission attached). Everything is managed via F10 menu, go to spectators BEFORE entering the client at mission start (press the "BACK" button and select spectators), then you can enter. NEW_PG_REAPER_MOVING-TARGET_TEST (Universal Lasing Script Test).miz Universal BuddyLase Script.lua

AFAIK, only static coordinates/units can be lased via scripting. There's no way of telling a JTAC unit to keep lock on a moving target via scripting (that I know of). As a workaround, the refresh rate of the lasing coordinate could be increased (to get a new coordinate every second, or so), but that would effectively "break lock"... and I'm pretty sure laser-guided bombs/missiles would simply trash. Feel free to test it ;) (I haven't played with laser designation via scripting in a long time, so take what I said with a bucket of salt)