fargo007

Or if your mission is using CTLD you can have it lase targets for you. It won't give you nine lines (a real RPA wouldn't either) but it lases them.

Another extension idea I had that may work out well for the tanker issue would be a command set that invokes custom functions. e.g. -func-tankerSpawn-argument func would be the command, tankerSpawn is the function, and argument is the arg passed to the function. The functions would have to be loaded from a separate script of course.

A version update is now seeing stats recorded, thank you Sir!

Maybe these do exist but are just not displayed in the UI? It seems so and I would consequently rebrand this as very low priority if that's the case.

Thanks man, I will be upgrading and retesting.

In the attached images, you can see that in the SP environment (unitname.png) a unitname is visible, while in MP, one is not. Reproducer mission: STATS_REPRODUCER3.miz

Happy to do that. I will get crackin' I've already found something that may leave slmod blameless as expected here. The units that are being dynamically spawned do not seem to have a unitname at all. See attached images. Testing: What I've found, is that dynamically (Script) created units in MP on the OpenBeta dedicated server are spawning without unit names. Such as the first image above. On single player, the unit names appear. I also verified proper operation by spawning some with :InitKeepUnitNames(true), which in SP does produce expected results. Move this same mission to the dedicated server, and neither one gets a unit name defined. I'm hoping that you'll be able to conclude that the SLmod behavior and logging is a victim of this. SINGLE PLAYER: OB DEDICATED (no unit name): STATS_REPRODUCER3.miz

hahahaha! Yes, assuming we're on the same map because they are map specific of course.

Why not simply export a static template from one, and import it into the other?

Thank you Sir. Nothing that is dynamically spawned via MOOSE gets recorded, regardless of type or kind. I will do some more direct testing by spawning a few infantry alongside a Huey and gun them down to see what the log statements look like. These are my log statements filtered on 'slmod'. I am at this time not writing mission stats, just the main stats. Everything looks OK to me here.

@Grimes Wondering if you could comment on this please. Thanks, /Fargo

I'm seeing an absence of stats being recorded, and these messages in the slmod.log. It seems like it is attempting to associate a hit event with a unique unit name from the ME. The net effect, is that anything spawned via a script (with an indexed unit name) Does not get recorded. Is this actually the case, or have I misconfigured something?

According that it looks like they got it working on 2.7! WHOOHOOOO!!!! Good working with you on this @davidp57

Slmod stats are just amazing. Is there any reliable project out there that is able to disassemble to the SlmodStats.lua file that gets written and parse that out? I'm really just looking for a way to parse out the stats for each individual ID found there. In a similar way that "-stats id (n)" would produce. Any help or hints greatly appreciated. I can build it but if this has already been canned up would rather use that.

Yes, that's the one. I just checked and you're right, it just doesn't spawn the object in MP.

Yes. Look back one page at my posts there.

Let me just clarify something if you don't mind. The ForEachGroup(func) does not function like an :OnSpawnGroup(func) in that when new set members arrive, any code in the ForEachGroup(func) will not be run. I suspect the answer is "no, it will not be run." I think this was the source of my confusion. It would be a great enhancement to the SET classes though. It could add something very similar to :OnSpawnGroup() e.g. :OnAdd(func (grp)) which would run that callback function upon the addition of any item to the set.

It's my understanding that the FCR is very seldom used IRL to actually locate targets.

Use the Molniya corvette. It has guns, and anti shipping missiles but no sams.

I gave up on scenery destruction. We need a war torn layer on these maps that can be triggered in the ME like a season is on caucasus. I've requested that in the syria map thread.

Speaking as a scripting yoda, if there's a method made available in the scripting engine to see the messages sent by the ah-64, this could be sent (via scripting) to the nearest artillery battery. The way artillery works in DCS, it's nearly impossible to interact with them in the same way that a FO would (e.g. bracketing, adjustment, etc) And they seem to consistently be able to hit all around the targets, while damaging or destroying as few as possible. Cruise missiles from ships are much better if something really needs to be hit as a mission success condition. So depending on how it's implemented, the FDC method might wind up being the best way to interact with arty that we've seen so far in DCS.

Thanks for taking a look. My original discovery of this was on a much more complex scenario. I have a filterprefix on "ARTY" where new units fitting that description (e.g. M270 batteries) are to spawn, and then be included in the set where they are declared as ARTY objects. I noticed that groups matching the filter that spawned after the initial :FilterStart() were not getting included as ARTYs. I used a mark containing "arty request, everyone, ammo" to verify. I will re-investigate the original condition that brought me to build the reproducer since it's still apparent. I spawned a second 270 battery, and after several minutes they are still not included in the set. Same occurs with a ship. Again, I know nothing's wrong with the filter itself, because if I either redeclare it (re-run the filter declaration or the entire script) or restart the mission with the group already active and in place, they all get included just fine. Adding also that this USED to work 100% as expected. The image here is showing that the new group, ARTY-PUNISHER#001 does not get included dynamically, but it would on either start, or re-run. I do agree that the set updates in some respect - they get removed exactly as they should. I can reproduce that fine. There's something else going on here. Thanks for helping me look in a more appropriate direction. Set classes do appear to be fine - how the groups are spawned is something I need to look closer at.

May I gently suggest doing your flyabouts in a helicopter?

Marinaras? Sounds delicious!

At BSD our squadron averages about a 1 hour briefing followed by a 2 hour mission flight for a total of 3. Some are longer, but very few are shorter than that. We got complaints of numb asses on really long ones.