KSP Interstellar Extended Continued Development Thread

[FreeThinker]

5 hours ago, SyzygyΣE said:

I'm not certain which file I should change though. I can seem to find where the transmitter is. Does the log say anything about its whereabouts?

Finding the file is not the problem, understanding what is sufficient is... It's in microwave/transmitter folder

Edited July 28, 2016 by FreeThinker

[Boris-Barboris]

Hi, fyi, you correctly decrease max fuel flow here, but isp should also be decreased, ModuleEngines.ispMult is probably just what you need. Looks like I was incorrect back then, thrust will drop with lorentz factor squared, it's fuel flow wich is simply divided by it, so

effective_thrust = timeDilation^2 * maxthrust * fusionRatio;
fuel_flow = effective_thrust / (engineIsp * timeDilation)  / GravityConstant;    // effective Isp will be base_isp * timeDilation
... // same here
curEngineT.ispMult = timeDilation; (field name may be incorrect, i don't remember well).

 

[FreeThinker]

40 minutes ago, Boris-Barboris said:

Hi, fyi, you correctly decrease max fuel flow here, but isp should also be decreased, ModuleEngines.ispMult is probably just what you need. Looks like I was incorrect back then, thrust will drop with lorentz factor squared, it's fuel flow wich is simply divided by it, so

effective_thrust = timeDilation^2 * maxthrust * fusionRatio;
fuel_flow = effective_thrust / (engineIsp * timeDilation)  / GravityConstant;    // effective Isp will be base_isp * timeDilation
... // same here
curEngineT.ispMult = timeDilation; (field name may be incorrect, i don't remember well).

 

But that would mean from the perspective of the ship, it becomes less efficient to accelerate, like as if the vessel is becoming heavier, but  from my understanding, the observers still thinks he is accelerating like  normal, it's just the external observer at rest mass will think the mass is increasing because it acceleration is slowing down due to time dilation.

But perhaps my understanding is flawed, do you have any trustworthy source that  proves Isp should become lower the closer to the speed of light?

Edited July 28, 2016 by FreeThinker

[Boris-Barboris]

1 hour ago, FreeThinker said:

it becomes less efficient to accelerate

and that is indeed what happens.

1 hour ago, FreeThinker said:

like as if the vessel is becoming heavier

not only that. Momentum exchange between rocket and propellant is also altered (observed exhaust velocity and rocket and propellant masses are changed).

While not diving into math, imagine a simple paradox:

you have rocket with delta-v for 1.5 c. You know it takes T seconds to burn through all fuel. If you just scale fuel flow (thrust), you'll just approach c assymptotically for eternity. But that is physically incorrect, there is a moment in time T' in observer's frame when burn stops, and it is long before the rocket reaches c.

I did the math myself, then checked with a couple of online sources, it may be correct for basic prograde\retrograde burns. For example, this one in it's second half gives a diff-equation, that (almost) matches what i've got, in particular that isp in rest-mass terms is divided by lorentz factor squared.

 

I'll check more and PM you if will find further errors. Lots of sources, many are quite diffirent in results, need to filter.

Edited July 29, 2016 by Boris-Barboris

[xRei]

Hey! I've been loving the mod after returning to KSP for 1.1.3. I do have a few notes though. In prior versions(the one just before this in fact) it seems like the various reactors had multiple nodes on the tech tree in which their upgrades appeared to let you know that reactor has improved. The Molten Salt Reactor in particular had quite a few, up to Mark 4 I think? Is it just me or are those missing in the new version? They still get upgraded as you unlock various nuclear-line techs though, same goes for the radiators too. Is this an oversight or intended? Fortunately you did list all the upgrades on the front page which I can reference.

Another thing was that the right-click fuel switch menu in the VAB doesn't reflect any change in Power/Core Temp when swapping between UF4 and Thorium fuels with the Molten Salt Reactor. When you get on the launch pad the reactor control window does show the correct info however, so it still works fine.

Last thing, I've been seeing weird anomalies with reactor output when Near Future Mods is installed. My Molten Salt Reactor shows 3GW! i had the whole suite of mods, but it didn't seem to be any specific one. I tried adding them one at a time and ones I tried all did it.

Great mod, thanks for your hard work.

Edited July 29, 2016 by xRei

[Kenken244]

I don't know if lowering isp would be the correct way to model time dilation though. the main reason you end up getting less DV is because the effective mass of your craft increases, without increasing your total impulse. so simply keeping fuel flow constant, but decreasing the acceleration provided would be the most realistic way. unless there is a problem resulting from the effective mass of the fuel increasing too? I admit I am not too knowledgeable about this. come to think of it, the increased mass of the propellant would result in less isp naturally. so I guess the isp should be reduced by that slightly, but also reduce the effective acceleration because of the increased effective mass.

Edited July 29, 2016 by Kenken244

[SyzygyΣE]

14 hours ago, FreeThinker said:

Finding the file is not the problem, understanding what is sufficient is... It's in microwave/transmitter folder

This is most strange. I had a look in the folder as you advised, under the path GameData > WarpPlugin > Parts > Microwave. However, no item had an undefined chargeRate. In fact, there is only one item that does have the parameter "chargeRate"—the MWTransmitterMk2. But that parameter is defined as having a chargeRate of 8. I really don't know what I'm doing wrong here. Am I looking in the wrong folder?

Edited July 29, 2016 by SyzygyΣE

[FreeThinker]

58 minutes ago, SyzygyΣE said:

This is most strange. I had a look in the folder as you advised, under the path GameData > WarpPlugin > Parts > Microwave. However, no item had an undefined chargeRate. In fact, there is only one item that does have the parameter "chargeRate"—the MWTransmitterMk2. But that parameter is defined as having a chargeRate of 8. I really don't know what I'm doing wrong here. Am I looking in the wrong folder?

The problem is that Realsim overhaul mod assumes every solarpartmodule contains a chargeRate  property, which is not the case in the Microwave definition file.

[SyzygyΣE]

5 minutes ago, FreeThinker said:

The problem is that Realsim overhaul mod assumes every solarpartmodule contains a chargeRate  property, which is not the case in the Microwave definition file.

If the microwave transmitter isn't meant to have a chargeRate, and RO simply assumes it has, I suppose it's not really going to affect gameplay in any way except for the error message? It's alright if that's the case. As long as it works in game, I don't mind how many error messages pop up.

But then again, I don't think RO is exactly compatible with Interstellar right now. I'm still testing to see whether the two can work together.

Edited July 29, 2016 by SyzygyΣE

[FreeThinker]

6 hours ago, Boris-Barboris said:

and that is indeed what happens.

not only that. Momentum exchange between rocket and propellant is also altered (observed exhaust velocity and rocket and propellant masses are changed).

While not diving into math, imagine a simple paradox:

you have rocket with delta-v for 1.5 c. You know it takes T seconds to burn through all fuel. If you just scale fuel flow (thrust), you'll just approach c assymptotically for eternity. But that is physically incorrect, there is a moment in time T' in observer's frame when burn stops, and it is long before the rocket reaches c.

Yes, this simple paradox coincide with my observation that vessels with 1.5c deltaV tend to kill themself with dialation, as they appoach the speed of light 0.999999999999  they never run out of fuel but do run out of significant numbers in the floating point number ......

I will take over your proposes changes

Edited July 29, 2016 by FreeThinker

[FreeThinker]

5 hours ago, xRei said:

Last thing, I've been seeing weird anomalies with reactor output when Near Future Mods is installed. My Molten Salt Reactor shows 3GW! i had the whole suite of mods, but it didn't seem to be any specific one. I tried adding them one at a time and ones I tried all did it.

Are yopu sure it was in Giga Watts and not Mega Wats, because that what I would expect when NFE is installed

9 hours ago, Boris-Barboris said:

Hi, fyi, you correctly decrease max fuel flow here, but isp should also be decreased, ModuleEngines.ispMult is probably just what you need. Looks like I was incorrect back then, thrust will drop with lorentz factor squared, it's fuel flow wich is simply divided by it, so

effective_thrust = timeDilation^2 * maxthrust * fusionRatio;
fuel_flow = effective_thrust / (engineIsp * timeDilation)  / GravityConstant;    // effective Isp will be base_isp * timeDilation
... // same here
curEngineT.ispMult = timeDilation; (field name may be incorrect, i don't remember well).

 

mmm, I wasn't aware there is property called ispMult that allowed direct Isp manipulation.

Edit: Alright, now we have a farely accure approximation of Relativty at real time.

But now the tricky part, the Persistant acceleration. As you know deltaTime can variate between 0.05s and 2000s (higher with better time warp). The problem at is that at higher delta, you can effectivly reach higher speed with a single deltatime frame of 2000s  then  with 2 frames 1000 seconds (as the second frame will lower your Isp and thrust). So we need to somehow compensate for this paradox difference. Any Ideas?

Edited July 29, 2016 by FreeThinker

[xRei]

1 minute ago, FreeThinker said:

Are yopu sure it was in Giga Watts and not mega wats, because that what I would expect

Right sorry, getting my terminologies mixed up I think(Or maybe I don't understand what im doing lol). In the VAB right-click menu its listed as:

Active Raw Power: ####MJ

This number goes up with upgrades and as far as I could tell it affects max possible thermal power/thrust potential. Here, I loaded up Near Future Electrical again to show you what it looks like. This time instead of 3 GW it turned to 2MJ:

 

Which is.. quite the downgrade. I switched to the launch pad and the reactor control window also shows reactor output as 2MJ.

When I removed Near Future Electrical it goes back to normal again, showing 1000MJ.

[FreeThinker]

20 minutes ago, xRei said:

Right sorry, getting my terminologies mixed up I think(Or maybe I don't understand what im doing lol). In the VAB right-click menu its listed as:

Active Raw Power: ####MJ

This number goes up with upgrades and as far as I could tell it affects max possible thermal power/thrust potential. Here, I loaded up Near Future Electrical again to show you what it looks like. This time instead of 3 GW it turned to 2MJ:

 

Which is.. quite the downgrade. I switched to the launch pad and the reactor control window also shows reactor output as 2MJ.

When I removed Near Future Electrical it goes back to normal again, showing 1000MJ.

Actualy it's not a downdrade as all KSPI power consuming applications (thermal nozzle/ electric engines) are reduced by a factor of 500. It allows you to play wiith Near Future Engine in a balanced way, otherwise a single small reactor would be enough to power a 100 Near Future Propulsion engines and make NF engines very overpowered.

Edited July 29, 2016 by FreeThinker

[xRei]

3 minutes ago, FreeThinker said:

Actualy it's not a downdrade as all KSPI power consuming applications (thermal nozzle/ electric engines) are reduced by a factor of 500. It allows you to play wiith Near Future Engine in a balanced way, otherwise a single small reactor would be enough to power a 100 Near Future Propulsion engines and make NF engines very overpowered.

AH. So you have an extension for KSPI-E that scales back the power output/requirements specifically if Near Future is installed. I didn't notice that. Thanks for clearing things up for me.

[FreeThinker]

24 minutes ago, xRei said:

AH. So you have an extension for KSPI-E that scales back the power output/requirements specifically if Near Future is installed. I didn't notice that. Thanks for clearing things up for me.

For your information, that is what KSPI Extended originaly was  intended for, a Near Future Technology compatibility mod for Fractals Interstellar Mod, but Fractal went AWOL and I kind of took over and extended it. That's why it is called KSPI Extended.

Edited July 29, 2016 by FreeThinker

[Boris-Barboris]

1 hour ago, FreeThinker said:

The problem at is that at higher delta, you can effectivly reach higher speed with a single deltatime frame of 2000s  then  with 2 frames 1000 seconds (as the second frame will lower your Isp and thrust). So we need to somehow compensate for this paradox difference. Any Ideas?

None, but as always with numerical integration, you can just decrease time step (artificially, creating a loop inside fixedupdate (or update, I don't know exactly what persistentacceleration does) on high velocity regimes). Also, you could just clamp v to some max value just below c (just hard reset it when FTL detected), that should be doable if the vessel is on rails.

 

Edited July 29, 2016 by Boris-Barboris

[FreeThinker]

1 hour ago, Boris-Barboris said:

None, but as always with numerical integration, you can just decrease time step (artificially, creating a loop inside fixedupdate (or update, I don't know exactly what persistentacceleration does) on high velocity regimes). Also, you could just clamp v to some max value just below c (just hard reset it when FTL detected), that should be doable if the vessel is on rails.

 

Well, the clamp solution is already implemented, but doesn't solve the problem, only prevents runing out of floating point precision

Now the internal loop fix sounds intresting, While DeltaTime > 1, I could loop deltatime times for 1 second equivalent of persistant propulsion

Now the question is,  is calling 2000 times the same function that alters the vessel the speed going to work with KSP physics model?

Edited July 29, 2016 by FreeThinker

[Boris-Barboris]

1 hour ago, FreeThinker said:

Now the question is,  is calling 2000 times the same function that alters the vessel the speed going to work with KSP physics model?

What function exactly?

[FreeThinker]

2 minutes ago, Boris-Barboris said:

What function exactly?

calling vessel.orbit.Perturb  (which is the following extension method )

        public static void Perturb(this Orbit orbit, Vector3d deltaVV, double UT)
        {
            // Transpose deltaVV Y and Z to match orbit frame
            Vector3d deltaVV_orbit = deltaVV.xzy;

            // Position vector
            Vector3d position = orbit.getRelativePositionAtUT(UT);

            // Update with current position and new velocity
            orbit.UpdateFromStateVectors(position, orbit.getOrbitalVelocityAtUT(UT) + deltaVV_orbit, orbit.referenceBody, UT);
            orbit.Init();
            orbit.UpdateFromUT(UT);
        }

 

Edited July 29, 2016 by FreeThinker

[Boris-Barboris]

@FreeThinker looks fine. Though every 1 second may be too frequent, it should be fine even on much larger time steps imho.

[FreeThinker]

8 minutes ago, Boris-Barboris said:

@FreeThinker looks fine. Though every 1 second may be too frequent, it should be fine even on much larger time steps imho.

perhaps it's an idea to add a timer and measure in miliseconds how much time 2000 iterations cost, if it's less than 10 ms, it should be safe, if not, I need to reduce the number of iterations untill it does

Edited July 29, 2016 by FreeThinker

[Boris-Barboris]

50 minutes ago, FreeThinker said:

10 ms

10 ms is a lot, actually. I'd say it's best to just choose minimum amount of iterations to prevent FTL on 0.99999c, just create a test save and tune until no overshooting c on some light craft.

[FreeThinker]

18 hours ago, Boris-Barboris said:

10 ms is a lot, actually. I'd say it's best to just choose minimum amount of iterations to prevent FTL on 0.99999c, just create a test save and tune until no overshooting c on some light craft.

Confirmed, using timers I found out a single OnFixedUpdate only last 0.033 ms durring high time warp and 0.001 ms during real time

Btw, the changes are having a huge effect. Getting even near 0.9 Kerbal Lightspeed is now hard , as it should be..

Edited July 30, 2016 by FreeThinker

[Hypercosmic]

Suggestion: Two Daedalus engine size: one for first stage (And thus larger one, 5 m) and another for second stage (smaller, 2.5 m)

[TwinKerbal]

Hello,

How do I use the Warp drive in KSP Interstellar?  It seems like it requires way too much electricity to be efficient.