Repro RPT example:
Server:

22:20:45 #############################################################
22:20:45 # ProjectileCreated: 10: rocket_rpg7.p3d (R_PG7_F)
22:20:45 local = true
22:20:45 source = B Alpha 1-1:1 (Sa-Matra) (B_RangeMaster_F)
22:20:45 instig = B Alpha 1-1:1 (Sa-Matra) (B_RangeMaster_F)

Client:

22:20:45 #############################################################
22:20:45 # ProjectileCreated: 10: rocket_rpg7.p3d (R_PG7_F)
22:20:45 local = false
22:20:45 source = B Alpha 1-1:1 (Sa-Matra) REMOTE (B_RangeMaster_F)
22:20:45 instig = <NULL-object> ()

should be fixed

I'm surprised it event works anyhow on dead unit. I wont touch it in fear it might break something else, so just kill unit after mission start rather than starting with health 0. Gonna close this as fixed

With an eye on #constrList constituency, might also default member #type #create functions with a sensible default along similar lines. i.e.

_self getOrDefault ["#create", {_this}];

Again, could be #flag opted in either way, assuming early adoption, breaking changes, etc.

lastEntityCausingDamage is the engine pullup, so adding instigator would require the whole new implementation, not likely happening any time soon

Could also facilitate via #flags for that matter, if it is considered an early adoption breaking change.

Is this related to lack of vehicle or instigator on the entity in lastEntityCausingDamage @ T178711? I think it would be correct for entities to store both last damage vehicle and instigator and then use it for proper Killed event handler arguments and these explosions parents.

Revision: 151379

As designed, the explosion doesnt have separate instigator as the shotShell has

Revision: 151378

Could even optimize the core of the approach a little bit further.

bit of insight conveyed to me, apparently has to do with the #create mechanism and #constrList being formed. which is a bit tricky when the ctor arguments are a bit differently shaped from a base class type to derived one. the workaround is tricky, selecting around #create when specifying a #base and doing the ctor chaining manually, which seems to resolve the issue.

Thank you that you took the time to answer my inquery.

In T170647#2563304, @michaelwplde wrote:

In T170647#2563281, @michaelwplde wrote:

Probably been covered before, having had a couple of learning moments doing appropriate method, ctor, dtor chaining. #base. prefixing works for academic use cases, IAnimal to ICat or IDog, for instance.

But if your hierarchy is deeper than a couple of levels, then I think perhaps prefixing to the interface is probably best. Say, IAnimal to IDog to IAustralianCattleDog. For instance, IDie (loosely, [_sides]) to IHeroSystemBody ([_sides, _zeroes, _twos]) to IHeroSystemBodyRoll ([_sides, _times, _summary, _zeroes, _twos]), attributes loosely illustrated. Plus "Roll" method behavior comprehension, i.e. "IDie.#create", "IDie.Roll", "IHeroSystemBody.#create", and so on

Such chaining may be set during "#create" ctor, or perhaps could be part of the formal type decl itself, in order to ensure appropriate declarations are being made. Would need to tinker with that what works, seems best, etc.

Starting to notice what others have reported concerning spurious, possible scheduled unscheduled, #create callbacks. Put some systemChat reports into my #create callbacks to examine the method chaining, and I am definitely seeing multiple "default" callbacks going on.

As observed, for instance with reports such as, meaning, should SHOULD report what I passed during createHashMapObject, correct? Ultimately... I see one such report on up the chain. Then there is a second pairing involving a _this "default" what looks like default arguments.

systemChat format ["[fn_hmo_onCreateHeroSystemBodyRoll] [_this]: %1", str [_this]];

That buggerboo is going to need addressing before HMO could be considered "ready" for prime time IMO, FWIW.

The pattern even looks a bit combinatorial, IOW (in other words), as you hike the callbacks on up the method chain, that introduces another combination to the resolution.

Definitely not what I would expect be happening creating a single instance HMO.

All that was viable has been done for 2.18.
If there is new stuff then probably a new ticket for that (link it to this one tho)

Probably not 2.16
2.16 profiling branch though, shall be good enough

In T170647#2563281, @michaelwplde wrote:

Probably been covered before, having had a couple of learning moments doing appropriate method, ctor, dtor chaining. #base. prefixing works for academic use cases, IAnimal to ICat or IDog, for instance.

But if your hierarchy is deeper than a couple of levels, then I think perhaps prefixing to the interface is probably best. Say, IAnimal to IDog to IAustralianCattleDog. For instance, IDie (loosely, [_sides]) to IHeroSystemBody ([_sides, _zeroes, _twos]) to IHeroSystemBodyRoll ([_sides, _times, _summary, _zeroes, _twos]), attributes loosely illustrated. Plus "Roll" method behavior comprehension, i.e. "IDie.#create", "IDie.Roll", "IHeroSystemBody.#create", and so on

Such chaining may be set during "#create" ctor, or perhaps could be part of the formal type decl itself, in order to ensure appropriate declarations are being made. Would need to tinker with that what works, seems best, etc.

Maybe something that can be looked at

In T178888#2563300, @BIS_fnc_KK wrote:

What about https://community.bistudio.com/wiki/uniqueUnitItems is this faster?

What about https://community.bistudio.com/wiki/uniqueUnitItems is this faster?

Probably been covered before, having had a couple of learning moments doing appropriate method, ctor, dtor chaining. #base. prefixing works for academic use cases, IAnimal to ICat or IDog, for instance.

In T170647#2563059, @michaelwplde wrote:

Have my eyes on the XPS OOP effort going on, aimed at leveraging the HMO work. I understand couple of improvements, corrections, in the dev queue around that effort. Meanwhile, trying to make a somewhat uninformed usage involving some forms of method, ctor chaining. I wonder if the internals are prohibitiing some key liberties I am taking in order to achieve that.

Have my eyes on the XPS OOP effort going on, aimed at leveraging the HMO work. I understand couple of improvements, corrections, in the dev queue around that effort. Meanwhile, trying to make a somewhat uninformed usage involving some forms of method, ctor chaining. I wonder if the internals are prohibitiing some key liberties I am taking in order to achieve that.

TL;DR will review some of the comments eventually... however, can I suggest a more elaborate page detailing just _what is a HashMapObject_, particularly nuances along the lines of #Flags, what they are, what can they be, "sealed" for starters. thank you...

Is this issue back? I've observed the same behaviour since two weeks ago.

On a different note:
setMagazineTurretAmmo is broken when there are 2 players in a vehicle, it does not like split locality.

Revision: 151373

Storing stringtable keys, like "Is this defined" would be acceptable in this specific case. And also the package/container names would be okey in this specific case.
But this only applies to base game's stringtables from un-encrypted PBO's. For CDLCs I would say no.
I assume your mostly vanilla mission is unlikely to use CDLC stringtable keys anyway.

It would be very nice to see the following be implemented:

They are local.

Okay, after lots of testing, here is a patch that fixes all vanilla flare issues:

class CfgAmmo {
	class FlareCore;
	class FlareBase:FlareCore {
		intensity = 500000;
	};
	class Flare_82mm_AMOS_White:FlareCore {
		intensity = 1000000;
		effectFlare = "FlareShell";
	};
};

40mm flares inherit from FlareBase. From my tests 100k intensity (that RHS has) is nowhere close to OA or early A3 GL flare brightness, I tested 500k and it seems to be too bright it seems to be close to whatever original A3 had:
original A3:

Here is what RHS does it:

class rhs_ammo_flare_m485: F_40mm_White
{
    intensity = 100000;

and vanilla config only has intensity defined in 2 classes, checked with

"'intensity' in (configProperties [_x, 'true', false] apply {toLower configName _x})" configClasses (configFile >> "CfgAmmo") apply {[configName _x, getNumber(_x >> "intensity")]}

In T172751#2467536, @dedmen wrote:

Revision 150736 now deleteVehicle also works on them

(allMissionObjects "#track") apply {deleteVehicle _x} will now delete all tracks (its not instant, they disappear next simulation cycle)
(allMissionObjects "#mark") apply {deleteVehicle _x} will now delete all footsteps

thank you guys :)

Update: Noticed that zooming in with the 3x-9x pulls the reticle out of center and down into the right.

Oh the Video seems to be encoded using Av1

but you will have to execFSM with allowTerminate param

We will add a "Auto" ultra-wide option. That should take care of you.
Its the same as the old Auto but it disables triple-head.
Dev branch tomorrow. maaybe profiling branch

ignoreForTargeting _unit or _unit setKnowledgeLimit 0 would be nice as well

Looks like removing all action "preprocessings" was a bit too much and it breaks some actions. I'll have to go case by case