Incrementally Improving PowerPlay - Remove commander from instance as soon as landed

This is part of a series of proposals to improve PowerPlay in various ways. The goal is to make PowerPlay a more interesting, dynamic, and rewarding experience, without needing to scrap the whole thing and rebuild from the ground up - evolution rather than revolution. Each proposal is intended to be relatively straightforward to implement (though of course we have no special insight into the specifics of the Elite codebase), and most of them (except where mentioned) stand alone and do not need a lot of other changes to make them work.

Please limit discussions to the specific topic at hand - pros, cons, tweaks, etc. If you have alternative proposals, by all means make a separate topic! The parent thread for this series is here: https://forums.frontier.co.uk/threads/pull-your-fingers-out-incrementally-improving-powerplay.551571/ Although the authors are Winters/FLC commanders, these proposals have been made and discussed by pilots from many Powers.


Remove commander from instance as soon as landed

Instead of being able to park the ship on the pad, but not in the hanger, this proposal automatically moves the ship to the hanger as soon as landed, and then removes the ship from the instance, so the pad cannot be blocked.

Discussion:

Currently a landed ship can be either on the pad, or in the hanger, and functionally there’s no real difference - the ship is still invulnerable, and is still blocking the pad. It’s not clear why this functionality is present - it seems to serve no purpose to have the ship be “in the world” when the commander is just interacting with the station UI.

This proposal changes it so that as soon as the ship lands, it plays the “enter hanger” animation, and then the ship is removed from the instance (aside from communications), which frees the pad for use by others. There is no option to return to the surface - the only option is to launch, and then the ship returns to the instance (or a different one if the pad is full, just as if they had logged in), plays the usual launch sequence, at which point the ship is vulnerable again.

This solves two problems. The first is that there are many intermittent bugs around the sequence. NPCs sometimes land inside each other or other players, a pad can be assigned to dock even though there is an invulnerable NPC already docked, and there’s generally a lot of strange corner cases. This proposal would remove (most of) those.

The second problem is deliberate pad-blocking by enemy commanders to prevent hauling cargo to/from a system. Currently if they do that, there is no remedy - the pad cannot be used, and the commander cannot be destroyed. The only solution is to switch to Solo, or to block the commander, jump out, and jump back in. Both these are very much against the spirit of PowerPlay, but pad-blocking is very powerful (two commanders leaving their machines running overnight can completely prevent preparation or expansion of a system) and has no other remedy. This proposal would solve that problem.
 
This feels like a sensible solution to one of the critical roadblocks for Open-Only PowerPlay or even BGS. Frontier will have to work through a few technical challenges, though. For instance, when a player launches, the game must decide which instance they will enter. That means going through a FSD-jump-like transition sequence to keep loading smooth, while the game establishes the peer-to-peer connection it uses for pilots in the same instance. It may slow landings and launches due to the addition of hangar entry and exit on every landing, as well as the loading transition sequence to establish an instance. For pilots who are habitually in a hurry, this may damage their gameplay experience. I would suggest that this can be mitigated by keeping the current surface-landing paradigm available in Solo mode only.

Second, although the game is not 100% consistent on this, it does try to launch you from the exact same pad you landed on. Loading into a new instance may prevent you from using your original pad, because another pilot may have it reserved in the instance you join. The simple solution is to select a different pad of the same size, much like the game sometimes does already when you log out while landed. Some players may complain that this breaks their immersion. Personally, I believe it is an acceptable trade-off to eliminate pad blocking entirely. I get the idea that most complainants about immersion don't play in multiplayer modes in the first place! As above, I would suggest that the current landing and takeoff sequence can be preserved in Solo mode only. The vast majority of players would notice no difference with this implementation. Only players who are currently vulnerable to pad-blocking would notice a difference, and I wager that the overwhelming majority of those will accept the trade-off of a little immersion for quite a lot less frustration.
 
I don't agree with this proposal. Congestion at Outposts is part of their charm in Open play. Is pad blocking irritating and troublesome? Yeah, it is, but actively creating a mechanic intended to de-instance players with each other is something that I don't want to see become the norm for Elite.
 
I always felt like the structures have been very poorly planned in general for Elite's scale. A single landing pad is pretty ludicrous, even half a dozen of them aren't really reasonable considering the spaceship traffic that a billion population system would easily generate. To consider pad blocking as valid emergent gameplay is an abomination of poor design.

I don't really like the forced de-instancing, though. It adds a few annoying seconds that over time would add into hours when you're doing it 30+ times every day, maybe if it only happens when someone requests to dock and there's no free pad.

I feel like that this issue could be solved in a more natural way with associated gameplay, like part of a modular upgrade system for structures through CGs or even through an enhanced BGS that would get to this aspect. Stations in general feel too similar.
 
Another solution:

Have extra megaships that act as 'home base' as well in capitals, bolstering pad numbers. Or, allow FCs to be powerplay bases in said systems- then the problem stops.
 
pad-blocking is a flaw that must be addressed or Powers could simply be shutdown for lulz.
Id prefer to see Powers' HQ systems be treated uniquely to enable an iron-clad fix, since any measure that might be balanced for most other systems, wont quite cut it for those essential HQ bases.
Solution might be to limit the number of players in a Power HQ station instance, to the number of largest pads available.
This would limit 'social interaction' at Power HQs, but for a team strategy layer like Powerplay, its a downside thats barely relevant..
 
Didn't we already have something similar, for awhile? I'm thinking of the Gnosis "emergency protocol" during the Thargoid attack. Pad-hogging was impossible.
 
Top Bottom