Delta Fork: Introduction and Progress

[RisingLeaf]

Introduction

This is the Delta fork of endless-sky.
If you do not know what the Delta fork is, I strongly suggest you visit the wiki to inform yourself.

This discussion is made to keep everyone up to date with what goals are being worked on and what new changes got recently introduced.

You want to say something? Sure...

...but I ask you to conform to two points:

1. Instead of creating a new comment if you want to reply, write a reply on the comment instead just to keep things nice and tidy.
2. Stay polite at all times, should be easy enough.

How do I get involved?

Nothing easier than that, just write an issue if you want to request something specific or open a PR if you have something that you want some testing on.
I can not promise you that it will be accepted but we try to allow as much radical changes as possible.

Style guide on a comment on this discussion:

I expect something like this:

1. Name of the feature
2. Details on the feature
3. Possible changes
4. why it got implemented
5. list of connected PRs

[RisingLeaf]

Additional Scan Information and modular access (#2)

This feature adds:

• Calculated gun range (uses the hardpoint location & gun range to calculate the longest ranged gun on the target)
• Calculated turret range (uses the hardpoint location & turret range to calculate the longest ranged turret on the target)
• Calculates the targets actual turn speed (includes effects of slowing)
• Dynamically adjusts the display depending on the outfit configuration to display just tactical display, just strategic, or both.
• If a ship has just a tactical scanner, it will not have any visual changes compared to continuous prior to this PR.
• Tactical scan and strategic scan are available as before, both individually and together.
• Range, Weapon ranges, Turning speed, Fuel, Energy, Thermal, and Crew count can each be accessed individually as stand-alone items.

No changes planned

Got implemented to enable a more strategic gameplay, give the player access to more information that they can use in combat

[Zitchas]

Just a note that while the code supporting this has been in Delta for some time, it was only recently that in-game outfits were modified to make use of them. After consulting with a number of the faction contributors existing outfits were adjusted to reflect that faction's priorities. The Tactical scanner was shrunk down somewhat, and a couple of new outfits were added to take various aspects of it. The Thermal scanner was created as an outfit that becomes available alongside the flamethrower, as that is when thermal really becomes relevant.

A note for people looking for ideas of things to contribute: It would be nice to have unique graphics for the rangefinder and thermal scanner. They currently just reuse the tactical scanner. Likewise, it would be great if we could have a separate mission string that is available around the same time as or shortly after the flamethrower that focuses on the development and release of the thermal scanner.

[RisingLeaf]

Lateral Thrust and Drag Reduction (#10)

This feature adds:

• Minimizes the impact of drag on ships. It will now only kick in when above maximum speed or at less than 10% max velocity. Outside * * of these two extremes ships will operate without drag, which is to say a much more realistic method that actually feels like spacecraft.
• Implements left and right lateral thrust. Some might call it strafing, but I opted to call it lateral thrust because when an aircraft strafes a * target it is generally doing a pass across it. Aircraft would call what this is sideslipping.
• Implements the control key as a modifier on turning, making the ship turn half as fast.
• Implements lateral thrust flares. So if a ship has lateral engine points, it will get flares there using the standard engine flares.
• Implemented the "lateral thrust ratio" X attribute for ships.
• Implemented a default lateral thrust ratio.
• Added keybinds for left and right lateral thrust.
• The default lateral thrust ratio is now set in the gamerules.txt file, so content creators can change it without needing to rebuild the application.

Planned changes:

• Adjust lateral thrust depending on ship mass

Implemented to make smaller ships more useful in combat.

Associated PRs:
#14:
replacing the default 0.25 with lateralThrustValue = (3000 - mass) / 3500; or 0.1 if the mass is over 2500.

Ship	Max Mass	Lateral Thrust Ratio
Bactrian	2210	0.23
Carrier	1830	0.33
Dreadnought	1520	0.42
Falcon	1180	0.52
Osprey	760	0.64
Firebird	740	0.65
Hawk	380	0.75
Shuttle	210	0.80
Sparrow	195	0.80
Lance	130	0.82

[RisingLeaf]

Adding Player in-flight information (#11)

Adds indicators on the right side that inform the player of their flagship's current:

• Speed
• Max acceleration (will reveal slowing when present)
• Max turning speed (will also reveal slowing when present)
• Current effective ramscoop value
• Current effective solar energy value

Flagship motion indicator

• with preference to allow choice between off, ghost, white arrow, or both.
• Longitudional thrust bar (forwards and reverse)
• Rotational thrust bar (steering left/right)
• Lateral thrust bar (left and right lateral thrust)
• Thrust boxes and icon for thrust indicators

No changes planned

Added to make it easier for the player to notice where and how they are moving.

[RisingLeaf]

Limited Turret Arcs (#18)

Allow limiting the angle that turrets can aim and fire both from ship's hardpoint and the weapon itself. Will use the most limiting of the two if both exist. Unlike the previous PR, the arc is relative to baseAngle/idleAngle as I think it is more intuitive and easier to visualize. Now first arc value have to be less than second arc value.

PRing this to Delta fork experimental branch because I think it's can greatly affect combat gameplay especially when used along side other potential balance changes like large difference in speed between large and small ships as well as new fighter AI in #17 .

Planned changes:

• Using it in game

[1010todd]

I just found my old plugin I made to implement arcs on ships but it was fairly outdated and seems like only human ships are done. I'll update it and post it here.

[Zitchas]

Turret arcs have had some renewed interest lately, including someone mentioning that there's a plugin that adds them floating around. I wouldn't be surprised to see some movement on implementing some turret arcs on select ships in the coming months.

[MadisonianX]

The plugin you mentioned is Arc Over by Saugia. The problem is that gun/turret/pylon hardpoints are not separately overridable; when you declare new turrets, you have to declare new guns and pylons too. So the plugin's gun ports still have pylon based systems declared when playing on Delta which causes errors, and ships that had turret arcs added overwrite pylons causing negative pylon slots.

Aerie: outfit "Sidewinder Missile Launcher" installed as a gun but is a pylon.PT
	gun -12.000000 -78.000000 "Sidewinder Missile Launcher"

I would recommend adding Saugia's turret arcs to Delta ships for testing so that there's a congruous set of all three hardpoint types that includes turret arcs from which to copy hardpoint data from for plugin experimentation.

[TheGiraffe3]

I had an issue about that: #80.
So turret arcs in Delta may not happen/would need a modified plugin.

[Zitchas]

It would certainly be an interesting basis for turret arc work, for sure.

[Zitchas]

Limit number of fleets & spawn specified number when entering system (#24)

Feature Details (copied from UnorderedSigh's PR)

1. Limit the number of a specific fleet that can be spawned at a time.
2. Limit the number of non-disabled fleets of a specific type that can be spawned at a time.
3. Require that a minimum number exist upon entering a system.
4. Give fleets a "category" so that multiple fleets count as one for the purposes of items 1 & 2.
5. Have a fleet ignore the enemy strength when deciding to spawn.
6. Tell a fleet not to spawn at system entry during the loop that spawns five seconds of ships. (This is needed for integration testing.)

Syntax:

system
    fleet "Fleet name" <period>
         period <period>             # alternative to <period> at top line
         limit <limit>               # No more than this many can spawn with the same category
         non-disabled limit <limit>  # No more than this many can spawn with the same category,
                                     # ignoring fleets of all disabled ships
         initial count <count>       # Ensure this many have spawned when system is entered (overrides limit)
         category "fleet category"   # The category of the fleet; multiple fleets can have the same category

         # Normally, the game will not spawn random event fleets if the side is too
         # much stronger than its enemies. This flag tells the Engine to ignore that:
         ignore enemy strength

         # There is a loop during system entry where the engine will spawn
         # 5 seconds of ships, which causes problems for integration tests.
         # This option turns it off for one fleet
         skip system entry

All arguments are optional, except the fleet name. The default category is "fleet name@system" so the limits and initial counts only apply to that fleet in that system if you give it no category.

The Engine will keep track of fleets as they despawn. However, disabled ships have not despawned, so if there's a limit of 10 fleets and 10 fleets are sitting in the system disabled, no more will come. To avoid this, use non-disabled limit which skips fleets whose ships are all disabled.

Usage Examples

1. A guard ship. There's an example of this in the test cases. An Archon is assigned to Korath Exile space because somebody is pillaging the Korath Exiles to extinction. Six systems have a limit of one Archon each, but the limits have the same category. That gives the illusion of an Archon being wherever it is needed.
2. Ensure at least a certain number of fleets are present without going over. The Drak vs. Pug fight shows this. A non-stop flow of Pug Arfectas come into the system and die. They're limited to 12 fleets of 6 though, so the number never gets out of hand. Likewise with the Remnant vs. Korath examples.
3. Tell a ship to ignore the strength (cost) of enemy governments when spawning. This would be useful for Korath raiding fleets in human space, where the Korath ships cost so much more than human ships that they only spawn when they're overwhelmed with firepower. If this option were turned on, the Korath would keep raiding even if they could vastly overpower the humans.

If the period, limit, and initial count, are connected to conditions, then we can do this:

1. Presence or absence of an Archon is dependent on a single condition.
2. A non-stop battle may or may not be raging in a particular system, and its intensity depends on the limit, period, and initial count set in conditions.
3. The player rudely boards a disabled ship. The faction activates a rescue fleet by increasing the limit above 0.

[TheGiraffe3]

Use a separate folder for saves/plugins (#78)

This moves all the Delta files over into their own unique folder so that it will have separate preferences, saves, plugins, errors.txt, etc from the regular alpha/beta version of ES.
and plugins are still largely cross-compatible, so copying those from one to the other will still work.

Before this, preferences from ESD that didn't exist in ES would be erased, while preferences that didn't exist in ES would be blank/default when copied into ESD.

[TheGiraffe3]

Scaling Sol (and potentially other interesting things) (#52)

This is expanding Sol to show what is possible when the system is larger and has more places for traffic to go internally. The end goal is to be big enough that it provides meaningful terrain for combat as a model for future endeavors.

Makes combat much more interesting in-system, and if there are ever storyline battles in Sol, there could be guerrilla tactics.

[Zitchas]

Sol is an interesting case as, due to the many inhabited places, it is possible to observe the development of flight paths as ships arrive from defined directions of hyperroutes, then path to various destinations; as well as taking off from planets and going to other planets. It can be quite interesting to watch, and could be even more so if there happened to be conflict within it.

I also note that -due to the size of the system, it is possible for pirates to be triggered to show up by the player and arrive, and get side tracked on some other ship due to the scale making it reasonably likely that spawned pirates, while still hostile to the player, are far enough away that they don't lock onto them. This has the net effect of making the game feel much less "player-centric" as well as generally safer for the player (especially new players when the pirates are a more meaningful danger.)

[Zitchas]

Pylons

---

With the introduction of Pylons, we now have three hardpoints to use in defining a ship's weaponry:

• Gun ports, used primarily for primary weapons and guns of all sorts.
• Missile pylons, used primarily for rockets, missiles, torpedoes, and things of that sort, usually secondary weapons.
• Turret mounts, used primarily for primary weapons mounted on rotating platforms.

All the relevant weaponry has been modified to use the new slots, and all ships that had rockets, missiles, or torpedoes installed stock or variants have had enough pylons added to enable those to fit. I do not anticipate changing any of the ship loadouts to increase the amount of weaponry carried, as I don't see any gameplay benefit to making NPCs more deadly. In terms of balancing, so long as stock and variants are not revised to have more weaponry I don't see a balance problem. The exceptioin is probably primary weapons. One of the points of having pylons is to allow for ships to still have primary weapons instead of it being either/or situations. Weapon space will still be a heavy restriction, but a little more flexibility in using it.

Other games (such as EV) don't limit the secondaries at all other than the outfit space itself without problems, so while balancing in the future may be required, I don't see an imminent need for it. Likewise, if the player happens to manage to be a bit deadlier than the NPCs, I don't see a problem with that.

[xobes]

How do I get involved?

Nothing easier than that, just write an issue if you want to request something specific or open a PR if you have something that you want some testing on. I can not promise you that it will be accepted but we try to allow as much radical changes as possible.

How?

git branch delta-experimental
git switch delta-experimental 
git remote add -t experimental endless-sky-delta-experimental http://github.com/endless-sky/Endless-Sky-Delta.git
git reset --hard endless-sky-delta-experimental/experimental 
git pull endless-sky-delta-experimental experimental -f --rebase
clear && cmake --build --preset linux-debug && ./build/linux/Debug/endless-sky  

[TheGiraffe3]

Scaling Kornephoros and Sabik (#102, #104, #131)

Kornephoros and Sabik have had orbits doubled, to expand the combat terrain and make FW battles more interesting.
Sabik has gotten a new uninhabited planet, Donya, with an interesting backstory as to why it has been abandoned.

[Zitchas]

Variable Fuel for jumps

Endless Sky has had the ability to vary the amount of fuel used in a hyper jump for a while now. From the wiki:

"jump mass cost": an additional jump fuel cost per 100 tons of ship mass. Adds to the base jump fuel cost above. (v. 0.10.0)

"jump base mass": a value that subtracts from a ship's mass during the jump mass cost calculation. If a drive's jump base mass is high enough and the ship's mass is low enough, the impact of the jump mass cost is allowed to go negative and begin subtracting from the normal jump fuel cost. Reducing your jump cost in this manner is only allowed to go as low as a cost of 1 fuel per jump. (v. 0.10.0)

However it had some display problems, namely in the fact that the fuel bar always only shows increments of 100, which is a standard hyperjump, so it is easy to assume that those bars always indicate number of hyperjumps one can do. This is OK in the old ES, but as soon as you introduce variable mass costs, that becomes problematic, since for a scoutship, it might only take 80 fuel. And a Carrier might take 300+

Implementation:

#123

Details:

I picked 900 mass as that was right around the cutoff line between light ships and medium ships. Anything that is smaller than 900, is going to take less fuel to make a jump. And anything over 900 is going to take more. Currently, this is set at 4/100 for hyperjumps. It was decided that Scramdrives should be +50% fuel cost, not +50 fuel cost; and likewise that jump drives should be +100% fuel cost instead of +100. In upstream, these are all identical. But had to be clarified to determine what the proper increases were for Delta. Currently, this takes the form of +6/100 for scram drives, and +8/100 for jump drives.

In order to be more transparent to the player, a new HUD display mechanic was introduced, whereby players can buy outfits (included in the game now) that make an indicator visible on the HUD that shows how much fuel their ship will use for the selected jump type. There is an outfit that will display the fuel cost per hyperjump, another for scramdrive.

There is a separate outfit that changes the bars on the ship fuel segmenting so that it will segment into sizes appropriate for HD, SD, JD, or fixed sizes, depending on which outfit they install. People who want the old method can use the fixed size, which is currently set to 100. The fixed size one stacks. So if people want increments of 200 instead of 100, they just need to install 2.

Screenshot

The following shows a picture of a scoutship that has all four otufits installed. As such, it's HUD shows its current mass, and current fuel cost to make a hyperjump, then a scramdrive jump, then a Jump Drive jump. I anticipate that most people will only want one of these installed, or maybe just have the one(s) that correspond to which drive(s) they have installed. Mass is mostly just an interesting statistic to kno, but can be very helpful when troubleshooting, fine tuning outfitting, or creating new content. So like many of Delta's improvements, this sums to put real data and control in the hands of the player instead of locking it away. Note: When landed ES assumes the ship is fully equipped, but has no cargo. So the numbers can change a fair bit between on-planet and in-flight for ships that have a lot of cargo onboard.

[TheGiraffe3]

Four new person ships (#134, #136, #144)

We've added new person ships, not meant to represent specific people in real life, but just for more variety. Feel free to PR a person ship for yourself as #135 suggests!

Random Author is a heavily modified Protector - eight turrets, ten guns.
Sanujab is a Hai Cicada with multiple Keystones and many questions for human.
Intola is a Scout who is of the opinion that speed is better than power... always.
Verdorve has decided that Plasma is Powerful, and the Splinter uses nothing but plasma for both engines and weapons.

Both of the latter two love to shoot pirates.

The spawn rate for person ships has also been doubled, and Zitchas has received more hails.

[TheGiraffe3]

Thermal Scanner missions (#90, #100)

Short mission chain to unlock the Thermal Scanner at a more realistic time, as suggested in #15 (reply in thread).

[TheGiraffe3]

Lampyrid Start, move normal start date back (#116, #112)

A new start in a Modified Lampyrid. Is unlocked after a few years of in-game playtime; uses the same ship as the person Tranquility.
#112 moved the starting year back by six months, giving players a bit more time to explore before the Free Worlds conflicts begins.