I'm sure that you have all had that one turret that can't turn 360° because part of the ship sticks up behind it and when it tries it gets stuck or starts causing physics to happen, so wouldnt it be nice if you could artificially set limits to how far it can turn in either direction.
that is an interesting idea > clippy/laggy turrets are all too easy to build, and certainly hurt game play. But implementing this might not be straightforward - presumably new coding (or additional level) for turret movement would have to be implemented...(?)
Another issue is that if this is player determined only, then human error can still cause the same lag and turret clipping.
Might it be possible to set up a self-check on turrets ? This would do something like run turrets through their full movement arcs, record the angle at which the clipping occurs somehow, and use this to generate a set of limits on each arc (ie set to some angle before the recorded clipping occurs).
This would put a big calculation/lag spike at the point of 'auto-check' (eg on first entering core during a single log-on perhaps), but alleviate it during rest of game play.
There would probably need to be an array of dual numbers (min and max?) to record the arcs, because vertical arcs can change from one degree of horizontal turn to the next. and vice-versa.
Example:
Turrets placed on the edge of ship: it can point down maybe two degrees when in the same direction as the mother entity, but as it turns outward, it can point further and further down. So maybe it can angle down a whole 45 degrees at a 90 degree turn, which is significantly different from the paltry 2 degrees at the original angle. Likewise, if the "pole" (referenced in the Original Post) is tapered in some way, horizontal turret travel will change depending on the turret's vertical angle. So effectively, it can turn farther from side to side when it is raised 60 degrees vertical compared when it is angled down at negative 2 degrees.
Brainstorming:
There is the issue of "holes" between restrictive elements, so that a turret could aim down a hole, but the rest of the travel arc is separated by something. Other turrets, for example. Would you calculate the two sets of angles separately? If the turret tries to travel from one arc to the other, it would run into the obstacle, so the turret would need to store instructions on how to "reach" each area. Example: when the turret reaches 90 degrees, and that's the end of arc 1, point straight up and continue on to 135 degrees and return to the original vertical angle, then coontinue horizontal travel to target.
On the other hand, if you were to program the game to run the turret through every possible angle, you'd either have to sacrifice accuracy for data size (and calculation time) or vice versa. (Maybe a server-selectable turret-angle-accuracy option?) At the minimum level of 1 degree increments, that is still 360^2 (129,600) values to check. Most players will probably want degree-minute-second accuracy, with a few settling for mere degree-minute accuracy, which would have 466,560,000 values. (Degree-minute booleans can be referenced in a standard Java 32-bit int. Degree-minute-second booleans cannot.) These large numbers could spell disaster for a server processing many turrets at once.
Then there is the issue of determining "availability" of each angle. Maybe that could be solved via A* or some other pathfinding algorithm. For instance, there may be a 1 or 2 degree "hole" that the turret cannot point, due to surrounding obstacles. If it were spawned on the ship in the correct orientation, it could aim through that hole, but from the original angle, it can't get to it. So pathing would probably need to be calculated and stored for each angle increment from the starting angle.
Automated calculation time shouldn't be a problem. The set of calculations can be stored in some sort of builder calculation queue with the ID of the rail (turret) entity, to be processed a few at a time for each game tick a few seconds after the turret is placed in build mode. That way, the computer can work on the angles in the background while the player continues to build. Pulling just a few calculations to process per tick should keep the game running smoothly for the player. If the turret is removed before calculations are complete, just match the ID of the removed turret with IDs in the queue list and delete those queued calculations.
that is an interesting idea > clippy/laggy turrets are all too easy to build, and certainly hurt game play. But implementing this might not be straightforward - presumably new coding (or additional level) for turret movement would have to be implemented...(?)
Another issue is that if this is player determined only, then human error can still cause the same lag and turret clipping.
Might it be possible to set up a self-check on turrets ? This would do something like run turrets through their full movement arcs, record the angle at which the clipping occurs somehow, and use this to generate a set of limits on each arc (ie set to some angle before the recorded clipping occurs).
This would put a big calculation/lag spike at the point of 'auto-check' (eg on first entering core during a single log-on perhaps), but alleviate it during rest of game play.
i dont thing it would be too difficult considering the spin blocks already do something similar by the way of being able to set how far they rotate at once.
[doublepost=1495751284,1495750345][/doublepost]
There would probably need to be an array of dual numbers (min and max?) to record the arcs, because vertical arcs can change from one degree of horizontal turn to the next. and vice-versa.
Example:
Turrets placed on the edge of ship: it can point down maybe two degrees when in the same direction as the mother entity, but as it turns outward, it can point further and further down. So maybe it can angle down a whole 45 degrees at a 90 degree turn, which is significantly different from the paltry 2 degrees at the original angle. Likewise, if the "pole" (referenced in the Original Post) is tapered in some way, horizontal turret travel will change depending on the turret's vertical angle. So effectively, it can turn farther from side to side when it is raised 60 degrees vertical compared when it is angled down at negative 2 degrees.
Brainstorming:
There is the issue of "holes" between restrictive elements, so that a turret could aim down a hole, but the rest of the travel arc is separated by something. Other turrets, for example. Would you calculate the two sets of angles separately? If the turret tries to travel from one arc to the other, it would run into the obstacle, so the turret would need to store instructions on how to "reach" each area. Example: when the turret reaches 90 degrees, and that's the end of arc 1, point straight up and continue on to 135 degrees and return to the original vertical angle, then coontinue horizontal travel to target.
On the other hand, if you were to program the game to run the turret through every possible angle, you'd either have to sacrifice accuracy for data size (and calculation time) or vice versa. (Maybe a server-selectable turret-angle-accuracy option?) At the minimum level of 1 degree increments, that is still 360^2 (129,600) values to check. Most players will probably want degree-minute-second accuracy, with a few settling for mere degree-minute accuracy, which would have 466,560,000 values. (Degree-minute booleans can be referenced in a standard Java 32-bit int. Degree-minute-second booleans cannot.) These large numbers could spell disaster for a server processing many turrets at once.
Then there is the issue of determining "availability" of each angle. Maybe that could be solved via A* or some other pathfinding algorithm. For instance, there may be a 1 or 2 degree "hole" that the turret cannot point, due to surrounding obstacles. If it were spawned on the ship in the correct orientation, it could aim through that hole, but from the original angle, it can't get to it. So pathing would probably need to be calculated and stored for each angle increment from the starting angle.
Automated calculation time shouldn't be a problem. The set of calculations can be stored in some sort of builder calculation queue with the ID of the rail (turret) entity, to be processed a few at a time for each game tick a few seconds after the turret is placed in build mode. That way, the computer can work on the angles in the background while the player continues to build. Pulling just a few calculations to process per tick should keep the game running smoothly for the player. If the turret is removed before calculations are complete, just match the ID of the removed turret with IDs in the queue list and delete those queued calculations.
Thats quite a bit more complicated than i was thinking about, i was mostly thinking about two simple values one for the lower limit of the turret (how far it can go to the right/left) and the upper limit (how far it can go the the left/right) where if each were set to 180 the turret could turn 360 degrees (this could be shown as visual representation something that looks somewhat like a clock with one hand controling the the lower limit and one controling the upper limit)
thanks Jayman38 !! i appreciate your thoughts and time in putting them here > your more detailed consideration of the actual program framework and calculation issues is more insightful than mine :/
>>queued calculations as you suggest would seem to be key to such potential 'automated' game systems < <
Alternatively, given the obvious complexity you have revealed in implementation, Extholius original idea of player set parameters might be much simpler (even if less elegant) , and therefore more 'do-able'.
It's not that easy to just allow firing arcs. Not necessarily from a programming aspect, but from a managing one.
As firing angle depends on the turret and the entity it is docked to, it sounds like setting it manual would be a never ending chore for the player to edit.
Swapping out a turret of the 100 on a ship, would require you to change its firing arc.
Changing hull around a turret's base or the turret barrel itself, would require you to change its firing arc.
Questions that need to be answered:
On which entity do you set it? The one that has the rail turret block, or the entity that docks to a rail turret block.
How do you set it, GUI sliders, block based modifiers or something else?
Do you set it for only 1 entity (gun barrel) and does it inherit downwards/upwards and would that even work for all cases? Or does it not inherit at all and require you to set each axis per entity.
Are the rotation limits set relative to the ship or the turret base? A turret base firing arc of -90° to 90° doesn't mean anything unless you say it's relative to the rail docker or turret rail. Problem here is that rotating the rail docker/turret rail will also rotate the turret and require you to change the firing arc interval.
If it's relative to the parent's ship direction, you lose a decent amount of control over it and some firing arcs might not work too well...especially when turrets are docked to moving parts.
What to do with special cases such as turrets on moving parts? Or turrets docked to turrets? Or turrets docked to turrets docked to moving parts docked to turrets?
Would rather have the game figure out what it can use as firing arc dynamically. The need to set it manual right now would be because the game isn't great at figuring the firing arc automatically, so sounds like we just need to improve that part instead of introducing a new overriding complicated method that has to be set manual by the player.
Would rather have the game figure out what it can use as firing arc dynamically. The need to set it manual right now would be because the game isn't great at figuring the firing arc automatically, so sounds like we just need to improve that part instead of introducing a new overriding complicated method that has to be set manual by the player.
I agree a turret should always know if it has a line of sight towards the enemy it wants to shoot or if not in which case it should repick a target that is better suited to be shoot at. And we need turrets to know what they are supposed to shoot at as primary secondary tertiary... targets.
Could we use the structure menu and employ a firing arc grouping as we do with groupings turrets? Perhaps allow us to group the turrets here or elsewhere to then provide a grouping mechanism for not only configuration, but firing control and targeting specifics.
I would expect this as a given regardless. We do this already.
ret barrel itself, would require you to change its firing arc.
Questions that need to be answered:
On which entity do you set it? The one that has the rail turret block, or the entity that docks to a rail turret block.
How do you set it, GUI sliders, block based modifiers or something else?
Do you set it for only 1 entity (gun barrel) and does it inherit downwards/upwards and would that even work for all cases? Or does it not inherit at all and require you to set each axis per entity.
Are the rotation limits set relative to the ship or the turret base? A turret base firing arc of -90° to 90° doesn't mean anything unless you say it's relative to the rail docker or turret rail. Problem here is that rotating the rail docker/turret rail will also rotate the turret and require you to change the firing arc interval.
If it's relative to the parent's ship direction, you lose a decent amount of control over it and some firing arcs might not work too well...especially when turrets are docked to moving parts.
What to do with special cases such as turrets on moving parts? Or turrets docked to turrets? Or turrets docked to turrets docked to moving parts docked to turrets?
I think it would logically be set by the entity the turret axis is part of.
I like your slider idea! Would be nice to have a visual movement of the turret in game so you could see the actual arc for those of us who don't know what degrees are.
I would make it entity specific as in 1. I would not allow inheritance. It makes no sense to me having inheritance.
I would make the limits relative to the axis block. It already has direction and orientation built in.
Refer option 1.
Something others and I have wished for is a form of group firing control over our turrets. If you incorporate the configuration, this could solf the firing arc and other issues like the dynamic targeting control the others and myself would like. Dynamic as in being able to switch between the different BobbyAI settings for firing on "Any, Target, Missiles" etc.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
