2.1 Discussion on AI weapon spam "rate of fire" bug
- Thread starter Mengy
- Start date
Commander Henna got this twice in a row the lucky guy, couldnt afford to rebuy twice
Haven't had it yet and I'm being very careful with my credits, what do frontier do to people that have been killed because of this? credit refund?
Haven't had it yet and I'm being very careful with my credits, what do frontier do to people that have been killed because of this? credit refund?
Yes. You can simply submit a support ticket and you'll get your credits back.
I'm not clear on whether the update happened or not. In other threads there's discussion of basically the same glitched weapon behavior still happening, so maybe they didn't get it done before they knocked off for the day and went to the pub?
I posted in the bug thread already but I'll put it here as well cause it's cool! Taken today, I think after the 'change'. The OMG comment at the end was from my wingman and not related to the situation, although it fit perfectly.
[video=youtube_share;6vrQ0zsvDic]http://youtu.be/6vrQ0zsvDic[/video]
Same guy, a little later nearly killed me with splash damage!
[video=youtube_share;2g6pdbjjfYQ]https://youtu.be/2g6pdbjjfYQ[/video]
[video=youtube_share;6vrQ0zsvDic]http://youtu.be/6vrQ0zsvDic[/video]
Same guy, a little later nearly killed me with splash damage!
[video=youtube_share;2g6pdbjjfYQ]https://youtu.be/2g6pdbjjfYQ[/video]
Last edited:
I feel the need to voice my opinion on this 'bug'. I find it very, very disheartening.
Not because it's there; bugs happen. But because of what can be inferred from it.
Unless a player can reproduce this bug for his own weapons - and there has been to my knowledge no such instance - it IMHO shows that the statement 'the AI plays by the same rules as players (minus MC ammo)' is misleading.
If that was the case, the weapon model
* would stop firing for the proper ROF and reload (both visibly missing)
* would decrease WEP capacitor storage (missing, those plasma balls would empty any capacitor after at most 10)
* would increase ship heat (the ship should boil with modules failing everywhere - not conclusive, but I don't see any degradation in, say, maneuverability).
It fails to do so, otherwise there would be no such videos. And the AI shouldn't be able to do anything else than a player: pull the trigger & juggle PIPs - I take FDevs word on that. Hence, the weapon model alone would not permit this behaviour if it was identical to the players'.
From that I conclude that the NPC ship modules use a completely separate set of module/model parameters - and if there's an issue with that second/NPC parameter set (e.g. like here: ROF 10/sec, reload 0s, heat +0, energy -0) like behaviour occurs - a bug.
So yes. The NPCs play by the same rules as players. It just seems with their own special parameter set. I dread to think about the possible consequences.
There's much guess work here all of which may be wrong. But I consider this conclusive enough to be disheartened and disappointed by it. Thus, I really wish FDev would describe how to reproduce this with player ships to prove me wrong.
Not because it's there; bugs happen. But because of what can be inferred from it.
Unless a player can reproduce this bug for his own weapons - and there has been to my knowledge no such instance - it IMHO shows that the statement 'the AI plays by the same rules as players (minus MC ammo)' is misleading.
If that was the case, the weapon model
* would stop firing for the proper ROF and reload (both visibly missing)
* would decrease WEP capacitor storage (missing, those plasma balls would empty any capacitor after at most 10)
* would increase ship heat (the ship should boil with modules failing everywhere - not conclusive, but I don't see any degradation in, say, maneuverability).
It fails to do so, otherwise there would be no such videos. And the AI shouldn't be able to do anything else than a player: pull the trigger & juggle PIPs - I take FDevs word on that. Hence, the weapon model alone would not permit this behaviour if it was identical to the players'.
From that I conclude that the NPC ship modules use a completely separate set of module/model parameters - and if there's an issue with that second/NPC parameter set (e.g. like here: ROF 10/sec, reload 0s, heat +0, energy -0) like behaviour occurs - a bug.
So yes. The NPCs play by the same rules as players. It just seems with their own special parameter set. I dread to think about the possible consequences.
There's much guess work here all of which may be wrong. But I consider this conclusive enough to be disheartened and disappointed by it. Thus, I really wish FDev would describe how to reproduce this with player ships to prove me wrong.
It’s an excellent point, and one I’ve also thought about.
It’s clear that the AI does not use the exact same set of rules as players do or yes like you said this would never happen, or at least players would be able to duplicate it, which we can’t. My gut feeling is that the AI uses a streamlined and faster routine for its system management, something meant to mimic the player’s ship systems routines but quicker with regards to CPU cycles. Or, like many people suspect, the AI does cheat some with regards to ship management and heat penalties, thus their own separate routines that got broken with a bug for 2.1. We’ll most likely never know because I doubt FDev will come out and tell us how this happened. Sarah has continually claimed that the AI does not cheat and that it uses the same rules as the players do. Clearly, they are not exactly the same rules.
This bug has been as interesting as it has been devastating IMHO.
They may have a significant advantage here too, of course; the best human pilot with them most efficient macros can still only juggle pips at a maximum rate if only because there's a finite time between muscle stimulus and the electronic signal reaching the PC. NPCs have no such restrictions and could be doing pips to engines, apply a brief thruster burst, pips to weapons, trigger a pulse laser shot, pips to systems to absorb a couple of shots, rinse and repeat very quickly which would give the illusion of a more efficient capacitor system over time. Not that it explains all of the AI behaviour. But it might contribute to AI that, while not actually cheating, can be much more efficient than a human pilot.
I'm not sure how this could be avoided other than by programming in artificial delays to mimic the slower reactions of a meatbag pilot. Who knows, this might already be part of how SJA scales the difficulty for lower rated NPCs.
My feeling is that AI ship loadouts are generated by a set of rules corresponding to the modules that we can buy, but those are represented on the actual ships you see in a session not as types such as '2F Fixed Pulse Laser' but as a long list of attributes usually defined by those types. Something went wrong either in writing or reading those attributes, creating ships with 'impossible weapons'. Because there is no fixed type that enforces those attributes, the NPCs were free to have a gun that fires plasma but with MC rates of fire, or beam lasers in a frag cannon spread pattern. The fix to remove the Engineer mods from loadouts being server side, and ED's backend being in part NoSQL, suggests to me that there are a bunch of JSON or XML documents on the servers representing NPC loadouts containing these untyped lists of attributes.
Drop me a friends request in game verminstar and I'll help you get used to these challenges
No argument here, it is harder to make the AI seem human than to make it god-like. But I feel this is not relevant to my observations. I know of no capacitor that would at 4PIPs put out enough power to fire (guesswork) 40 PA shots in a row. If the AI takes the PIPs elsewhere, as instantaneous as that may be, this would reduce the recharge rate accordingly making the 'MultiPA' behaviour even less probable.
Reload time should be completely unaffected by PIPs, with heat I am not 100% sure. My understanding is: more PIPs to SYS make the weapons cool quicker, but transfer the heat into the ship's reservoir. I.e. the weapons will overheat a tad slower at the expense of the ship toasting faster. Still, after 40 PA shots a player ship would go all melty - 4 PIPs to SYS or not.
Technical, quite possible. And with the degrees of freedom the Engineers give to modules, likely required. Also, this makes having different parameter sets for the modules much more practical.wstephenson said:
Mark Allen
Programmer- Elite: Dangerous
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. 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
. 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
. 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
Last edited:
Last edited:
So you're saying Thargoids?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
Also, the issue being related to authority transfer sounds like solo players or people in sparsely frequented space would be far less likely to be affected by that weirdness?
- - - - - Additional Content Posted / Auto Merge - - - - -
I want that plasma accelerator. Sounds way more fun.Now I want a laser shotgun.
Last edited:
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
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
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
Yes, some bugs are really nasty bugs. As a former programmer, I know it far too good.
Thank you for the explanation and hat off for an excellent job.
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
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
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
So, this is the beginning of Skynet, right? The machines learning how to bend the rules for their own good and ultimately develop the knowledge and ability to destroy the human race?