A miscellany of observations
Which race do you like most? What do you like - what you don't like? Discuss it here.
posted on September 22nd, 2013, 10:47 pm
These aren't so much bugs, or balance criticisms, or presented with any expectation that they'll change or even should be changed; these are, as the title says, observations that I've made while playing this mod. Most of them are quirks, a few are annoyances, but none are really anything I'd specifically make a great fuss about. Except for one, which I'll mention in its specific point.
Mostly though, these are observations that may be useful; behaviours I've seen that might be overlooked but yet be the cause of frustration. I'm sure that most of us have seen things like this, and I'm sure that my interpretation of some elements is wrong and will need to be corrected. Many, if not all, of these are documented elsewhere too.
There's an obvious Fed / Rom bias in mine, but that's because it's what I play the most of. I hope similar nuggets of information are made available for other races.
Mostly though, these are observations that may be useful; behaviours I've seen that might be overlooked but yet be the cause of frustration. I'm sure that most of us have seen things like this, and I'm sure that my interpretation of some elements is wrong and will need to be corrected. Many, if not all, of these are documented elsewhere too.
There's an obvious Fed / Rom bias in mine, but that's because it's what I play the most of. I hope similar nuggets of information are made available for other races.
- Yoyodyne Nebula -- classed as a cruiser, but ranks grant stat increases more like a support ship (weighted to System). Officer upgrade most trivial of any ship that has one (adding one point of phaser damage per volley, and effectively downgrades the phaser against any ship with damage resistance against weak attacks).
- Serkas -- So good at formation disruption. Groups on the move lose a lot of weapon efficiency (weapons out of arc, ships just not firing even with targets in range, target selection not what the player would want). Low defence and impact of even single losses in single player keeps this ship out of the replays, alas.
- Serkas -- A Serkas shot is coming in on a stationary target. I click to move the group its in before impact. The other members of the group accelerate normally, but the targeted vessel accelerates slowly, if at all. Intentional or not, there does seem to be some sort of snare effect on the weapon.
- UI -- This does actually bug me. There's a significant delay (more than half a second) between selecting a control group and being able to give an order to it. On numerous occasions I've selected a ship that's being focused fire and tell it to go for repair, and the entire control group I had selected last starts going instead.
- Newtons -- Basic Newtons have some weird behaviours. Put all three in a control group, select the control group, and move them, and one will often stay put. They'll often ignore eligible repair targets in range (for way longer than a second or two, and this is with AI behaviour settings set properly), or move as a group so that one of them is in range to repair, but the others aren't. Their AI-driven repair priority list differs substantially from what I would want, but that's what micro skill is for.
- Movement Autonomy -- I always get a sadface when a chunk of my fleet decides to go haring off towards an enemy base even though nothing appears to have provoked them into moving.
- AI unit targeting behaviours -- Various AI classes definitely seem to target vessels they are more effective against. I regularly see Norexans shoot at an undamaged Rank 5 Excelsior-II behind a group of base or low rank Akiras for one example, and Remores always seem to have a bullseye painted on them.
- Pulling ships out of the repair queue -- I always need to be careful when issuing commands to a control group with a ship that's been sent to the repair yard; an attack or move command at the wrong moment will pull the ship out of the queue.
posted on September 23rd, 2013, 2:55 am
I can confirm all your observation. Sometimes i thought its me, i am so clumsy. But you are right
if i may add, random decloak, when escaping from battle with my entire fleet, without any ping or any cause (brel fire, low energy) i seen 1/3 of my fleet decloaking . Just for fun of being killed. Happends to klingon or romulan.
if i may add, random decloak, when escaping from battle with my entire fleet, without any ping or any cause (brel fire, low energy) i seen 1/3 of my fleet decloaking . Just for fun of being killed. Happends to klingon or romulan.
posted on September 25th, 2013, 3:18 pm
Very well observed, particularly the selection delay. I have a replay up where the control palette actually changed to the new ships, and it still gave the old ships the order that used to occupy that slot instead of the order that I clicked on.
And I know this sounds strange, but in the past I've observed a longer delay for control group 2 than the others. I tried it with different ships in different groups but it seemed like the delay was tied to the number 2 rather than what was in the group.
And I know this sounds strange, but in the past I've observed a longer delay for control group 2 than the others. I tried it with different ships in different groups but it seemed like the delay was tied to the number 2 rather than what was in the group.
posted on September 25th, 2013, 10:39 pm
Some other notes I remembered:
- Formation movement -- ships in a control group will settle into a formation with each other when stationary. When clicking to move the ships in a formation, you are clicking for where the centre of it will be.
- Formation movement -- ships will tend to stay with the formation's "lead ship". There have been times when I've sent one ship in a formation off to repair, and the rest of the group will follow it, often ignoring other move commands. This can occur even if you've compensated for selection delay.
- Pathfinding -- Ships can have some strange pathfinding behaviour. I have often seen ships take curved paths around invisible objects, and you have to be careful when sending front-line vessels to repair as sometimes their path takes them further into the enemy formation before they get to safety.
- Movement autonomy -- a ship ordered to attack a ship that's out of weapon range will need to be on high movement autonomy for them to move into rang. However, when the attack is complete, the ship will then lunge after the next target on their priority list. Which will often be in the middle of the enemy formation when there's a Norexan with full special energy just coming into range.
posted on September 26th, 2013, 1:54 am
yea that last one is everlasting awesomness.
posted on September 26th, 2013, 2:25 am
I think I can safely say that every single one of your concerns has been addressed for the next version . Some are obviously more complex things to fix, but all are addressed to the best possible extent
posted on September 26th, 2013, 7:28 pm
iv seen issues with wormholes,
if you send some ships into a wormhole, other ships will start flying into the direction of the other side.
im not sure if this is to do with teams and formations and the like but they were not selected but followed the others.
most noticeable in nirvana 2 as the unselected ships start flying through your base and get stuck at the asteroid wall
if you send some ships into a wormhole, other ships will start flying into the direction of the other side.
im not sure if this is to do with teams and formations and the like but they were not selected but followed the others.
most noticeable in nirvana 2 as the unselected ships start flying through your base and get stuck at the asteroid wall
posted on September 26th, 2013, 10:01 pm
Boggz wrote:I think I can safely say that every single one of your concerns has been addressed for the next version . Some are obviously more complex things to fix, but all are addressed to the best possible extent
Thanks for that Boggz. Yet more reasons to look forward to 4.0!
I am surprised that some of these behaviours can be changed at all, considering that they appear to be rooted deep into the game engine, and was aiming to document them to reduce the amount of hidden knowledge for less experienced players (not that I'd call myself a good or great player, just one who's played enough AI bashes to have seen some of this stuff).
posted on September 27th, 2013, 5:01 am
Now, normally I'd be happy to extoll the virtues of up and coming versions, but in this case I think it's important to correct a few misconceptions that have crept up. Version 4 will hopefully be quite well received by everyone, but it's not the messiah in terms of adjusting craft AI behavior
Yes, we have adjusted some key parameters that do result in better performance, but we aren't and won't be all the way there.
The Armada engine has gifted us with a host of 'wonderful' behavior. All games have their quirks (although in many games these are called and celebrated as "features" ), and Fleet Operations is not alone there . The Craft AI (which controls how craft behave) that is part of Armada is the root of most evil, but as with everything, the trick has always been to figure out how to best use those quirks to your advantage and to understand how they come about. On that note...
In v3, all ships grouped together are considered a 'fleet' by the engine. Orders taken by one ship in that "fleet" can often be passed on to other ships in that fleet. That's the root cause of most of the behaviors that have been described in this thread - not a 'UI lag' or wormhole issues, etc. As long as you understand how that behavior occurs, you can adjust your own gameplay to compensate, and you'll notice much better performance .
1. Ships decloaking when in a grouped fleet - that's because one of your ships took a hit to its subsystem. If sitting still, the ship will decloak. If moving, the ship will not decloak. In v3, that behavior is transferred to the whole grouped, sitting fleet.
2. Craft AI speed - especially noticeable with cloak or Newtons. The AI that acts on your ships is slower than you are - that's why you can give faster repair orders or faster attack commands versus ships that just decloaked.
3. Movement autonomy. Despite what it says on the box, green, yellow, red movement have nothing to do with ships staying in place. There is no Hold Position in Armada. Green/yellow/red ONLY serve to tell individual ships what they should do in the fleet (whether they should always stay in the fleet, move partially with the whole fleet, or move independently of the fleet). When ships on green/red/yellow movement autonomy are separate (not cemented to a group), they behave identically.
4. There's no specialized AI targeting behavior in v3 - lowest hitpoint vessels are attacked first. Freighters and Constructors are the only exception, with a higher priority than nearby mining stations.
5. Just as there's no specialized AI targeting behavior, there's no 'snare' effect. Would be nice, could lead us to make some cool weapons .
6. Pathfinding in v3 is very simple - if there is an object with a footprint in the path, it's taken into consideration for pathing. Things that aren't there can't affect pathing - the engine isn't that smart. It only takes into consideration footprinted objects between the unit and the destination. There are however two ways to make it appear as if pathing is broken. One is the Tab command - Tab through a nebula, and you ignore the pathing cost of the nebula. The second is ship formations. Ships that are fairly far apart, but ordered to go to the same location, will attempt to account for each other's pathing. That can mean some turn arounds etc so that they can get close to their neighbors.
7 As before: When vessels are given a movement or attack order while grouped, they become considered part of the same "fleet" by the game engine (this has nothing to do with hotkeying units). This behavior results in such grouped vessels inheriting certain commands. As a result, when a unit of such a group is given a repair (or priority repair) order, the rest of the fleet might inherit the repair order for instance, resulting in all units heading out of the battlefield. Similarly, units ordered to repair might suddenly turn around and re-enter the fight.
To avoid this behavior, a vessel you wish to repair should first be given a movement order separate of its grouped fleet. This dissociates the unit from its group and it will no longer inherit commands given to the rest of the fleet.
Consequently, a perfectly executed repair sequence is as follows: select unit, give movement order, hit "R" (repair) or "Shift+R" (priority repair).
That's the cause of the "UI being slow" (as it's not the UI being slow at all - you can test that in instant action with artificially huge amounts of lag and give rapid commands to two separate fleets for instance with no UI lag). The UI is in general rather fast in A2/FO - far faster than a human can abuse. Unlike AI cycles, which are extremely slow by comparison, and are the root of pretty much every "feature" that causes annoyance.
In Conclusion
Yup, there's a lot of strange behavior there (I've made an attempt to document it in the v4guide in such a way that players can learn how to use it to their advantage), but most of it can be mitigated by adding an extra click or two into your command routine. Pretty soon it becomes a natural part of your gameplay and requires no extra thinking .
Yes, we have adjusted some key parameters that do result in better performance, but we aren't and won't be all the way there.
The Armada engine has gifted us with a host of 'wonderful' behavior. All games have their quirks (although in many games these are called and celebrated as "features" ), and Fleet Operations is not alone there . The Craft AI (which controls how craft behave) that is part of Armada is the root of most evil, but as with everything, the trick has always been to figure out how to best use those quirks to your advantage and to understand how they come about. On that note...
In v3, all ships grouped together are considered a 'fleet' by the engine. Orders taken by one ship in that "fleet" can often be passed on to other ships in that fleet. That's the root cause of most of the behaviors that have been described in this thread - not a 'UI lag' or wormhole issues, etc. As long as you understand how that behavior occurs, you can adjust your own gameplay to compensate, and you'll notice much better performance .
1. Ships decloaking when in a grouped fleet - that's because one of your ships took a hit to its subsystem. If sitting still, the ship will decloak. If moving, the ship will not decloak. In v3, that behavior is transferred to the whole grouped, sitting fleet.
2. Craft AI speed - especially noticeable with cloak or Newtons. The AI that acts on your ships is slower than you are - that's why you can give faster repair orders or faster attack commands versus ships that just decloaked.
3. Movement autonomy. Despite what it says on the box, green, yellow, red movement have nothing to do with ships staying in place. There is no Hold Position in Armada. Green/yellow/red ONLY serve to tell individual ships what they should do in the fleet (whether they should always stay in the fleet, move partially with the whole fleet, or move independently of the fleet). When ships on green/red/yellow movement autonomy are separate (not cemented to a group), they behave identically.
4. There's no specialized AI targeting behavior in v3 - lowest hitpoint vessels are attacked first. Freighters and Constructors are the only exception, with a higher priority than nearby mining stations.
5. Just as there's no specialized AI targeting behavior, there's no 'snare' effect. Would be nice, could lead us to make some cool weapons .
6. Pathfinding in v3 is very simple - if there is an object with a footprint in the path, it's taken into consideration for pathing. Things that aren't there can't affect pathing - the engine isn't that smart. It only takes into consideration footprinted objects between the unit and the destination. There are however two ways to make it appear as if pathing is broken. One is the Tab command - Tab through a nebula, and you ignore the pathing cost of the nebula. The second is ship formations. Ships that are fairly far apart, but ordered to go to the same location, will attempt to account for each other's pathing. That can mean some turn arounds etc so that they can get close to their neighbors.
7 As before: When vessels are given a movement or attack order while grouped, they become considered part of the same "fleet" by the game engine (this has nothing to do with hotkeying units). This behavior results in such grouped vessels inheriting certain commands. As a result, when a unit of such a group is given a repair (or priority repair) order, the rest of the fleet might inherit the repair order for instance, resulting in all units heading out of the battlefield. Similarly, units ordered to repair might suddenly turn around and re-enter the fight.
To avoid this behavior, a vessel you wish to repair should first be given a movement order separate of its grouped fleet. This dissociates the unit from its group and it will no longer inherit commands given to the rest of the fleet.
Consequently, a perfectly executed repair sequence is as follows: select unit, give movement order, hit "R" (repair) or "Shift+R" (priority repair).
That's the cause of the "UI being slow" (as it's not the UI being slow at all - you can test that in instant action with artificially huge amounts of lag and give rapid commands to two separate fleets for instance with no UI lag). The UI is in general rather fast in A2/FO - far faster than a human can abuse. Unlike AI cycles, which are extremely slow by comparison, and are the root of pretty much every "feature" that causes annoyance.
In Conclusion
Yup, there's a lot of strange behavior there (I've made an attempt to document it in the v4guide in such a way that players can learn how to use it to their advantage), but most of it can be mitigated by adding an extra click or two into your command routine. Pretty soon it becomes a natural part of your gameplay and requires no extra thinking .
Who is online
Users browsing this forum: Google [Bot] and 28 guests