[1.12.x] FTL Drive Continued

[krh42]

3 hours ago, linuxgurugamer said:

Absolutely.  It's been stable for a while, there were a number of improvements and refactoring which was done a while ago

Thank you. I see you are four that have worked together on the mod. How have you organized that, have you added them as collaborators to the repository?

If that is how you have done it, then my github username is krhe.

I also have to admit I am new to git. I've just resently decided to move to github from an internal svn server (yes - I know - I am a Dinosaur  The FTLDrive was on github originally to test git, but I never got around to move to git at that time, because I was to busy with work, and SVN was working. Now on the other hand, I am amazed about how much better git is over svn.

Edited September 18, 2019 by krh42
Supply more information on skill level in git.

[linuxgurugamer]

19 minutes ago, krh42 said:

Thank you. I see you are four that have worked together on the mod. How have you organized that, have you added them as collaborators to the repository?

If that is how you have done it, then my github username is krhe.

I also have to admit I am new to git. I've just resently decided to move to github from an internal svn server (yes - I know - I am a Dinosaur  The FTLDrive was on github originally to test git, but I never got around to move to git at that time, because I was to busy with work, and SVN was working. Now on the other hand, I am amazed about how much better git is over svn.

No, I don't prefer to work that way.

Generally, I prefer to have someone clone the repo, and then push their changes in a PR.  This gives me a chance to review the code before merging, or, if I am not comfortable, I can merge it into a branch and test it.  Generally, this has worked well for me, and I think that I've only had one or two merges in the past several years which I had to revert because of issues

I do this when working on other repos as well.  Keeps things cleaner

Edited September 18, 2019 by linuxgurugamer

[krh42]

8 minutes ago, linuxgurugamer said:

No, I don't prefer to work that way.

Generally, I prefer to have someone clone the repo, and then push their changes in a PR.  This gives me a chance to review the code before merging, or, if I am not comfortable, I can merge it into a branch and test it.  Generally, this has worked well for me, and I think that I've only had one or two merges in the past several years which I had to revert because of issues

I do this when working on other repos as well.  Keeps things cleaner

As, I said, I am just learning to use the full capabilities of Git. Previously, I have worked on big teams with SVN but so far I have only used Git on projects on which I have been working alone, so I guess I haven't really been using Git yet. Also on all the projects I have worked so far it has been with people I know personally and can meet with in real life (research projects at the university / I'm at Aalborg University), so there we have always just worked on the same repository, and if you messed up you bought some cake and apologized.

I guess the clone + PR is a pretty standard way to collaborate on open source projects with Git, so I'm very ok with learning it. For now I think I will just clone the project and see if there is any thing I can perhaps contribute with. One thing I originally was considering was that there should be an antenna link between the beacon and the FTL drive in order to be able to jump.

[AmpCat]

Thanks for picking this one up, @linuxgurugamer. Out of all the FTL/warp drive mods, this was my favorite sort. Still keeps a good challenge in ships, but removes the tedium in late game of all the time warps and long flights, and dealing with really high part count ships to make that trip and the huge performance hit those bring.

[linuxgurugamer]

New release, 0.2.3

• Added InstallChecker
• Updated for KSP 1.8

[linuxgurugamer]

New release, 0.2.3.1

• Fixed vars initialization

[Jimbodiah]

Just a quick but super big THANK YOU for keeping all these mods alive.

Guru, you are AWESOME!

[DeadJohn]

@linuxgurugamer, This is just an FYI (that maybe you already know) rather than a bug report or fix request. Some of the FTL calculations can give unusual results with planet packs. I emphasize that this is not crashing or causing any real problems. It might open the door to "cheats" such as being able to FTL an unlimited mass, but we can already do worse with alt-f12.

My first playthrough with FTL Continued was the stock KSP system plus Outer Planets Mod. I think I developed a good feel to know when I'd be too deep in a gravity well to bother shipping an FTL beacon there.

For my 2nd playthrough with FTL Continued, I'm using it with JNSQ + GEP_JNSQ (rescales Grannus Expansion Pack and places it beyond the edge of the already large JNSQ system). Most of those 2.7x worlds seem to have a similar balance as 1x scale regarding gravity wells and jumping while too close to a planet. Some tiny moons, though, seem exceptionally easy for FTL:

• GEP_JNSQ's RAB-58E moonlet has its minimum safe jump distance displayed as a negative number, and there's effectively no gravity well. A ship with an FTL drive can jump as soon as it's 1m above the surface. RAB-58E is in a reverse orbit but I doubt that affects your FTL gravity well calculations.
• I encountered something similar with an earlier small moonlet but I forget that body's name and don't even remember whether it was from JNSQ or GEP. Oops.

P.S. I love this mod. It makes huge systems fully explorable without needing repetitive 100 year timewarps.

[linuxgurugamer]

6 hours ago, DeadJohn said:

@linuxgurugamer, This is just an FYI (that maybe you already know) rather than a bug report or fix request. Some of the FTL calculations can give unusual results with planet packs. I emphasize that this is not crashing or causing any real problems. It might open the door to "cheats" such as being able to FTL an unlimited mass, but we can already do worse with alt-f12.

My first playthrough with FTL Continued was the stock KSP system plus Outer Planets Mod. I think I developed a good feel to know when I'd be too deep in a gravity well to bother shipping an FTL beacon there.

For my 2nd playthrough with FTL Continued, I'm using it with JNSQ + GEP_JNSQ (rescales Grannus Expansion Pack and places it beyond the edge of the already large JNSQ system). Most of those 2.7x worlds seem to have a similar balance as 1x scale regarding gravity wells and jumping while too close to a planet. Some tiny moons, though, seem exceptionally easy for FTL:

• GEP_JNSQ's RAB-58E moonlet has its minimum safe jump distance displayed as a negative number, and there's effectively no gravity well. A ship with an FTL drive can jump as soon as it's 1m above the surface. RAB-58E is in a reverse orbit but I doubt that affects your FTL gravity well calculations.
• I encountered something similar with an earlier small moonlet but I forget that body's name and don't even remember whether it was from JNSQ or GEP. Oops.

P.S. I love this mod. It makes huge systems fully explorable without needing repetitive 100 year timewarps.

Thank you, I do consider this to be a bug report.

Any images showing the issue would be useful

[linuxgurugamer]

10 hours ago, DeadJohn said:

@linuxgurugamer, This is just an FYI (that maybe you already know) rather than a bug report or fix request. Some of the FTL calculations can give unusual results with planet packs. I emphasize that this is not crashing or causing any real problems. It might open the door to "cheats" such as being able to FTL an unlimited mass, but we can already do worse with alt-f12.

My first playthrough with FTL Continued was the stock KSP system plus Outer Planets Mod. I think I developed a good feel to know when I'd be too deep in a gravity well to bother shipping an FTL beacon there.

For my 2nd playthrough with FTL Continued, I'm using it with JNSQ + GEP_JNSQ (rescales Grannus Expansion Pack and places it beyond the edge of the already large JNSQ system). Most of those 2.7x worlds seem to have a similar balance as 1x scale regarding gravity wells and jumping while too close to a planet. Some tiny moons, though, seem exceptionally easy for FTL:

• GEP_JNSQ's RAB-58E moonlet has its minimum safe jump distance displayed as a negative number, and there's effectively no gravity well. A ship with an FTL drive can jump as soon as it's 1m above the surface. RAB-58E is in a reverse orbit but I doubt that affects your FTL gravity well calculations.
• I encountered something similar with an earlier small moonlet but I forget that body's name and don't even remember whether it was from JNSQ or GEP. Oops.

P.S. I love this mod. It makes huge systems fully explorable without needing repetitive 100 year timewarps.

Given that it's only 25km in diameter, it sounds correct.  From what I see, the minimum test altitude when looking at the possible destinations shows as 0.0 km.

Where do you see the "minimum safe jump distance"?  Do you have a beacon there?  If so, where is it?

A save file would be helpful

Edited April 17, 2020 by linuxgurugamer

[DeadJohn]

2 minutes ago, linuxgurugamer said:

Given that it's only 25km in diameter, it sounds correct.  From what I see, the minimum test altitude when looking at the possible destinations shows as 0.0 km.

Where do you see the "minimum safe jump distance"?  Do you have a beacon there?  If so, where is it?

A save file would be helpful

I should have said "Optimum Altitude" instead of minimum safe jump distance. A small FTL-equipped probe hovering above RAB-58E displays a negative Optimum Altitude when jumping to other beacons. You can see it in the image linked below, for both the FTL drive part window and the FTL Possible Destinations.

I started a new sandbox save for you. There's just a single vessel design in flight with stock parts, FTL drive, and FTL beacon. 3 destination beacons are orbiting Kerbin and 1 at Grannus SOI. There's 1 more vessel named "Test jumper" landed at RAB-58E; as soon as it lifts off the surface it gets 100% success probability to the other beacons.

I've only noticed this with small vessels and tiny mod moons. A larger 2.5m vessel cheated to RAB-58E had to be several km above the surface before getting 100% FTL success.

Screenshot https://drive.google.com/file/d/12fUSylQmbbXjR1gXUp72d1wQ4BQemhJy/view?usp=sharing

Savefile https://drive.google.com/open?id=1NiJgwEENQ0wQgEyR2njpy_j0ofqgVQCz

P.S. I just thought to check FTL Possible Destinations in the VAB. I'm only seeing 7% maximum Success Probability there, even when I move the test altitude slider to maximum (1809 km) for RAB-58E. All of the beacons are showing an Optimum Altitude above 11,000 km (which seems too high for such a small moon) instead of negative numbers.

 

[Jansn67]

After years of using FTL:

1. Beacon is to near to next massive body gravity.
2. Vessel is too heavy/have to less jump drives on board
(sometime with multiple drives it seems a bit cheating)
3. If jump drives on board, you are too close to gravity mass.
(is best to burn into kerbol orbit, wait some days, then jump
to a provinient beacon.)

and 4. never try to jump ship over 100+ and more tons.

PS: i use a heavy jump-transporter i can dock with (8 big drives),
for a pair of small vessels, or one big vessel.
It still fail sometimes (quicksave before!)

I like the drive-stacking-feature.
(Thanks LGG)

Edited April 17, 2020 by Jansn67

[bice]

Hi!

How I can access the settings window?? I can't find it.

 

[linuxgurugamer]

19 hours ago, bice said:

Hi!

How I can access the settings window?? I can't find it.

 

I think it's the stock settings window.  Hit escape, then click the settings, then click the Difficulty Options

[Goaty1208]

Hi, does this work on 1.10.1?

[JadeOfMaar]

14 hours ago, Goaty1208 said:

Hi, does this work on 1.10.1?

Try it and find out. It's a pretty lightweight mod so I expect it not to break easily.

[Goaty1208]

16 hours ago, JadeOfMaar said:

Try it and find out. It's a pretty lightweight mod so I expect it not to break easily.

Not only it worked, but I warped a 120 ton craft! Great mod!

[Craze]

Can I use it with RSS ?

[JadeOfMaar]

10 hours ago, Craze said:

Can I use it with RSS ?

There's no real reason why the answer would be no. This mod is a very simple mod and it's meant for use to make extreme distances easily traversible. The only thing you really need to watch out for is if you'll need to meet proprtionally high resource demands for a jump over the distances in RSS.

[Craze]

On 1/5/2021 at 7:46 AM, JadeOfMaar said:

There's no real reason why the answer would be no. This mod is a very simple mod and it's meant for use to make extreme distances easily traversible. The only thing you really need to watch out for is if you'll need to meet proprtionally high resource demands for a jump over the distances in RSS.

Well of course I worried about it.

[LemonZest]

Hey is anyone having trouble getting the mod to work with 1.12? the parts show up in game but have no functionality

[linuxgurugamer]

7 hours ago, LemonZest said:

Hey is anyone having trouble getting the mod to work with 1.12? the parts show up in game but have no functionality

How did you install it?

Did you install the dependencies?

If you are still having a problem, provide a log file as described in my signature

[linuxgurugamer]

New release, 0.2.3.2

• Added AssemblyFileVersion
• Updated version file for 1.12
   

[g_BonE]

Came back to this mod after my last trials in 2016 - long time ago. Have to say its really great now, the bugs seem to have been ironed out and its just nice to get around the solar system using FTL beacons and drives. Thanks for keeping this alive @linuxgurugamer! 

[Gordon Dry]

I wanted to create a more generic patch which can easily be edited to add more (non stock scaled) planet packs.
Doing so I recognized that the shipped patch GameData\FTLDriveContinued\Parts\RSS_patch.cfg contains a wrong/outdated value name:

maxGeneratorForce

Neither in the  deprecated parts nor in the actual parts is a value like that, but generatedForce, chargeRate and chargeTime.

So my attempt of creating a patch is even more like a fix:

I replaced GameData\FTLDriveContinued\Parts\RSS_patch.cfg with GameData\FTLDriveContinued\Parts\Planets_Scale_patch.cfg

@PART[advancedFTLdrive*]
{
	scalefactor = 1
	@scalefactor:NEEDS[SigDim] = #$@SigmaDimensions/Rescale$
	@scalefactor:NEEDS[!SigDim,RealSolarSystem&!SSRSS] = 10.10625
	@scalefactor:NEEDS[!SigDim,JNSQ] = 2.7
	@scalefactor:NEEDS[!SigDim,GPP_Rescale_10x] = 10
	@scalefactor:NEEDS[!SigDim,JNSQ_Rescale_10x] = 10
	scalesqrt = #$scalefactor$
	@scalesqrt != 0.5
}

@PART[advancedFTLdrive*]
{
	@MODULE[FTLDriveModule]
	{
		@generatedForce *= #$/scalesqrt$
		@generatedForce ^= :\.\d+::
		// not sure if chargeRate and chargeTime also need patching
		@chargeRate *= #$/scalesqrt$
		@chargeRate ^= :\.\d+::
		@chargeTime *= #$/scalesqrt$
		@chargeTime ^= :\.\d+::
}

@PART[advancedFTLdrive*]
{
	-scalefactor = delete
	-scalesqrt = delete
}

As you can see there are two commonly unkown NEEDS:
GPP_Rescale_10x and JNSQ_Rescale_10x

Those come from https://github.com/Galileo88/Galileos-Planet-Pack/pull/75 and https://github.com/Galileo88/JNSQ/pull/39

The reasons for those two PRs are obvious I would say.

 

Edit:
btw - does anybody have screenshots of the new parts? There are none on the OP and the video is from the time as the deprecated parts were the only ones.

Edited December 14, 2021 by Gordon Dry