2.1 Discussion on AI weapon spam "rate of fire" bug

Be interesting to see if the NPC handover code is to blame for any of the other accusations of them cheating or their odd fails to jump out etc - he might be onto a goldmine!

Good work that man!
 
Well if you read Mark's explanation in detail, he outlined that the bug was happening with a combination of events that included transfer of control of the NPC from one instance to another - that only happens in Open / group modes, so if you were playing in solo you would not see it. I believe it would also only happen when there are other players in the same instance, and the player whose machine is controlling that instance leaves - that means that the whole instance needs to be passed off to another machine. It's at this point that things went wrong if I understood correctly.

Huh, so it's possible that solo mode isn't affected by this bug at all? I might just grab my Python and play in solo until the update then...
 
Huh, so it's possible that solo mode isn't affected by this bug at all? I might just grab my Python and play in solo until the update then...

I play almost exclusively in Solo and I have not been affected by this bug. Seems like a viable route to go until the rest of the bug gets patched out.
 
Haha, so now people are leaving Open for Solo because even the NPCs in Open are cheating gankers! :D



(I'm kidding! I'm kidding! I love playing in Open, especially in a few days when the bug is fixed. Just thought it was funny :) )
 
Last edited:
Mark, thanks so much for the detailed response. I know that takes time out of your day to do, but I absolutely love learning the little behind the scenes details.
 
On one hand, this is a nice look under the hood. Always fascinates me when developers can explain to a layman what went wrong. On the other hand, how long was the beta? How was this not caught?
 
On one hand, this is a nice look under the hood. Always fascinates me when developers can explain to a layman what went wrong. On the other hand, how long was the beta? How was this not caught?

If I had to guess... Low number of beta testers = Insufficient feedback
 
If I had to guess... Low number of beta testers = Insufficient feedback

And/Or, low number of beta testers = low probability of getting the extreme manifestation of the bug. If the pointers were pointing to weapon types that are somewhat close, then it's possible players didn't notice, or chalked it up to "new feature" instead of a bug.
 
If I had to guess... Low number of beta testers = Insufficient feedback

Likely. Especially given the bug only presented in certain circumstances.

I also feel that beta testers are less concerned about negative outcomes like this during beta. They're not supposed to be. That's the whole point of beta. Make everything cheap and easy to get so that you can experiment, and nothing affects your live account. It's amazing how much more effort you put into looking for answers to things that actually start to hurt. That's just a theory, of course. [wink]
 
And/Or, low number of beta testers = low probability of getting the extreme manifestation of the bug. If the pointers were pointing to weapon types that are somewhat close, then it's possible players didn't notice, or chalked it up to "new feature" instead of a bug.

Honestly when beta testers died to AI ships they probably just chalked it up to the new improved combat AI using strong engineer weapons. Seems like a plausible explanation to a quick death. It wasn't really until we started seeing AI ships from an outside view spewing plasmas like Gatling guns that we knew something was terribly, horrendously wrong. That prompted all of the closer examinations that led to discovering the bug.

Not to sound daft, but a longer beta testing period probably would have found this before it went live. :D

I'm just very happy it's now figured out and getting fixed. [yesnod]
 
In the books of the series War Against the Chtorr, by David Gerrold (inventor of tribbles[hehe]), there was a cool hand held weapon called a needler. It was a rapid fire gauss rifle (similar to rail gun) that fired about 1,000 tiny needles per second at a very high velocity.
If this weapon was converted to an ED ship based weapon, we would have a beam railgun [woah]
 
The hilarious part (for people not being aimed at) is that the bug can potentially cause hybrids of almost any two weapons... In my testing I've seen cases of railguns firing like slugshots, cannons firing as fast as multicannons, or my favourite absurd case of a Huge Plasma Accelerator firing every frame because it thought it was a beam laser... Ouch.

Ouch doesn't even begin to cover it. :D

Let us assume that the dps on coriolis.io is correct at 26 MJ/s. Now the weapon fires each and every frame, not knowing if that means 30 shots or 60 shots per second, we have a multiplier of 30 or 60. That gives a grand total of 780 MJ or 1560 MJ per second. No wonder that commanders report seeing nothing but a bright light followed by the rebuy screen!

Cudos to Mark for the update and background info!
 
Given the speculation about what might be causing this bug, and what it means for the game - I thought I'd clarify a few things on the technical side :). Sadly it wasn't as simple a change as an un-initialised or out of range value, my head would be a lot less hurty this week if it had been!

So, to try and explain.
The data for a module in Elite is split up into a set of blocks: things like power consumption, vulnerability to overheating, health, and of particular interest in this case, Weapon data. Weapon data is about 40-50 values controlling everything from the more obvious rate of fire & range, to slightly obscure things like how fast the beam fades after you release the trigger. More or less any combination of values is allowed (you want a laser shotgun? sure, take a pulse laser and set the Rounds Per Shot value to 12). This flow is identical between players and npcs, even stations and skimmers actually.

Prior to 1.6/2.1 the cached pointer each weapon held to its data was a simple affair pointing at a bit of data loaded from resources, but as part of the changes to make items modifiable I had to change this so it could also be a pointer to a block of data constructed from a base item plus a set of modifiers - ideally without the code reading that data caring (or even knowing) where it actually came from and therefore not needing to be rewritten to cope. This all works great in theory, and then in practice, up until a few naughty NPC's got into the mix and decided to make a mess. I'll gloss over a few details here, but the important information is that a specific sequence of events relating to how NPCs transfer authority from one players' machine to another, combined with some performance optimisations and an otherwise minor misunderstanding on my part of one of the slightly obscure networking functions got the weapon into an odd state. The NPC's weapon which should have been a railgun and had all the correct data for a railgun, but the cached pointer to its weapon data was pointing somewhere else. Dangling pointers aren't all that uncommon (and other programmers may know the pains they can cause!) but in this case the slightly surprising thing was that it would always be a pointer to a valid WeaponData - It's correct enough that it'd never have tripped any of the sanity checks or asserts that something was wrong, and yet.. clearly it's not right either!

What did this do exactly? Well in that example the weapon would have thought it was a slugshot: it'd make decisions on ammo, when to fire, how much power to consume and heat to generate as if it were a slugshot. It then tells the game to fire 12 shots but now we're outside the areas that use the cached data, the weapon manager knows its a railgun and dutifully fires 12 railgun shots :p. Depending on which machine this occurred on exactly it would either be as a visual artefact only that does no damage, or (more rarely but entirely possible) the weapon would *actually* fire 12 shots and carve a burning trail of death through the space in front of it. The hilarious part (for people not being aimed at) is that the bug can potentially cause hybrids of almost any two weapons... In my testing I've seen cases of railguns firing like slugshots, cannons firing as fast as multicannons, or my favourite absurd case of a Huge Plasma Accelerator firing every frame because it thought it was a beam laser... Ouch.

Why does this never occur on players? Well AI and players aren't governed by different rules in combat - but one thing AI's do that players never do is transfer authority between machines (it's rather hard to move out of range of yourself after all), which is the trigger at the heart of this bug. Removing modified weapons from NPCs earlier in the week will have reduced the frequency of the problem as it's more-or-less tied to how many modified weapons are in the session, the fix included in the build Zac mentioned coming soon should stamp it the rest of the way out. With the usual caveat of programmers: I fixed the problem I found, can't promise it's the last one!


Much as I love the insane weapons, and part of me likes having the proof that actually the system is hugely flexible... lets add them when we mean to next time! er... Sorry ;)

-Mark


As a developer i know your pain. Thank you for sharing :D Had a good laugh until.... i realized that i am at work right now and need to fix my own code. Damnit :p
 
Last edited:
Back
Top Bottom