CEONSS

Overview and Current Status (04/04/2016):

A comprehensive examination of over 300 logs on ut2004stats.epicgames.com indicates that damage types from custom content created after late 2013 are never listed on matches' per-damtype frag tables. Confirmation that the unlisted data is contained within the corresponding match reports sent from a live server to the site lends substantial credence to the hypothesis that this omission is likely owed to a bug in ut2004stats database's internal custom DamTypes reference method, one probably related to a key's conservatively assigned value space (e.g., defined as a 2-byte short integer, ranging from 0 to 65535, rather than something longer) that's now been exhausted and prevents newer content from being properly registered when first seen and then listed.
As of this writing, the status of the bug appears to be one of official acknowledgement after communication with an Epic Community Manager, but with a poor outlook regarding being addressed.

---------------------


So while perusing some ut2004stats pages, looking for insight into how gameplay has actually changed in the most recent Tanks-a-Lot edit (which features the Basilisk) compared to my previous predictions, an unexpected oddity came to my attention instead: there are no frag stats for its damtypes to be found at all in any of the map's CEONSS-hosted matches. I knew for a fact that at least in one match some Basilisk kills did occur, so the hypothesis of some freak statistical aberration going on (i.e., nobody ever actually using it) wasn't valid to begin with, and looking through more n' more TaL-V5b matches it became clear they were simply not being registered at all.
At that point, it was already safe to say this qualified as some kind of bug, but to determine to what project's thread reporting the issue belonged (here or in TaL), I had to broaden the search scope a bit more to include other maps with existing online match stats where the Basilisk has been added. After wading through a sizable number of broken match stats - and that's another baffling n' longstanding issue that's been plaguing most ONSPlus servers and IMO merits its own sleuthing at this point, btw - here's what the full(er?) picture looks like in terms of the presence of Basilisk frags:

- Tanks-a-Lot-V5b: fully detailed stats, never appears among shown damtypes in the 17 listed matches; total frag counts almost never fully match up to breakdown tables' figures (usually a +5-6% discrepancy for total frags, possibly belonging to undocumented Basilisk kills)
- ONS-Tanks-A-Lot-2014: partially broken stats, but never appear among shown damtypes in the 45 listed matches
- ONS-DesertJunkyard-V10: entirely broken stats, but never appear among shown damtypes in the 44 listed matches
- ONS-Nevermore-TMU-2015-V2: entirely broken stats, but never appear among shown damtypes in the 25 listed matches
- ONS-MinusTankMeUp-Randomizer-V5b: partially broken stats, but never appear among shown damtypes in the 59 listed matches

Okay, seems the issue has more to do with the Basilisk than being endemic to the TaL edit, but is this all there is to it? On a lark I tried expanding even further to include all other vecs sharing the same heatray-shockwave weapon in maps with recent ut2004stats data available. This wasn't exactly a massive undertaking, to be honest, as it just involves the Helios SPMA included in the recently made ONS-ArcticJunkYard, and the older Poltergeist being a part of the custom vehicle loadout for ONS-GritNights-TMU-2013-V1, both hosted on the Omni server. Still...

- ONS-ArcticJunkYard: broken stats, but Helios driver gun frags never appear among shown damtypes in the 42 listed matches
- ONS-GritNights-TMU-2013-V1: broken stats, too few matches to draw useful conclusions, but Poltergeist frags absent among the listed damtypes

At this point it seems likely that all custom vehicles incorporating the heatray-shockwave weapon code share the flaw of not having their frags listed in ut2004stats for some reason, even though they are properly recorded and displayed in players' individual frag tables ingame - albeit both just under the vehicle's name rather than separately.

As a final pair of minor observations arising from looking into all this, for one thing, the similar in behaviour Antigrav SpiderTank laser beam does get proper billing for its DamTypeSpiderTankAGSliceBeam kills in Minus-Rando-V5b and MasterShower-V3-SP3, even though I didn't manage to discern any crucial difference between its implementations and that of the Basilisk from a quick glance. Lastly, while not directly related, your Battery Launcher also doesn't seem to be getting its hitscan zap kills listed in Epic's match data repository, although probably for a different reason.

Anyway, heads up, Worms, we got a data-eating bug on the loose!

Hmm, very strange bug indeed. However, I'm not even sure it's something I could fix.
You see, there is a central place in UnrealGame.UnrealMPGameInfo where all the kill stats are dispatched: This function calls the PRI functions for registering the kill in the ingame stats screen and the GameStats function that sends the kill event to the global stats server. If you had local stats set up, the same function would also log the data there.

There is nothing special about the heatray/shockwave damage itself or the way it is applied (all standard TakeDamage as it's used all over the place in stock and custom damage sources alike) and, in fact, the stats logging doesn't even care about any special damage type properties. Stats logging only ever sees the damage type name: The KillType parameter originates from Engine.GameInfo.Killed() and can be either "K" (regular kills and suicides) or "TK" (team kills). GetItemName(string(Damage)) ends up being the damage type's unqualified class name, e.g. "DamTypeBasiliskBeam", "DamTypeAttackCraftMissile" or "DamTypeRedeemer".

(GetLastWeapon(), although quite unrelated to this bug, returns the last actual weapon the victim player ever had in their hand. If you spawn and hop right into a Minotaur and die in there, your last weapon will likely be an Assault Rifle.)


The stats screen tracks damage differently: The PRI has a list of weapons and vehicles and each entry has three counters - "kills with", "deaths by" and "deaths while holding/driving". For Weapon/VehicleDamageType classes, it reads the associated WepaonType or VehicleType in the damage type and assigns the kill to the appropriate counter of the corresponding entry. That's why you will only ever see "Basilisk" or "Shock Rifle" in there, not "Heat Ray" or "Shock Combo". But the fact that you see "Basilisk" there at all makes me suspect the problem elsewhere: on the stats server.

How long are the Aegis and PPC Tank around already? (Those seem to show up in the stats.) How long is the AG Spider thingy around? What if the stats server's backend logic did not expect such a huge number of damage types to pop uo eventually? It wouldn't surprise me if they were cheap and only allocated e.g. a smallint column as the primary key for a global damage type list table. (I know UTAN once had that problem - the tracker table had an int primary key and that became too small at some point.)

It would be interesting to see if local stats log files correctly contain appropriate kill event lines.

[edit]
Shouldn't there also be some Badger kills in the TaL stats?

Sorry about the response delay, it's been a pretty busy last few days with little room for web writing, so this had to sit half-finished for most of the week till I could find the time (and sleep-replenished brainpower) to finish it.

Wormbo wrote:[...][T]he fact that you see "Basilisk" [in the ingame stats screen] at all makes me suspect the problem elsewhere: on the stats server.

How long are the Aegis and PPC Tank around already? (Those seem to show up in the stats.) How long is the AG Spider thingy around? What if the stats server's backend logic did not expect such a huge number of damage types to pop uo eventually? It wouldn't surprise me if they were cheap and only allocated e.g. a smallint column as the primary key for a global damage type list table. (I know UTAN once had that problem - the tracker table had an int primary key and that became too small at some point.)[...]

So, at first, even after reading the above paragraph a few times, I wasn't able to make sense of the context these questions were framed in, because the phrasing made the whole thing seem like you were examining the issue within the confines of, say, a particular match or just throughout the tenure of this latest edit. In that sense, my instinctive thoughts were something like "err, both the Aegis and the PPC tank are there from the very start, just like the Basilisk is, what do you mean 'how long'?", which wasn't leading anywhere. Helpfully, however, after taking some time away, it occurred that the last bit you edited in about the equally absent Badger damtype frags was the missing Rosetta stone, pointing to an even wider scope than I'd ever expected to consider at first, namely a systemic flaw.
But before that, to back up a bit and offer a more useful response regarding how long any of the aforementioned newer custom vecs, along with their corresponding damtypes, have been around, historically speaking, this took a bit of archive diving. Going by the dates of my permanent cached assets then, the safest answers I can provide are that, judging by the BioAegis_* and PPCTank.u dependencies, both the Aegis as well as the PPC tank have been around at least since early 2010 (although I certainly remember using 'em in other servers even before CEONSS' late-2009 launch), while the map where I first encountered the Tarantula Anti-Grav Tank online, namely ONS-MasterShower-V3-beta1, was downloaded in late October 2010. In all cases, then, we're talking about custom content that's at least older than 5 years.
Equally interestingly, while the Badger damtypes are indeed absent from the recent TaL edit's ut2004stats match listings, as you point out, when one turns to maps in which the previous Badger version is still present, like ONS-Tyrant-{KL}-BigAl-V2 that CEONSS still hosts (for some strange reason), lo and behold, they're present and accounted for - almost grabbing top billing too! Key difference between these two is that the older Badger's damtypes were BadgerCannon_Kill, BadgerGrenade_Kill, BadgerMinigun_Kill, BadgerPancake and BadgerRoadkill, whereas the new version, designated "Mk. II" and found in your Badgers_V2beta3.u pack, departs from that convention and instead uses the more indicative terminology of DamTypeBadger*, which results in 5 new damtypes the Epic master server hadn't encountered (and enumerated) before. These, indeed, do not appear anywhere in ut2004stats.

To return to the larger point, this observation definitely lends more credence to the hypothesis that what's amiss has more to do with damtype recency in general rather than just being the result of some exotic conflict between the heatray/shockwave damtypes in particular and some other bit of custom code happening to've been embedded in the same map, an assumption that probably "seeped over" to this topic from my current thoughts regarding the neighbouring problem of near-empty match stats (possibly due to all pre-match player connect events getting intercepted/mishandled somewhere along their propagation and across the various mutators'/addons' code?). If recency's the key to all this, however, the obvious question that arises is, "how recent are we talking about?"
Well, for one thing, Badgers_V2beta3.u seems to've been released around early 2014, while the aforementioned (in my previous post) ONS-GritNights-TMU-2013-V1, being the only map I can cite that hosts some of your newer hover vehicles showcased in this thread and which still gets played on occasion (and therefore has recent ut2004stats), is from, unsurprisingly, late 2013, September in my archive; as already covered, no references to the hover vecs' damtypes exist in those stats. Predictably, custom vehicles from later dates (winter 2013 and on), such as the Draco, the Perses and the Banshee, do not have their individual damtypes appear in any of the online hosted maps featuring them that are still getting played - namely, ONS-Syrma-SE/ONS-Syrma-)o(-SE-V4 and ONS-DiamondSword-Turbo)K( for the Perses, and ONS-SlatedWorld-BigAl-V2 for the Banshee (no live maps still feature the Draco AFAIK).
Going by the above, it would seem that this presumed key values exhaustion event likely happened somewhere within 2012 or around early/mid-2013 at the latest, since custom damtypes from 2011 are present in a number of cases I looked into. If true, this raises the question of how an issue as odd and cross-gamemode-spanning as this managed to remain unnoticed for such a long time across the UT communities that both you and I have been monitoring or frequenting for the past number of years; although I suppose it's always possible someone might've brought this up elsewhere, but it just never got passed along (or emphasized) enough to ripple across to our attention.
Lastly and even more crucially, viewing this problem in conjunction with its sibling (albeit map-n-match-specific) data-gobbling bug mentioned previously, as well as taking into account the rather restrictive 30-day stats retention Epic's server works off of, it all points to a set of, let's say, pretty challenging conditions that both modders and server staff have to face day in and day out as far as data-driven development of new custom content and content management go respectively, and their impact isn't exactly beneficial either. So the major and concluding question obviously is, what can be done about it at this point?
Personally speaking, I dunno how pragmatic it could even be at this point to consider appealing to Epic or expect them to do anything about it, although I don't suspect it would take any DBA worth their salt more than half an hour a morning to, say, reset such a key, while, optionally, also preserving functionality for extant match stats by re-indexing recently seen damtypes with (much) lower fresh values. Their current company stance n' agenda in terms of supporting older, but still active, UT titles versus wanting to shift their entire community's attention to current projects doesn't exactly fill me with confidence for a fortunate outcome, but, of course, I could be wrong here - hell, I'd welcome a pleasant surprise in that sense no matter how unlikely. Either way, establishing rapport with any official representative at their msg. board isn't something I've ever pursued, and this hardly seems the circumstance to be rolling the social dice under. That said, should anyone else care to pick up this torch n' take the issue to Epic Central, they can certainly count on any support from me they might need to bolster their case, through data digging or otherwise.

Anyway, however things pan out, thanks for helping get to the bottom of this, Wormbo; at least now we'll know what stats to expect to (not) see and why.


PS 1:

Wormbo wrote:[...](GetLastWeapon(), although quite unrelated to this bug, returns the last actual weapon the victim player ever had in their hand. If you spawn and hop right into a Minotaur and die in there, your last weapon will likely be an Assault Rifle.)[...]

Hmmm. Given the existence of per-vehicle "deaths holding" stats in players' personal ut2004stats pages - but only for stock vehicles - in the "Vehicle and Turret Specific Totals" table, but all the zeroed out values for custom vehicles' turret pawns/weapons in the immediately preceding "Weapon Specific Totals" table, as well as the fact that the GetLastWeapon function essentially returns the class of the weapon a controller's current pawn possesses, which, if they're in a vehicle, shouldn't normally be returned as an xPawn (with whatever gun inventory that might have), but as the vehicle's own [ONS]Weapon, I gotta admit to some confusion on the matter of whether an AR-wielding player dying inside a Minotaur would result in them getting an additional notch to their AR's "deaths with" stat, to their Goliath's corresponding stat (because Omnitaur extends ONSHoverTank, even though its turrets extend ONSWeapon), or to no stat addition anywhere :s. I mean, purely from a game design perspective, what sense would it make to downgrade efficiency related to any infantry weapon when the player died inside a vehicle and not using it? Ah well, minor point anyway.

PS 2:

Wormbo wrote:[...]It would be interesting to see if local stats log files correctly contain appropriate kill event lines.[...]

I have some experience using a localhost server for non-standalone context map testing in the past, but it's pretty limited, so I'm not sure about this one: is this achieved through turning on bEnableStatLogging in UT2004.ini?

Thanks for the thorough analysis to narrow down the date range on this potential exhaustion bug. That may help explaining our hypothesis to the Epic folks. (And sorry about the confusion caused by butchering the grammar almost beyond recognition in my previous post.)

About the local stats logging: You need to set bLocalLog=True in [Engine.GameStats] (to enable writing log files) in addition to setting bEnableStatLogging=True in [Engine.GameInfo] (to spawn the stats logging actor). Addtionally, the GameStatsClass must be valid, e.g. "IpDrv.MasterServerGameStats". The logs produced by that correspond to the stats data sent to the masterserver. If the new damage types show up there, it should confirm we are seeing an issue on the masterserver side.

GetLastWeapon() only returns the weapon of the current Pawn when it actually still has a weapon. Otherwise it will return the class stored in LastPawnWeapon, which is updated only on weapon change or on death if the Pawn's Weapon still is valid.

Pegasus wrote:[...]ONS-Tyrant-{KL}-BigAl-V2 that CEONSS still hosts (for some strange reason)[...]

It's on the "to-do list".

(no live maps still feature the Draco AFAIK).

The Draco is on ONS-Kingdom_SE-(RTS)-BadWolf-SP4 and ONS-MinusTankMeUp-Nightwolf-C-R-beta2, Minus also has the hover Badger from Badgers_V2beta3.u

Kingdom's stats show up, Minus do not.

Pegasus wrote:PS 2:I have some experience using a localhost server for non-standalone context map testing in the past, but it's pretty limited, so I'm not sure about this one: is this achieved through turning on bEnableStatLogging in UT2004.ini?

Wormbo wrote:About the local stats logging: You need to set bLocalLog=True in [Engine.GameStats] (to enable writing log files) in addition to setting bEnableStatLogging=True in [Engine.GameInfo] (to spawn the stats logging actor). Addtionally, the GameStatsClass must be valid, e.g. "IpDrv.MasterServerGameStats". The logs produced by that correspond to the stats data sent to the masterserver. If the new damage types show up there, it should confirm we are seeing an issue on the masterserver side.

I'll enable it tonight.

Well, that was not quite unexpected:

Stacey Conley @Flak wrote:It doesn't look like it's going to be fixed

Unfortunate. Not exactly surprising, as you point out, but unfortunate nonetheless. Ah well, at least we got acknowledgement via official word on it, so... that's something? 'Sides, all is not lost, as there may be alternative routes & methods that could be explored and developed unilaterally in order to restore part of the missing data, but such kind of brainstorming's probably best left for later posts.


As a minor and somewhat belated addendum that I'd still like to get on record, I should point out that, in an effort to proverbially dot the I's and cross the T's to this bug's documentation about 10 days ago and prior to a possible official presentation, I sifted through the ut2004stats match data from the two Draco-featuring maps that Cat mentioned to ensure it all conformed to our assumptions about the bug. Everything looked in line with it, but near the end of this 70-plus-log check I came upon a match in Minus-TMU-NW-C-R-b2 (that's a lot of suffixes!) from Feb 17th that places the previously proposed hypothesis in doubt by containing a single DamTypeBansheeRoadkill frag entry in its weapon-specific table (over-a-month-old source is, predictably, dead, but archived here)! The presumed "2012 to mid-2013" period of first appearance was an estimate that relied on the individual Banshee damtypes' ut2004stats absence being considered as a bug-induced fact, in hindsight erroneously concluded due to the small sample size of maps & matches, in conjunction with the apparent rarity of the vehicle's use by players. Be that as it may, this naturally threw a wrench into the whole notion and sent me scrambling to refactor the chronology by digging around even further. To be clear, this doesn't place the existence of the bug itself into question, as IMO there already exist sufficient and compelling proof of that, but it does demand a readjustment of the timeline to actually accommodate this finding by (re)considering the likelihood of a few possibilities. Specifically, the following two:
- In my initial post about the issue, and as far as ut2004stats is concerned, the Banshee was presumed to've first appeared in "winter 2013" or later, but is that really the case? While the first version of the vehicle was officially presented on Aug. 30th and indeed "premiered" online in a pair of maps in the following two months (ONS-Evergreen-Turbo)K(-V2 in mid-Sept. and ONS-SlatedWorld-BigAl-V2 in late Nov. 2013), going by the header of the relevant class itself within WVBanshee.u, the actual creation date is marked as 2013-02-15, i.e. a full six months before its official release; oh, and kudos here for properly documenting your work, btw, Worms - it happens rarely, but in cases such as this, it can help a lot . Odds may be low with UT2004 being almost a decade old by that point, but there is still the possibility that someone was handed a beta version of the custom vehicle for feedback purposes and they decided to give it a trial run on their personal server that was somehow live stats-enabled, thereby causing the site to "see" and index the Banshee's damtypes before September, thus rendering the "November premiere" assumption inaccurate by as much as half a year. Thankfully, Wormbo is still around, active and can shed some light here, so the likelihood of this scenario won't be hard to ascertain. If it's somehow true though, it would necessitate shifting the earlier end of the bug's appearance window from beginning of 2012 to whenever that hypothetical beta trial took place within early/mid-2013.
- The plausibility of another, even more exotic, possibility to consider here has to do with how ubiquitous the Banshee name is for a vehicle among gaming & modding communities. Consider that just within Epic's own msg. board there's references to at least two "official" Banshee vehicles from other games being considered and/or worked on to be ported to UT2004 at different times, namely the Halo Banshee and the C&C Tiberian Sun Nod Banshee; all that is to say nothing of any other creator doing their own thing and deciding to give their own custom vehicle that same name just because "it sounds cool" or whatnot. The chance, then, cannot (and should not) be automatically dismissed that somehow, somewhere and by some freak coincidence a completely unrelated DamTypeBansheeRoadkill might've appeared years before Wormbo even began work on his cicada mod, thus getting "grandfathered in" before the presumed exhaustion bug and accounting for its visible listing now on a recent MinusTMU edit's match log in 2016 ...not without some amount of investigating anyway. After all, whether earthbound or flyer, all vecs can get a roadkill frag so that should be grounds enough for plausibility.
What I managed to conclude after a few (busy) days' worth of sleuthing focused around the forums.epicgames.com domain is that, for one thing, the Halo Banshee was part of the released HaloUT P1.5 project (live link, 43.7MB, umod pack), but after having had to look for a third-party tool to unpack it with (because ucc doesn't do it natively, for some reason :s), it turns out it doesn't use any such damtype, so that's one down. As far as the (most?) prominent project aiming to mass-port C&C:TS vecs over to UT2004, namely the C&C vehicles pack (also more tersely known as UTCC at their home site), that too came into fruition in 2005 with the UT2004 C&C Vehicle Mutator (11.2MB, zip archive), but the Banshee didn't make it into the near-dozen vehicles included in said pack (probably for the best, considering the overall porting quality).
Apart from the previous two cases, no other reference to custom vehicles by the same name led anywhere useful, so as a bottom line, this "false positive via ancient doppelganger" scenario remains a far-fetched, but not dismissable, possibility until some other damtype undoubtedly related to Wormbo's Banshee gets sighted in the ut2004stats wild, thereby proving the bug took place later than when WVBanshee.u went live. For reference, the damtypes one should be on the lookout for are WVDamTypeMercuryDirectHit, WVDamTypeMercuryHeadHit, WVDamTypeMercuryPunchThrough, WVDamTypeMercuryPunchThroughHead, WVDamTypeMercurySplashDamage, DamTypeBansheeLinkBeam, DamTypeBansheeLinkPlasma and (the less forensically useful) DamTypeBansheePancake. So, you know, if you spot one of those, give us a call at 1-800-DAMTYPE for a surprise prize*! At any rate, in the extremely unlikely case that this is true, it'd simply invalidate the weight of the MinusTMU finding, thereby making the original bug time placement assumption the prevailing one again.
As a footnote to this section, that same MinusTMU match log also happens to contain a mysterious "Unknown Weapon" entry in the same per-damtype frags list that I cannot offhand ascribe to any custom content embedded or included in that edit; any guesses what that might be about :s?

* There is no prize; surprise!


Okay, that about concludes the addendum. Apologies for the lengthy exposition there since it's not likely to have any bearing at all to how this bug gets treated going forward, but I felt it ought to be included in the thread all the same, even just for the sake of honesty and accuracy after looking into all this. Beyond that, there's two final, related points left to (quickly) go over.
Firstly, I hope by this point it's safe to assume that all participants in (and observers of?) this bug hunt are probably convinced the issue has little to do with Wormbo's hover tank collection specifically, meaning this page's discussion can now be regarded as a derailment that's irrelevant to this topic's initial subject and, therefore, as a stub in need of relocation. As such, unless any objections or counter-proposals are presented in the coming days, I plan to tear it off from here and place it in its own thread in the msg. board's General forum (as it's not CEONSS-related, nor about a specific creative project) within the next week, under a header like "[Known bug] Recent custom DamTypes not listed in ut2004stats' match logs".
Finally, while I know that hunting and documenting a bug can be tedious and time-consuming work, it's the only time in recent memory that this specific iron has been hot, so to speak, so... would either of you (and/or anyone else) be interested in looking into this bug's data-eating sibling that's been causing ut2004stats match logs to look like ghost towns next? It might be a bit harder to pin down, as, by a preliminary look of things, it seems to only occur as the result of a number of coinciding custom-coded factors, but, on the upside, if we do manage to trace it to its source, squashing it shouldn't involve any official sources, meaning we could do it ourselves. Also communities beyond our own could stand to benefit from addressing it as well, so, who knows, we might even get some unexpected help along the way from elsewhere too. So... any takers?

As far as beta testing goes, I probably didn't give it to anyone but CEONSS and/or Omnip)o(tents. But I can't rule out testing it on my own local server while stats tracking was enabled.

I'm going through by backups at the moment, checking timestamps of files and folders. It seems I created the WVBanshee folder in mid-August 2012 already. The WVPersesMAS folder even appears to exist since August 2011 with its damage types class files having creation dates in the same month. The first hover tank damage type classes (those of the Firebug) seem to exist since mid-October 2012. That's a bit odd, as the first one was the Poltergeist, back then called just "Hovertank". Renaming the classes via UnCodeX may have not renamed the file, but actually created a new one. The Hovertank class file itself was created in August 2011. For the Railgun Tank, I can see change dates from June 2010.
I think some of those dates may have been the result of some copy operation between my PC and laptop. (The Railgun Tank's file creation dates are in March 2011, for example.) Yeah, some of my releases lurk around for years before I get around to bring them to a releasable state. Some of those things are never going to see the public, or at least not any time soon, despite existing for years already.

Pegasus wrote:As a footnote to this section, that same MinusTMU match log also happens to contain a mysterious "Unknown Weapon" entry in the same per-damtype frags list that I cannot offhand ascribe to any custom content embedded or included in that edit; any guesses what that might be about :s?

EONSGrenadeLauncher, EONSMineLayer, PortableIonPainter?

----------

If you give me a couple of weeks i can go through all of our maps and build a complete list of missing info and what vehicles those maps have. Perhaps then we can see the trees from the forest.

Cat1981England wrote:EONSGrenadeLauncher, EONSMineLayer, PortableIonPainter?[...]

EONSGrenadeLauncher: DamTypeEONSGrenadeProjectile
EONSMineLayer: DamTypeEONSMineProjectile
PortableIonPainter: uses stock IonCannon class, thus DamTypeIonBlast

Doubt it's any of the older custom stuff, cause we would've caught sight of this oddity years ago; gotta be something more recent, I reckon :/. Given that, IIRC, this edit requires wrangling some 30-ish files in order to extract its classes, do a full census of what all custom stuff is in there and start checking further, I'm afraid I don't have any more helpful leads to offer tonight.

Cat1981England wrote:[...]If you give me a couple of weeks i can go through all of our maps and build a complete list of missing info and what vehicles those maps have. Perhaps then we can see the trees from the forest.

Heh, if you're referring to the (near) empty match reports bug with that, it's been around for years, as you know, so there's not exactly any rush to solve it within some immediate timeframe. I do suspect it might require a fair amount of DDx-ing as far as isolating/excluding suspect bits of code, and perhaps also the use of the match server as a comparison platform to get some of the necessary findings, though, so, you might wanna keep that in mind too in terms of planning and CEONSS resources availability, if that comment is your way of signing up for the hunt .