[1.3.0] OPT Space Plane v2.0.1 - updated 29/07/2017

[K.Yeon]

It's not particularly complex and it would less of a dependency than whatever current fuel switching system you have now:

Behold!

@PART[j_4m_tanks]:NEEDS[ModularFuelTanks]
{
    MODULE
    {
        name = ModuleFuelTank
        volume = 2160
        type = default
    }
}

Doesn't do anything unless ModularFuelTanks is installed.

For Real Fuels it would be

@PART[j_4m_tanks]:NEEDS[RealFuels]
{
    MODULE
    {
        name = ModuleFuelTank
        volume = 10800
        type = default
    }
}

Done.

Want to add configs for other parts? Just do it as above with the part name in the brackets. Volume is stock volume unless it's for Real Fuels in which case it's stock volume * 5

Done.

Thanks Starwaster!! Save me alot of time haha ill add those config in the next update

Hey, I just wanted to say that this mod is awesome. I absolutely love the design of the parts, and the new cargo bays are really useful.

I have a couple of questions, though -- I've been having trouble attaching things to the outside of the big cargo bays; KSP doesn't seem to like it if they clip even slightly and my ship starts shaking. It might be that this is an unavoidable issue because it needs to collide so you can drive things into it, but, if not, could you take a look?

Secondly, I noticed that some of the part descriptions could use a little work in places; I was wondering if maybe I could help there? I'm quite good at writing, if I say so myself, and I'd love to help out with this incredible mod.

Is the thing you attach to the side a large heavy part? if yes you have to strut them down ;\ and the cargo bays will be replaced with a better and more stable model in future!

About the descriptions,, I havent really spend time on it if you have a better description please PM me ill add it to the parts haha, Thanks for your times

Awesome parts pack but i have to express my dislike of the new cockpits. I preferred the cockpit that has been removed. it had a more sharp/angular look to it rather then the very rounded new ones.

also that AERIE engine seems totally pointless I cannot see how it is useful at all unless im setting it up wrong.

as a plane engine its just far to fuel hungry or am I totally missing the point of this engine?

I added them to a SSTO space plane I had that works fine with rapiers and it ran out of fuel before it got past 10,000m.

but that said good job on the new models and textures they are looking really sleek.

looking forward to the next update. is the fix for FAR/NEAR in the next update?

Ofcourse the configs will be fixed, about the cockpit ill reconsider it There will also be changes to the engines as well as new ones, ill make sure they will get your spaceplanes to space haha.

One more thing K.Yeon. Your landing gear still needs some work. When I use it I constantly have to fight to keep the plane on the runway. It always wants to veer off either left or right. This doesn't happen when I use B9 gear. Furthermore you have balanced your gear that when you put the small gear under your fuselage in the middle and the big gear under the wing then it is balanced. That's great but the gear is simply not long enough. When you place the large gear under the CoM somewhere in the center of the plane, it is very very likely that you will crash the engine mount into the concrete of the runway. I do not want to say it is impossible to take off, but so far I haven't managed an angle that is small enough for this not to occur. Other than that, please keep up the great work. Very excited for the new upcoming and remodeled parts

Thanks!

Yeah stick to B9 gears or Adjustable Landing gears for now. Ill be sure to get the OPT gears fixed soon

the opt landing gear (all of them) are not working for me. The animation shows in the sph but when I launch the gear start extended but as soon as the plane is dropped to the runway the gear retract and cannot be extended. I am using the 0.90 recompile of firespitter

try to stick to the firespitter dll this mod provided, it was already updated to 0.90. Just reinstall the mod and check if theres no multiple firespitter.dll should fix it

Some updates:

i just got back from a trip and starts to work on this mod again, I just finished modelling the new mk2 sized engine, and testing begins...

Instead of the old LFO engine, this one will be a dual mode atmospheric Engine. The intake will start generate super compressed air above mach 2,

then you can switch to Ramjet mode that can take you to mach 6. Below mach 2 the intake act like an regular air intake.

It behaves much simpler than a real world engine would, so i might add support to advanced jet engines for those wish it to behave more realistically.

Another engine im working on is a J sized Linear Aerospike.

the next update i estimate is in two weeks

[Alewx]

http://i.imgur.com/dS0J3Gv.png

http://i.imgur.com/exVv9lI.png

Uh that is a nice toy

[ss8913]

What needs to happen is that a new transform has to be added with its Y axis pointing out of the docking port. That's its control transform. In the docking port module's config, it has to have controlTransformName = <the name of the transform> added

Preferably that should be added to the model itself but it is possible to hack it in via the part's config using MODEL nodes. I've done that before to add in proper control references to Porkjet's FLAT habs.

Any chance of some hints/code for the part config to fix this? Docking port is completely unusable in its current state... thanks

[subaru]

I only see one engine in the pack. Is it supposed to be like that?

I saw the guy on the video showcase had the another engine, the LFO(I hope that is a eureka seven reference).

[Gaalidas]

@PART[j_4m_tanks]:NEEDS[ModularFuelTanks]
{
    MODULE
    {
        name = ModuleFuelTank
        volume = 2160
        type = default
    }
}

@PART[j_4m_tanks]:NEEDS[RealFuels]
{
    MODULE
    {
        name = ModuleFuelTank
        volume = 10800
        type = default
    }
}

You know, you could save the MM system from having to add the module to the part by just entering the module into the part configuration file itself. MM can either add a module to a config based on certain criteria, or it can remove a module from a part if the mod it needs does not exist, from the "part.cfg" itself. Observe:

PART
{
    name = whateveryourpartname

    blah blah blah... and all that important data for the part...

    MODULE[B]:NEEDS[modularFuelTanks][/B]
    {
        name = ModuleFuelTank
        volume = 2160
        type = default
    }
}

The part in bold will cause MM to check if the plugin exists and, if not found, delete it from the part.

So, while it's really the same amount of processing power being used to add or remove the module, there are a few steps that can be skipped by the loader. First, it can skip having to load the MM config file that the patch would be inside. Second, it can skip having to process the MM patch to figure out what it needs to find. Third, it can skip having to scan all the other loaded data for the part name. Finally, because it is going to look through all the loaded configuration files either way, it can simply detect whether or not the plugin exists when it reaches that check, which I printed in bold above, and then simply remove it if it doesn't like what it sees.

Granted, it won't speed anything up much in the long run, if everyone embedded their modules directly in the configs and used these "needs" checks right there, instead of using separate MM patch nodes, the length of the KSP loading process would be significantly improved for people who can report over 10,000 patches per launch.

Just a little tidbit of info I thought I'd share. Might reduce the amount of work for the modder to just do it that way as well.

[AccidentalDisassembly]

You know, you could save the MM system from having to add the module to the part by just entering the module into the part configuration file itself. MM can either add a module to a config based on certain criteria, or it can remove a module from a part if the mod it needs does not exist, from the "part.cfg" itself. Observe:

PART
{
    name = whateveryourpartname

    blah blah blah... and all that important data for the part...

    MODULE[B]:NEEDS[modularFuelTanks][/B]
    {
        name = ModuleFuelTank
        volume = 2160
        type = default
    }
}

The part in bold will cause MM to check if the plugin exists and, if not found, delete it from the part.

So, while it's really the same amount of processing power being used to add or remove the module, there are a few steps that can be skipped by the loader. First, it can skip having to load the MM config file that the patch would be inside. Second, it can skip having to process the MM patch to figure out what it needs to find. Third, it can skip having to scan all the other loaded data for the part name. Finally, because it is going to look through all the loaded configuration files either way, it can simply detect whether or not the plugin exists when it reaches that check, which I printed in bold above, and then simply remove it if it doesn't like what it sees.

Granted, it won't speed anything up much in the long run, if everyone embedded their modules directly in the configs and used these "needs" checks right there, instead of using separate MM patch nodes, the length of the KSP loading process would be significantly improved for people who can report over 10,000 patches per launch.

Just a little tidbit of info I thought I'd share. Might reduce the amount of work for the modder to just do it that way as well.

One issue is that it is much, much easier to tweak values, update things if something like MFT needs changes in its syntax, whatever - both for the modder or for the end-user, since lots of us end-users like to fiddle with things too - if modules like Modular Fuel Tanks / TweakScale / whatever are loaded via MM config. MUCH easier. One file to edit in order to change an entire dependency's interaction. It may be a tiny bit less efficient, but it's so much easier to manage I think it's worth it.

Likewise, an end-user can then also decide "I don't like MFT!" (or whatever) and simply delete that ONE config file rather than editing every single part's config.

[Bakase]

Is the thing you attach to the side a large heavy part? if yes you have to strut them down ;\ and the cargo bays will be replaced with a better and more stable model in future!

About the descriptions,, I havent really spend time on it if you have a better description please PM me ill add it to the parts haha, Thanks for your times

Alright, I'll get to writing some!

[Edit: So I've noticed a few things -- a couple of the parts have the same name, which makes writing descriptions a little harder. Perhaps these could be renamed in a future update? For example, there are two I-J connectors -- maybe one could become the I-J aerodynamic adapter, or something.

I've also started writing descriptions in a kind of humorous manner to emulate the stock part descriptions, but I don't know if that's what you want. Would you rather have more serious descriptions?]

[Edit 2: Is it alright if I change the names of some of the parts? Only minor things, like changing 'adaptor' to 'adapter' (both are correct spellings, but to be consistent with KSP's stock parts it might be worth changing it).]

Edited January 18, 2015 by Bakase

[Mekan1k]

Any news on FAR development for the parts?

[Flashblade]

Any news on FAR development for the parts?

What are you specifically asking for? The no part shielding issue of the docking and utility bay aside these parts work perfectly well with FAR.

[Mekan1k]

What are you specifically asking for? The no part shielding issue of the docking and utility bay aside these parts work perfectly well with FAR.

I am specifically asking if the parts that have a lift value (a great many of the parts), have a FAR config- otherwise I need to use stock aerophysics, and those are not too reliable.

[Flashblade]

I am specifically asking if the parts that have a lift value (a great many of the parts), have a FAR config- otherwise I need to use stock aerophysics, and those are not too reliable.

All OPT parts have a FAR config, just go back two pages and you will find blowfishs fixed config for FAR (although not everything is fixed but that has nothing to do with lifting surfaces).

[blowfish]

All OPT parts have a FAR config, just go back two pages and you will find blowfishs fixed config for FAR (although not everything is fixed but that has nothing to do with lifting surfaces).

Here's an updated version. It won't fix the docking bay (where apparently the docking port doesn't work anyway), but it should fix the drop bay.

{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
}
@PART[i_4m_cockpit_isp]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
}
@PART[j_cockpit]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[ij_adaptor]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[ij_4m_adaptor_variant]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[j_docking_port]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@title = J-Inline Docking & Cargo Bay
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0

!node_stack_top01 = delete
!node_stack_top02 = delete
}
@PART[j_4m_lab]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[j_4m_tanks]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[j_engineMount_4]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[mk2j_adaptor]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[j_dropBay]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@title = J - Experimental Cargo Bay
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}

!node_stack_top01 = delete
!node_stack_bottom,2 = delete
}
@PART[js_adaptor]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
}
@PART[jjf_adaptor]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[jf_cargo]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
@PART[jf_cargo_tail]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
!MODULE[ModuleLiftingSurface] {}
}
PART[Mk1_compressor]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@dragModelType = default
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
}
PART[AAengine]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
}
@PART[opt_gears_m]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
}
@PART[opt_gears_s]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
}
PART[OPTdropTank]:NEEDS[FerramAerospaceResearch|NEAR]:Final
{
@minimum_drag = 0
@maximum_drag = 0
@angularDrag = 0
}

@PART[mk23_cockpit]:NEEDS[FerramAerospaceResearch|NEAR]:Final

[kklusmeier]

I want to semi-approximate a SABRE using the AIRE, and since the SABRE seems to not use oxidizer for the first engine mode I would like to remove the 'Oxidizer' component from 'SupercompressedAir'. What exactly should I edit to do this? I can't seem to find the ratio between these two in any of the config files...

Ninja EDIT: Note that I know that the RAPIER is supposed to fill this slot, but I find myself thinking of it more as a jet + rocket squished together rather than a single engine with two modes because of the massive ISP difference. Plus, this requires a compressor, just like the SABRE... I think that the RAPIER is well balanced with this AIRE since the weight increase of the compressor and massive power requirements is balanced by the higher thrust of both modes and the lower ISP of the jet mode.

Edited January 20, 2015 by kklusmeier

[kiyoshisaotome]

Outstanding detail and model I just can't get enough of it, here something I built recently

Had and accident on the last one lol crash into my large ship

[Flashblade]

I want to semi-approximate a SABRE using the AIRE, and since the SABRE seems to not use oxidizer for the first engine mode I would like to remove the 'Oxidizer' component from 'SupercompressedAir'. What exactly should I edit to do this? I can't seem to find the ratio between these two in any of the config files...

Ninja EDIT: Note that I know that the RAPIER is supposed to fill this slot, but I find myself thinking of it more as a jet + rocket squished together rather than a single engine with two modes because of the massive ISP difference. Plus, this requires a compressor, just like the SABRE... I think that the RAPIER is well balanced with this AIRE since the weight increase of the compressor and massive power requirements is balanced by the higher thrust of both modes and the lower ISP of the jet mode.

That is because it is not part of the config files. The new plugin handles the creation of super compressed air, which causes problems onto itself because it hinders Kerbal Engineer to calculate the TWR. It always shows zero so you will be guestimating/eyeballing this stuff.

[Mekan1k]

Just a question here: does the compressor REALY need to have oxidizer to work? I mean, it is just supercompressing the air for the engine- once the engine is running, the compression should be self-sustaining.

[Railgunner2160]

Nice ship, nice use of GN-drives. How do you avoid the twin-drive sync error?

[kklusmeier]

Just a question here: does the compressor REALY need to have oxidizer to work? I mean, it is just supercompressing the air for the engine- once the engine is running, the compression should be self-sustaining.

No, it shouldn't- this is part of the reason I wanted to fix it.

@Flashblade Why did OP put the resource production into a new plugin instead of just adding a converter module from stock into the config file?

[Flashblade]

@Flashblade Why did OP put the resource production into a new plugin instead of just adding a converter module from stock into the config file?

From the words of the OP himself:

The plugin is still abit incompleted. Ill upload the code on next update. I know there is resource generator module, but im working on this one so different resource generated or consumed can be dependent on speed or atmosphere level. It will also can give it sound. Its sort of like an enginemodule but abit simpler

[kiyoshisaotome]

Nice ship, nice use of GN-drives. How do you avoid the twin-drive sync error?

It just for look, I only use 2 GN-Drive

[Alewx]

Outstanding detail and model I just can't get enough of it, here something I built recently

http://i.imgur.com/mVPLhGB.pnghttp://i.imgur.com/JhRjCjl.pnghttp://i.imgur.com/5zPy2yx.jpghttp://i.imgur.com/dw4SfGc.pnghttp://i.imgur.com/Gso6b37.pnghttp://i.imgur.com/lcrjV23.pnghttp://i.imgur.com/NSgal1c.pnghttp://i.imgur.com/PS1IQQh.pnghttp://i.imgur.com/hkd7a4L.pngHad and accident on the last one lol crash into my large ship

Wow that is really a nice jet. impressive, but you didn't use the 1.49 parts .

[K.Yeon]

I want to semi-approximate a SABRE using the AIRE, and since the SABRE seems to not use oxidizer for the first engine mode I would like to remove the 'Oxidizer' component from 'SupercompressedAir'. What exactly should I edit to do this? I can't seem to find the ratio between these two in any of the config files...

Ninja EDIT: Note that I know that the RAPIER is supposed to fill this slot, but I find myself thinking of it more as a jet + rocket squished together rather than a single engine with two modes because of the massive ISP difference. Plus, this requires a compressor, just like the SABRE... I think that the RAPIER is well balanced with this AIRE since the weight increase of the compressor and massive power requirements is balanced by the higher thrust of both modes and the lower ISP of the jet mode.

Just a question here: does the compressor REALY need to have oxidizer to work? I mean, it is just supercompressing the air for the engine- once the engine is running, the compression should be self-sustaining.

The original intent was create an engine that can operate in the atmosphere without oxygen, but I think the compressor part was abit unnecessary aswell. Im changing the engine back to LFO + Air Engine so it will be much easier to use.

I am almost done with the next patch! Ill be uploading it to the mod sites this Sunday if all goes well! Heres some test shots!

[Railgunner2160]

Are those new gears?? Also nice job on the parts!

[Starwaster]

Wow. When I saw those screenshots, I thought images 2 & 3 were part of the same image... that you had Kerbin orbiting.... A MUCH LARGER KERBIN...

And I was just.... WOW MAN.

[Captain Sierra]

The original intent was create an engine that can operate in the atmosphere without oxygen, but I think the compressor part was abit unnecessary aswell. Im changing the engine back to LFO + Air Engine so it will be much easier to use.

Cant wait to play with it.

ALso, I'm certain you'll find a happy medium with the engine. If it is any help, I once had a concept about an engine that was air breathing, but not dependent on oxygenated atmosphere. I'll send you a PM later with some info about what it did and how that might be applicable to your stuff.

In other news that may or may not be applicable, I just changed my major from mechatronics engineering to computer software engineering (CSE1301C (C# coding) has shown me the light). With me learning C#, I'm taking a more serious look into KSP plugin modding. I'd guesstimate I'll know more or less what I'm doing with enough competency to potentially start modding KSP by the end of 2015.