Major overhaul finished

[arekbulski]

This is a final, as in beta testable version with all features implemented and tested ingame. I encourage you to fiddle with it hands on and look at all nice details I put there, so I wont describe all features that were added. Let me just justify the controversial choices where we disagreed.

• Target vessel (stock game mechanic) is the FTL target. If you have engineer redux mod, selecting is easy. On stock game, not so sure. There is no Next button anymore.
• TweakScale allows scaling parts but... double sized part is only 2x force while it is 8x size and 8x cost. Since its heavier, it also needs more force. Those exponents make upscaling drives either harshly diminished return or counterproductive. I made a test, two identical ships with normal and 1-up drive 2500iN. Success went from 19% to 22% at significant cost in mass (therefore fuel consumption) and money. This makes TS fair.

I will need your help with few things before shipping this public. Please play the game a little and get back to me with your impressions. Hopefully you get smitten.

[linuxgurugamer]

I'll look, but renaming patches for the sake of renaming patches (ie: RSS) doesn't provide any benefit, and actually can be a problem for people upgrading. It's now possible for someone to end up with multiple patches all trying to do the same thing.

I'm not happy about changing the mechanism for the destination. It's not obvious, especially if someone does NOT have KER. And the loss of the Next button is problematic. You just made it much more difficult for someone to select a beacon if there are multiple beacons. Rather than just "Next"ing through all the beacons, you are forcing them to go into another mod, or into another screen. This is not an improvement

[arekbulski]

RSS patch was renamed to match other patches. Upgrading mods usually involves replacing entire directory (not merging files) so there is no problem.

I understand your reservations about changing targeting. There are advantages to using builtin targeting mechanism over implementing another one. Can I ask you to try it ingame (with Redux installed) and get your hands on impressions first? Solution wise: we can recommend installing Redux as a soft dependency mod, after all it is one of most popular KSP mods in ecosystem. Wont be difficult to post a short manual explaning this change. I can also implement a Next button. But I disrecommend it.

[linuxgurugamer]

Please list all of your improvements; I don’t have time to go exploring. Also, what do you need help on?

[arekbulski]

Player wise:

• mostly what is being displayed, what info, number formatting
• Added optimum altitude info.
• Flight mode restritions are OFF but can be easily enabled.
• Targetting mechanics, as you know
• Spin engine (first button) and then jump (second button)

[arekbulski]

In case you are interested, I would be willing to take over the project. I mean gaining write access to repo, not taking over spacedock/forum pages. Essentially co-maintaining it with you.

I took over a library called Construct. Inherited it with 20+ open tickets and now it maintains near-zero tickets and I redesigned entire library too. https://construct.readthedocs.io/en/latest/

[arekbulski]

Do you want me to record a few minute video showing the mod in game?

[linuxgurugamer]

Not interested in your taking this over at this time, but thanks for the offer. Wait on the video until I accept it,please I'll try to put in some time to playtest this over the weekend

[linuxgurugamer]

Ok, I tried to organize this, but it's a little scattered. Sections are numbered, but paragraph 5 is essentially a continuation of paragraph 2

I'm going to be pushing up some minor changes to the .gitignore (added some stuff), the VS solution and project files and my batch files. You will also see a "jenkins.txt" file, that is for my Jenkins server, which will do automatic builds when I finish the config.

First impression:

Overall Impression is mostly positive

1. Please put back the "Next" button. My very first test was very awkward, since I had to then find the beacon (and KER was installed) and that was painful. Too many extra clicks, as opposed to clicking the "Next" button once or twice. Alternative would be to see my proposed enhancement to the old FTL Analysis window below

Many people aren't familiar with the Rendezvous window of KER

2. Please put back the analysis window. I know some people keep it up while timewarping and maneuvering, and yes, the right-click can do that in flight view, but it goes away in the map view, which is where it is needed

3. Also, while it is nice, the Optimum Altitude takes some of the uncertainty out of the mod, which was part of it's attraction. That is something I can take care of in a Settings page, I do see people wanting it both ways.

4. Regarding the Spin/Abort and ExecuteJump buttons: I'm on the fence, it is changing the way it works, but it might be ok. I need to talk to some people about it

5. Reported information and Analysis window (cont from #2): What you are reporting is also different than the old window. Specifically, the Total EC required is mislabeled. Given the way that KSP deals with EC, Total EC = total over the entire time. What you are reporting is "EC required", not a total. ie: my test is showing:

Total required EC: 234.0/s over 10.0s

What it should say is:

Total required EC: 2340 EC required: 234.0/s over 10.0s

Also, an enhancement to the old FTL Analysis window which I never got around to doing, would be to show the data for ALL beacons, not just the currently selected beacon. With this, the player would have an easy way to see which beacon he can/should jump to. It would be even better if the player could select the targeted beacon in this window.

If you don't want to add this, then I will.

For some reason, I am getting a non-zero success probability when on the launch pad.

6. Also, please add the following mechanic:

   a. Ability to disable a drive, to be used when multiple drives are on a vessel, also used to prevent any accidental enablements, also, see the next line b. I don't mind this, but it conflicts with an earlier statement from you, or maybe I'm misremembering: I put multiple drives on a vessel, but only one was needed for this test jump. However, both powered up to full power, and both continued draining EC. Having the ability to disable a drive would solve this problem.

[linuxgurugamer]

Oh, please update the Changelog.txt file with your changes

[arekbulski]

I will add GUI displaying all beacons, record a video and get back to you.

[linuxgurugamer]

Thank you