Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
However, these ships, the moment they're in combat, seem to lose their ability to reverse. I'm assuming it's some sort of bug as, outside of combat, the ships appear to perform as they should.
For example, last night, my main combat ship - which is actually there to out-distance / tank an enemy, while my second ship snipes vitals - was faced with a quite tough opponent with two large Cannons (Starting system). This ship was slow and tanky, but with a vulnerable spot on the rear where the Cockpit can be sniped, after getting through a couple of layers of armour.
On paper, my lead ship should have easily been able to maintain distance - it had two Large Thrusters in each direction, and isn't very massive at all - yet they attacker just face-planted my ship, its cannons bypassing my layered shields, and took it out quickly. I reloaded. Second attempt, my ship was still initially sluggish reversing, but it maintained distance after an initial "rubber band" getting too close then gaining distance again, while my second ship sniped the attacker.
Note: to be 100% clear, I'm not being fooled by relative movement speeds here. I.e. my ship is reversing, but the attacker is approaching more quickly, acceleration/momentum stuff. No, I'm using landmarks such as asteroids so I KNOW my ship is simply not reversing as fast as it can. It's like my ship is suddenly wading through treacle or something, it's just not responding as I know it can.
While very apparent in a ramming scenario, the issue also occurs with other movements. For example, I order a ship of mine to attack from a different vector, so it tries to strafe - something my main ship is very good at - yet, once again, it starts moving MUCH slower than it's actually capable of. Again, this isn't an enemy out-turning my ship's strafe, it's clearly just not moving as it can. Only happens when in a Fight.
Note: while losing power to an engine, either through damage or momentary lack of fuel, would explain things, that's certainly not what's happening. I keep my ships over-crewed, so I simply don't see things like that.
So, yeah, while there are MANY genuine reasons for a ram, from vast speed differences, acceleration, damage, fuel, lack of crew etc. That's not what I was seeing last night. My ships was simply not attaining it's actual max speed in reverse reliably. Reload, try again, and it did much better. Set distances would the same - right at the edge on my ships firing range - it has basic lasers, so better than the attackers large Cannons - but it could not stick to it.
Note: Occasionally, rather than relying on my ship maintaining distance based on the set attack distance, I've manually overridden this, giving the ship a move while facing same direction order, and it's pulled away just fine. So, it CAN increase distance just fine, it just COULDN'T when trying to maintain that attack distance. Significant?
a few things to consider would be the engine ramp up time, depending on the size of your engines, combined with the weight distribution of your ship (also center of mass), which leads the AI to "try" to balance around that in comparison to the set attack range/angle and the enemies ship movements to achieve/hold optimal (set) position. which leads to your ships not using maximum throttle as this would make it impossible to "hit" the mark set.
another thing is, as you described, you first "tank" a ship via a reverse kiter that is more expensive than your sniper, which is common tactic. at first this is a 1v1 fight, for the enemy AI as well as your ships AI that handles the attack settings you set up. what a lot ppl dont know is, that as soon as you assign a second ship to a target, e.g. your sniper circled the target and you set it to finally attack it, the fight becomes a 2v1 for both AI´s. in this case your 2 ships behave differently sometimes. this is albeit a AI ship can always just "engage" 1 enemy, thus the tanking works, but it can pretty well "target" multiple of your ships, if proper weapons (free aim/missiles) are present with a proper fire arc.
i witnessed this while testing some "wolfpack" tactics, where if you assign only one railkiter for example to an enemy, it behaves as it is suspected. once the second one gets attached to the enemy, the first one in front of it kiting, reduces speed and gets closer, which in 99% of the time is fatal for railkiters. this happens nearly always if you set the ships to use the combat helper AI presets and, but still, a lot less when you use the manually attack presets.
and finally, you gotta know that technically the AI cant fly in arcs =). it might seem that way, but generally what you observe is a combination of forward/backward and side thrust distribution. you can pretty easy see it with "orbiter" ships. that means that if the enemy alters its vector to your ship, your ship will always reduce speed to some extent to alter its own. the same is valid for enemy ships. which you can abuse with said "orbiter" ships. where you force the enemy to technically stand still and only turn, by just circling it, because it cant distribute its thrust to simultaniously fly forward and turn (rotate command). it will however always, 100%, try to face its nose (depending on flying direction), on your centerpoint.
at the same time you can see that "orbiters" achieve the circling only because they have a "glitched" attack preset, that forces them to overshoot the position where they would turn, then re-align the position, and overshoot again. hard to explain, but if you test it you will see it. more obvious the faster the orbiter is. and much more consistend on slower ones like the "Streamliner" from fringe.
so long story short, the 3 things the AI can handle atm are ramming, kiting and orbiting (to some extent). all the wobbling around you see in combat is just RNG, where the AI has a set/random timer to switch targets, etc. which forces it to adjust its vector/speed. its pretty basic for now until the AI overhaul comes down the roadmap. and yes, sadly the ramming one is the easiest to maintain, thus nearly all AI ships have that as a design philosophy...
I've actually seen other games that get confused when a ship is thrusting over multiple vectors and Cosmoteer seems to behave in very similar way at times. I.e. in isolation a ships stats might be thus:
Forward/Backwards thrust, up to 30
Left/Right thrust, up to 20
(just random example)
The ship is doing its full 30 forwards or backwards, then left/right thrust is applied. Ship is already going over 30 in one direction, and seems it cannot side thrust until is slows down a bit as the speed would exceed what that thruster can achieve. Maths, but not as we know it lol. It's not quite as bad in Cosmoteer as this other game, in that, if a ship is going say 30 forwards, any thrust - from separate thrusters - in ANY direction that cannot achieve more than 30, will yield no vector change at all. It's just poor physics in that other game, but I think there's more to it in Cosmoteer.
I'm likely not explaining it well, but it's an acknowledged issue in this other game, something they've never been able to fix, or don't want to.
It's just a little frustrating to build a ship with a certain tactic in mind, something it appears to be very competent at when testing in isolation, only to have the ship fail when under AI control. By AI control I mean when the *game* is trying to maintain a set distance during an attack. As I mentioned, manually ordering a ship to move while facing the enemy, yields far more reliable results.
I'm sure these issues will be refined over time. The issue seems to lie in the speed limit applied to the physics in order to achieve a more playable experience. With hard speed limits based on various variables - mass, thrust etc. - just like the other game I mention, the hard caps effective break when thrust is in multiple vectors.
The interesting thing, perhaps, is that other game never used to be like that. Indeed, applying thrust over more than one vector was a way to achieve higher speeds than intended. It's when they prevented that with a hard speed cap that the physics of vector changes became broken.
Perhaps that's the answer here, make the speed limit less hard, so a ship thrusting on multiple vectors can slightly exceed the overall speed limit. I.e. a ship might only be able to achieve 30 in any one direction, but can do 40 when thrusting in two directions. That would, in theory, make the ship behave better. There's still a hard limit - needed for gameplay of course, full Newtonian would be, well, hilarious, but not that playable - it's a slightly increased hard limit factoring in TWO vectors.
i mean if the game engine is already busy enough calculating all the supply/demand pings for the crew/modules, the dmg ticks per second from dozens of guns with penetration on multiple target tiles, and then have a ship with a ton of differnt engine sizes and vectors...
as the task limit already forces the game to skip some tasks for crew so they just chill in their bunks... why not skip some calculations for the steering part as well?
just a thought though =P.
Internal processes can indeed impact things though, very clear in some other games I play. You might encounter a situation where there's a lot going on, so performance drops for example. It's natural to assume that perhaps the hardware is being pushed, hence the fps drop, but that's not always the case. Indeed, in another game I play, as things get busier, you can often see both CPU and GPU utilisation drop, as the internal scripting engine become overwhelmed.
In simple terms, you might have Harware that can handle 200 jobs per second, but the game's engine chokes when it's trying to do more than 100. Again, not that uncommon, but usually something that improves with development - certainly true of an early-access title that's still being padded with features.
I will tinker more with my ship designs, likely making them ridiculously "thrusty" (that's a word, honest) in all directions, and observe the results.
Select your ship, hold Shift and you'll see a red ghosted outline. You can then drag it closer / further away or even off to the side. You'll see ghosted images showing weapons cover too.
Got a save before that encounter that you wouldn't mind uploading somewhere? I'd like to play around with it and see this for myself.
Ah, don't think I have, sorry. I purge all but my last couple of saves at the end of each session, so don't have any from prior to that encounter. I really should have done that, but the issue isn't new to me, so I didn't think to keep it. Am I right in saying that this isn't a new issue? I recall reading about it in the past, I've just recently come back to Cosmoteer, having not played in a while.
Note: tinkering last night, I added some mods to my game, so that's likely now excluded me from testing and bug reports. Just extra weapons, more crew type things.
Going forward, in a vanilla game, I'll be sure to upload a save that shows the issue for me. I'd be fascinated if it didn't occur for anyone loading that save. Though, that said, I had a different result after reloading myself / manually ordering the ship to move backwards, rather than rely on the AI maintaining distance for me.
The moment the ship is in flight formation or in attack formation, it loses half it IQ...