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

[jestermaximus]

@JoE Smash Well now if I could only get IR Next and JKR to work properly, I could finish recreating V8Jester's awesome Protolift VTOL craft from the first post in this thread!

[Apaseall]

@JadeOfMaar Hi, I have a weird alignment problem. I will try to describe it.

[snip]

SPH. Drop in the cockpit. Slap normal cargo bay on. Flip the short cargo bay so that the doors open towards the ground not the sky. Add to end of first cargo bay. Add tri coupler to end of flipped cargo bay. all should be along mid-line from nose to tail. All good. Flip a bi coupler and stick on end of short cargo bay so that it is under the tri coupler. Add fuel tank on top of short cargo bay. Look closely.

Where you would now stick another bi coupler to the end of the fuel tank, so that it is on top of the tri coupler that is a miss alignment. The fuel tank sits a little further back from where the tri coupler joins the short cargo bay.

The reason why I mention this is thrust vector. The tri coupler thrusts along the mid line and hopefully through the CoM. If both bi couplers point of thrust were equal distance from CoM then the final vector would act through the CoM. As one bi coupler is slightly more towards the nose, the resultant vector is not along the mid line. To make matters worse, the effect is to lever the nose down.

I did get round this with adding another fuel tank, a larger one before the tri coupler. By the time extra small fuel tanks were added, the alignment for the bi couplers was fine.

Today I cut the tail off my plane and chopped a bit off before sticking it back on. Thus I discover my problem.

I rather wanted those bi coupler engines. Sure I can slap a reverse nose cone on, no one will really notice that they end in differing places. But...moar power!

i doubt there is anything to be done. I tried using a SAS module, but erm none are for H mounted. Even the KH is a bit too thick. Oh well.

 

Edited August 16, 2018 by Vanamonde

[Vanamonde]

@Apaseall, I'm sorry, but we had to remove the log file because posts that large cause problems for our forum. Please upload it to a file sharing site and use the link they provide in your posts here. 

[Apaseall]

Ah you came, you saw, you moderated, well I did wonder about the limit on the hidden post. I hope that the description is clear enough to follow. Thank you.

[Apaseall]

A new day a new find. This one is a small bug. I draw your attention to;         texture=ijk_side_texture, OPT_Legacy/Textures/ijk_side_texture
This can be found in GameData\OPT_Legacy\Parts\Avatar\OPT_a_6m_fuelTank.cfg

The texture ijk_side_texture.dds can also be found in GameData\OPT_Legacy\Parts\Avatar\

It is not located in either GameData\OPT_Legacy\Textures or GameData\OPT_Legacy\Textures_Legacy.

I stumbled on this, thought I would mention it, you can put it in your todo list for things erm todo before a new update etc.

In case you are wondering why I bothered with posting this, then this should answer your question:

Spoiler

180817T230425.787 [ERROR] [PartLoader.CompileModel] PartCompiler: Cannot replace texture 'ijk_side_texture' as cannot find texture 'OPT_Legacy/Textures/ijk_side_texture' to replace with
180817T230427.370 [ERROR] [PartLoader.CompileModel] PartCompiler: Cannot replace texture as texture replacement string is invalid. Syntax is 'origTextureName newTextureURL'
180817T230429.393 [EXCEPTION] [ModuleAnimateGeneric.AssumeDragCubePosition] IndexOutOfRangeException: Array index is out of range.
   at ModuleAnimateGeneric.AssumeDragCubePosition (System.String name)
   at DragCubeSystem+<RenderDragCubes>c__Iterator1.MoveNext ()
   at UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
   at UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
   at <RenderDragCubesCoroutine>c__Iterator0:MoveNext()
   at UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
   at <SetupDragCubeCoroutine>c__Iterator2:MoveNext()
   at UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
   at <CompileParts>c__Iterator1:MoveNext()
   at UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

 

Oh and this;     texture=j_texture_1, OPT\Parts\main\j_texture_1

in both GameData\OPT_Legacy\Parts\Juno\j_droneCoreOMS.cfg and GameData\OPT_Legacy\Parts\Juno\j_oms.cfg

That one is a little tricky to spot, but I think linux and copy paste are to blame, as it should read like this; texture=texture_main_1, OPT_Legacy/Textures/texture_main_1.

 

Another one, texture = texture_opt_prop, OPT_Legacy/Spaces/JSLIVA/texture_opt_prop

in both GameData\OPT_Legacy\Props\flight_control_wheel\flight_control_wheel.cfg and GameData\OPT_Legacy\Props\joystick\opt_joystick.cfg

The folder OPT_Legacy/Spaces/JSLIVA/texture_opt_prop does not exist, but texture_opt_prop.dds is located in both GameData\OPT_Legacy\Props\flight_control_wheel\ and GameData\OPT_Legacy\Props\joystick\

 

 

Edited August 18, 2018 by Apaseall

[Apaseall]

Thought I would drive by and toss this in your direction as I went past:

Spoiler

PartLoader: Compiling Part 'OPT_Legacy/Parts/Stail/b_docking_port/OPT_b_3m_dock/b_docking_port'
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Module ModuleDockingHatch threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at ConnectedLivingSpace.ModuleDockingHatch.IsRelatedDockingNode (.ModuleDockingNode dockNode) [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.CheckModuleDockingNode () [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.isInDockedState () [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0

and this:

Spoiler

PartLoader: Compiling Part 'OPT_Legacy/Parts/Stail/b_docking_port1/b_2m_dockingPort/b_docking_port1'
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Module ModuleDockingHatch threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at ConnectedLivingSpace.ModuleDockingHatch.IsRelatedDockingNode (.ModuleDockingNode dockNode) [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.CheckModuleDockingNode () [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.isInDockedState () [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0

 

[Apaseall]

Here is an interesting little issue. O problem with resource distribution.

Get a opt K cockpit. Add a couple of opt k fuel tanks. Add an opt k tail.

Set the tail to hold equipment [as you cannot store equipment in an omni storage configured part]. Get the other parts to be omni storage.

Make all parts share storage. Note. At this stage none of the omni storage parts have been told what they are meant to store.

Put a connector on the cockpit. Put a mass driver pipeline box on the ground. Link up. Try to assemble.

Not able to assemble as their seems to be no way of getting the equipment that is stored in the tail through the body to the nose and down the connector.

edit.

Huh ?

Well this is annoying now. So I pick up a spare connector and slat it onto the opt k tail cargo ramp, cos that is configured to store equipment via storage_template in opt_wbi I pressume.

I get two messages. First one tells me I need 20,000 of equipment. Only its written with out the comma, 20000.00. hmmf. Second message tells me that no active distributors have equipment to share etc.

Ok so I need a whole pile of equipment, fair enough. Can't use fuel tanks to store equipment thanks to opt_wbi, can't use omni storage to use the fuel tanks to store equipment.

Looks like opt_wbi needs looking at again now that omni storage is an option, as I do understand why fuel tanks cannot be repurposed the same as cargo bays, but with omni storage they can now. See how the nice limitations are broke with the option to use omni?

As for why omi storage will not allow me to store equipment I fail to find where in the files this restriction takes place, it does not appear to be a blacklisted item.

Right back to the darn sph to refit stuff. Good job I have a bed setup in the sph...

 

Edited August 25, 2018 by Apaseall

[Apaseall]

Ok back on safer ground now.

@JadeOfMaar I have a suggestion for modifications to the OPT_WBI.cfg

For example we currently have:

Spoiler

@PART[k_3m_fuselage|kh_3m_fuselage|k_3m_cargo|kh_3m_cargo|kh_7m_cargoTail_variant]:NEEDS[Pathfinder]
{
    !RESOURCE[ElectricCharge] {}
    !RESOURCE[LiquidFuel] {}
    !RESOURCE[Oxidizer] {}
    !RESOURCE[MonoPropellant] {}
    !MODULE[FSfuelSwitch] {}
    !MODULE[InterstellarFuelSwitch] {}
    
    MODULE:NEEDS[KIS]
    {
        name = ModuleKISInventory
        maxVolume = 100
        externalAccess = true
        internalAccess = true
        slotsX = 5
        slotsY = 4
        slotSize = 50
        itemIconResolution = 128
        selfIconResolution = 128
        openSndPath = KIS/Sounds/containerOpen
        closeSndPath = KIS/Sounds/containerClose
        defaultMoveSndPath = KIS/Sounds/itemMove
    }
    
    MODULE
    {
        name = WBIMultipurposeStorage
        enableLogging = True
        isInflatable = False
        fieldReconfigurable = True
        confirmResourceSwitch = True
        showGUI = True
        
        // Tanks
        templateNodes = STORAGE_TEMPLATE;SPICE_TEMPLATE
        defaultTemplate = LFO
        capacityFactor = 0.6
        
        // If KIS mode
        baseStorage = 0.001
        maxStorage = 10000
    }

    MODULE
    {
        name = WBIResourceDistributor
        resourceBlacklist = ReplacementParts
    }
}

I draw your attention to two items.

1 maxVolume = 100 as a key value pair passed to the module ModuleKISInventory and

2 maxStorage = 10000 passed to WBIMultipurposeStorage.

For comparision I will use a Buckboard6000.

First of all, you will see that the values in 1 and 2 are not the same.

What can we do in game with this part at the moment?
Well we can use manage operation to either configure the fuel tank to hold stuff ie LFO etc or to hold items ie be a KIS container.
With either configuration we have access to a KIS inventory.
If configured to hold stuff ie LFO, then the KIS inventory is able to hold 0.001 L, which appears to be defined as the baseStorage.
If configured to hold items, that is be only a KIS container, we are able to store 10000 L, which is the maxStorage.

This all seems reasonable, we can hold a tiny bit of stuff if we fill the tanks with fuel or we can hold lots of stuff if we use the space for items.

Here is the hitch though. Not matter how we configure the fuel tank, we are limited to an array of 5 by 4 into which we can actually place items.
Now the Buckboard6000 only holds 6000 L and has 24 slots arranged as 6 by 4.
This means that despite having access to almost twice as much storage space as the Buckboard6000 we have lost 4 slots into which we can place items.

Taking a quick peek around cfg's I do not see the solution I was going to suggest, which is to pass slotsX = 10 and slotsY = 4 to WBIMultipurposeStorage.
Thus either those fields are not present in WBIMultipurposeStorage or if they are, they are not referenced in the cfg's I looked in.
If those fields are available, then I suggest OPT_WBI is updated to pass a more appropriate slot array. My thought is that there are 4 Y slots per 1000 L and 1 X slot.
If those fields are not available in WBIMultipurposeStorage then I suggest that you merely change the slot array passed to ModuleKISInventory.
Of course you may chose to do the latter anyway, but it would seem then odd to have 40 slots that can only hold 0.001 L if we use the fuel tank to store stuff like LFO.

You see I ran across this, and thought I would discuss, suggest changes.
As a slight side note, as mentioned previously I dislike using :FINAL. Other than using some clever file naming, can you suggest a solution in terms of :AFTER[] such that both OPT plus WBI have done their stuff and I can then write MM patches in safety?

edit.

Whilst we are talking about slot arrays in OPT_WBI, perhaps you could take a look at the other ones passed and adjust them to conform to 4 Y slots per 1000 L and 1 X slot?

Edited August 27, 2018 by Apaseall

[Apaseall]

I wonder if :AFTER[WildBlueTools] would suffice?

[Starwaster]

5 hours ago, Apaseall said:

I wonder if :AFTER[WildBlueTools] would suffice?

Only if the relevant configs are using :FOR[WildBlueTools], in which case: AFTER should work just fine.

If not, consider the use of :FOR[zzzOPT]

 

[Apaseall]

14 minutes ago, Starwaster said:

Only if the relevant configs are using :FOR[WildBlueTools], in which case: AFTER should work just fine.

If not, consider the use of :FOR[zzzOPT]

 

The issue I am grappling with is that I am wanting to make changes to patches of a mod. The patches do not use :FOR which is fine. Those patches I am confident work fine. I wish to make changes for testing or personal reasons. The trick is to make the changes after the patches make changes to the original mod. Hence my wondering how to avoid using :FINAL. I would like to avoid using :FOR for my personal patches, if possible. So far I did use it once, but later worked out a way to still make the patch without the :FOR. Anyway this is just a pondering, not desperate.

[JadeOfMaar]

@Apaseall The answer is simple: :AFTER[OPT_Reconfig]. A patch using AFTER will plainly run after the specific mod has run, and only if that mod is present.

Pardon me for being scarce. I've been burning out, and I still am, from modding. I've had more troubling things to deal with in my own install, and these making KSP unplayable has been turning me off. I'll give more of an answer a bit later.

[Apaseall]

37 minutes ago, JadeOfMaar said:

@Apaseall The answer is simple: :AFTER[OPT_Reconfig]. A patch using AFTER will plainly run after the specific mod has run, and only if that mod is present.

Pardon me for being scarce. I've been burning out, and I still am, from modding. I've had more troubling things to deal with in my own install, and these making KSP unplayable has been turning me off. I'll give more of an answer a bit later.

I suspected that you were busy. I mentioned recently that I was away from KSP for a while. I will be away from it again later this week, probably for a month. I try to point out or discuss things when I stumble over them. By now I am quite aware that folks cannot work to my time scales. The best I can do is try to delve into something, see if I can take a guess at what is going on, provide logs and cross my fingers that what I write helps with my issue by easing those trying also to solve them. My thought is that if I find it an issue then probably others do to. With large projects like WBI or OPT my aim is to test and communicate with the target of improving or enabling others to enjoy KSP.

Or I waffle on and on in my own little world stamping my foot until life is sweet for me again. Who knows?

[Jesusthebird]

Just poppin in for a quick question. Or two. Are there plans to fix the stail class dockingport node?? After i attach it i cannot add anything after it(im sure its been mentioned somewhere in the 100+ pages lol). The node is there? Just...doesn't seem to do anything. Also...not a big thing or anything..but i always thought a stail to J class adapter would be ultra legit. I was thinking about taking a crack at it to learn modelling. But dont want to step on any licensing toes.

 

Also...ive noticed when building with opt parts...spawning at the ksc runway...puts me about 300m in midair. But not sure if its the mod doing it or not..but i havnt noticed it when i build without opt parts..anyone else have this issue too?

Cheers. This is still the active opt support thread correct?

[JadeOfMaar]

6 minutes ago, Jesusthebird said:

This is still the active opt support thread correct?

Yep.

I don't use Stail class enough to have noticed that. Maybe there's a bad attachment rule on it.

There's no licensing issue. OPT is Sharealike, and OPT Legacy (unlike Main) has always been open for folks to donate parts into. Though there are plans concerning fully adopting OPT.

Install World Stabilizer. The spawn bug is caused by a collider issue (which is now a huge deal) in the J docking ports, Humpback cargo bay, and possibly other animated parts.

[Jesusthebird]

51 minutes ago, JadeOfMaar said:

Yep.

I don't use Stail class enough to have noticed that. Maybe there's a bad attachment rule on it.

There's no licensing issue. OPT is Sharealike, and OPT Legacy (unlike Main) has always been open for folks to donate parts into. Though there are plans concerning fully adopting OPT.

Install World Stabilizer. The spawn bug is caused by a collider issue (which is now a huge deal) in the J docking ports, Humpback cargo bay, and possibly other animated parts.

Ohh awesome. I thought the world stabilizer mod became obsolete when squad patched the spawning issue with the wheels. I was curious why it got updated lol. I'll pan through some cfgs later to see if i can find an error with the attachment rules, not at home currently.

Thanks! I hope i can contribute. I love opt so much! Its my favorite partpack by far. And after seeing your sabre mod. I cant think of having one without the other

Edited September 6, 2018 by Jesusthebird

[JadeOfMaar]

@Jesusthebird Another thing, Tweakable Everything (if you have that) has been known to mess with attachments in OPT parts. I'm really curious now. What makes my SABR3 a great companion to OPT? I've seen a hint of it myself but I'd like to know what the other players think.

[Jesusthebird]

3 minutes ago, JadeOfMaar said:

@Jesusthebird Another thing, Tweakable Everything (if you have that) has been known to mess with attachments in OPT parts. I'm really curious now. What makes my SABR3 a great companion to OPT? I've seen a hint of it myself but I'd like to know what the other players think.

I do have tweakable everything too...hmm.

 

Aesthetically...i think they work great together(i also made a TU cfg for em ). But mainly, i find it difficult to make opt spaceplanes functional given how heavy the parts are(they contain ALOT of fuel capacity) so since youre sab3r engines are high thrust/efficiency. It makes it a bit easier on the design side for me at least. Before the reconfig patch..i always had to used the crazy op starwaster engine, or the other mk2 high atmo engine(the name i cant remember offhand) for my takeoff atmo flight stages. It was a godsend for me because im not great at designing efficient planes. I try to make them lifelike to an extent..and for spaceplanes that can go into orbit..that usually ends up in failure for me as i was never a fan of slapping 6-10 rapiers on em lol

[Jesusthebird]

On 8/14/2018 at 9:18 PM, jestermaximus said:

@JoE Smash Well now if I could only get IR Next and JKR to work properly, I could finish recreating V8Jester's awesome Protolift VTOL craft from the first post in this thread!

JKR? Typo for kerbal joint reinforcement mod? I beleive someone updated it for 1.4+...ill edit this post if i can find the link. IR...i download the core/legacy parts from ckan and overwrite with the re work pack. A simple google of "infernal robotics rework" should point you in the right direction for it. 

[jestermaximus]

52 minutes ago, Jesusthebird said:

JKR? Typo for kerbal joint reinforcement mod? I beleive someone updated it for 1.4+...ill edit this post if i can find the link. IR...i download the core/legacy parts from ckan and overwrite with the re work pack. A simple google of "infernal robotics rework" should point you in the right direction for it. 

Thanks for the pointer. I'd installed IR Next and LinuxGuruGamer's rework of KJR (for 1.4.x I believe), but when I tried to make simple rotating engine nacelles (simple in that there were no nested IR joints, just engines attached to a rotatatron), the whole build would vibrate until it exploded. I still assume it had something to do with KJR not yet being updated to be IR Next compatible. I was going to wait until KJR or IR Next was updated to be compatible. Would love to know if any of my assumptions are now false!

[Jesusthebird]

1 hour ago, jestermaximus said:

Thanks for the pointer. I'd installed IR Next and LinuxGuruGamer's rework of KJR (for 1.4.x I believe), but when I tried to make simple rotating engine nacelles (simple in that there were no nested IR joints, just engines attached to a rotatatron), the whole build would vibrate until it exploded. I still assume it had something to do with KJR not yet being updated to be IR Next compatible. I was going to wait until KJR or IR Next was updated to be compatible. Would love to know if any of my assumptions are now false!

I bet you would have better luck asking over in those respective threads(just so we dont get off topic here). Unfortunately i cant answer that fully..as even tho i have both mods installed...i dont use IR much..what i can say..is that the smaller the attach node the easier it can brake/vibrate with large amount of weight attached to it. Seems counter productive tho considering that KJRs purpose was made for just that reason. Sorry i cant be of more help with your situation 

[CaveJohnson376]

@K.Yeon When OPT will come for 1.4.x?

[NHunter]

1 hour ago, CaveJohnson376 said:

When OPT will come for 1.4.x? 

It works just fine in 1.4.* as far as I can tell need. There might be some issues, but I don't routinely run into them. And I use OPT spaceplanes for a good half of my kerbal'ed mission.

Edited September 7, 2018 by NHunter

[JadeOfMaar]

On 8/27/2018 at 7:00 AM, Apaseall said:

I draw your attention to two items.

1 maxVolume = 100 as a key value pair passed to the module ModuleKISInventory and

2 maxStorage = 10000 passed to WBIMultipurposeStorage.

For comparision I will use a Buckboard6000.

First of all, you will see that the values in 1 and 2 are not the same.

What can we do in game with this part at the moment?
Well we can use manage operation to either configure the fuel tank to hold stuff ie LFO etc or to hold items ie be a KIS container.
With either configuration we have access to a KIS inventory.
If configured to hold stuff ie LFO, then the KIS inventory is able to hold 0.001 L, which appears to be defined as the baseStorage.
If configured to hold items, that is be only a KIS container, we are able to store 10000 L, which is the maxStorage.

This all seems reasonable, we can hold a tiny bit of stuff if we fill the tanks with fuel or we can hold lots of stuff if we use the space for items.

Here is the hitch though. Not matter how we configure the fuel tank, we are limited to an array of 5 by 4 into which we can actually place items.
Now the Buckboard6000 only holds 6000 L and has 24 slots arranged as 6 by 4.
This means that despite having access to almost twice as much storage space as the Buckboard6000 we have lost 4 slots into which we can place items.

Taking a quick peek around cfg's I do not see the solution I was going to suggest, which is to pass slotsX = 10 and slotsY = 4 to WBIMultipurposeStorage.
Thus either those fields are not present in WBIMultipurposeStorage or if they are, they are not referenced in the cfg's I looked in.
If those fields are available, then I suggest OPT_WBI is updated to pass a more appropriate slot array. My thought is that there are 4 Y slots per 1000 L and 1 X slot.
If those fields are not available in WBIMultipurposeStorage then I suggest that you merely change the slot array passed to ModuleKISInventory.
Of course you may chose to do the latter anyway, but it would seem then odd to have 40 slots that can only hold 0.001 L if we use the fuel tank to store stuff like LFO.

The idea for the weak maxVolume value is so that while KIS as a feature will always be available (I assume it can't properly be enabled/disabled on demand for a (usually crewed) part that has the module), it's not meant (in mine and Angel-125's opinion) to be usable while the given part is set to hold other things such as fuel. This is specially true for fuselage parts but exceptions may be made for cockpits and cabins.

Re: the number of slots you want for fuselage parts, I think you made a very funky mis-statement of what you're hoping for. If I provide that kind of Y slots, the KIS inventory window would be disturbingly tall, and one X would make it uncomfortably narrow. In accordance with your request (roughly), I've simply buffed the numbers of inventory slots. 20 ~ 48 slots (8 ~ 12 wide on X by 4 tall on Y) will be provided for inventory in the large fuselage parts that allow KIS.

[Apaseall]

On 9/12/2018 at 10:14 PM, JadeOfMaar said:

The idea for the weak maxVolume value is so that while KIS as a feature will always be available (I assume it can't properly be enabled/disabled on demand for a (usually crewed) part that has the module), it's not meant (in mine and Angel-125's opinion) to be usable while the given part is set to hold other things such as fuel. This is specially true for fuselage parts but exceptions may be made for cockpits and cabins.

Re: the number of slots you want for fuselage parts, I think you made a very funky mis-statement of what you're hoping for. If I provide that kind of Y slots, the KIS inventory window would be disturbingly tall, and one X would make it uncomfortably narrow. In accordance with your request (roughly), I've simply buffed the numbers of inventory slots. 20 ~ 48 slots (8 ~ 12 wide on X by 4 tall on Y) will be provided for inventory in the large fuselage parts that allow KIS.

Hi, quick flyby, maybe I got my x n y crossed, but I think my point was basically if there was a way of changing the number of slots via mm.cfg file code such that when it is holding goodies like fuel, the slots would be less than if it was just one giant sack for santa. Thanks for taking a look at this.