New Ai Damages own grid
Reported
The new Ai seems to be damaging their own grid, including custom turrets and normal turrets. Is this a bug?
The new Ai seems to be damaging their own grid, including custom turrets and normal turrets. Is this a bug?
I have the same bug
Note: Certainly for the CTC block, only the selected aiming reference, weapon or camera, is checked for intersection with its own grid, or generally any grid relevant for aiming and firing. If you have multiple weapons on the custom turret, and the view for the aiming reference is clear, the CTC fires all weapons even when the view is not clear for all of them.
This compounds with the issue that the CTC likes to be a dick and overrides your dedicated selection of a camera with an automatic selection of a weapon from the list (although granted, while a camera needs no lead angle, a weapon does), and depending on what order you placed them in, or what names they have, or what colour of socks you wore thirteen hours before you placed the weapon, this could be any weapon on your turret, and as such you have little to no control over which block actually ends up being selected as the reference … except perhaps when it's the only one.
Here's a classic ball turret with two columns of three gatling guns each. The CTC, in its whimsical mood, has decided to humour us with its selection of the top-left one, painted in red and with its aim visualised by the projection, as the reference. As you can see from the bullet marks on the yellow block, while firing at the battery owned by an enemy, the CTC obliviously coerces the middle and bottom pairs of gatlings into firing while they are still pointed at an otherwise friendly grid. And of course this is aggravated the higher the value for the permitted aiming deviation is.
Likewise, as soon as the aim of the reference weapon grazes the friendly block, the whole turret stops firing even though most of its weapons still have clear line of sight.
Granted, given how there could be any number of weapons in any arrangement on a turret, this is an understandable compromise. However, the player should have more control and authority over the reference block selection. For example, use the ballistic properties of the guns present and apply them to the camera's place on the turret as if it was itself such a gun. And/or make the reference gun explicitly selectable, too, instead of offering only cameras in the dropdown. As such, this is perhaps as much a feature request as it is a bug, or rather an undesirable side effect of an existing implementation, at least for the CTC.
As for the non-custom turrets, due to some of them having two distinct and widely spaced guns, they seem to be afflicted by a similar issue. On this test stand, the turrets can regularly be seen hitting the friendly yellow blocks with their respective left gun:
World attached. (Ignore the filename.)
Note: Certainly for the CTC block, only the selected aiming reference, weapon or camera, is checked for intersection with its own grid, or generally any grid relevant for aiming and firing. If you have multiple weapons on the custom turret, and the view for the aiming reference is clear, the CTC fires all weapons even when the view is not clear for all of them.
This compounds with the issue that the CTC likes to be a dick and overrides your dedicated selection of a camera with an automatic selection of a weapon from the list (although granted, while a camera needs no lead angle, a weapon does), and depending on what order you placed them in, or what names they have, or what colour of socks you wore thirteen hours before you placed the weapon, this could be any weapon on your turret, and as such you have little to no control over which block actually ends up being selected as the reference … except perhaps when it's the only one.
Here's a classic ball turret with two columns of three gatling guns each. The CTC, in its whimsical mood, has decided to humour us with its selection of the top-left one, painted in red and with its aim visualised by the projection, as the reference. As you can see from the bullet marks on the yellow block, while firing at the battery owned by an enemy, the CTC obliviously coerces the middle and bottom pairs of gatlings into firing while they are still pointed at an otherwise friendly grid. And of course this is aggravated the higher the value for the permitted aiming deviation is.
Likewise, as soon as the aim of the reference weapon grazes the friendly block, the whole turret stops firing even though most of its weapons still have clear line of sight.
Granted, given how there could be any number of weapons in any arrangement on a turret, this is an understandable compromise. However, the player should have more control and authority over the reference block selection. For example, use the ballistic properties of the guns present and apply them to the camera's place on the turret as if it was itself such a gun. And/or make the reference gun explicitly selectable, too, instead of offering only cameras in the dropdown. As such, this is perhaps as much a feature request as it is a bug, or rather an undesirable side effect of an existing implementation, at least for the CTC.
As for the non-custom turrets, due to some of them having two distinct and widely spaced guns, they seem to be afflicted by a similar issue. On this test stand, the turrets can regularly be seen hitting the friendly yellow blocks with their respective left gun:
World attached. (Ignore the filename.)
Hello, Peter!
Sorry to hear you're experiencing this issue. I have been looking into this and we do have this issue https://support.keenswh.com/spaceengineers/pc/topic/gatling-turrets-hit-armor-blocks relating to the turrets which I assume is possibly related? You mention specifically AI, if you see this as something different, could you please provide a save file and reproduction steps for us to reproduce the issue?
Please let me know if you believe you're experiencing a similar issue.
Kind Regards
Laura, QA Department
Hello, Peter!
Sorry to hear you're experiencing this issue. I have been looking into this and we do have this issue https://support.keenswh.com/spaceengineers/pc/topic/gatling-turrets-hit-armor-blocks relating to the turrets which I assume is possibly related? You mention specifically AI, if you see this as something different, could you please provide a save file and reproduction steps for us to reproduce the issue?
Please let me know if you believe you're experiencing a similar issue.
Kind Regards
Laura, QA Department
Note: Certainly for the CTC block, only the selected aiming reference, weapon or camera, is checked for intersection with its own grid, or generally any grid relevant for aiming and firing. If you have multiple weapons on the custom turret, and the view for the aiming reference is clear, the CTC fires all weapons even when the view is not clear for all of them.
This compounds with the issue that the CTC likes to be a dick and overrides your dedicated selection of a camera with an automatic selection of a weapon from the list (although granted, while a camera needs no lead angle, a weapon does), and depending on what order you placed them in, or what names they have, or what colour of socks you wore thirteen hours before you placed the weapon, this could be any weapon on your turret, and as such you have little to no control over which block actually ends up being selected as the reference … except perhaps when it's the only one.
Here's a classic ball turret with two columns of three gatling guns each. The CTC, in its whimsical mood, has decided to humour us with its selection of the top-left one, painted in red and with its aim visualised by the projection, as the reference. As you can see from the bullet marks on the yellow block, while firing at the battery owned by an enemy, the CTC obliviously coerces the middle and bottom pairs of gatlings into firing while they are still pointed at an otherwise friendly grid. And of course this is aggravated the higher the value for the permitted aiming deviation is.
Likewise, as soon as the aim of the reference weapon grazes the friendly block, the whole turret stops firing even though most of its weapons still have clear line of sight.
Granted, given how there could be any number of weapons in any arrangement on a turret, this is an understandable compromise. However, the player should have more control and authority over the reference block selection. For example, use the ballistic properties of the guns present and apply them to the camera's place on the turret as if it was itself such a gun. And/or make the reference gun explicitly selectable, too, instead of offering only cameras in the dropdown. As such, this is perhaps as much a feature request as it is a bug, or rather an undesirable side effect of an existing implementation, at least for the CTC.
As for the non-custom turrets, due to some of them having two distinct and widely spaced guns, they seem to be afflicted by a similar issue. On this test stand, the turrets can regularly be seen hitting the friendly yellow blocks with their respective left gun:
World attached. (Ignore the filename.)
Note: Certainly for the CTC block, only the selected aiming reference, weapon or camera, is checked for intersection with its own grid, or generally any grid relevant for aiming and firing. If you have multiple weapons on the custom turret, and the view for the aiming reference is clear, the CTC fires all weapons even when the view is not clear for all of them.
This compounds with the issue that the CTC likes to be a dick and overrides your dedicated selection of a camera with an automatic selection of a weapon from the list (although granted, while a camera needs no lead angle, a weapon does), and depending on what order you placed them in, or what names they have, or what colour of socks you wore thirteen hours before you placed the weapon, this could be any weapon on your turret, and as such you have little to no control over which block actually ends up being selected as the reference … except perhaps when it's the only one.
Here's a classic ball turret with two columns of three gatling guns each. The CTC, in its whimsical mood, has decided to humour us with its selection of the top-left one, painted in red and with its aim visualised by the projection, as the reference. As you can see from the bullet marks on the yellow block, while firing at the battery owned by an enemy, the CTC obliviously coerces the middle and bottom pairs of gatlings into firing while they are still pointed at an otherwise friendly grid. And of course this is aggravated the higher the value for the permitted aiming deviation is.
Likewise, as soon as the aim of the reference weapon grazes the friendly block, the whole turret stops firing even though most of its weapons still have clear line of sight.
Granted, given how there could be any number of weapons in any arrangement on a turret, this is an understandable compromise. However, the player should have more control and authority over the reference block selection. For example, use the ballistic properties of the guns present and apply them to the camera's place on the turret as if it was itself such a gun. And/or make the reference gun explicitly selectable, too, instead of offering only cameras in the dropdown. As such, this is perhaps as much a feature request as it is a bug, or rather an undesirable side effect of an existing implementation, at least for the CTC.
As for the non-custom turrets, due to some of them having two distinct and widely spaced guns, they seem to be afflicted by a similar issue. On this test stand, the turrets can regularly be seen hitting the friendly yellow blocks with their respective left gun:
World attached. (Ignore the filename.)
Unrelated: Why can I set my own answer as "Best Answer", let alone my answer to someone else's thread??
Worse yet: I can't un-set it!
Unrelated: Why can I set my own answer as "Best Answer", let alone my answer to someone else's thread??
Worse yet: I can't un-set it!
Hello, Keen, how much more information do you need?
Hello, Keen, how much more information do you need?
Hello, Peter!
Thank you for reporting this.
We have successfully reproduced the issue and reported it internally.
Kind Regards,
Keen Software House: QA Department
Hello, Peter!
Thank you for reporting this.
We have successfully reproduced the issue and reported it internally.
Kind Regards,
Keen Software House: QA Department
Replies have been locked on this page!