Isn't that the mayor feature of the next release? Is it just the conflicts that prevents it from being merged?

I think the major thing preventing this from being merged is the still insufficient AI support. Morlic said he might be able to do that until the end of the year, but of course that depends on how much time he'll be able to devote to that task.

And then there is the backlog of things which had been put on hold because of the release, and is currently worked through by the majority of the devs. Once that's done, I guess/hope the Fighters branch will rceive more attention.

IMO it's not necessary to already come up with a perfect solution for the related techs and where to place them in the tech tree before merging. To start with I'd just introduce a "Fighter" tech (which could depend on "Agression" or something like that) acting as the theoretical prereq and several dependent techs that unlock the various fighter/carrier related components. The Flak Cannon tech(s) could be made dependent on the Mass Driver tech.

After merging that we can start with more serious playtesting and finetuning the fighter/carrier related techs (and probably introducing more variety like different fighter types, related refinements etc.).

Isn't that the mayor feature of the next release? Is it just the conflicts that prevents it from being merged?

I think the major thing preventing this from being merged is the still insufficient AI support. Morlic said he might be able to do that until the end of the year, but of course that depends on how much time he'll be able to devote to that task.

And then there is the backlog of things which had been put on hold because of the release, and is currently worked through by the majority of the devs. Once that's done, I guess/hope the Fighters branch will rceive more attention.

Well, the AI builds fighter designs and considers them when comparing fleet strength. However, the underlying heuristic is far from perfect and nothing but a quick fix I implemented once I had no real understanding of how fighters actually work. I hope to find a better mathematical model once I have more time in november. In doubt, uncle Monte Carlo will always be a possibility, I guess. It's performance-heavy but, well, 1 iteration is a good enough approximation for the extreme cases, huh.

The AI does understand it needs to "refuel" its fighters and should do so.So, the branch should be in a playable state but the AI may over-/underestimate the fighter strength (seems to be more on the overestimate side) but the same will hold for the human players while working strategies are figured out, I guess...

So, in principle, we can merge the branch and work in master. However, there were quite some new commits to master since my last thorough playtesting on fighters-branch. Some of the commits introduced errors in the fighter branch that I have now hopefully resolved - the AI can play for 100 turns and conquer me without throwing errors. There may be more in uncommon cases though... As I won't have time before november to test for that or react quickly to bugs that other people found, it is probably best to wait for that...Anyway:

I will rebase the Fighters branch to latest master to resolve remaining conflicts this saturday. If anyone is working on the branch, he should commit the work before then (or say something).

_________________If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

I assume that means the absolutely necessary rudimentary techs are already in place too. If htat's the case, no objections from my side. Anyone?

Yeah, techs etc. aren't in yet. I was speaking from the AI perspective. The techs would of course also need to be added to the AI tech lists but that is such a trivial change (unless trying to optimize the research order) that I didn't include it in my consideration.

Also, the fleet window / UI must still be adapted to handle fighter stats better. Not sure if that should be done before merge but the current state is definitely... unsatisfactory.

_________________If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

One issue I'm not certain about addressing is representing different fighter types.

The most notable reference is the combat logs, the only way to tell between different fighter types is the attack damage (and then, not always).It would also be nice to be able to distinguish a specific fighter type in a tooltip, instead of the ship part.

Forgive the rough implementation, lining up total damage seems a bit more OT (more so the idea of summing part types).

I agree with that actually: when I started doing the scripting there were just different Fighter hangers, all with the same name, I renamed them bomber, interceptor and fighter for my own convenience but I quite like it now, nothing has been done to the backend in that branch since.

It's not a deal breaker, but if the "fighter shot at X" text and the "Fighter Weapon" link in the combat reports accurately described the type, or at least gave some distinction, it would make large furball results easier to read.

From the PR thread

LGM Doyle wrote:

Kudos on the Pedia blurbs for Fighters and the fighter tech progression. "Fighters and Launch Bays" is a clear explanation of the mechanic

Thanks I, um, knocked it up at the last minute before pushing the content, it needs cleaning up and preferably putting into a Pedia article but for now it's got the basics put down well enough.

Quote:

Love the new and improved Krill … Give the small Krill 1 fighter, so that so that there is a hint as to their next stage, but they still can't kill anything.

I'm also liking the Krill a lot, had a stealthed carrier take down a large swarm over multiple turns by simply running it out of fighters, they can be quite nasty in large numbers. We'll need to do more with them I suspect, have them perhaps replenish supplies in Asteroid Belts or similar. Oh, and give kraken an advantage fighting them, perhaps an increased ROF.

However, if we give the basic krill a fighter, it'll then count as armed and be able to block supply, etc. I have zero problem with this flavour wise but it might cause a mild balance problem and almost certainly confuse the AI. It'd be cool if we can do it without problems though.

Quote:

If ship A can't damage ship B, because of B's shields, should ship A still be able to blockage ship B? I designed a Krill hunter unit with only Flak cannons, and it could not damage Floaters, but it was able to blockade them indefinitely

Good question, I have no strong opinion either way. Anyone? Ships that can't do any harm at all are going to be more common when this goes in, I've had stealth carriers that've run out of fighters and are out of supply blockade an entire system a few times, that seems off to me.

_________________Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

I've also noticed this issue. The problem is more pronounced with MattGB's new Laser/Plasma/Death Ray plus pilot species variations in Fighters.

Your addition of the *N in the ship damage popup is good. It reduces clutter.

I was thinking of adding the fighter power to the fighter count icon popup, because it is different than direct damage. It is shield bypassing and is not applied every round. However it also makes sense in the weapon power icon, since it is a weapon power.

I agree, it would be better to see the fighter type in the ship window and the combat log. We could add a munition name to the FOCS ship parts, which in this case would be Interceptor, Fighter or Bomber. The pilot species information is already in the combat log data, but unused in the report. It may be difficult to fetch the fighter grade Mass Driver/Laser/Plasma/Death Ray other than as it currently stands the total damage, or it may as easy as altering the aforementioned munition type to change when the part is upgraded. Those (type, pilot and upgrade type) are all of the relevant details to the fighter power and should ideally be in the combat log.

For blocking monster movement, I'd argue it is up to the individual monsters behavior. If there is no actual damage to the monster, what keeps it from leaving the system?

With blockading, does the ship need to actually fire to prevent supply, or is the mere threat enough?For the former, changing armed to account for ammo depletion may be the simplest approach.The latter is the current case (the government/player may know the ship is not a threat, convincing the vessels that comprise the supply line is another matter).

I like the suggestion to add a new descriptive string to ship parts. It does occur to me that the fighters are not different, just their payload.Hence a bomber hangar can store less fighters due to the support equipment involved, not because of a different type of vessel.

I don't think fighter damage should be shown in the ship damage summary, as it stands the icon does not display if the ship has no other weapons.It is also more a property of the fighter, if the ship is lost in round 1 the fighters were still launched and attack next round.

Note, I don't see the tooltip change holding up a merge of the fighters branch. If it is, I'd like to request a rebase, specifically to utilize Ship::FighterCount

Over the course of this thread you've discussed many options both in design and implementation. Your implementation is complete and you've enjoyed feedback and time to refine it. Is there place I can read how fighters and carriers work"? Thanks

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum