fargo007

Not sure about "Unit.", but if you add MOOSE to the build path it certainly does work this way with the MOOSE objects. e.g. GROUP: would produce a drop down with all the methods. Same with all the other MOOSE classes.

In the light of common sense, I agree with you on the third seat in the cockpit. The juice isn't worth the squeeze.

This is how it's done IRL. Just setting it to nighttime isn't remotely the same.

The bag is a series of opaque panels that attach via velcro in the back seat, and block the view of the outside world, forcing instrument-only flying. The hardest evolution to pass in the AH-64 training pipleline. Seems like it would be easy to do, a good challenge and useful training tool.

LMFAO It's funny because it's true....

Yup, BTDT. All the iterator functions have to be called in essentially a scheduler.

Thanks Kappa! The overarching issue I had was fundamentally misunderstanding that the ForEachGroup(func()) doesn't fire each time a new group gets added to the set. It has to be called via a scheduler or DO SCRIPT from the ME. What I would like to have is a callback function similar to :OnSpawnGroup(), where any time a new member joins a set, that function runs with the group object as its arg.

In for the interest. I know for sure you could (at least 2.5.6) spawn static objects on stationary ships, but not moving ones. I did this with cargos. Also pointing out - not everything that the ME offers has an accompanying facility in the scripting engine.

I agree, you have to expect some hiccups with a big version bump. And it's helpful to remind ourselves that we choose to fly the openbeta.

I tried and no go.

I agree, there are numerous improvements in there that I consider to be very substantial.

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.