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
There is something however that bugs me a lot, and as far as I know this game has been out for a year already so to be honest I am really surprised it hasn't been reported and corrected yet.
It is not an improbable glitch that happened under one-in-a-million circumstances; it has to do with lines of fire.
In order to make communication as smooth and easy as possible let me define a few things. Anyone with some understanding of the game mechanics will agree that we can characterize 12 "directions of fire" when dealing with the direction from which damage is taken (this is obviously due to the hexagonal nature of the ship layout). I will refer to those directions as with the trigonometric circle, with degres values (so going from 0° to 360° with a 30° increment).
I had fun trying stuff in the sandbox mode, and it quickly appeared that there must be some kind of error in the way those directions of fire are defined. I mean come on guys, who hasn't already noticed that for two ships facing each other perfectly, the damage is always dealt with a 30 degres angle. And not like 30 degres on the left or 30 degres on the right, that would statistically even out, no, always 30 degres on the left.
So my first hypotheses was "maybe all directions are rotated with an angle of 30 degres towards the left direction, i.e. in the trigonometric direction (a.k.a. counterclockwise).
But no, as further investigation easily shows: the left (90°) and right (270°) directions are okay, yet the back direction (180°) is also messed up, but with a 30° difference towards the right this time. In other words, both front and back directions are bent towards the left.
I hope make myself clear, I am sure any developper will instantly see what I am talking about. I am looking forward to hearing from you, whether this is a problem that can be fixed (I have faith it is) or there is some kind of reason (that I am currently unaware of) that brings sens to this.
In essence this would mean that all damage is shifted to the nearest median. 30, 90, 150, 210, 270 and 300 degrees "straight" lines, starting from the hex it impacts at.
There is a very quick and simple way to support my claim: just build a big hexagonal bulk of sheer armour with a dot of control deck at each of his 6 corners. Then attack it with a laser.
You can see that the damage progression travels "as a frontline", that is straight, and hence you can define the damage direction as the perpendicular to that line.
Thanks to the scale grid we can easily play with the angle from which your attacking vessel will damage the immobile hexagonal target (only thing you need to know is that tan(30°)=0,58), and you can see that the 60°, 120°, 240° and 300° are well-define. So there is no logical reason why the 0° and 180° ones could not be.
In other words, the rounding of ranges system should shift (-15°) - (+15°) to the 0° direction, 15°-45° to the 30° direction, etc...
It does it well for every directions BUT the front and the back. Try what I described and you will see the point instantly.
I'm just trying to help make a great game perfect you know x)
1. with Mono i can not upgrade a lvl 0 planet to lvl 1 planet, if it has only lvl 0 resources or without resources. So it is no reason to me to colonize a planet with iron or aluminium, because it gave me only 4 (6) labor with cost of 80k maintenance +150k and time to produce population(+FLT shards). Factories with some upgrades can give 11+ labor for 150k maintenance and only 20k cost to build... And factory do not use pressure!
2. I toggle repeat query button, to make cyclic construction 1b population. Then i add some orbital construction in this query, for example - outpost. When planets finish currently constructing population - it start to construct outpost, and place construct 1b population into query. It is ok. But when planet finish construction of outpost - he is do not remove it from query and again place outpost in next query after construct population. If i press "cancel outpost" (because outpost is already ready) - outpost are magically disappear :)
3. zoom in spiral Galaxy are broken. Very often when i try to zoom in to some of "lower" system in it - it not zoomed, because interface think that i try to zoom in to some "upper" system and it is already max zoom here :( it is big headache to manage zoom with spiral galaxy. So i avoid to create such type of galaxy in the my games.
I have a laptop with a touchpad. So there are no mouse dual mouse buttons.
I run into the following 2 issues:
1) I can't rotate a turret. Object rotation is not listed in the key bindings.
2) I can't do the tutorial as it is documented because zoom is shown as either pull the mouse-wheel (there is none) or click both mouse buttons at the same time while dragging (can't click both buttons at once on the mouse-pad).
A workaround is in the key bindings to use the keys I and O for zoom, but that isn't explained in the tutorial dialog, so it will confuse other new players using a touchpad.
I recommend trying to play the game on a touch-pad laptop for QA, or worst-case (I'm kidding here) listing a mouse as a system requirement and saying touch-pads are not supported.
Also, please report issues as a separate thread, not as a reply to this thread.