Fractal_UK

No, it's not based on the solar panels, it's entirely new code, it uses a proper inverse square curve so should be much more effective near the sun. Yeah, the thrust is applied along the KSP Y axis, which thinking about it is actually all we need because the other components cancel. It does receive thrust from both sides. I think in the version you're using it applies thrust while not deployed but that module is very much a half-finished test, I've already fixed some of the problems today.

Yeah, I was playing around with the module earlier and though I did write the retraction code, the button never appears - I guess I never got far enough to need it! If you try max physical time warp for a while, you should see a change in your peri/apoapsis. At present the thrust is just applied parallel to the sail orientation so that needs some work too. I did make a little progress making it work better during timewarp but it's still a little unstable.

I am indeed very interested, I've been looking for models like these for what seems like an age without much success. Models are one of the main limiting factors on Interstellar development because I'm so bad at this part myself. I'd be more than happy to find a place for these models in Interstellar! Really nice work AArtisan, drop me a PM and we can go from there.

One of any radiator in the mod will do that. They will all build up heat for a while then stop once the radiators heat up sufficiency to dissipate the heat. It shouldn't take long to stabilise.

If you have an install with KSP Interstellar you can try the existing code by replacing whatever MODULE{} you're using to animate that sail in the .cfg file with MODULE { name = ModuleSolarSail surfaceArea = 100 // replace with the actual surface area of the sail animName = sailAnim // replace with the name of the animation you're using to deploy/retract the sail } Stick to physical timewarp while you have the thing deployed though, there is some code that will try to adjust your orbit during non-physical timewarp and it tends to slowly make your orbit unstable at the moment. I'm fairly sure I can fix it though.

Interstellar has an experimental solar sail part module that could control this, it works at physical speeds but it doesn't yet work under on-rails time warp, while that's not surprising - other KSP engines are the same - I'd really like to get on rails working because it makes a solar sail function sensibly. I can certainly put some more work into it if you're interested?

The stackable scoops and radial scoops are just the same. Kaethorin, you're not trying to use them as intakes are you? They need quite a bit of power and take gases from the atmosphere and compress them into fuel tanks.

I'd like to edit these a little to support different resource consumption rather than just electric charge and to support resource managed resource consumption, that would make them consistent with the existing modules. After that, I can include them as a general use module if you like?

It's the sabatier process you will need to produce Methane and Oxidiser, you need some LiquidFuel (Hydrogen) to make it work, so you can either take that with you or you can collect water from the surface of Duna and electrolyse it.

I want to alter the design for the larger reactors, the small reactors are laser powered interial confinement fusion units but I want the large units to be a kind of fusion torus - these would be more analogous to the large fission reactors, i.e. pretty heavy and use non-linear power scaling but capable of breeding their own supply of tritium from a lithium blanketed reaction chamber. I haven't worked out exact stats but unupgraded they'll probably be roughly on a par with the gas core fission reactors albeit with slightly different power scaling so they'll have a slightly different feel rather than just being bigger versions of the existing reactors. You should, however, still expect that it will need ongoing electrical power consumption to support plasma confinement/heating and a focus on higher power consumption and lesser fuel efficiency compared to other reactors in the same tech node.

I'd guess if you're having strange lag and weird behaviour with thermal rockets you've probably got an install issue, thermal rockets are among the parts that malfunction when the mod is installed in the wrong location. Check you don't have an extra GameData folder in your install path or something similar, it might eveb be worth deleting the WarpPlugin folder and then fully reinstalling the mod. Waste heat mechanics changed in recent versions, it will build up for a while but radiation will also go up as it does so provided you do, in fact, have enough radiators it will eventually stabilise. The next version will have a thermal mechanics helper in the VAB to make all the numbers clear to you as you design your rocket. You can only transfer nuclear fuel with an EVA kerbal when the reactor is shutdown. Actinides never transfer, they get reprocessed. It won't work on Kerbin, try using it on the Mun. It will if you time accelerate up to about 1000x. It doesn't work at lower time acceleration due to some weird change the developeds made to the resource system in 0.23 that makes all instantaneous resource requests smaller than 1e-5 return 0.

Radiation is the most probable answer then, perhaps you can describe what you're seeing in more detail?

No but you do need full power all the time, it uses the same power at 1% throttle as at 100% because the specific impulse scales. Make sure you have the full 2.5GW electrical power. Edit: also check for nearby Kerbals and, if present, move them or turn off the radiation safety features (accepting they will probably die in the process).

If you actually have specific questions, there are plenty of people here who will be willing to help you.

I'm fairly sure this was already identified as a RemoteTech issue.

Glad you like it. The behaviour of the included parts is to hide options to collect resources if the amount available is a hard zero, if you leave a part collecting a resource it will also stop if you move into an area where there is zero of that resource available. The collection option will reappear when there is something to find. Yes, that's right. In the current version of Interstellar almost all of this code is replicated but the next version of Interstellar will reference this instead. Interstellar takes advantage of some of the more powerful features included here so I'll try and put up some example code from there showing how to use the ResourceManager. Interstellar also creates the megajoules power management display by using a trick (it reimpliments some parts of ORSResourceOvermanager and ORSResourceSuppliableModule to create a factory for a subclass of ORSResourceManager) so I can show how other modders can do the same thing and create GUIs that provide information about resource managed resources. I'm fairly certain your resource integration addon won't be affected by the change in architecture, KSPI alters the resource definitions found in this with standard MM nodes (to try and make sure that other mods can make changes afterwards). Your addon uses final nodes so all its changes should be executed after Interstellar's.

Check out this post: http://forum.kerbalspaceprogram.com/threads/43839-0-23-KSP-Interstellar-%28Tweakables-New-ISRU-Preecoolers%29-Version-0-9-2-%28Beta%29?p=783727&viewfull=1#post783727, it's where I originally described the planetary resource system for Interstellar. The gamma ray spectrometer is displaying the thorium and the uranium values found just below the scanner while the marks show a few strategic locations (within line of sight) that contain high value deposits while maintainity variable quantities across the surface of the entire planet.

Remember that the definitions are going to be shared by all mods, that is the point of integrating into a single resource system, additionally multiple definitions are generally bad - that means if there are no defaults but four or five seperate mods want to use this to define the ocean as containing water (not an unreasonable thing to want) you immediately have five duplicate definitions and the whole thing becomes a mess. It is much much safer for atmospheric and oceanic resources to define defaults and edit them with ModuleManager. Once I release the next update KSPI will use MM .cfgs to edit some resources into these existing definitions. It may also be possible to add some kind of masking system so that certain mods can hide certain resources from others if they need to do something funny or create duplicates for some reason. Planetary resource definitions are a bit different and no defaults are defined there.

The idea of having a predefined set of oceanic and atmospheric resources is basically to ensure a good player experience, everything is designed to work from percentage abundances. It wouldn't really make much sense and wouldn't provide a good experience for players if the atmosphere or ocean ended up having resources that totalled up to 856% or something. I provide a set of defaults not to prevent changes but rather to try and define a range in which changes should be made.

It's already in the part description in the VAB, it's the first thing listed.

There is no difference between 1 and 9 engines because you don't have enough power to reach the maximum power of the 62.5cm engine. 1 engine can already consume all the power so adding more engines doesn't help, you just split the same power between many engines and end up with the same thrust. If you have more power, you will see a difference.

What it says in the ModuleEngines definition in the .cfg file doesn't matter, it's controlled by the ElectricEngineController module. The reason the two engines in your pictures are different is due to the maximum power definitions, the small engine has a lower maximum power, it has a hit a cap and it can't go above that power. The larger engine has a bigger cap, so it can use a lot more power.

KSP will always use the first version loaded for PartModules defined directly, which should always be the latest version - OpenResourceSystem.dll. Mods that require a version independent copy should reference the version specific copy of the dll (OpenResourceSystem_1_0_0.dll at present) and create new classes that inherit from these. In your case, if you want a scanner, you might make: using System; using OpenResourceSystem; namespace SarbianMod{ class SarbianResourceScanner : ORSResourceScanner { } } Then in your part.cfg you use MODULE { name = SarbianResourceScanner resourceName = Thorium mapViewAvailable = true } SarbianResourceScanner is now tied to the version specific copy of the .dll that you want to use for your own mod, whereas ORSResourceScanner is tied to the most up to date copy.

Re-entry effects/atmospheric shock heating and atmospheric engine overheating without precoolers are not the same. Turbojets cease to function due to materials limitations from the heat generated by the slowing down of intake air at maybe Mach 3-4 while scramjet aircraft and rockets are capable of hypersonic travel through the atmosphere, all of these experience shock heating which is what DRE simulates, only the first will suffer from internal overheating. These are very different problems.

Yeah, it doesn't really have anything to do with the heating system, it's all about the intake design - most intakes slow down flow to be subsonic, often pushing it through turbomachinery, it's this rapid decrease in intake air speed that causes the internal components to overheat. Fission and fusion reactors both scale down their Isp in order to increase thrust with atmospheric engines, which implies there is some kind of turbomachinery going on in there to reduce the actual exhaust velocity. Antimatter engines don't so you could imagine, with the right intake, they could be used with purely supersonic flow, a bit like a SCRAMJET. A slightly different intake design would be needed, of course. A real sabre is actually unit consisting of an intake, precooler, turbomachinery and nozzle. The nozzle is only the part that's really represented on the rapier, the B9 sabre intake, B9 precooler and B9 sabre is a good representation of the whole unit. Any scheme for having those kind of core temperatures requires some kind of non-material seperation from the reactor walls, an example is a fusion torus that magnetically contains a plasma - you don't melt the reactor because the plasma never touches the walls. Your plane, however, cannot be seperated from the air which it is flying through so you can still cook the interior by flying too fast without a heat exchange mechanism.