This update was amazing. Well done team!
I mostly played Bomber.
Flying the Bomber felt incredibly satisfying.
Torpedoes are amazing. Both hitting and missing feels good. A miss does a lot less damage, yes, but the spectacle is grandiose.
All the effects update did so much to add satisfaction. Getting kills with the shotgun felt fun too.
Pushback from the shockwaves felt at an alright place … yes capitals get knocked around quite a bit but it is fun!
Camera shake is a bit too pronounced to my liking. All of it, also boosting.
In the bomber the minimum distance to an explosion and the amount of damage received is quite small compared to the big fireball. I feel like torpedoes are more mid range brute force weapons. I think strike craft should go skin to skin with capitals but more when it comes to shooting down modules and such.
Shockwaves have a travel time yet sound and screen shake does not. Now the shockwave effect is much less pronounced and less noticable compared to last patch, still there’s a disconnect there. I feel like they both should be more closely connected, time wise (occur more closer together in time). Or maybe leave sound as is but connect screen shake to the shockwave.
I was playing and just earning money without specifically having to grind for stuff. Great! I did some turret destruction and such but never to earn money and still got enough to fly capships after a while. Felt great. Just doing what was fun and being rewarded.
Battle system was great. Like. Directions! Yet still options to decide and interesting decissions too. Stay here and finish the fight or head over to the critical one? Which one is more important? That’s super great! It brought urgency and excitment when it wasn’t expected.
Capital ship mode works quite alright yeah. It limits a lot of options though. Haven’t tested with the modifier key yet, guess it is not in yet. Heaving the “set direction” function though made it so much more managable to fly these ships without stress and the camera feels so liberating and removing those blinds from before.
The camera in cap ship mode has a blindzone at the top, that one is reasonable and not too big, and one at the bottom. The bottom one is huge though. Multiple dozens of degrees. That’s not acceptable. I should be able to aim down and shoot down at more then 90%. I guess that limitation was not intended.
I also agree that strafing should be prioritised with maybe the modifier key switching to rotation or the arrow keys at the keyboard. Strafing is important in I:B in many things more then just dodging.
The “set direction” should be the main way to steer capitals in my opinion. Does anyone use they keyboard? I can imagine but it seems inferior and kind of like two ways to do the same thing.
I had quite a bit of network and general FPS slowdown during big battles. The GPU didn’t seem to be using its full capabilities during these battles (otherwise it is going 100% max FPS) and I think neither my CPU did (Maybe single thread was maxed) … so I don’t exactly know where the bottleneck was.
Something feels wonky when it comes to atmospheres. The change in density is definitely noticeable. I am still waiting for a serious atmosphere flight mechanics update before that though.
Warp damage interrupting warp doesn’t allow to trade shield for speed anymore to pass atmospheres faster.
Scanner
I feel like the scanner should also use the engineering notation for numbers like the distance displays do and not the scientific notation. So comparison would be easier. Also. A unit would be good so we know what it is even displaying … at least on one axis … ha.
From left to right
|
|
|
|
|
|
|
|
10^0 |
10^1 |
10^2 |
10^3 |
10^4 |
10^5 |
10^6 |
|
1km |
10km |
100km |
1Mm |
10Mm |
100Mm |
1Gm |
|
Decluttering flight modes
Here’s a (potentially cotnrovesrial) suggestion to unify the controls of the flight modes as well as make binding clear and less ambiguous.
There are three flight modes: Direct, Virtual Navigation and Capital
Some of them have hard-coded elements in them that work in tandem or on top of the input profile configuration.
For instance the Virtual Navigation mode is usable even if no mouse input has been bound anywhere in the input profile or the capital mode allows one to use the strafe command to rotate the ship and a modifier set to the same event as “view” switches this behaviour back.
I would suggest to do away with separate sections in the input profile for the different control modes.
This here is a suggestion which in my opinion more represents the structure of the control system in the game right now.
Most important thing to note is that if the mouse is used it should be “captured” like in many other games. Meaning it can only be used for one thing. This stops conflicts.
The priority would be such:
- View Controls
- Menu / Cursor Controls
- Flight Controls
- Others
So if the mouse is bound in bound in multiple of these groups the event/function in the group with the highest priority would always “capture” the mouse and not allow firing of events in other groups but only if it is needed like in a menu or in a mode that has a cursor.
The flight modes would still all be there but use the events slightly differently.
All flight modes now pull from Generic Flight Controls. The generic controls now have all 6 Axis.
Virtual Navigation
The generic controls would work in this mode but it would primarily use the Menu / Cursor Controls.
Above “capture” logic stops conflict.
Direct Flight mode
This mode does not have a cursor and as such just uses all the generic controls.
Capital Mode
This mode would use the “view” controls to move the camera like already the case as far as I know. As well as the generic controls.
As you can see in the example above the “switchover” (using WASD to pitch) has also been realized by just adding bindings to already existing events.
With the added benefit of working in all control modes.
Edit:
There is a potential problem. When in virtual mode and activating freelook one want to be able to look arround with the mouse.
But when in capital ship mode and then activating a menu, acording to the priority list above, the menu would not work and the freelook would still prevail …
I think openening menues should disable freelook while they are active in order to handle this special case … or maybe I have a logic error in there.