[0.25]KSP Interstellar (Magnetic Nozzles, ISRU Revamp) Version 0.13

[John Crichton]

so i was building and anti matter collection station in kerbin orbit the first two payload went up fine but the third one being the anti matter collectors and the tanks.

i noticed my electric charge was drained i a few seconds so i added some batters and launch claps but my charge still drained.

i believe this is the anti matter stuff as the other launches went fine.

also i have the latest version of KSPI so if anybody else has this problem pleas say.

P.S.sorry if this is a re post.

Do you have an Alcubierre drive? It drains a ton of power and is switched on from the start...disable charging before launch

[roxedboxer]

I'm having a very annoying problem... I can't, no matter what I do, beam power to another craft. I've got a vessel with reactors, a computer core, a transceiver, and electricity generators and I've also got another separate vessel with a plasma engine, xenon, a probe core, and a receiver. The transceiver activates and says it's beaming power, but the receiver on the other vessel won't open or receive any power whatsoever. This problem is really really making me angry. Please help..

[WaveFunctionP]

I'm having a very annoying problem... I can't, no matter what I do, beam power to another craft. I've got a vessel with reactors, a computer core, a transceiver, and electricity generators and I've also got another separate vessel with a plasma engine, xenon, a probe core, and a receiver. The transceiver activates and says it's beaming power, but the receiver on the other vessel won't open or receive any power whatsoever. This problem is really really making me angry. Please help..

Receivers must be pointed at a transmitter or relay to receiver power. The closer the angle, the better the reception, the further the angle, the less reception until about 90 degree where you will receive no power.

A very simple way to use beamed power is with a big reactor on the ground, with an array set to transmit, and at least 3 arrays in orbit around kerbin set to relay mode at 0 degree inclination and 120 degree separation around 750km. This should give you 360 degree power availability around kerbin. You can use more relays/transmitters with smaller separation if you wish. And you can launch whole powerstations with 2 arrays to both transmit and relay power if you wish.

In my main save, I personally use 6 3.5m fusion reactors orbiting kerbosyncronously at 0 degrees inclination and 60 degree separation, each with two arrays, ktec and direct drive generators, 2 of the flat radiators, a computer core, and docking ports for refueling. This setup however gives me obscene amounts of power, something like 220GW, which is overkill. But it's late in the save, so absurdity is the rule. I can get usable amounts of power all the way out to Jool with the deployable array (Area/size only matters for recieving power, not transmission or relay modes, and it mostly only useful to combat losses due to very long distances.).

You can learn this and much more on the wiki, located here:

https://github.com/FractalUK/KSPInterstellar/wiki

Edited March 27, 2014 by WaveFunctionP

[Tery215]

Fractal(UK), there are significant issues in the power priority system.

Fuusion Reactors powered by lasers and such really need higher priority than power transmitters, since the reactor needs power to run (obvious)

To solve this, I highly recommend allowing players an "up" button (^) and a "down" button(v)

[WaveFunctionP]

Fractal(UK), there are significant issues in the power priority system.

Fuusion Reactors powered by lasers and such really need higher priority than power transmitters, since the reactor needs power to run (obvious)

To solve this, I highly recommend allowing players an "up" button (^) and a "down" button(v)

It's a bug involving direct conversion mode generators. It will be fixed in the next update.

[Donziboy2]

That's a good idea. I'll try defaulting the containers to disabled.

edit: Annnnd, done!

- Antimaters containers now have charging disabled by default.

If you have MJ, you have EC. If you have a MJ demand, and MJ are not present, it will consume EC. It is simply how the mod works.

Sadly my SSTO says your wrong, during time warp the EC's drain but MJ are still full, once I come out of warp or slow it down the EC goes back up.

Donziboy2, you had a very nice looking SSTO plane there, very similar than my own design, ie. 2x 2.5m fusion reactors and thermal turbojets. Its not the fastest to takeoff but after that, it does fly pretty well.

And no, there's no such thing as playing too much KSP...its just not possible...

Sadly it killed 2 Kerbals yesterday when I time warped and the EC's ran out...... TAC Life Support is a killer

[macdjord]

Microwave receivers really need to limit themselves to only producing as much power as is currently needed. I just upgraded my main power station from base fission to upgraded fusion - the new output level is great for large plasma-driven vessels, but causes my smaller craft to overheat and shutdown in seconds when I activate their receivers.

Also, the power allocation priority system is a great idea, but it is drastically under-specific. It doesn't protect against my plasma drives causing my DT-Vista engine to flame out, nor does it keep the engines from killing the fusion reactors. I therefore propose the following set of priorities:

0: DC electrical system (because its drain will never significantly affect anything else)

1: Computer Core (because the last thing you want in a power crisis is to lose control)

2: Fusion Reactors (because the second-last thing you want in a power crisis is to suddenly have even less energy production)

3: D-T Vista engine (because it is all-or-nothing)

4: Antimater Containment (because BOOM)

5: Cryostats (because a shortage here will cause permanent resource loss)

6: Plasma Engine (because it can scale to whatever amount of power remains)

7: Nuclear reprocessing, Uranium Ammonolysis, Deuterium Centrifuging (because they produce reactor fuels)

8: Research (lab, telescope, or computer core), all other resource extraction/processing operations

9: Antimatter production, Alcubierre Drive (because they are scalable, low-urgency, high-max usage operations)

10: Microwave Transmitters

One thing there that I think requires explanation: I put DT-Vista above antimatter containment. That's because the containment units have their own internal reserve, while the DT-Vista is totally useless unless it gets its full 2.5GW. If you power your containment at the cost of the drive, your ship is dead in the water. Whereas, if you power the drive at the expense of the containment, you're fine as long as you don't have a single burn long enough to completely drain the containment units.

[pantheis]

Microwave receivers really need to limit themselves to only producing as much power as is currently needed. I just upgraded my main power station from base fission to upgraded fusion - the new output level is great for large plasma-driven vessels, but causes my smaller craft to overheat and shutdown in seconds when I activate their receivers....

After experiencing much of the same issues as you, I completely agree with your list of proposed power priority changes.

[jinks]

@Fractal_UK: You talk often about things coming in the next update, yet there is no movement in your github repo. Would you be willing to develop a bit more out-in-the-open, so that people can track the progress of requested features and maybe even give input on new stuff?

There is little to no movement to issues and pull request on github. Is this all just waiting for the next update or are you generally not using those features. (I submitted a very simple pull request quite a while ago *hint* *hint* )

@WaveFunctionP: I looked a bit through your repo, since it seems to be the most up to date. There is quite a bit of redundancy in the repository (GameData folders and dlls). It would be easier to follow if there were one canonical copy of everything. I'd suggest getting rid of FNPlugin\WarpPlugin\, OpenResourceSystem\OpenResourceSystem\, OpenResourceSystem\obj\ folders and all dlls in the GameData folder and then manage GameData\ as the canonical copy for assets.

(As a very small bonus this would also get rid of the PreBuild instructions (xcopy...) which MonoDevelop cannot handle.)

The reason I ask is that I really need a way to limit received microwave power for my current save to progress. I'm almost about to implement it myself, but I'd prefer to do it in a compatible fashion that can be integrated back into the upstream code.

As an aside: Implementing the limit itself is actually quite straightforward as far as I can see. The stumper for me is at the moment how to build a proper UI around it. Transmitted power can vary wildly from a few GW to several TW during the lifetime of a save. What would be a good boundary? Max available? Max the current ship can handle? I'm personally leaning to ~10x or 20x dissipation capacity as upper limit so you can get bursts of high power if you want to.

I'd like to implement it as a slider (akin to the thrust limiter), but so far I couldn't find any example code for slider UIs, does anybody know of a mod that implements them?

[Donziboy2]

Got myself a new model, has an 8m Cargo hold and can move alot of fuel into space, and its easy on fuel, cost me less then 2T of LF to get into orbit. Its under 100 parts, I plan to add a few more to the base model but it has insane range(80k Dv) using the Plasma's. Only issue is the Plasma's seem to be bugged and I only get 16kN from each, my reactors hardly even register the power draw.

I may make another one with less fuel and more cargo bay area, have not decided yet. And I could always go big

[Makeone]

Since similar vessel killed its crew (Hum!), didn't you kept reactors online while in transition? I learned that i forgot any sort of backup power on my similar thermal spaceplane, so i had to keep fusion reactors running for the whole duration from kerbit to jool. Not a biggy, though i didn't have lifesupport on that save, but i do have now

Am i assuming correctly that those are direct conversion generators? They have really small output on normal D/T fuel mode and since one 0.625m thruster can take up to 4GW of power... And that's by no mean light vessel either. I just used those thermal turbojets for travel as they have 4000 Isp, works for me. Oh, and it had about 40T of fuel (2x KW half 2.5, tanks).

[WaveFunctionP]

@Fractal_UK: You talk often about things coming in the next update, yet there is no movement in your github repo. Would you be willing to develop a bit more out-in-the-open, so that people can track the progress of requested features and maybe even give input on new stuff?

There is little to no movement to issues and pull request on github. Is this all just waiting for the next update or are you generally not using those features. (I submitted a very simple pull request quite a while ago *hint* *hint* )

@WaveFunctionP: I looked a bit through your repo, since it seems to be the most up to date. There is quite a bit of redundancy in the repository (GameData folders and dlls). It would be easier to follow if there were one canonical copy of everything. I'd suggest getting rid of FNPlugin\WarpPlugin\, OpenResourceSystem\OpenResourceSystem\, OpenResourceSystem\obj\ folders and all dlls in the GameData folder and then manage GameData\ as the canonical copy for assets.

(As a very small bonus this would also get rid of the PreBuild instructions (xcopy...) which MonoDevelop cannot handle.)

The reason I ask is that I really need a way to limit received microwave power for my current save to progress. I'm almost about to implement it myself, but I'd prefer to do it in a compatible fashion that can be integrated back into the upstream code.

As an aside: Implementing the limit itself is actually quite straightforward as far as I can see. The stumper for me is at the moment how to build a proper UI around it. Transmitted power can vary wildly from a few GW to several TW during the lifetime of a save. What would be a good boundary? Max available? Max the current ship can handle? I'm personally leaning to ~10x or 20x dissipation capacity as upper limit so you can get bursts of high power if you want to.

I'd like to implement it as a slider (akin to the thrust limiter), but so far I couldn't find any example code for slider UIs, does anybody know of a mod that implements them?

I'm new to programming, and certainly repositories. My repo has both the source code, configs and assets all integrated into the project. (Which is why you see nested assets inside each solution folder, because they are imported assets. It's how visual stupid handles things.) Which then builds the proper gamedata folder as an output. The reason I use xcopy on post build is that visual studio requires that I go to each asset in the project individually and set it to output (I can't just click on the folder and set everything to output), which is a pain in the butt as there are a lot of files. And even when I tried to do so (by editing the xml for the project script), it didn't copy files to output properly as it put them into all the same base folder. So my build would compile the dlls and put them into the targeted plugin folder, but it would also put the configuration files and assets in the plugin folder as well. It contains OSR and Interstellar because Interstellar (FNplugin) depends on OSR.

I edit and commit even the config files through my visual studio project, so that it is setup as a complete solution and I'm not switching back and forth between editors/managers. Each synced build is output to the gamedata folder, which is the version that actually is useable when placed into the actual game's gamedata folder. I use a batch script to move the files from the output folder to my test install and run ksp. The whole things works quite well considering.

Basicly, each build outputs fully usable gamedata addon when I press f6. And then I click on my batch file and the files are synced to the current build and the game is launched. I'm able to rapidly iterate with this method, but I'm open to suggestions about how to better manage things.

To publish to the github repo, I simply commit my changes and sync with visual studio. It syncs the source assets and the output all in one go.

I was going to look into the power limit thing, but I'm currently sidetracked attempting to make a heavy duty landing gear / resource extractor model in blender that I'd like to try and get included in the mod.

Besides, I figure that fractal already has a solution, though I too wish that he would share his progress so that we are all on the same page. It's his mod though, so he can do as he pleases.

Edited March 28, 2014 by WaveFunctionP

[Donziboy2]

Since similar vessel killed its crew (Hum!), didn't you kept reactors online while in transition? I learned that i forgot any sort of backup power on my similar thermal spaceplane, so i had to keep fusion reactors running for the whole duration from kerbit to jool. Not a biggy, though i didn't have lifesupport on that save, but i do have now

Am i assuming correctly that those are direct conversion generators? They have really small output on normal D/T fuel mode and since one 0.625m thruster can take up to 4GW of power... And that's by no mean light vessel either. I just used those thermal turbojets for travel as they have 4000 Isp, works for me. Oh, and it had about 40T of fuel (2x KW half 2.5, tanks).

I had an AM reactor and 4 fusion reactor's idling the whole time... And the crew still died. It may be a bug with the ship not being the active craft I was bringing a probe around to dock with the craft the Shuttle was docked with when I got a message saying 2 crew had died. At least I don't have them set to permadeath lol.

Yes the generators where in direct conversion mode damn.... Now I have full power!

Even with the plasma thrusters at full power it would take like 19 hours to burn thru the 82+kDv....

[jinks]

I edit and commit even the config files through my visual studio project, so that it is setup as a complete solution and I'm not switching back and forth between editors/managers. Each synced build is output to the gamedata folder, which is the version that actually is useable when placed into the actual game's gamedata folder. I use a batch script to move the files from the output folder to my test install and run ksp. The whole things works quite well considering.

Basicly, each build outputs fully usable gamedata addon when I press f6. And then I click on my batch file and the files are synced to the current build and the game is launched. I'm able to rapidly iterate with this method, but I'm open to suggestions about how to better manage things.

Ok, that's of course a possibility.

In that case you should put the top-level Gamedata\ folder and all .dll into .gitignore and remove them from the repository. It's bad form to commit autogenerated (or copied) files and it can easily lead to confusion when someone commits a change in the wrong place and it is overwritten by the next run of a batch script.

The better solution would of course be to keep the assets together but since I don't know VisualStudio, I have no idea how you can add the GameData folder as a whole to your project.

[TripleAlphaProcess]

I actually had an issue the other day because of the EC drain imposed by the AM tanks and time warp kill 2 of my Kerbals on a ship since im using TAC Life support.

It would be nice if they launched disabled and if they defaulted to using MW/MJ instead of EC.

Similar problem here. I'm the guy with the two vista engines, with one's thrust dropping a bit during firing. If i time accelerate, the electric charge will drop briskly for a few sec before it stops dropping and fills back up. this happens at all levels of time acceleration up to 10,000 or maybe 1000, I forget. at 10,000 or 100,000, the charge drops fast enough that it doesn't stop dropping before it all gets drained (and it has some 20k EC iirc), and if i push the time acceleration to max, the kerbal will actually die in the time that the it takes the game to dial back the time acceleration. This is DESPITE having more than enough power for everything. The power currently being drawn in the image is only 5.19 GW from the KTEC reactor and the nose reactor - i have tried running the ship with the nose reactor off by the way - off of an upgraded fusion reactor, so its capable of at least 25GW of output. So now i'm afraid to fly that ship at all because my kerbals just may die lol. Time accelerating from a different ship seems to be ok though.

[VaporTrail]

Known bug that will be fixed in the next version fractal releases. When attaching to different generators to a reactor in this version some parts get confused and report more avalible power than the generators are actualy producing. You'll probably find if you turn on the transmiter for long it tries to transmit more power than the reactor is producing untill it starves the reactor and shuts down.

Actually, I haven't had it shut down on me yet... Perhaps I haven't had it run long enough. On a interesting note, I've managed to orbit a similar version of this that output almost 2x the power the reactor was rated for.

Also had a strange issue where one of the generators kept swapping types when I reverted to VAB.

[WaveFunctionP]

Ok, that's of course a possibility.

In that case you should put the top-level Gamedata\ folder and all .dll into .gitignore and remove them from the repository. It's bad form to commit autogenerated (or copied) files and it can easily lead to confusion when someone commits a change in the wrong place and it is overwritten by the next run of a batch script.

The better solution would of course be to keep the assets together but since I don't know VisualStudio, I have no idea how you can add the GameData folder as a whole to your project.

I think I've figured out a solution. I found a post online that showed me how to link to assets in bulk. And I'm now ignoring the folder structure that is still imported by that method.

Good news is that the project folders now only contain code related files with no duplicate assets, and gamedata is only generated when it actually changed. There was some commits required to syncronize everything, but everything appears to be in order.

Bonus prize: I was able to remove the xcopy prebuild commands, since it no longer required.

Extra bonus: The solution is now using relative paths, so it should work right out of the zip file. Though you will probably need to update the reference paths for the c-sharp and unity library .dlls.

Sorry for any trouble, I'm still very new to this.

Edited March 28, 2014 by WaveFunctionP

[mrskwid]

Do you have an Alcubierre drive? It drains a ton of power and is switched on from the start...disable charging before launch

no it does not thank anyway:D

It could be the antimatter tanks. They require a bit of EC to keep containment and if you have no other source of power they could drain your batteries. It has been awhile since I sent mine up ... but I believe you can disable/turn off the tanks in the VAB. Then they won't start using EC until you re-enable them. I just left mine disabled until the were connected to my station which has a fusion power source.

that was my first thought but it did't seem to give the option to turn the tanks off that why i think it something buggy:huh:

[WaveFunctionP]

that was my first thought but it did't seem to give the option to turn the tanks off that why i think it something buggy:huh:

I'll look into it.

[jinks]

I think I've figured out a solution. I found a post online that showed me how to link to assets in bulk. And I'm now ignoring the folder structure that is still imported by that method.

Good news is that the project folders now only contain code related files with no duplicate assets, and gamedata is only generated when it actually changed. There was some commits required to syncronize everything, but everything appears to be in order.

[...]

Sorry for any trouble, I'm still very new to this.

Fantastic! This matches up 100% with what I was trying to do

A few additions: You can remove (and gitignore) GameData/OpenResourceSystem/Plugins/OpenResourceSystem_1_1_0.dll, GameData/WarpPlugin/Plugins/WarpPlugin.dll and OpenResourceSystem/obj, since those will be recompiled anyways.

[WaveFunctionP]

Fantastic! This matches up 100% with what I was trying to do

A few additions: You can remove (and gitignore) GameData/OpenResourceSystem/Plugins/OpenResourceSystem_1_1_0.dll, GameData/WarpPlugin/Plugins/WarpPlugin.dll and OpenResourceSystem/obj, since those will be recompiled anyways.

I intend to leave the compiled plugin .dlls for those that want to download and try out the version.

I'll look at the obj folder. I thought gitignore was needed to keep the repo in sync with my local copy. Guess not, if I can just remove it.

edit:

After a bit of wrangling with sync conflicts, I was able to delete the obj folder that was leftover. I think the repo is about as clean as it is going to get. I'm going to leave the gitignore file should someone want to setup thier own repo with mine as a template, as it actually contains the project files that should get things working right out of the box.

My timeline looks crazy. Hopefully from now on commits will match actual development more closely.

Edited March 28, 2014 by WaveFunctionP

[jinks]

I intend to leave the compiled plugin .dlls for those that want to download and try out the version.

While that's a nice gesture, it might create problems down the road. Say, I make a change to the repo, test it and want to send you a pull request. Those DLLs will be part of every pull request since everybody has to recompile them all the time.

Github has a download feature, maybe that is better suited for those cases. People that don't intend to compile the code have usually little business in using the latest checkout.

I'll look at the obj folder. I thought gitignore was needed to keep the repo in sync with my local copy. Guess not, if I can just remove it.

Sorry, I worded that wrong. I meant, you might add obj/* and *.dll to .gitignore (if it isn't already there) so those files don't get checked in by accident in the future.

My timeline looks crazy. Hopefully from now on commits will match actual development more closely.

Let's hope so. To be frank, the changes up to now might already dissuade Fractal_UK from including your changes in the official repo. Large scale restructuring tends to look ugly in git logs .

I also have noticed some problems with line ending, though they seem to get less on my end, is this from Fractal_UK or from you? -- In general: Windows users, please check your autocrlf settings, git hates Windows. -- These changes really suck, because they show up in diffs as all lines removed, then all lines re-added.

[Captain Catastrophe]

Hi everybody. First time post, got an odd thing happening and I wonder if it's a bug in the plugin / the game, or just a bug in my brain.

I have KSP 023, KSPI and a bunch of the planet packs from kerbal universe active.

Running the AIM reactor - reactor shows ~0% active when turned on, even when under load. It will power up initially to ~100% and then drop off to zero. I assume that it is supposed to throttle to zero when there is no power required however, it does not throttle up again in line with power requirements.

I noticed this when the ship has a microwave transceiver:

- With the microwave transceiver turned ON (in either send or receive mode) - If I time warp for a while, it will activate at 99%, then go back to 0 very quickly.

- With the microwave transceiver turned OFF and with no other load, after time warp it will function correctly when put under load. If I then turn on a microwave transceiver (in either send or receive mode) it will again fail and go back to 0%.

- Without using time warp, the reactor will remain at 0% regardless of the power configuration, occasionally perking up a little, i.e. to 0.0001%.

- If the ship does not have a microwave transceiver then the reactor doesn't seem to work at all.

I've tried a clean install of KSP and KSPI with a blank sandbox save, but that didn't work either.

Does anyone have any ideas / has anyone experienced the same problem?

[WaveFunctionP]

While that's a nice gesture, it might create problems down the road. Say, I make a change to the repo, test it and want to send you a pull request. Those DLLs will be part of every pull request since everybody has to recompile them all the time.

Github has a download feature, maybe that is better suited for those cases. People that don't intend to compile the code have usually little business in using the latest checkout.

Sorry, I worded that wrong. I meant, you might add obj/* and *.dll to .gitignore (if it isn't already there) so those files don't get checked in by accident in the future.

Let's hope so. To be frank, the changes up to now might already dissuade Fractal_UK from including your changes in the official repo. Large scale restructuring tends to look ugly in git logs .

I also have noticed some problems with line ending, though they seem to get less on my end, is this from Fractal_UK or from you? -- In general: Windows users, please check your autocrlf settings, git hates Windows. -- These changes really suck, because they show up in diffs as all lines removed, then all lines re-added.

I'll see what I can do to alleviate those issues. I appreciate your help.

[mrskwid]

I'll look into it.

thanks,i noticed that in the last updates that the notes sed fixed anti matter tank electric charge handling this could have something about it:huh: