[1.12.x] Near Future Technologies (September 6)

[MaverickSawyer]

16 minutes ago, Tyko said:

You might want to try two very simple craft - just docking ports and bare minimum necessary to navigate and dock - see if those work okay. Then you'll at least know it's not your modded install that's causing the problems

You can use F12 to rendezvous them so you don't even need to build a launcher

I'll give it a whirl. Reporting back shortly...

 

EDIT: Yep, still happens. Same amount of tilt and in the same direction:

Hmm... One thing in common to each of these scenarios is the fact that I had the docking port first stacked with a matching docking port in the VAB, then decoupled on orbit, then redocked... but that's never given me this kind of behavior before when used with other docking ports.

Edited October 31, 2018 by MaverickSawyer

[Kablob]

Trying out the Near Future Spacecraft testing branch: loving the new pods, making great use out of the 4-seat Federation-lookalike. Not sure if a known issue or not, but I haven't been able to get any of the pods with integrated landing engines to actually work: the engines just thrust into the pod and overheat it until it explodes without providing any acceleration.

Edited November 1, 2018 by Kablob

[MaverickSawyer]

18 hours ago, MaverickSawyer said:

I'll give it a whirl. Reporting back shortly...

 

EDIT: Yep, still happens. Same amount of tilt and in the same direction:

Hmm... One thing in common to each of these scenarios is the fact that I had the docking port first stacked with a matching docking port in the VAB, then decoupled on orbit, then redocked... but that's never given me this kind of behavior before when used with other docking ports.

Ok, further experiments have not turned up this issue with other docking ports, so it's something about that one in particular...

[Tyko]

1 hour ago, MaverickSawyer said:

Ok, further experiments have not turned up this issue with other docking ports, so it's something about that one in particular...

Hmm...just note that you're attaching parts really close to the docking plane. I think those are fuel cells..they're really close. I realize they may be just surface attached, but if the colliders for those parts are wonky at all they could impinge on the contact surface of the port

I strongly suggest trying this without attaching any parts that overlap the port. Use a longer fuel tank or put a structural part in between the two parts to avoid any collider clipping at all. Again, this is just a test, but as long as you have parts that close to the docking port you're not able to tell for sure that it's the port that's the problem.

If I were doing it I'd use all stock parts besides the docking ports. While Stock parts aren't perfect, they are at least a standard that someone else could use to reproduce your test

I just PM'd you. Let's take this discussion off-forum so we don't clog it up any more. When we have an answer we can post here for others who are following.

 

Edited November 1, 2018 by Tyko

[Gibster]

On ‎10‎/‎31‎/‎2018 at 2:44 AM, Streetwind said:

When designing a typical rocket, you pay attention to your mass ratio (wet mass to dry mass) and your thrust-weight ratio. With electric engines, there's a third thing you should consider: specific power. In other words, how many Ec/s you can generate for a given investment in dry mass.

This is important because electric engines give you this tradeoff in that they allow exceptional dV at the cost of having very bad TWR. But what if, in order to run them, you have to pack on a huge amount of dry mass just to produce power? Then you lose some of the dV advantage, while your TWR falls even lower. You want to avoid this. Therefore, you should examine your mission profile and decide on what kind of power solution you want to go with. On small expendable probes this is usually not such a big factor, but it definitely becomes one on larger ships that you want to be able to return home.

Here's a very rough rule of thumb guideline; the exact numbers and details may vary ingame (especially if you have other mods installed):

Solution	Specific Power	Advantages	Disadvantages
Thermoelectric	10 to 20 Ec/s/ton	Simply just works everywhere, no ifs or buts	Worst performance Somewhat pricey and late in tech tree Might decay over time (with optional patch)
Fuel Cell Array	up to 75 Ec/s/ton	Works everywhere Affordable	Fuel is limited and very heavy (reduces specific power) Array is too large for small probes Small single fuel cell performs massively worse than large array
Solar	65 to 120 Ec/s/ton	No fuel usage Specific power increases closer to the sun	Spacecraft must be able to align panels to sun during burns Specific power decreases away from the sun Might require a lot of area for high-end engines
Nuclear	100 to 250 Ec/s/ton	Compact and powerful Works everywhere Extremely low fuel use	Extremely expensive and late in tech tree Needs dedicated radiators Fuel is limited and very expensive Might break if mishandled
Trickle charged capacitor buffer	many hundreds of Ec/s/ton	Best performance Relatively cheap and accessible 	Manual discharge control required during burns Burn duration limited by size of buffer Wait time between burns Needs a different power source to go with it

Generally, the more you rely on storage - especially if that storage is capacitors - the higher your specific power becomes, but the lower your maximum full power burn time becomes. Since electric engines need long burn times, this needs to be carefully considered during spacecraft design.

However, if your storage solution becomes so large that it equals a large power production solution in mass, you might as well just go straight for that instead.

 

Thanks for the info! I've noticed balancing power needs is really difficult. I am trying to make a probe with 20,000 m/s of dv as a sort of proof of concept for a reusable multiplanetary ship and I can't really get anything over a TWR of .10 while using nuclear reactors with the goal of sustainable thrust. I've noticed that the lower my TWR is the less efficient I am with my burns. I'm still figuring out how to do interplanetary transfers properly with these engines. Usually I go out to a parking orbit by the Mun (which doesn't have too long of an orbital period) or closer. I would go out further to around Minmus (further reducing the dv requirements needed to escape_, but it makes your craft's orbital period too long, such that I once missed a transfer window because my craft wasn't in the right place and by the time it got to the right place, it had missed its window. I probably need to learn how to split up burns properly, I just haven't found any good tutorials on how.

I am probably expecting too much of the performance of the engines and should probably be aiming for lower DV requirements (20,000 is bit much but I still hope for it). When I've designed my craft, I usually go all in on either power capacity or production and if I had to guess the solution is probably in between (using consistent power production to reduced the stored power needs). We'll see, I clearly still have much learn on the proper use of these engines but I am having fun doing so!

Edited November 1, 2018 by Gibster
Corrected TWR to .10

[Tyko]

30 minutes ago, Gibster said:

Thanks for the info! I've noticed balancing power needs is really difficult. I am trying to make a probe with 20,000 m/s of dv as a sort of proof of concept for a reusable multiplanetary ship and I can't really get anything over a TWR of 10 while using nuclear reactors with the goal of sustainable thrust. I've noticed that the lower my TWR is the less efficient I am with my burns. I'm still figuring out how to do interplanetary transfers properly with these engines. Usually I go out to a parking orbit by the Mun (which doesn't have too long of an orbital period) or closer. I would go out further to around Minmus (further reducing the dv requirements needed to escape_, but it makes your craft's orbital period too long, such that I once missed a transfer window because my craft wasn't in the right place and by the time it got to the right place, it had missed its window. I probably need to learn how to split up burns properly, I just haven't found any good tutorials on how.

Is "TWR of 10" a typo? High efficiency spacecraft are usually below 1.0 TWR - sometimes a lot below. 

As far as doing your transfer burn, you're usually better doing it from a low Kerbin orbit - any DV you save by burning from out by the Mun is lost because you have to first increase your orbit up to the Mun in the first place which costs DV. If you set up your burn from 100Km over Kerbin your orbit is fast enough that you will be able to fine tune your departure to the hour. 

You're absolutely right about long burns being less accurate and therefore less efficient. The reason for this is that DV is for a burn is calculated as if you were doing all your acceleration instantly at one point. Since your actual burn takes time the accuracy falls off. That would be one benefit of departing from a higher orbit - the larger the orbit's circumference the better you are for accuracy over long burns. For LKO burns I typically limit myself to 5-6 minutes or less for a single burn. Anything longer than that and I look for another alternative.

 

Edited November 1, 2018 by Tyko

[Norcalplanner]

A good rule of thumb is to not burn longer than 1/6 of the orbital period. And if you're in a high orbit, a retro burn to lower the Pe first is frequently a good idea, assuming the timing and phase angle are correct.

[Kablob]

4 hours ago, Kablob said:

Trying out the Near Future Spacecraft testing branch: loving the new pods, making great use out of the 4-seat Federation-lookalike. Not sure if a known issue or not, but I haven't been able to get any of the pods with integrated landing engines to actually work: the engines just thrust into the pod and overheat it until it explodes without providing any acceleration.

Update: It's actually just with the Almathea+Hummingbirds, the Tethys works fine.

[sturmhauke]

The last few times I've done low TWR burns, I started by going to a highly elliptical orbit fitting these criteria:

• the periapsis was as low as possible without crashing/entering atmo
• the apoapsis was a high as possible without leaving the origin SOI
• my ship wouldn't accidentally get ejected out of the origin SOI (by the Mun, for instance)
• the argument of periapsis (its direction, more or less) was such that my ejection burn from periapsis would be at the correct angle for the transfer
• the orbital period was adjusted so that I would reach periapsis at the correct time for the transfer

Setting up this orbit might take several passes, so it's best to start well in advance of the transfer window. An elliptical orbit around Kerbin can have a maximum period of several weeks, for instance (although that's out past Minmus, so there's a danger of getting bumped).

[Tyko]

49 minutes ago, sturmhauke said:

The last few times I've done low TWR burns, I started by going to a highly elliptical orbit fitting these criteria:

• the periapsis was as low as possible without crashing/entering atmo
• the apoapsis was a high as possible without leaving the origin SOI
• my ship wouldn't accidentally get ejected out of the origin SOI (by the Mun, for instance)
• the argument of periapsis (its direction, more or less) was such that my ejection burn from periapsis would be at the correct angle for the transfer
• the orbital period was adjusted so that I would reach periapsis at the correct time for the transfer

Setting up this orbit might take several passes, so it's best to start well in advance of the transfer window. An elliptical orbit around Kerbin can have a maximum period of several weeks, for instance (although that's out past Minmus, so there's a danger of getting bumped).

Great technique (and we are way off topic, but this is interesting)

I wonder how much DV savings this really offers when you factor in having to set up the elliptical orbit vs just burning from LKO. I bet it's a bit better, but is it enough to justify the work? Real life interplanetary missions don't use this method and they're usually very stingy with DV (new horizons not withstanding  )

[sturmhauke]

6 minutes ago, Tyko said:

Great technique (and we are way off topic, but this is interesting)

I wonder how much DV savings this really offers when you factor in having to set up the elliptical orbit vs just burning from LKO. I bet it's a bit better, but is it enough to justify the work? Real life interplanetary missions don't use this method and they're usually very stingy with DV (new horizons not withstanding  )

It's less about dV savings and more about burn accuracy. KSP's interface, even with mods, has trouble with calculating long burns with enough accuracy if you're going much further than Duna. A single, super high accuracy burn would probably cost less dV, but that's really difficult to do when your burn time is more than a few minutes.

[Norcalplanner]

@Tyko I agree we're getting off topic. There are some threads which explored this topic extensively with complicated math a few years ago. I'll see if I can find them back when I'm at a real computer.

Back on topic, it looks like I need to download some NF dev builds and check them out when I get home tonight. 

[MaverickSawyer]

9 hours ago, MaverickSawyer said:

Ok, further experiments have not turned up this issue with other docking ports, so it's something about that one in particular...

So, further testing earlier today turned up the following...

When using the 5m ports that come with the Construction pack, they work flawlessly:

Switch to the ports from the Launch Vehicles pack, and, well...

Soooo... yeah. Those ports are legit bugged.

[KSPrynk]

On 10/30/2018 at 4:31 PM, Nertea said:

I welcome testing of the development version, chances are this will need some tuning to get the profiles right for re-entry.

I've done some initial tests on the biconic command pod in the Dev file.  I wasn't sure if there was a separate NFT dev thread, so results below....

Spoiler

The biconic shape seems like an interesting hybrid of blunt capsule and lifting body spaceplane.  As I suspected, the high (or far-forward, depending on viewing orientation) center of mass on the dev model makes it a lawn dart, which will burn through all monoprop and electricity trying to force it more than a few degrees above 0 AoA in the hardest part of the re-entry (~25-35 km).  I tried adding ballast to push CoM back, but by the time it was ~25% up from the base, the total mass was near 20t.

I took another crack at it by adding a line to the cfg file, CoMOffset = 0.0, -1.5, 0.0, after the part mass.  That produced better results, but I think the placement of the aft-side RCS thruster blocks in front of the new CoM threw off the SAS and MJ steering (which was previously pretty stable), as it was constantly bouncing and wouldn't settle.  Things got very unstable when I hit atmo, trying to maintain about a 45 deg AoA (which is about when I'd start seeing a light blue line of lift vector).  Control authority was better, but I think I created an unholy  balance between CoM, CoL, and CoP (I hadn't created new values for these last two; my understanding is the last two default to the first if not specified otherwise) and things got tumbley really fast.  I guess there needs to be a little bit of difference for all three, but I was hoping the pair of Elevon 4s that I had added at the base (as body flaps) would create some asymmetry to give me a slightly tail-heavy bias.

BTW, attaching elevons with mirror symmetry directly to the aeroshell wouldn't always result in them staying in the same place or orientation after the vessel loads.  I ended up having to attach to the crew compartment, then offsetting them out to the edge of the shell.  I saw a similar issue at least once after attaching some big batteries in mirror symmetry on the crew compartment (beneath the cargo bay doors), but I didn't spend any time picking at that.

I may take another crack at CoM/CoL/CoP this weekend, perhaps with the Kerbal Wind Tunnel mod (which I haven't tried), but I think it deserves the attention of someone who better understands the nuances of KSP aerodynamics.

 

Edited November 2, 2018 by KSPrynk

[MaverickSawyer]

On 10/30/2018 at 1:31 PM, Nertea said:

I welcome testing of the development version, chances are this will need some tuning to get the profiles right for re-entry.

On that note... the new version of the Mk. 3-9 pod has some sort of mesh artifact in the upper right RCS cluster. There's some semi-conical things stuck in the nozzles. Still functions just fine, but... might want to look into that.

[Nertea]

@MaverickSawyer, @KSPrynk, @Kablob, (or anyone else really) if you want to test or talk about the NFS dev version, PM me directly. There are a large number of bugs and problems with the current state and they are not really ready for precise testing yet. 

 

4 hours ago, MaverickSawyer said:

Soooo... yeah. Those ports are legit bugged.

Nothing wrong with the config or model that I can see. I'll continue to investigate but *shrug* I can't repro it!.

 

 

[MaverickSawyer]

19 minutes ago, Nertea said:

Nothing wrong with the config or model that I can see. I'll continue to investigate but *shrug* I can't repro it!.

Are there any plugins or mods that, in the past, have conflicted with docking ports? If there are, I'll check to see if I have any installed and see if that's the cause. Otherwise, it's repeatable on my end, and ONLY with that particular port.  I know @Tyko was possibly going to look into it as well...

 

Also, consider this to be an all-hands call: Can anyone else reproduce the crooked docking port from the Launch Vehicles pack?

[Streetwind]

2 hours ago, MaverickSawyer said:

Are there any plugins or mods that, in the past, have conflicted with docking ports? If there are, I'll check to see if I have any installed and see if that's the cause. Otherwise, it's repeatable on my end, and ONLY with that particular port.  I know @Tyko was possibly going to look into it as well...

I highly recommend that when hunting for bugs, you should do so with the help of a dedicated instance that only includes the mod that you are investigating and its dependencies. First, you devise a way to reproduce the issue reliably in your gameplay instance where you first noticed it; then, you follow those exact reproduction steps in your minimal testing instance. If you can reproduce it there in the same way, great! Submit a bug report. If you cannot - well, there's a cross-mod conflict somewhere. Your next step would be backing up your gameplay instance and then pulling out mods (usually via the "take half, leave half" method) until you find the group of culprits.

 

14 hours ago, Gibster said:

I probably need to learn how to split up burns properly, I just haven't found any good tutorials on how.

What you are looking for is the so-called Mangalyaan Maneuver. In a nutshell, this maneuver is a special variant of periapsis kicking, where you start in a low parking orbit and, through repeated short burns at every periapsis pass, lift your apoapsis higher and higher over time, until you reach escape velocity. The special part comes in when, based on where your apoapsis has to be during the transfer window, you calculate where your apoapsis must be weeks or months prior to departure. That way you can periapsis kick over long periods of time with spacecraft that need many, many passes due to their very low TWR, but still end up hitting your ejection angle exactly on the final escape burn. There used to be a great guide here, which really made it easy to grasp and pull of ingame with KSP's limited toolset. Unfortunately, the helpful pictures are broken, and the author hasn't been on the forums for over half a year. Still, the text makes it reasonably clear (at least to me) what you have to do. Give it a try with a probe - after you pull it off once, you'll never struggle with it again.

(I recommend setting yourself a dV budget for every periapsis pass, such as 100 m/s per burn. How much you choose depends on your TWR - it should be possible to complete in no more 4-5 a few minutes at most.)

 

Edited November 2, 2018 by Streetwind

[Tyko]

8 hours ago, Streetwind said:

10 hours ago, MaverickSawyer said:

Are there any plugins or mods that, in the past, have conflicted with docking ports? If there are, I'll check to see if I have any installed and see if that's the cause. Otherwise, it's repeatable on my end, and ONLY with that particular port.  I know @Tyko was possibly going to look into it as well...

I highly recommend that when hunting for bugs, you should do so with the help of a dedicated instance that only includes the mod that you are investigating and its dependencies. First, you devise a way to reproduce the issue reliably in your gameplay instance where you first noticed it; then, you follow those exact reproduction steps in your minimal testing instance. If you can reproduce it there in the same way, great! Submit a bug report. If you cannot - well, there's a cross-mod conflict somewhere. Your next step would be backing up your gameplay instance and then pulling out mods (usually via the "take half, leave half" method) until you find the group of culprits.

@Nertea - I'll confirm @MaverickSawyer's bug report on this. I tested on a bare bones 1.4.5 install with only NFLV, NFConstruction and dependencies - plus KER & DPAI, but those shouldn't affect the test. The ports don't dock cleanly and sit at a strange angle. There's no clipping or anything else odd about this craft.

Edited November 2, 2018 by Tyko

[AmpCat]

I can't remember if this is the right forum for this, but as of around 1.5 or so, I started getting this message:

I think this is referring to the big square trusses in NFConstruction. Is this something known, or do I need to dig in and try clean installs and log files? I did do one clean install, and put in all my billions of mods, and it was still there. I've not yet tried to install just @Nertea's mods and see what happens.

[Nertea]

1 hour ago, AmpCat said:

I can't remember if this is the right forum for this, but as of around 1.5 or so, I started getting this message:

I think this is referring to the big square trusses in NFConstruction. Is this something known, or do I need to dig in and try clean installs and log files? I did do one clean install, and put in all my billions of mods, and it was still there. I've not yet tried to install just @Nertea's mods and see what happens.

 

It's been reported, sorry I haven't shipped the fix yet. I was hoping to bundle the new NFSpacecraft release in with it but that has taken longer than anticipated (IVA hell)

12 hours ago, MaverickSawyer said:

Are there any plugins or mods that, in the past, have conflicted with docking ports? If there are, I'll check to see if I have any installed and see if that's the cause. Otherwise, it's repeatable on my end, and ONLY with that particular port.  I know @Tyko was possibly going to look into it as well...

 

Also, consider this to be an all-hands call: Can anyone else reproduce the crooked docking port from the Launch Vehicles pack?

I found an inconsistency in the model and have pushed a fix to dev branch. Can you see whether this resolves it?

[AmpCat]

No worries, doesn't seem to be breaking anything with me yet.

One of these days I'll bug you about why IVA is so hard. It seems to constantly be a thorn in your side. I'm just not familiar with what's involved, and it has me curious.

[MaverickSawyer]

17 minutes ago, Nertea said:

 

It's been reported, sorry I haven't shipped the fix yet. I was hoping to bundle the new NFSpacecraft release in with it but that has taken longer than anticipated (IVA hell)

I found an inconsistency in the model and have pushed a fix to dev branch. Can you see whether this resolves it?

Will do. May be a few hours before I can report back, but I'll let you know what I find.

[Nertea]

9 minutes ago, AmpCat said:

No worries, doesn't seem to be breaking anything with me yet.

One of these days I'll bug you about why IVA is so hard. It seems to constantly be a thorn in your side. I'm just not familiar with what's involved, and it has me curious.

It's not hard, it's just time consuming. Consider the visual distance you are in an IVA from the panel, it's much, much closer than an external. That means that the internal needs to be about an order of magnitude more detailed than the external. Typically I draw parts at 250-350 px/m these days, which is a good compromise - an IVA needs to be drawn at ~1000 px/m to look decently sharp. That's about 4x the linear texture density of the outside, so at LEAST 4x the time to draw textures. In addition, additional mesh detail requires additional UVing and that is passed on to texture time. 

This all combines to make it take forever (1.25m IVA will take upwards of 12 straight hours of work, 3.75m IVA could take 36), with results that are really not used that much by the average player (from my observations, most people take a quick look and then stop). However, there are some small portions of the playerbase who will scream and throw a tantrum if things are not exactly to their liking in the IVA space. This further discourages me from making them,  because if I do I want them to be appreciated. I tried an experiment with the PPD-1 and Mk4-1 IVAs where I spent less effort and really just laid out props for them. It didn't go well with the latter group. 

[AmpCat]

Gotcha. I can understand that (I do some UI design work for my real job). Gotta spend more time on things that're viewed up close, and then you have to balance the customer's bang for the buck. Do you spend 36 hours on an IVA for a pod, or spend that same 36 hours on a whole new pod? Which makes more people happy?