It's time to consider the SLF an exploit in multi-player

I'm not convinced FD even knows about this problem in their game, considering how long it's been going on. But it should at least be considered as much of an exploit as pulling the cable or loading a "trainer". Maybe just remove it from Open play entirely until it's fixed, like when other exploits were removed because they were against the spirit or intentions of the designers. My 2 cents. YMMV.

Source: https://youtu.be/wxh5aMEVnZI
 
The problem illustrated is quite clear. However, I'm far from convinced of it's prevalence, or certain of it's cause.

I've been in combats recently where several CMDR owned SLFs were in play simultaneously, without issue. Conversely, the only times I've seen rubber-banding as bad as shown in the OP's video, SLFs didn't exist yet.

I have heard credible reports of hammering the SLF with commands causing issues, which seems to be a recently introduced bug, but that the SLF is a problem in and of itself is less than clear.
 
This happens even when both players have awesome internet.

The game needs almost no bandwidth, so the source of any issue is unlikely to be related to that.

However, ping may be an issue, as could game (I jack up my 'MaxUpRate' in AppConfig.xml) or network settings, or other aspects of one's connection quality. It's even possible that their is a CPU/scheduler element at play here (I use custom settings for this too).
 
We could adopt a different stance to resolve this issue - removing open play from ships with SLF hangars? Prevent this issue at the core by preventing any ship with a fighter hangar from ever instancing with another player, as that seems to be the issue.

If SLFs automatically blacklisted all other players, I might even venture out into open play myself if I had a hangar equipped...
 
I’ve heard of crazy lag or framerate issues being caused by NPC controlled SLF’s, but not those being used by players.

Time for science.
 

Deleted member 38366

D
Dunno, this has happened plenty of times without SLF. And it happened before the SLF was even a thing.

Adding MultiCrew members adds to the chances of running into issues (if they're in an SLF) - but that's not the fault of the SLF either.

Crappy P2P Networking = crappy experience. SLF nor not.
 
cant and will not remove the SLF, I`m standing up for the Multi-crew players...
And while we are at it, I`m also standing up for solo players, as we also reserve the right to have carriers, as in clause 1 "Blaze your own way"

(Need legal advice call me on 555-125-785 today)
 
He's not wrong, it's a huge issue in pvp, and it can be deliberately caused by repeating commands to the SLF. The worst part is that spamming attack commands to lazy low level NPCs is sometimes necessary. I think Frontier have already pledged to fix it in the next patch. It's been like this since the April patch we think. Most of us avoid using slfs to avoid the accusations of exploiting this effect. There was huge drama about it recently between two big squadrons. Definitely don't want that kind of drama.
 
Just did a few tests with a pair of SLF equipped Corvettes.

Everything started off normal, but spamming orders almost instantly induced rubberbanding, which then persisted for the duration of the instance. Worse, even without excessive manual orders, it appears that the issue eventually cropped up regardless, though it was much slower to do so; the AI itself seems to be the problem.

This was also not limited to NPC crew flying the fighters; it happened even when they were left in command of the motherships, with the CMDRs in the fighters.

I also observed a fairly large bandwidth spike on the meter while commands were being hammered...not enough for bandwidth itself to be the limiting factor, but telling none the less. Didn't have the presence of mind to check CPU load, but I'll try to do that later.

Uploading my test now, will link it here and in the issue tracker when it's done processing.
 
Just did a few tests with a pair of SLF equipped Corvettes.

Everything started off normal, but spamming orders almost instantly induced rubberbanding, which then persisted for the duration of the instance. Worse, even without excessive manual orders, it appears that the issue eventually cropped up regardless, though it was much slower to do so; the AI itself seems to be the problem.

This was also not limited to NPC crew flying the fighters; it happened even when they were left in command of the motherships, with the CMDRs in the fighters.

I also observed a fairly large bandwidth spike on the meter while commands were being hammered...not enough for bandwidth itself to be the limiting factor, but telling none the less. Didn't have the presence of mind to check CPU load, but I'll try to do that later.

Uploading my test now, will link it here and in the issue tracker when it's done processing.
I wonder what it is about the npcs that makes this happen...
 
Maybe try a better internet connection ? Maybe he has a vad internet connection ?


Either way removing SLFs is dumb.
It's nothing to do with internet connection from merely passively having the fighter out, it's that sending instructions to the fighter doesn't appear to be rate-limited in any way so if you set an autoclicker script to spam orders, or merely bind it to your scrollwheel and spin it, you can effectively DoS everyone else in the instance. Sure you lag too, but your fighter (being an aimbot) can still hit them.

I've seen videos of 1v1s where they've suspected this and their received bandwidth is orders of magnitude higher than their sent, some 80k/s incoming to 2k outgoing, with their opponent rubberbanding all over the place during the fight.
 
It's nothing to do with internet connection from merely passively having the fighter out, it's that sending instructions to the fighter doesn't appear to be rate-limited in any way so if you set an autoclicker script to spam orders, or merely bind it to your scrollwheel and spin it, you can effectively DoS everyone else in the instance. Sure you lag too, but your fighter (being an aimbot) can still hit them.

I've seen videos of 1v1s where they've suspected this and their received bandwidth is orders of magnitude higher than their sent, some 80k/s incoming to 2k outgoing, with their opponent rubberbanding all over the place during the fight.
Fd should fix it, but removing them is not the answer
 
Back
Top Bottom