fargo007

Yes. The UN isn't a country.

I look at it from the perspective of the Ka-50 being developed as an all-encompassing platform at the time of its existence. It had such a short service life if any, that it never reached its full and intended potential before the Ka-52 took over. We're really not dealing with a platform that was produced in great numbers and deployed very widely. Was the KA-50 intended to have Iglas and these other systems at some point? I believe the answer would be yes.

I don't understand why people are so emotional about this. The updates are for sale. If you don't want them, don't buy them. If you do want them but want to deploy the Ka-50 in a historically correct way for a certain time period, task or mission, you can still do so. Everyone still has a chance to be happy here.

Anyone else notice the quality of the shkval image deteriorated a lot in 2.7?

Breathtaking. At this point I wonder why Molevich doesn't just make it a flyable Mi-24 on its own.

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?