Purpose

These are engine only changes which add the possibility to create a Drone Bay or Fighter Bay outfit as a purchasable and installable outfit.

This enables Fighter Bay and Drone Bay outfits to be purchased from an outfitter and installed on gun or turret mounts. This would convert Gun hardpoints and Turret hardpoints into fighter bays.

Download links

I maintain a custom fork of Endless Sky which includes all of my pull requests combined. You can get the latest download of this fork here https://github.com/samrocketman/endless-sky/actions/runs/2266893824

Videos

• Bactrian super carrier
• Fury drone miner (uses features from fleet mining pull request)
• Mule mining carrier with 2 drones and 4 fighters

Screen shots

Installed outfit can be moved around to different gun ports.

Click to expand and see screenshot

---

---

Navy carrier with drone bays and fighter bays installed in every gun port and turret mount.

Click to expand and see screenshot

---

---

Features added

This new feature adds the following:

• New weapon attributes "Drone Bay" and "Fighter Bay"
• "Drone Bay" outfits will dynamically generate Drone Bay hardpoints over the installed Gun weapon hardpoint.
• "Fighter Bay" outfits will dynamically generate Fighter Bay hardpoints over the installed Turret weapon hardpoint.
• Reorganizing where the bay is installed on a Gun or Turret will dynamically change where the docked fighter or drone is rendered externally on the ship.
• Drones mounted in guns always dock facing forward.
• Turret-based fighters now visually have new angles:
  • 0 degrees angle for Fighter Bays mounted in the center turrets.
  • 45 degrees angle for Fighter Bays mounted in starboard/right sided turrets.
  • -45 degrees angle for Fighter Bays mounted in port/left sided turrets.
• Outfit panel renders a proper description showing a Drone Bay or Fighter Bay is added when purchasing the outfit.

Related pull requests

Related issues:

• https://github.com/endless-sky/endless-sky/issues/6396 requests external bays for fighters/drones. This PR adds both Drone Bay and Fighter Bay outfit. Both drones and fighters get mounted externally by this feature.
• https://github.com/endless-sky/endless-sky/issues/5549 mentions an unhappy scenario where drones were bought but fleet was unable to carry them. This PR adds Drone Bay outfit.
• https://github.com/endless-sky/endless-sky/issues/4610 mentions having a generic "Bay" which could take a fighter or drone. This change adding Bay outfits would reduce the need for complicated engine logic to avoid fighters/bays taking the wrong bay which would leave a mixed-bay fighter/drone stranded. The playre can choose the bay they wish to have installed by the outfit being purchased.
• https://github.com/endless-sky/endless-sky/issues/4034 this change adds a cheap drone which is easy to replace.

This is an intentional design point of Endless Sky: bays are not outfits and cannot be added or removed on a whim. Why are we considering changing that?

I've stated that I'm not against the idea of adding functionality that would allow bay outfits to exist, but I don't think that it's something that should be used in vanilla. That is, maintain it as an intentional design point of Endless Sky the game that bays aren't outfits, but allow Endless Sky the engine to make such outfits.

This is an intentional design point of Endless Sky: bays are not outfits and cannot be added or removed on a whim. Why are we considering changing that?

While it may have originally been a design decision to not have the ability to add bays as outfits, it is something that has been highly requested. Even if having outfit bays in vanilla is something that has been "Noed," there's no reason why we should explicitly deny this flexibility to plug-in creators; and plenty of reasons why we should: (these are all in the context of plug-ins):

• enables entirely different sorts of ships than those currently found in the ES paradigm
• enables better support for solo play by allowing people flying large ships to have distractions without needing to lug around a fleet or focus on a carrier.
• enables better support for modular ships (aka plug-ins where the player has one ship that is modified over the course of a career.

Anyway, thanks for making this. Looking forward to trying it out!

@quyykk

Ability for converting hardpoints to custom bay categories

I'm still new to the hardpoint code. How would you see this as a feature? Can you describe in more detail? As-is I don't know what changes to make, if any.

Ability to specify which hardpoint type the outfit is for

Is this in-game by a player? Is this for plugin creators via properties in txt files? I'm not sure what changes to make based on this request.

@tehhowch

This is an intentional design point of Endless Sky: bays are not outfits and cannot be added or removed on a whim. Why are we considering changing that?

I've been discussing this in discord for the past week. Should I ping you more on topics such as these? I feel a disconnect between core maintainers and my changes lately. I don't want to work on stuff unlikely to be merged. I split out the data files into a separate PR #6793 since it was unlikely to be merged after discussion with Derpy in discord.

With regard to this feature: This is being added as an enhancement for gameplay around using fighters and drones. The bays themselves (even if added as a plugin) do not come free to the player. They're limited by the amount of weapon hardpoints available (and type of weapon). It does not grant the player ability to arbitrarily remove bays. If a ship comes with bays (drone or fighter) as part of its design those are considered static and not changeable. However, if an outfit is installed the outfit itself does bay +1 on the weapon hardpoint where the bay is installed. Those bays can be removed if they're added by an outfit.

@quyykk all code changes made upon your request except for the ones I didn't understand or have enough detail on.

@tehhowch @Amazinite adding on to my earlier comments and even pulling comments out of discord...

This proposed PR is being added as an enhancement for gameplay around using fighters and drones. The bays themselves (even if added as a plugin) do not come free to the player. They're limited by the amount of weapon hardpoints available (and type of weapon). Here's a breakdown of compelling points:

• The carrier's balance or really any ships balance is not drastically affected by replacing all weapons with bays. It just has more fighters/drones but significantly reduced combat power compared to a ship simply equipping weapons.
• (not in this change but planned) Fighters should use long-range weaponry if they have them first. Fall back to short-range weaponry defensively.
• Long-range energy/ammo based weapons that could be installed on a fighter are end-game outfits except for homing missiles. So (not currently implemented) kiting based AI enhancements to fighters would not be effective until late-game when these longer range weapons are obtained from aliens.
• Carrier-types still have a place because they can be more deadly than other ship types since they have built-in bays. So can carry that much more. These are basically fighters and drones for free from a player perspective.
• Up front cost for new players to use fighters or drones today is 7 million credits. Bays reduce the up front cost to < 500k credits + flagship cost.
• The bays add a lot of mass paired with the mass of the fighters. In practice, while play testing this... this makes large carriers with lots of bays sitting ducks because they're slow to turn and accelerate. Play testing this feels pretty clean with the heavy tradeoffs.

Warning

I am going to put forth strong opinions but it will be respectful.

Carriers are already indistinguishable

The current content around carriers means not much content for first-time players. I've seen this in-practice playing with many people over my thousands of hours of gameplay. The reason why I started working on the fighter AI in the first place is because of this situation. Carrier experience is currently poor carrier availability, expensive fighters, poor use cases where they're sink holes of money creating losses for the player. There's improvements which can be made to AI but gains are very limited in AI changes alone.

Carrier experience is not a good experience

Please strongly consider Bay Outfits for inclusion into vanilla. Engine support definitely for content creators right now. However, I still think vanilla gameplay would improve with installable bays (drone/fighter).

Current game play is: there's no cheap fighters and all useful carriers become available later in the game/towards the end. The first-time player is DONE with the game by this point (I cannot emphasize this enough...). First-time players then tend to replay the game by the time carriers become useful or they're moving on to another game to play. By the time carriers become useful (for human space) the player is already in new alien space where carriers are less useful.

Let's say a player even speed runs obtaining a carrier as a goal in the current game. They have to build a wealth of about 8m credits and purchase the Mule (1 fighter) or Aeri (2 fighters). One or two fighters at this point in the game will mostly be a novelty as their usefulness in battle is not great. They are a cost sink for the early game player due to likelihood of losses.

I am trying to improve carrier gameplay

I'm trying to change this cost sink to a benefit in the following ways in my other pull requests:

• Low powered fighters
  • Battery only fighters possible
  • Refueling fighters (tanker carriers)
  • Fighters help recover other escorts and fighters.
  • Carriers assist and pick up their own fighters.
  • Antimissile defense fighters (broken/does not work in vanilla but I have fixed in in my low powered fighter AI pull request)
• Fleet mining asteroids (good with fighters because they're fast combined with battery only power they can have cargo expansions installed in human fighters)
• This pull request adding bays as outfits engine support.
• If for vanilla, this pull request reducing the cost of a carrier for a player down to a little under 500k credits excluding carrier ship itself.

List of carriers from first-time player perspective

New and seasoned players are unlikely to have decent ships with fighters for most of the game. Here's a table break down of every ship that has drone or fighter bays in Endless Sky.

Please approach this table from the perspective of a first-time player/new player. The likelihood they are to obtain the ship considering they have no idea about the universe or map layout. Some of these ships took me over 100 hours of game play to stumble upon my first time playing from my recollection.

I define game play time from earliest to latest as the following.

• Early game (tutorial and into early part of FW)
• Mid game (FW)
• Late game (toward the end and after FW campaign. In alien quest lines)
• End game (content is mostly finished)

Ship name	Bays (fighter+drone)	Cost (credits)	Obtainability by first-time player
Heron	36	256.375m	Impossible
Tek Far 109	16	18.29m	End game/capture
Class C Freighter	12	13.4m	Late game/capture/unlikely
Tek Far 71 - Lek	10	22.87m	End game/capture
Carrier	10	15.2m	Mid-Late game/capture/unlikely
Tek Far 78 - Osk	9	25.63m	End game/capture
Pond Strider	8	5.25m	Late game/purchase from Hai
Solifuge	6	22.8m	Late game/capture
Skein	6	3.5m	Late game/purchase from Human
Ibis	6	11.627m	Mid game/purchase from Remnant
Heliarch Judicator	6	33.953m	End game/capture/unlikely
Emerald Sword	6	100m	End game/quest line
Roost	4	3m	Mid game/purchase from Human
Korath Dredger	4	29.37m	End game/capture
Cruiser	4	11.2m	Mid game/capture/unlikely
Auxiliary	4	13.72m	Mid game/capture/unlikely
Bactrian	3	17.6m	Late game/purchase from Human
Nest	2	2.5m	Early-mid game/purchase from human
Nanobot	2	50k	Impossible
Korath Raider	2	16.57m	Late-End game/capture
Kestrel	2	14.7m	End game/purchase from Human
Fetri'sei	2	50m	Impossible
Aerie	2	3.5m	Early game/purchase from Human
Mule	1	4.08m	Early game/purchase from Human

Please note the above cost is just for the hull. The total cost of the ship is actually more because I did not factor in their outfits + hull if the ship is purchasable.

Up front costs is really much higher. For example, the Mule and Aeri requires a net worth of roughly 8m credits to obtain with fighters (after purchase re-configuring outfits can bring cost down to 7m).

Summary

This game is an amazing game. Because MZ was against an idea does not mean it was a bad idea. Good examples of good ideas which are traditionally rejected in my opinion is fleet mining and installable fighter/drone bays. This project has good direction and its potential is still not fully realized so let's not limit ourselves to a specific original vision. Escape Velocity (I'm told but never played myself) had installable bays and cheap fighters were used as ammunition. I think Endless Sky does it better with customizable fighters. So this pull request is to make customizable fighters more readily available early game (even if only by plugin). Adding these features I think is in-line with the vision of being a homage to Escape Velocity.

I would be happy even if this is considered a stop-gap to getting better carriers in the game because as of right now I see no improvements to carriers in terms of content and ships in the foreseeable future reading through issues and content chat day to day (this is just a feeling I get).

If you took the time to read this all the way through I appreciate your time. Thanks.

As of now, I never use fighters as they are totally pointless; they die in seconds and don't do enough damage to warrant the pain to have to remember to carry them back before jumping (and loss of time). They could be okay as swarm but the kind of money needed and what you get back for it just doesn't feel right (and any other swarm is better because it would have less losses).

These changes (with the mining PR) look honestly very good and could make a very limited use ship become finally useful, as in you could have a carrier in your fleet specialized into making fuel for your other ships, this also makes using small ships way more viable as you can refuel them easily (instead of waiting for ages for a big fuel tank ship to refuel them)

That said balance seems to be an issue here (as always?), and I feel that instead of weighting in this new possible weapon that is a fighter (an expensive missile of such) and new possible customisation (which for me is the biggest positive point of this game, with the story) some just want to avoid that much needed question of balance at all and remove this option from this game, instead of finding what weapon; outfit space, maybe even energy generation would be needed to make this balanced. If that is indeed the case and there are no real arguments behind not allowing new content in vanilla, I strongly disagree with that.

I'm also not against the idea that we would allow "bay providing outfits" to exist (at least in the engine to allow plugins to use those), but I have a fundamental concern with the limited scope of this PR.

If we want to allow Gunports to be convertable to Bays, then we should have something like a generic notion of a "mount point" and we should be able to specify per mount-point what would be the default "operating mode" and what "conversions we allow on each mount point".

An overall vision (think RFC ) on such "mount points" should tell me how I convert Engine ports into backwards firing gun-ports (or even Bays) and it should tell me how a content-creator that is creating ships can control what conversions can happen on which "mount point".

A ship-content-creator should be able to prevent guns that are fully built-in (with just a small part of the barrel sticking out of the ship) from being converted to Bay/docking points. The ship-content-creator should also be able to specify if a "mount point" conversion to a bay results in an "INSIDE", "OVER" or "UNDER" bay. (And for turrets the "mount point" should also give me the default bay angle.) The overall vision should also tell me how those conversions affect engine-space, weapon space (and maybe also outfit space) and issue #4700 is also related to this PR.

If we allow "bay providing outfits", then I also want to have recursive bay support properly implemented (with a good set of automated tests to safeguard it). I should be able to install a "drone carry" outfit on a Boxwing; So a Drone docks into the Boxwing with my outfit, the Boxwing docks into a Aerie.)

I also agree to all of @quyykk remarks about customization, not hardcoding, and supporting all bay types. And a feature like this should also have an extensive set of automated tests that show that the feature works as intented, and that safeguard such a feature (with the tests acting as regression tests) from being broken in the future.

Not wanting to discourage you, but my opinion about the "mergability of this PR" is that it is not mergeable at least until:

• The overall vision is in place.
• The "affected system-functions" all have good regression tests.
• The new functionality has good regression tests.
• More basic functionality (like restricting missile launchers to some gunports and not others, and setting limits in outfit space on gunports itself) is in place.

I'm very happy with all the enthusiasm with which you are implementing new features. But IMHO there is quite a bit of rework on the core game-engine that needs to be done before we can get to very cool but very impactful features like this.

@petervdmeer good to know an RFC process exists as an idea in ES. I was not aware and probably would have followed it to begin with. (I understand my current work has been gun ho). With regard to fighter bays as outfits. I'm open to making all of the changes (more modular customization, respecting angles, integration tests, etc.). I have a question with regard to RFC feedback you shared. Would you like me to put forth the vision/idea inside of the pull request itself as a comment? Would you rather I file separate pull requests for RFCs and sponsor the RFC work as a dedicated pull request to be merged (RFC document)? With regard to testing is there a metric I should be targeting? Enough cases to be satisfied it won't break? 100% coverage, >100% coverage?

@samrocketman I'm not deciding the course for the game alone; we have a group of about 7 maintainers that all could have an opinion on this and I notice that none of the other maintainers did respond to my latest comment yet.

Part of my comment was really content-creation related; like the question if we should allow each and every hardpoint to be convertible to a bay (or if we should put restrictions on that). If all other content-creators feel that it is a good idea to allow each and every hardpoint to be convertible to a bay today, then I'm willing to step back from my statement and then you can just proceed with the implementation here.

Regarding the tests;

• I just merged #6770, which is a pre-requisite for integration-testing non-vanilla plugin-only functionality (the alternative test universes). This doesn't help you today, but it does give you multiple options;
  • Either you wait for me to finish the universes functionality (and then write an integration test for bay-convertors using the universes functionality).
  • Or you try to implement the universes test-functionality yourself (I'm willing to upload a branch with half of the functionality in, and I don't have a lot of time the coming 2 weeks for ES, so you do have some time to try by yourself then.)
  • Or if there is consensus that this PR can be merged without tests in place (maybe because it is plugin only functionality so we care less), then you could also try to convince us that this is mergeable without additional tests.
• I also have #6502 open, which tries to remove the GameData dependency from the Ship class. The GameData dependency is one of the factors that seems to prevent ships from being unit-testable. There still is quite a bit of work to get all the opens handled to make Ships and AIs unit-testable, but also there you have the options of waiting, contributing or convincing that testing can be ignored.

Sorry if my feedback is frustrating; I know how disappointing it is if you implement a very cool feature and then some maintainer is comming up with arguments like "long term vision", maintainability and testability. But I feel those arguments are quite important to avoid some nasty "technical debt" in the future.

Regarding RFCs: If you look at https://github.com/EndlessSkyCommunity/endless-sky/pulls then you see 3 open PRs marked as RFC. (You will also see that they are quite old already, so asking you to write an RFC might also feel a bit unfair. I created #6801 which I hope will also improve that process.)

Okay so I see three action items for me:

• Update this PR with less hard coding and better options for content creators, respect both turret and gun angles. Support more hardpoints than just gun/turret inside the ship. Allow CC customizing of inside/over/under. This is something I plan to do before merge.
• Regarding testing: Review @petervdmeer work on test reorganization and get some context around intent by reading through comments and references (a lot has been said so I'll need to review a couple times likely). I plan to contribute to the effort because I like tests.
• Separate from this PR: I can put together an RFC in the mean time around test infrastructure taking in suggestions already written by @petervdmeer and @quyykk on this PR and in the-hub discord.
• With even if this change is merged without tests there's still some things I need to change per feedback both in this PR and on discord.

I will add that the feature of having installable bays has been pretty enjoyable to play with. I am replaying the the game start to finish with my developed PRs and so far it is pretty nice.

• Separate from this PR: I can put together an RFC in the mean time around test infrastructure taking in suggestions already written by @petervdmeer and @quyykk on this PR and in the-hub discord.

No, the test-infrastructure can already be found at https://github.com/endless-sky/endless-sky/tree/master/tests . No need to create an RFC for the test-infrastructure.

No need to create an RFC for the test-infrastructure.

Just following up here since I said so in discord. I will not be writing an RFC (in case someone is only following PR).

Converted to Draft; this PR has open review-comments from quyykk and from me that are not handled yet. (Please feel free to convert back to non-Draft once the review-comments are handled.)

I've stated that I'm not against the idea of adding functionality that would allow bay outfits to exist, but I don't think that it's something that should be used in vanilla.

If you're going to say no, you need to actually say no. Otherwise you're saying "yes" and also not giving the feature the necessary due diligence.

Even if having outfit bays in vanilla is something that has been "Noed," there's no reason why we should explicitly deny this flexibility

The reason is simple: unnecessary complexity. Adding things because we can is not free; contributors must understand the feature, both intent and implementation, to make source code changes. Plugin authors will need to inspect their content to determine if this new functionality will break their existing ship designs and intended atmosphere. New content will need to be balanced against the existence of this functionality.

Unused features are by nature untested features, meaning we will silently break them. As Peter identifies, we can alleviate this somewhat with tests. But adding tests is also not free, testing each PR takes longer, tests must be maintained, etc.

I've been discussing this in discord for the past week.

I haven't been on Discord since mid February; pinging me will not create the free time needed.

--

I have no interest in adding a complex mechanic that will not be used in the game that we create, that we will need to maintain in perpetuity, for no benefit to ourselves. If it gets decided that this is a mechanic to be supported by the engine, then it better be vanilla-ready.

If it gets decided that this is a mechanic to be supported by the engine, then it better be vanilla-ready.

I wouldn't open a PR that I didn't think was vanilla ready. The engine support works. My intent is to add bay outfits and while the outfits themselves are not vanilla ready the engine support is. I have seen other features broken up into separate PRs for engine support and data files so not sure I fully understand what your meaning by vanilla ready is. This PR has about 40 hours of play testing as of this writing. It is stable and works as described.

That being said I see your rejection. I disagree with the balancing suggestion that this will break game balancing. I encourage you to try play the game with this feature yourself. The best I can do is argue in its interest (and point to multiple years of feedback in this area going through issues).

Ultimately if this feature is fully rejected and closed, then I will maintain a supported fork of the game and play it the way I want.

@tehhowch to clarify, could you expand on what you mean by vanilla ready? The change is stable and works. There is some feedback per code review but once implemented it would be fully play tested and considered stable for merging. I put a lot of work into making sure all of my PRs are stable, production-ready, features.

@samrocketman I'm sorry to disappoint you, but this feature is far from vanilla ready.

I listed a number of things in my earlier comment and that is just a start of what I feel is needed to get a little bit closer to making this PR vanilla ready. Your last replies suggest to me that you didn't understand what tehhowch or me said. You will however need to do a lot more than just handling our review-comments for a PR like this; you will need to have a deep understanding of the concerns behind the reviews. (And I expect that at least 5 other PRs need to be implemented and merged as basis before we could even consider merging this PR.)

If you're up to the challenge, then I'm very much okay with you trying to make this PR (and the 5 other PRs) vanilla ready. Feel free to ask for clarification if any of my review-comments are unclear, but also keep in mind that the time the maintainers have is limited. (And all the time we spend on your PRs is not spent on other PRs.)

@petervdmeer

I'm sorry to disappoint you, but this feature is far from vanilla ready. I listed a number of things https://github.com/endless-sky/endless-sky/pull/6792#issuecomment-1119036605 and that is just a start of what I feel is needed to get a little bit closer to making this PR vanilla ready.

I think you misunderstood me. I understand there's feedback in this PR. I address feedback when it comes in and I am fine with you converting it back to a draft. I was mostly meaning the PRs are stable code-wise but I agree with the feedback given and that the changes will need to be made. My main concern with vanilla-ready comments was it felt like my code stability and idea in general was called into question.

I am hopeful this would be merged given all of the following conditions are met. 1) all feedback is addressed and there's no outstanding feedback 2) all prerequisite pull requests are merged. The vanilla-ready comments make me think otherwise.

I believe this is a feature which would be used by many even as a plugin. I play the game with this today. So I do not believe this would be an obscure code path which would see little use.

And I expect that at least 5 other PRs need to be implemented and merged as basis before we could even consider merging this PR

Are these PRs that you're referring to ones that I have already opened and am shepherding them currently through feedback? Or are these yet-to-be implemented PRs? In which case I need a little more to go on if I'm to participate in implementing them.

If you're up to the challenge, then I'm very much okay with you trying to make this PR (and the 5 other PRs) vanilla ready.

I'm hopeful that I am. I try to be forthcoming with as much information as I can in the PR itself (both the description and the commits). I also try to address all feedback either with comments or with code changes.

Feel free to ask for clarification if any of my review-comments are unclear

Thanks I will; and in general I'm pretty good about asking others when I do not understand theirs.

but also keep in mind that the time the maintainers have is limited. (And all the time we spend on your PRs is not spent on other PRs.)

I understand completely. I am a maintainer in other large open source projects so I am sympathetic to these statements. I try to approach all of the feedback in a positive light, with good intentions, and giving the benefit of the doubt. Your feedback (tehhowch and others') has helped me become better at C++ and I value all of your time (being willing to share with me your experience).

In order to help alleviate maintainers, I have also taken your advice/request from discord to heart and have been both play testing and code reviewing other pull requests that are not my own in order to help facilitate their merging.

---

As an aside, I found bays as outfits to be quite useful in order to both find, fix, and test #6866. The ability to add/remove bays to try out different scenarios made testing the fix quite easy than it otherwise would have without.

Let's set code implementation aside for a second and talk purely data files. Instead of the Fighter Bay weapon attribute, I want to implement this in a way that is flexible for content creators per the feedback. Help me determine how this would look or behave. I'm thinking something like the following.

outfit "Fighter Bay"
	category "Turrets"
	cost 320000
	thumbnail "outfit/unknown"
	"mass" 40
	"outfit space" -40
	"weapon capacity" -40
	"turret mounts" -1
	"required crew" 1
	"unplunderable" 1
	bay "Fighter"			//<-- Enables more generic flexibility beyond weapons.
	"bay angle" 45			//<-- Not adding angle means 0. by default or turret or gun angle if weapon bay is chosen.  Alternate angle could be "bow" or "stern" which sets 45 degrees like hard coding in PR.
	"bay position" 0 0		//<-- I'm not sure how point should look here for where bay should be stored.
	"bay side" over			//<-- defaults to weapon type (turret=over or gun=under) but can be overridden otherwise default is "inside"
	"bay ship" "Mining Drone"	//<-- Filter so that only a specific ships is allowed.  Could allow more than one.
	weapon
		Bay			//<-- This indicates the bay should be a weapon type and so look to the hardpoint for bay position
					// Any other weapon-specific attributes I'm forgetting?

@samrocketman

My main concern with vanilla-ready comments was it felt like my code stability and idea in general was called into question.

Your code stability was not called into question, but the code maintainability was (and still is).

The idea in general was also called into question, and that is actually a good thing; implementing some features can block implementing other features in the future, so we need to make well informed choices.

I am hopeful this would be merged given ...

That's not how it works, not for this PR. If you continue working on this PR (possibly re-implementing it multiple times), then there still is a chance that in the end we will still find a reason not to merge this at all. Tehhowch is one of the most experienced members in the community, so if tehhowch expresses doubts about some idea, then consider that to be an early warning that all work on this PR might be in vain in the end.

I believe this is a feature which would be used by many even as a plugin.

Drop the idea of plugins; this feature will need to be so well defined that an experienced content-creator would be able to use it in one of the ships in vanilla (without affecting any other ships). Anything less than that would be non-vanilla ready.

Which brings me to one of the 5 other PRs I was talking about; the PR that implements https://github.com/endless-sky/endless-sky/issues/5443 will likely be needed to avoid the silly looking attached drones from Zitchas comment.

Btw, I found https://github.com/endless-sky/endless-sky/issues/3776 while looking for the other issue, 3776 also seems related to this PR (or to one of the 5 other PRs I was talking about).

@petervdmeer

if tehhowch expresses doubts about some idea, then consider that to be an early warning that all work on this PR might be in vain in the end.

That's fair and so be it if it comes to be. I will continue to maintain the mod in my fork even if it never makes it into vanilla for the community.

I will play the game the way I want and update the code on the basis that it may get merged.

If this PR gets closed that will be the final indicator that this is full rejected and I won't raise a fuss. I'll just maintain it for myself. Others would still be able to access it from my fork should they want to play with it.

I put it back into review when I have addressed outstanding feedback

https://discordapp.com/channels/251118043411775489/308902312741568512/980224843859496970

Another idea: bay filter for the kind of ship that is allowed to be stored.

Kitteh:

Could be it be feasible to design a heavy warship that during heavy combat can deply 'chunks' of it iself as light warships or interceptors to assist with the fight? How hard could it be to make it so only its designed 'fighters' dock with it?

You can filter what could dock. Bays as outfits allows a leviathan to have any fighter. But it would be cool to have fighter-specific bays. Such as the mining drone bay (only holds a mining drone).

I went ahead and updated my example to include a ship filter in comment https://github.com/endless-sky/endless-sky/pull/6792#issuecomment-1138166615

Another idea: bay filter for the kind of ship that is allowed to be stored.

You're trying to cram too many different features into a single PR. This type of filter has been requested multiple times already, and should have it's own PR (for regular bays first) before we should even discuss it here.

Another idea: bay filter for the kind of ship that is allowed to be stored.

You're trying to cram too many different features into a single PR. This type of filter has been requested multiple times already, and should have it's own PR (for regular bays first) before we should even discuss it here.

I'll do what I want as long as it is fun.

I'm just playing the game and enjoying the bays. I asked for feedback above on the data file format for this feature; it would be great if I could get feedback on it. Currently, I've been asked to make changes yet no direct feedback on how those changes could be or what they should look like from an end-user's perspective. I'm going to push this forward one way or another regardless of opinions expressed here.

The nice thing about a fork is you can do whatever you want.

---

This type of filter has been requested multiple times already

Is there a GitHub issue? Is it well defined and could be implemented by a contributor? I could contribute something like this but not before my existing pull requests are addressed.

It sounds to me like the core devs and I have very different ideas on how we'd like to play the game. At some point, this process has become painful for me so I'm going to focus more on what I enjoy and less on caring whether or not my features get accepted.

I'm still open to feedback and I'll make changes here and there.

I'm sorry to hear you don't feel welcome in the ES community. From my side I'm very happy with you being part of the community and I also noticed a lot of positive responses from senior community members like Amazinite, Quyykk, Zitchas and Hurleveur already just on this PR. Tehhowch and me are also not actively opposing the feature itself, but it is more of a "if we are going to do this, then we better make sure it is very well done".

Many active developers that quickly want to try out something have some sort of (private) fork or private plug-in, so I fully understand that you are considering to do something similar. If you want to contribute code to the vanilla main game, and feel comfortable to interact with the community, then you are also always welcome to create or update a PR here.

Is there a GitHub issue?

Yes, #5443, #4684 and #4610 seem relevant.

I also noticed #692 and #3795 when looking through the issues; those seem relevant for this PR.

Note: I'm not going to spend time on providing feedback on the data file format, because I feel that the overall vision first needs to be created. There is no point in discussing details when the bigger picture is still missing.

@petervdmeer

I'm sorry to hear you don't feel welcome in the ES community.

It's not that I don't feel welcome; I do. What I meant by painful (probably better described as impatience or angst) is the following.

The pace in which I would like to develop vs the pace of my PRs are merged has been a challenge to balance. I would like to develop the AI further as my primary focus and the review cycle between changes has been fairly long. I prefer small PRs though sometimes if I'm working on multiple features in similar areas there will be lots of merge conflicts. So it is simpler for me to keep adding on instead of breaking up the change.

I understand this is spare time for all of us but still pretty hard to balance sometimes for me. Sometimes it's hard to control my excitement to develop further which is how the low powered fighter PR (and general fighter AI overhaul) has grown to be so large.

---

I appreciate you taking the time to explain the process and outline changes which are future-looking that you'd like to see.

---

If you want to contribute code to the vanilla main game, and feel comfortable to interact with the community, then you are also always welcome to create or update a PR here.

I do plan to develop this further. At the moment I'll focus on my non-draft PRs and reviewing others' PRs.

When I'm in a good spot to continue this effort I'll take a look at the issues you've kindly outlined.