maneatingape / rsvp Goto Github PK

I tried to deploy this library on a vessel that was already low on space. There wasn't enough room. I tried compiling the code to ksm files, which would fit - except the cross-file runpaths use the file extension.

If you don't use a file extension, the library can be used in either compiled or non-compiled form:

https://ksp-kos.github.io/KOS/commands/runprogram.html#automatic-guessing-of-full-filename

Feature Request

Allow for a custom specific orbit as a destination.

I'm working on this. As of now no help needed. Issue created as a point to talk about ideas.

Currently I think the best way to do this would be to:

• Add a destination type "custom"
• Add parameters for this destination type
• use a similar function as for rendevouz with vessels, but instead of getting the target parameters from the target vessel get it from user input

Before creating a bug report please check that:

• Issues list does not already contain this bug report.

Describe the bug

When traveling from a moon, the transfer will go astray with the following symptoms:

• Massive delta-v values
• Missing target completely
• Scripts crashes with exception

To Reproduce

1. Place vessel into stable orbit of moon (e.g Mun, Ike, Laythe, Tylo)
2. Attempt to rendezvous with another moon
3. Attempt to rendezvous with a vessel in orbit of parent planet

Expected behavior

Maneuver nodes are created that execute rendezvous.

Environment:

• Operating System: macOS
• KSP version: 1.10
• kOS version: 1.2.1
• RSVP version: Pre-release
• Mods installed: None

Feature Request

Before creating a feature request please check that:

• Issues list does not already contain this feature.

Is your feature request related to a problem? Please describe.

Happy New Year! It is currently not possible to plan a vessel intercept when the destination vessel is around a child of the current body, even if the inverse is possible. For example, a vessel in orbit around Kerbin cannot plan an intercept with a vessel around Minmus, however, a vessel in orbit around Minmus can plan an intercept with a vessel around Kerbin.

Describe the solution you'd like

Ideally, it would be possible to plan these transfers as it would appear to be the same 2-body SOI problem that's been solved so well with your library. All the standard options for vessel intercept planning would still apply.

Describe alternatives you've considered

The obvious solution being simply planning a transfer out to the second body, say Minmus, then planning a transfer from there is the immediate work-around, however sub-optimal the deltaV of that transfer set up might be. I expect there's probably a good reason for this feature not being in the current release, but I will try to go through the code myself as well to see what would be required to get this functioning. Creating this issue to see what roadblocks there might be, and happy to put up a PR with my implementation if by some miracle I understand enough orbital mechanics to make it work.

Additional context

Appreciate the library a lot already and hope for some helpful feedback!

Before creating a feature request please check that:

• Issues list does not already contain this feature.

Is your feature request related to a problem? Please describe.

Celestial bodies sometimes get in the way of transfers, causing them to fail. e.g Mun when leaving Kerbin

Describe the solution you'd like

Return list of transfers in ascending order of cost, instead of just returning best transfer. If a transfer can't be made for some reason (e.g. an unwanted encounter with another body gets in the way) then try the next best transfer and so on.

Describe alternatives you've considered

The user could handle retry logic in their own scripts.

current vessel is ion-u [nero]. target is nero (from gpp).

neeero.zip

Feature Request

Describe the solution you'd like

If the mid course plane change option is active, then the first node will have a normal/antinormal vector that will place a relative AN/DN in an inexpensive interval of the transfer orbit (nearer the apoapsis, but prior to reaching target SOI; would vary whether going inward or outward from transfer orbit body (Sun in most cases). Then a midcourse plane correction maneuvernode would be created at that relative AN/DN.

If the midcourse option is selected and valid departure times coincide with the initial body being at a relative AN/DN between the first node body and the target body then the first node would be created that accomplished the plane change during the initial burn, or alternatively, a "pre-first" node that puts the craft in a circular orbit at an inclination and LAN that will match the desired plane change at the time of the normal first node burn. This initial node could be burned by the player long before the normal first node burn time arrives in prep for actual departure.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Feature Request

Is your feature request related to a problem? Please describe.
When rendezvousing a very low orbit the orbit often get's dropped below dangerous limits (atmo for example, not sure if the script respects for terrain or if it would crash into that also)

Describe the solution you'd like

Define atmosphere and terrain limits as minimal altitude per default and allow the user to overwrite the default.

Describe alternatives you've considered

Let only the user define minimum altitude without automatic defaults.

Additional context

I thought this only happens by approaches from below, but it also affects approaches from higher orbits to lower orbits.

This is a result of this issue: KSP-KOS/KOS#2721

Interestingly, all 3 parameters to RANGE() are supposed to be integers, but KOS will round the first two.

I've locally made a tweak that seems to work, but not sure if this is the best fix:

    local window_duration is latest_departure - earliest_departure.

    for x_offset in range(0, window_duration, round(search_interval)) {
        local x is earliest_departure + x_offset.

Before creating a feature request please check that:

• Issues list does not already contain this feature.

Is your feature request related to a problem? Please describe.

Sometimes a transfer that is only slightly lower (e.g. by 1 m/s or so) but much further in the future is selected, resulting in more time warping than necessary.

Describe the solution you'd like

Create a setting with units of m/s^2. Then when comparing transfers the total adjusted cost is the raw deltav + the time difference from now. This will weight transfers that occur sooner, in order to prevent a transfer that is only very slightly cheaper but much further in the future from taking precedence.

For example: impatience_factor = 5e-6 = 0.000005

Then if there are 2 transfers:
Current time: Y1 D1
Transfer 1 => Time Y2 D1 => Raw deltav: 1000 => Adjusted deltav: 1046
Transfer 1 => Time Y2 D1 => Raw deltav: 999 => Adjusted deltav: 1091

Describe alternatives you've considered

Use existing earliest_departure and search_duration setting to limit searches to windows. User can search within each window then select transfer using arbitrary criteria.

I was going to deploy a relay in polar orbit at the destination, and realized that there’s no option for polar insertion. Perhaps as a “final_orbit_orientation” parameter? You could do polar_north or polar_south if you wanted to get real fancy, but if it just picked arbitrarily I wouldn’t mind.

Bug Report

Describe the bug

Documentation indicates that default value of max_time_of_flight setting should default to twice the ideal Hohmann transfer time. But see line 61 of search.ks

This results in transfers that have large radial components of their planned delta V. Usually this delta V is more than the prograde component. Total delta V can exceed 1800. In some cases it will create transfers exceeding 2000 delta V where the trajectory takes you through Kerbin.

To Reproduce

My game is in a 2.5x system, but it shouldn't matter. In a circular, equatorial orbit around Kerbin, get a transfer to the Mun.

	LOCAL options is LEXICON("create_maneuver_nodes", "first", 
							 "verbose", FALSE,
							 "search_duration", SHIP:OBT:PERIOD * 2.5,
							 "search_interval", SHIP:OBT:PERIOD * 0.01,
							 "final_orbit_periapsis", 50000,
							 "final_orbit_orientation", "retrograde"
							 ).

Expected behavior

A maneuver with ~ 1400 delta V required for the munar injection burn.

Additional context

If you explicitly pass the

	 "max_time_of_flight", rsvp:ideal_hohmann_transfer_period(SHIP, Mun) * 2

the resulting transfer is "correct."