0.4.6.0 Feedback Thread

Battlescape
1

I didnt get much time to test today (curse the fact that i’m always busy saturday mornings) but i do have a few points of feedback.

The dual circle/dot crosshairs i actually thought was for the guns at first, but it also works for the missiles. Good stuff, but its not immedately obvious what they are or that they represent missile locks.

Not a fan of the anti-drift thing.There was a technique in SC for a few really awful patches called “peak accel”. Basically the way it worked in such a way so that accel depended on velocity, there was a specific velocity where you could get better accel and therefore better evasion… connecting the dots, this is very similar to what we’re getting now. Unfortunately it drastically limited the number of possible movements, basically you either stick to the peak accel zone or you were at a disadvantage, it’s also somewhat contradictory to the goal of Newtonian combat. I don’t like the idea that my ship will respond differently to an input depending on current velocity. It also seems to act much more strongly in flight assist on than flight assist off (or maybe it doesnt act at all in FA off) which causes some issues with higher accel being available in FA-on.

In terms of actual negative gameplay effects i would need more time and some pvp, but just against some npcs it was very annoying to have them seem to get sudden bursts of accel they shouldnt have. Especially when in an inty against larger ships like the corvette it’s very dangerous to have them to have anti drift accel as they slingshot and you lose your main advantage being higher accel for some moments.

I have to also give a big negative to the random shield penetration. The last thing we need in dogfighting is purely random elements deciding whether you live or die, i dont really see the purpose of this change. If this is really just for visual effects later i can’t say it’s worth it in terms of gameplay, it would be better to have a fake probabilistic visual that sometimes looks like it penetrates and sometimes doesnt but still do the same percent based damage bleed.

1 Like
2

We have a major problem with ships getting too much momentum and taking forever to turn back. We’ve been watching new players try to get into the game and spend hours before being comfortable and picking up their first kill. Usually what happens is that they’ll fly towards their target, turbo boost, land maybe a few random hits, then overshoot. And spend the next 1-2 minutes changing course.

Moving forward this is going to be the #1 issue frustrating new players. Space-sim hard / soft-core players will adapt much more quickly, but if we want a shot at having full servers, we can’t just target fans of newtonian space-sims.

It might be possible that the speed cap would be enough to address the issue ( that, plus better feedback, tutorials, etc… ), but still we have to give a try to this anti-drifting system before we go into EA. After EA, core gameplay will be set in stone, as too many players would be pissed by a change of direction that late in the project.

FA-off should behave in the same way than FA-on. The difference in behavior is probably that FA-on automatically compensated the side forces while you need to do it manually in FA-off to get the same result. So it requires more skill with FA-off to achieve the same result, but the flight model should be identical.

In addition to lowering the learning curve, the question is whether the anti-drifting system makes the game more dynamic / having less downtime and overall, more fun. I don’t have the answer to that question yet, it needs more testing. However for capital ships my impression so far is that they’re far more dynamic and interesting to play. Reverting the anti-drifting means going back to lowering their accelerations ( cause the accumulated momentum issue is exacerbed on large, slow ships that take forever to reach even low speeds ). It also means going back to a super slow carrier, which was quite boring to play.

So all aspects of the question have to be carefully evaluated before taking a decision. We could revert anti-drifting and go back to the previous momenum/acceleration issues. We could keep the anti-drifting but try more adjustments. We could go in a different direction to lower the learning curve / overshooting / boring capital ship movements ( in which case, let us know your ideas ). The only option not on the table is “the previous version was fine, and fuck new players with a high learning curve”.

As for the probabilistic shield, the randomization is unlikely to affect the outcome, as a single projectile isn’t gonna affect whether you live or die ( unless in an extreme case maybe, getting hit in an interceptor by an MK6+ ? which is very unlikely ). It’s the sum of all projectiles behaviors that will define the amount of damage, and it’ll quickly converge to the same average simply due to the high number of projectiles needed to destroy a ship. Personally I think it’s going to be very weird later on when the shield on a capital ship is 500m away from the hull, and you’re going to see a projectile aborbed by it visually, but it’ll still do armor damage. It’s also particularly ackward in terms of which sound effect do you play ? the shield’s or the armor’s ? what about the visual impact effect ? or do you play both ? an impact on the shield, followed later by an impact on the hull ? then you have double the particle effects and double the audio effects…

3 Likes
3

I think trying to make the newtonian space combat easier by making it non newtonian is kind of defeating the point and i suspect it might not really help new players. Yes, new players need a softer introduction and yes the learning curve needs to be better, but is it really likely that velocity based accel is just going to solve this problem for newbies? Someone who has no control of their ship isn’t going to get that control with accel tweaks. At the cost of combat being newtonian well, its putting the cart before the horse, the game needs to be deep so new players have things to look forward to. Being fully newtonian is a big selling point for many.

But yes, because we need solutions, here are some alternate suggestions:

More flight assist modes, enabled by default. Right now in assist turn speed is limited by velocity, but what about a different mode option that limits velocity by turn speed, something that even cancels the players forward velocity if they’re trying to turn faster. Basically how comstab worked in SC a long time ago. If the problem is getting to such high velocities forward that the player drifts out of control while turning, then limiting forw velocity based on current turn rate can work. Also, there could be an artificial assist only ramp down on increasing velocity, just to help new players, something that could always be turned off.

High-strafe thrust loadouts options with low mains by default, these could be the default “easier” option with current behavior coming in the form of an upgrade.

Tractor beams (not webifiers)? In a different discord i was having a lot of conversations about how many a tractor beam that when activated mutually accelerates both you and your targets towards each-other might be a good idea. Pulling laser tractor beams are real life working tech too and the equal and opposite element keeps it nicely newtonian, though right now they only work on very tiny particles in lab enviornments and don’t pull the emitter towards the target but ehhh, details. These could reduce the amount of “running” that happens by biasing both players to accelerate towards eachother.

On the random penetration, it will converge over large numbers yes, but it doesn’t exactly take many hits to kill an inty and with large caliber cap ship weapons the difference between a pierce and not will make the difference between a turret under the shields getting stripped off or not. Double the particle effects and audio effects seems worth it really. You could also combine both into a third particle effect/sound specifically for times when the shields penetrate and the hull gets hit.

here is a quick simulation i’ve written and run in python based on the ingame stats and probability based functionality running 100000 simulations, damage of one kinetic shot and adjusting the probability of a pierce based on the percentage. In my opinion the Std deviation here is unacceptably large, the law of large numbers can’t really take effect. (x axis is number of hits from the kinetic inty gun to kill)

Figure_1

Code 
import numpy as np
import random as rand
import matplotlib.pyplot as plt

hp = 80 
shield = 125
dmg = 8


data=[]
for loops in range(100000):

	shipshield=shield
	shiphp=hp
	alive=True
	hits=0
	while alive:
		hits+=1
		
		if rand.random() > (shipshield/shield):
			shiphp-=dmg
		
		elif shipshield >=0:
			shipshield-=dmg 
			if shipshield <=0:
				shiphp+=shipshield #shipshield negative overflow added to shiphp, subtracting values

		else:
			shiphp -=dmg
						

		if shiphp<= 0:
			alive = False

	data.append(hits)
	
histrange= max(data)
plt.hist(data, bins=histrange,range=(0,histrange))
print(np.std(data))
plt.show()

The range is from 16-27 shots to kill and the std dev is 1.6… Basically, ouch! (And i know weapons with higher dmg and lower rate of fire are planned. This will be much much worse for those weapons!)

2 Likes
4

Even though I see both sides of the pro and con concerning the damage split or probability options I still felt like “oh, either it goes in or not, that seems much less complicated to understand”.

I know RNG is not liked when it comes to competitive games … still … it introduces some fun luck kind of shots. Like. A sniper seeing that the ship has high shields but still trying his luck. Knowing that the probability is low. It introduces the “gambling” kind of fun into the game where else, currently it would have been more of a “if I land a perfect shot it is degraded by 90% no matter what. Need to land that shot a couple of times … is it worth my time?”

The other extreme is of course when he has 10% shields and you expect a certain quick kill but the shields gulp it up.

Concerning the situation with new players. I would prefer more aggressive flight assist for that too. The speed limits was one such change on the flight assist layer that worked out ok I think.
@Mattk50 Isn’t the flight assist already trying to change the vector if you turn the ship? Are you suggesting the flight assist predicting the players behaviour in some form? Or are you suggesting to instead of making the additional boost velocity dependand making it “deviation from velocity vector” dependend?
Another idea would be to have the turbo be partially also controlled by the Flight Assist. Past a certain deviation it kicks in automatically … although we have seen how automatic function, like warp, kind of failed spectacularly.

Generally I am quite confused why so often core aspects of the games are changed for very specific reasons. I am just shaking my head often because I wonder “how the hell is this getting balanced later on?”

Atmosphere Thickness Falloff of Planets, this will affect atmospheric flight balancing later on an totally changed the altitudes different flight height will. Gravity Falloff. Hardcoded key combinations.
There aren’t that many examples. Just wanted to add that here again to underline how it makes it really hard to look at a certain thing separately if they all are (made) intertwined.

1 Like
5

It’s a bit more drastic than just individual lucky gamble shots, if sometimes there’s a (reasonable, not counting the tails of the curve) chance of 18 shot kills or 25 shot kills. That’s 7 clean hits of difference which even then is a randomized potential ~40% extra hits it can take to kill the target.

If it did just quickly converge to the same values it might not matter but this randomness is way too much for a game to have competitive dogfighting. Its worth considering that as players get better at the game, skill levels will get closer and closer with smaller differences between eachother. At some point with this much randomness in kill shot count, it will quickly be exclusively random outcomes in dogfights as skill levels approach eachother.

Consider a game that’s risen to great popularity lately, mordhau, a game with zero randomization in hit damage in a melee setting! It’s actually unusual in melee games not to have some randomization because devs see it as an elegant solution, but really people want to predict what happens when they perform an action. and that makes games competitive.

Currently it assists in changing your vector yes, but it will never slow down your forward velocity based on your turn rate. The way this type of assist worked very specifically says, say you are turning at some degree/s and you are asking your ship to thrust forward. When you are at a certain target forward speed and you turn, you can calculate the “effective” or “frame of reference” acceleration caused to your side/up velocity. As you turn speed will “bleed” from your forward direction to your side direction at a known rate calculated from the current rate, no prediction needed.

You then take that acceleration and say, is this higher than the acceleration of my strafe thruster? If it is, then cap/reduce the target forward velocity until we can make this turn while compensating for all (relative frame of reference)side acceleration. That’s SC’s old comstab, in a nutshell. I thought it was pretty good before they replaced it with a completely different thing many years ago.

2 Likes
6

I think I dont like the new flight model.
The game pretty much feels “on rails” now compared to before.
The drifting is part of the spacey feeling in space IMO, it also made the game stand out to the other airplanes in space games.
It would be okay if the anti drift system would be a piece of gear that occupies a medium gear slot and could be swapped for other things. That way you could have new players have the system and when the game becomes more competetiv they have the option to enjoy newtonian flight by swapping it out and having a free slot on top.
But it still needs to be toned down a little still then.

I also noticed that the anti drifting introduces some unintuitive behaviours in some situation were I lost sense where the ships is moving in that moment. This will probably change with more playing.

IMO drifting could be instead countered by increasing the boost output (faster energy depletion because of stronger boost). Boosting to a stop or to catch up to the enemy would also be better than mindlessly hammering the boost button in combat like I pretty much do now.:thinking:
I also think the boost shouldn’t apply to anything but the forward and backward engines, boosting to turn faster is nice but also kind of annoying and mandatory unfun in pvp.

The new missile lock icons are very nice, they replaced the need to listen to the audio cue.
Also the bomber textures are very nice.
I noticed that the weapons on the bomber flicker in visibility from an outside view.

1 Like
7

Usually what happens is that they’ll fly towards their target, turbo boost, land maybe a few random hits, then overshoot. And spend the next 1-2 minutes changing course.

This is fundamental to newtonian mechanics. It will always present a learning curve to new players who have played nothing but arcade-like airplanes in space.

Moving forward this is going to be the #1 issue frustrating new players. Space-sim hard / soft-core players will adapt much more quickly, but if we want a shot at having full servers, we can’t just target fans of newtonian space-sims.

I understand your desire to want to attract players, I’m not going to argue against that.

I’d like to propose a middle ground solution:

Space brakes

Seriously. It’s not players getting to the target that’s the problem…it’s the overshoot and the time it takes to get back that ends up being frustrating.

Think of space brakes like the pirate ship movies where they like to drop anchor and quickly swing their ship around behind their opponent.

Mechanically for the game, I would propose that upon application of the braking function you would:

  1. Remember their current coordinate and then
  2. Treat the ship like an object at the end of a bungie coord or rope whose length is the difference between the ship’s current location and the remembered coordinate.
  3. Apply a counter force along the vector towards the remembered coordinate.
  4. The strength of the force is proportional to the distance.
  5. Heat builds up at a rate proportional to force. Drop heat sinks to compensate or release brakes.
  6. Cease force upon release of brakes or exceeding operational capabilities.

In order to actually turn, it would require the player to change their heading and apply thrusters. Otherwise it will just slow them down (drastically by intent)

These numbers can be fine tuned to give desired turn rate capabilities. You can also offer options under the ship customization loadouts by offering parts with different variables such as force per distance, heat buildup efficiency, force elasticity i.e. more like a bungie coord (snaps back) or a rope (plateaus), max/min “rope” lengths.

Yes, it would probably require a new key or a combination of keys.

Yes, it would probably require a new networking check for the server which might lead to wierdness with latency (I would hope there’s a happy medium between turn radius and networking checks)

I propose this out of a desire to maintain a degree of uniqueness for I:BS. Right now it feels like it’s headed towards an “Airplanes-in-space” solution, which has been done before, probably for the very reasons mentioned here.

For interceptors, this translates to me just using kinetic weapons against them…They die too fast for caring whether the probabilistic nature of the shields stops them. Fire in volume and make contact…they go down. For other ships, you just fire kinetic anyway, cause you won’t run out of ammo before you die and you’re more likely to take them down that way. Overall, it just makes blasters that do little to no hull damage less useful. If you go to bubble shields, it might change the dynamics, but right now just spam kinetics when available.

1 Like
8

There is a reaction, but the force used to move a tiny particle is unnoticeable on the laser itself. Otherwise I like your proposal even though I didn’t pay attention to the flight model changes honestly.

Does this happen outside of warp?

Edit:

  • I paid attention to the flight model, it is really weird to have almost no drifting at 400m/s. I orbit the station very close without effort. Not my thing, I prefer newtonian flight.
  • The bomber has too many gun reticles. I think both the machine gun and shotgun reticles show up simultaneously.
  • The mine icon outline doesn’t work well on radars (and the front/rear radars still need to be closer or merged IMO):
    screenshot0.
  • All ships turn much slower in warp as noted elsewhere.
  • The missile lock reticle is not very clear for me. Does it turn red when locked? How do you precisely aim dumbfire torpedoes when you don’t know which hardpoint will fire?
  • I still don’t use external view on capships because of the aiming offset issue and the top/down blind spots.
  • Often when I pick a target it is already swarmed by allies and dies before I can do much damage (no kill assist notification). To mitigate this, combat HUD should either show allies in shooting range of the target, allies targetting the target or a clue on how many allies are targetting it, so I can choose my targets better without using the exploration HUD.
  • I am not very fond of the random shield penetration, I think dedicated FX would be better.
  • I have not noticed the health bar blinking so far.
9

My 2c:

  • I mention my idea for the overshoot problem here:
    General Suggestion Mega Thread LOOK HERE FIRST
  • I am not a fan of the random green laser shots that appear on screen during battle. They simply need to go IMO. … Everybody sees that, right? EDIT: I have since learned that those are the corvette’s repair drones. Still, I would prefer a less blaster-fire looking affect, maybe a small subtle greenish vignette.
  • Warp is unnecessarily sluggish. I think turn rate should be very, very much faster than what it is. It was okay before this patch, but it’s unbearably slow. In fact, it’s pretty much easier to exit warp, turn around, then re-enter warp.
1 Like
10

That was an unintended change ( a side effect of the flight model update ). It’ll get fixed in next patch at least :wink:

2 Likes
11

If you select torpedoes, there’s only one reticle, so there cannot be any ambiguity. It’s a different launcher from the missiles, it’s placed on the underside at the front of the ship.

12

I’m not a fan of newtonian flight, thats probably because I want a different experience than an ultra hardcode space combat sim.
The game is much better now, but its is still very hard.
The flight model is good now imo. I’d still prefer a non-newtonian one though, but for a newtonian flight model its completely okay. Maybe If I master it more I will think different, but as a casual gamer this is how I feel.

The other thing that makes the game hard atm is battle awareness.
In yesterdays community event there was so much going on that I had no idea what was happening.
I did not even realize I was being shot at, I just read “critical hit” and died soon afterwards several times.
The amount of enemy target recticles was overwhelming.

I think recticles should not be shown when the ship is not visible from the user perspective (this is how it appeared to me, somebody please correct me If I’m wrong).

Ships cannot hide from one another and I cannot tell if an enemy is behind the station or in front of it.
It kind of makes space inconsequential because you can see through walls.

1 Like
13

nice idea :+1:

14

Also it occurred to me that having a dedicated “brake” button on spacebar by default might help new players (not quite the same as thelazyjaguar’s suggestion). It would temporarily set the goal velocity to zero (putting it back where you had it set after you released it) and also activate boost. This creates a one button way to cancel current velocity quickly and counter overshooting. As critic has noted in the past, he and other players often do not use up their energy much as they stay on the default overcharge. Then, using boost and energy as a way to counter drift is probably a better solution and having a dedicated brake key on the biggest key on the keyboard might be a big help especially if emphasized in the tutorial. If not, then if anti drift used the equivilent amount of boost energy and was disabled in FA-off then it would still be newtonian.

The goal here is essentially to create assists in such a way that the game is playable and fun with just the mouse and W, even if it’s not very good for competetive play. so basically turning and holding forward. The comstab assist i talked about is one step, and a brake like this could create an easy “help” button for when a player feels they are overshooting. For a newbie setting throttle system to 0 to brake is very confusing, heck i don’t use the throttle either because i think its too much to manage sometimes and im better in just pure FA-off.

For making capship combat more dynamic, why not allow boosting on capitals?

3 Likes
15

Seconding the suggestion of a dedicated brake button. For someone who doesn’t know what they’re doing, it’s very easy to hold W when going towards a target and then overshoot because they weren’t looking at where the target was going. Another change I’d like to see made is some greater amount of awareness in the combat hud mode. Maybe instead of entirely removing non-prioritized enemies targets, replace them with a colored dots (so you can at least see how many/where all the enemies are.

Yesterday during the stream, I felt that at high velocities, the turn speed felt slowed. Today, I got in game and tested turn speeds with different settings and velocities.

all in interceptor, turning horizontally, flight assist and rotational assist on unless otherwise specified (vertically is faster though)
Stationary
9 sec 360 no overcharge rot assist on
~4 sec 360 no overcharge rot assist off (but it requires manually slowing rotation)
9 sec 360 engine overcharge rot assist on
~4 sec 360 engine overcharge rot assist off (manually slowing rotation)

at 400m/s
~13 sec 360 no overcharge rot assist on
~5 sec 360 no overcharge rot assist off
~13 sec 360 engine overcharge rot assist on
~5 sec 360 engine overcharge rot assist off
~9 sec 360 rot assist on, flight assist off
~4 sec 360 rot assist off, flight assist off

Essentially, turning ends up feeling very sluggish at high speeds with flight assist on

4 Likes
16

Disclaimer: I haven’t tested 0.4.6 yet so can’t comment on that specifically. This is a general reaction to what I’ve read.

I’m on holiday at the minute so this will only be a quick response! I just wanted to add my opinion that I would be extremely cautious about nerfing the Newtonian flight mechanics just because of this problem.

The Newtonian flight (regardless of the specifics of how it operates) is one of I:B’s USPs alongside the planetary generation. It’s unusual to have true freedom of flight in a true-to-scale system and the more it is restricted, the more generic the game will become, although I agree it has to be accessible.

Equally it’s nothing that can’t be solved with player education. A quick tutorial (or even a tips and hints popup) would go a long way in helping new players pick up the game and learn the rules of flying in Battlescape.

In short:
Make it hard, teach it well, earn the reward.

It will feel more satisfying to the players as they master it, as long-standing backers have done.

7 Likes
17

I have one more bit of feedback before the main comment:

I would really like some consistency in the mouse wheel. It seems like half the time, moving the wheel down will instantly set the target velocity to zero. Moving up is fine, moving down is a pain. I don’t know why I’m using the mouse wheel for target velocity, but I would absolutely love it if there was a way to have the increments equal for both up and down.

Now, I wholly agree with Sab1e’s comment. I would be very sad indeed to see the Newtonian flight model ditched or modified to such an extent that this game literally just becomes a nicer-looking Elite Dangerous. Going from ED to IB is like playing most other FPSs, then afterwards playing Warframe. I think that for something like overshooting, changing the flight mechanics is akin to throwing the baby out with the bath water.

Another 2c on the overshoot problem ~

It might be difficult for a first-time player who has no idea what Newtonian even means to immediately be able to pick up the game and become an elite pilot, however there’s nothing inherently wrong with difficult flight mechanics. I would urge that instead of making drastic changes to the flight mechanics, the opportunity is taken to give something to the player to overcome these challenges.

I see three general paths that might be considered, most if not all have already be covered. I’m not going to spell it out, as I think it is redundant at this point, but in brief, first a tutorial, most helpfully a video, that explains the flight mechanics, as well as a general combat guide, that goes over all the basic errors that new players tend to make, such as overshooting. The community here probably will do this anyways, the sooner the better.

@mattk50 has done a wonderful job in making a write up, however if players are truly ‘struggling for hours’, then I don’t think that they have read it. That said, reading a wall of text to know how to play a game is DCS level territory at this point of gaming history. Having a video going over these topics, with mattk50’s write up as a template, would probably alleviate the majority of pulled hairs. At the very least, a link to the forum tutorial should be put somewhere on the launcher.

Second, address the problem by giving the players something to counteract the undesired behavior, such as the brake button. Having to push one button to stop is pretty easy to remember, and the brake feature can be later refined for more in depth game play (eg, separate energy bar dedicated to the brake-boost). Another could be a quick-intercept feature, where the player selects a target, then upon activation, the auto throttle will try to keep the player within a certain radius of the target. Another could be a UI-only feature, with the HUD giving players estimated time to arrival, with prominent, unmissable numbers, and warnings if you’re going too fast.

Third, address the problem by giving players a special ability to completely negate the undesired behavior. I mentioned one earlier, where the interceptor has the ability to ‘jump’ to within a certain distance of a target: one button, then you’re within 500 meters of target.

I’m sure there’s more, but this post is getting rather long.

That said, I think that the game already has a perfectly usable counter to overshooting: the Match Velocity function (at least there was, I haven’t used it in a while so it could have been removed). It’s just that it’s hidden under some other ominous functions, and it isn’t something that a new player would necessarily understand if they did find it. It could very well be tweaked to address the overshoot problem.

I’ll wrap up by saying that I think that the game is too young to try to adjust major aspects of gameplay that might not actually turn out to be a problem in the long run if simply left alone. Personally, I would try to give the players more tools, then focus on other things. If those tools aren’t enough, then to make the flight model changes as needed.

4 Likes
18

Anyone else missing the ‘Ship Yaw’ axis on the key binding page after the update? You can assign individual buttons still, but not a joystick axis like you can for pitch and roll. I need to yaw!!

19

I remember somebody else having the same problem. It’s probably related to an input profile version issue. You can either add it back manually, or just remove the config file from your user folder ( C:\Users\XXX\Documents\I-Novae Studios\Infinity Battlescape\Profiles ) and let the game re-copy the original.

20

Okay, that fixed it, although now I’m going to have to re-map everything. Seems like I’ve spent more time dicking around with control configurations for this game than I have playing it.

Another suggestion on flight controls. Using a throttle, the ‘zero’ range is somewhere in the middle and hard to pin down, so you are almost always applying forward or reverse thrust unless you program in a huge dead zone on your own.

I’d recommend making the throttle zero --> max. Then, for ‘retro-thrusters’ or ‘reverse-thrust’, either require a ‘condition key’ (like the pinkie switch or something) in order to reverse the throttle range, or use keys for retro thrust. That way when you pull the throttle all the way back in either mode, you are at ‘zero’ thrust.

STILL NEEDS A HUD PITCH LADDER IN ATMO!! :slight_smile:

1 Like