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.

[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