[1.1] SXT - Lack's Stock Extension [SXT-25-10APR16] - Basic 1.1 compatibilty

[stali79]

@Lack I was wondering, I did notice that in your configs, The Bonny for an example, your use of commas in the texture line. What I am curious about is that the 2 .PNG files it references are 1kb each. Should they be this small or would they be unneccesary? I know I somehow managed to get the wings to gain textures at one point by deleting the wings.png file in their folder. I did just do a test also by renaming your folder to 1SXT and used notepad++ to update the folder references in all your cfg's in the hopes it may spoof KSP to load your mod BEFORE Squad gets loaded but alas it didn't work.

"MODEL{

model = 1SXT/Parts/Command/Bonny/model

texture = model000 , Squad/Parts/Command/mk1InlineCockpit/CockpitDiffuse

texture = model001_NRM , Squad/Parts/Command/mk1InlineCockpit/CockpitNRM2

scale = 1.055 , 1.055 , 1.055"

[Lack]

@Lack I was wondering, I did notice that in your configs, The Bonny for an example, your use of commas in the texture line. What I am curious about is that the 2 .PNG files it references are 1kb each. Should they be this small or would they be unneccesary? I know I somehow managed to get the wings to gain textures at one point by deleting the wings.png file in their folder. I did just do a test also by renaming your folder to 1SXT and used notepad++ to update the folder references in all your cfg's in the hopes it may spoof KSP to load your mod BEFORE Squad gets loaded but alas it didn't work.

"MODEL{

model = 1SXT/Parts/Command/Bonny/model

texture = model000 , Squad/Parts/Command/mk1InlineCockpit/CockpitDiffuse

texture = model001_NRM , Squad/Parts/Command/mk1InlineCockpit/CockpitNRM2

scale = 1.055 , 1.055 , 1.055"

That's the 'place holder' (on my end at least) they're necessary to allow the game to swap to the Squad textures (if it works for you without, then feel free to delete away). They can even be a text file renamed as 'model000.png' or mbm/tga/etc (although then I get bother from people running automated converters for things like .dds). They're 1x1 generally to keep the memory footprint low (although I've been told that they get scaled to 64x64 anyway by the part loader, hence I have things grouped into 'part families' like the Osaul or ServiceMod1 rather than each in a separate folder).

The folder will need to load after Squad, that's the reason it's got a stupid acronym and is called SXT.

I've wasted a lot of time with different variations of this, but it doesn't seem to affect what ATM does.

[stali79]

I can understand your frustrations. If its bad for us fans of your work then its worse for you the developer!

[Lack]

I can understand your frustrations. If its bad for us fans of your work then its worse for you the developer!

Yeah, it can be a bit frustrating. But then it's not really different from trying to optimise protocols at work, you can hammer away at something for ages, but try enough things and you can usually get it to work. Then it's worth it.

@The Mechanic,

That plane looks great! Don't be sorry about posting screenshots, I love seeing them so the more the merrier.

[The Mechanic]

That plane looks great! Don't be sorry about posting screenshots, I love seeing them so the more the merrier.

Thanks. I included an upside-down cargo bay in the middle to leave space for a VTOL mode. Not perfect, but works nicely even though I need some flight assistance (Vertical Velocity control and Smart A.S.S., but I think it would also work with SAS only). Also added some Vernor engines and air-brakes.

Javascript is disabled. View full album

EDIT: This one actually flies with FAR. However, I immediately crashed while turning because of a large-scale stall. Pretty explosions. Rockets are so much easier...

Edited February 18, 2015 by The Mechanic

[RobotsAndSpaceships]

It's next in line, but it'll take time. I'm going to have to re-do all the buildings, the way the current texture map is set up isn't working and just swells the poly-count un-necessarily making it slow to run in Blender and very frustrating to work with, the camera tools don't help either (I'm going to have to have one colour tile in each texture, so the grey and then a brown one, then scale the UV map accordingly. Then a separate one for all the details like windows).

Sounds good, take your time with it, it's an excellent mod, and I would love to see the screenshots you posted of the revamp make it in game.

[boontze]

is it intentional that the prop engines are reeeeeeally low thust and so is one of the liquid fuel engines

[Lack]

Thanks. I included an upside-down cargo bay in the middle to leave space for a VTOL mode. Not perfect, but works nicely even though I need some flight assistance (Vertical Velocity control and Smart A.S.S., but I think it would also work with SAS only). Also added some Vernor engines and air-brakes.

EDIT: This one actually flies with FAR. However, I immediately crashed while turning because of a large-scale stall. Pretty explosions. Rockets are so much easier...

Nice, how long can it sustain hovering for? I'm guessing it must burn through LFO fairly quickly.

@RobotsAndSpaceships,

I'm starting to realise it's going be a whole lot of work, I wouldn't expect anything too extensive soon. (Probably mainly small additions to start with).

@boontze,

Their power is intentional (and should be roughly right for their horsepower going by my slightly hammy calculations, which made gross assumptions for things like pitch, etc). Although I've spotted that I need to update the FAR-thrust corrector MM patch with the Jumo F and Merlin 66.

Which LFO engine do you mean? There are rather a lot.

[The Mechanic]

Nice, how long can it sustain hovering for? I'm guessing it must burn through LFO fairly quickly.

Your guess is right. I don't have the exact numbers in my head, but it indeed burns through LFO very fast so it is only practical for taking off and hovering a bit. It also (obviously) greatly reduces the range of the plane. Awesome, but impractical. Maybe I'm going to make a version using jets.

[Lack]

Your guess is right. I don't have the exact numbers in my head, but it indeed burns through LFO very fast so it is only practical for taking off and hovering a bit. It also (obviously) greatly reduces the range of the plane. Awesome, but impractical. Maybe I'm going to make a version using jets.

I have a feeling I'd use it if I was coming in too hot for a landing, then unbalance it and nose-dive into the runway (since this is what I've done multiple times with vtol capable planes).

Figured out the scaling problems so can place objects properly now. Starting small and simple.

[The Mechanic]

Got around making a version with jets. I still need to find a good replacement for the vernors as stabilizers during hovering, they just need to much LFO.

Javascript is disabled. View full album

I also posted some failures of previous flight tests with the jet over at You Will Not Go To Space Today.

I have a feeling I'd use it if I was coming in too hot for a landing, then unbalance it and nose-dive into the runway (since this is what I've done multiple times with vtol capable planes).

That is why I try not to fly to fast during hover and have yet to try transitioning from normal flight to hover. I guess unbalancing and crashing is exactly what would happen.

[stali79]

@ The Mechanic you may want to give this mod a look at to assist in your stabilizing during vtol.

https://kerbalstuff.com/mod/510/Throttle%20Controlled%20Avionics%20-%20Continued

[The Mechanic]

@stali79 Thanks. I'll give this one a try. I think I have seen it before (In the Daily Kerbal?) but didn't use it yet. From the description it sounds like what I need.

[stali79]

@The Mechanic - its really useful. No need to have your engines dead on the COM, place 3 engines like you would place landing gear and that mod takes care of the rest. With one of my planes I have 2 radial rapiers above the wings and another 2 below, with tca enabled it drops thrust on the upper engines and helps with pitching up and the reverse for pitching down. It also auto tunes per craft too which is helpful. You can also mismatch your engines also. If a 50kn engine is all you need to lift the nose and say you need 200kn to lift the tail then ALL thrust is balanced automatically to maintain stability. Just make sure you turn SAS on and then TCA on and you are good to go.

[The Mechanic]

@stali79 Unfortunately it doesn't really like jet engines for hovering because of their slow reaction time. I also tried it with the old version of that plane using all those little radial rockets and it somewhat worked, although having all those engines concentrated is a bit problematic for stabilization. Needs some design work. But it is really nice plugin.

[stali79]

Its a shame it didnt quite work how you needed it to.

[AlonzoTG]

... is up with the tszar tanks? First the scaling was all wrong.... (I'm seeing the number x.888888889 lots of times when I fix it for my own install). After that, it's pretty er, majorly, fugly right now... What gives?

Here's what it used to look like, shiny, with an elegant black/white/orange coloring scheme...

Now it's just bleh. =((((

[Kerbas_ad_astra]

Hey Lack, I've got a patch for you! I've been a little bugged by the fact that satellite contracts which request "a mystery goo unit" are keyed to only accept the stock goo containers and not equivalent goo experiments (e.g. from DMagic Orbital Science and this mod -- the contracts are keyed to specific parts, not the experiments themselves), so here's a Module Manager patch that will add SXT's inline goo container to the list of parts that satisfy satellite mystery goo unit contracts (you can put it in its own standalone file, or add it to the goo cannister's config file):

@Contracts:FOR[SXT]
{
    @Satellite
    {
        @PART_REQUEST:HAS[#Part[GooExperiment]]
        {
            Part = SXTProbeGooo
        }
    }
}

(I haven't actually gotten a goo contract in my test install yet, so I don't personally know that it works, but I see someone else has confirmed that a similar set of patches for DMagic Orbital Science works, so I feel mostly okay with sharing this patch with you.)

[eddiew]

Hey Lack,

I'm having issues with the latest SXT giving me a crash on the base screens - the old favourite where it refuses to switch back to KSC and you get two sets of menu bars hanging around. If I kill the game at this point, the last entry in the output log is as follows:

NullReferenceException: Object reference not set to an instance of an object

at Contracts.Contract.Save (.ConfigNode node) [0x00000] in <filename unknown>:0

at Contracts.ContractSystem.OnSave (.ConfigNode gameNode) [0x00000] in <filename unknown>:0

at ScenarioModule.Save (.ConfigNode node) [0x00000] in <filename unknown>:0

at ProtoScenarioModule..ctor (.ScenarioModule module) [0x00000] in <filename unknown>:0

at ScenarioRunner.GetUpdatedProtoModules () [0x00000] in <filename unknown>:0

at Game.Updated () [0x00000] in <filename unknown>:0

at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode) [0x00000] in <filename unknown>:0

at MCSceneSpawner.onMCDespawn () [0x00000] in <filename unknown>:0

at EventVoid.Fire () [0x00000] in <filename unknown>:0

at MCDespawner.BtnExit (.POINTER_INFO& ptr) [0x00000] in <filename unknown>:0

at (wrapper delegate-invoke) EZInputDelegate:invoke_void__this___POINTER_INFO& (POINTER_INFO&)

at UIButton.OnInput (.POINTER_INFO& ptr) [0x00000] in <filename unknown>:0

at AutoSpriteControlBase.OnInput (POINTER_INFO ptr) [0x00000] in <filename unknown>:0

at UIManager.DispatchHelper (.POINTER_INFO& curPtr, Int32 camIndex) [0x00000] in <filename unknown>:0

at UIManager.DispatchInput () [0x00000] in <filename unknown>:0

at UIManager.Update () [0x00000] in <filename unknown>:0

at UIManager.DidAnyPointerHitUI () [0x00000] in <filename unknown>:0

at SpaceCenterCamera2.InputCamera () [0x00000] in <filename unknown>:0

at SpaceCenterCamera2.Update () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

Problem goes away if I revert to the previous version of SXT. Any thoughts? I was wondering if I had an old completed contract to test a part that you've removed or renamed?

Cheers!

[Lack]

Hey Lack,

I'm having issues with the latest SXT giving me a crash on the base screens - the old favourite where it refuses to switch back to KSC and you get two sets of menu bars hanging around. If I kill the game at this point, the last entry in the output log is as follows:

Problem goes away if I revert to the previous version of SXT. Any thoughts? I was wondering if I had an old completed contract to test a part that you've removed or renamed?

Cheers!

Hmm, I'm not sure. I only removed a few parts, but they'd been disabled for quite a few versions (and I think you have to add something in the contract for it to be contract-able). I did change the name of Korolov Design Bureau to Kerbolyov Design Bureau, I wonder if that could be it. Try replacing the Agencies folder from 20 with the one from 19.

@ Kerbas_ad_astra,

Thanks, it'll be in 20.5 (once I've finished adding the new part descriptions from SpaceHungryMan).

[eddiew]

Hmm, I'm not sure. I only removed a few parts, but they'd been disabled for quite a few versions (and I think you have to add something in the contract for it to be contract-able). I did change the name of Korolov Design Bureau to Kerbolyov Design Bureau, I wonder if that could be it. Try replacing the Agencies folder from 20 with the one from 19.

That was it! I copied Korolov into the config for 0.20 so that it now has 3 agencies, and now the game is happy

[robson1000]

I have a few things to report:

1. Kn-225 'Oscal Payload' is sinking through the ground (pictures below).

2. Mk1-2 SST 'Entente' and MK3 'Marble-8' kerbal going in to EVA is rotate in 180 degrees ((pictures below).

3. Ke-111 'kondor', Kossak, MK.P-YavkaRadial cockpit and Kn-225 'Oscal Payload, those cockpits are adding capsule icon to staging, this is not that big problen, but I want you to know.

I tested this on stock game, with only your mod installed.

Edited March 3, 2015 by robson1000

[Lack]

I have a few things to report:

1. Kn-225 'Oscal Payload' is sinking through the ground (pictures below).

2. Mk1-2 SST 'Entente' and MK3 'Marble-8' kerbal going in to EVA is rotate in 180 degrees ((pictures below).

3. Ke-111 'kondor', Kossak, MK.P-YavkaRadial cockpit and Kn-225 'Oscal Payload, those cockpits are adding capsule icon to staging, this is not that big problen, but I want you to know.

I tested this on stock game, with only your mod installed.

Thanks, the Osaul falling through the ground is since I've neglected to add a few convex colliders in, an easy fix.

2. Yeah, the transforms need fixing for those (serves me right for relying on the blender import from the Mk3ckpt, must have been a parent transform that applied some rotation).

3. I think that's a relic of the ModuleScienceExperiment, I'd just copied it over from one of Squad's parts and they later changed it, although looking at the cfgs now, I'm not sure which line governs it.

[BudgetHedgehog]

3. I think that's a relic of the ModuleScienceExperiment, I'd just copied it over from one of Squad's parts and they later changed it, although looking at the cfgs now, I'm not sure which line governs it.

stagingIcon = COMMAND_POD is the line you're after, underneath the "// --- standard part parameters ---". Remove that to remove the capsule from staging (not that it does anything there anyway).

[The Mechanic]

Is the OX-HEX supposed to be so easily breakable in the atmosphere? Maybe I'm wrong here but I assumed that it was supposed to behave like the OX-STAT panel because it is always deployed.

The OX-HEX also has the "Panel Strenght" line in the VAB/SPH which the OX-STAT does not have so KSP treats it like a normal, deployable panel.

I took a look at the part.cfg of both parts and found a slight difference in the "ModuleDeployableSolarPanel" (which strangely is also used by the OX-STAT).

Here is the "ModuleDeployableSolarPanel" in the part.cfg of the OX-HEX Panel.

MODULE
{
    name = ModuleDeployableSolarPanel
    sunTracking = false
    raycastTransformName = Cube_001
    pivotName = Cube_001
    animationName = solarpanels
    resourceName = ElectricCharge
    chargeRate = 1.5
    powerCurve
     {
        key = 206000000000 0 0 0
        key = 13599840256 1 0 0
        key = 68773560320 0.5 0 0
        key = 0 10 0 0
     }
}

This is the "ModuleDeployableSolarPanel" in the part.cfg of the OX-STAT Panel.

MODULE
{
    name = ModuleDeployableSolarPanel
    sunTracking = false
    raycastTransformName = suncatcher
    pivotName = suncatcher
   [COLOR=#ff0000][B] isBreakable = false[/B][/COLOR]
    resourceName = ElectricCharge
    chargeRate = 0.75
    powerCurve
     {
        key = 206000000000 0 0 0
        key = 13599840256 1 0 0
        key = 68773560320 0.5 0 0
        key = 0 10 0 0
     }
}

I added the line "isBreakable = false" to the part.cfg of the OX-HEX. It stopped breaking in flight and the "Panel Strength" line in the VAB/SPH is gone, too. So it behaves like a bigger, hexagonal OX-STAT now.