AlphaMensae

@NecroBones, ok, I've created a Dropbox page and put the two log files in it: https://www.dropbox.com/s/sh7mtpxjszh552b/KSP.log?dl=0 https://www.dropbox.com/s/ntnk1evtvb5gnqa/output_log.txt?dl=0

Here's a VOD of EJ_SA testing out the MuddrTech version of auto-strutting, including how it still works by redocking something with a wheel to another craft. He repeats the test a few minutes after this one ends. If you read the chat (and also @Claw, @NathanKell, @Arsonide), I'm AlphaMensae on Twitch. I call this "KJR-Lite" since when it was brought up on a Squadcast, @Mu said that @ferram4would understand what was involved in implementing the auto-strutting since he had to deal with similiar issues with KJR. So while it's not full-up KJR, it does appear to use the same basic principle. KJR affects everything on a craft, while auto-strutting can be targetted to affect only certain parts, e.g. putting a gear (or other part in 1.2) at the end of a string of lighter parts with a more massive part at the other end makes that whole particular section of parts strong.

The wheel auto-strutting was put into 1.1.2 as another workaround for the issues with the gear/wheels/klegs. As intended, wheels will invisibly auto-strut to the most massive part on a plane, I guess to help overcome the weakness and over-stressing problems. Well, others then realized (I believe it was Muddr, a chat moderator for Das Valdez, who was first, hence the name "MuddrTech") that this capability could be used to reinforce otherwise wobbly craft, be they planes, rockets or even things like space stations (or launch pads and towers in the cae of EJ_SA) by the careful placement of landing gear at the proper spots. This technique became very popular (Das and EJ are the biggest KSP streamers on Twitch), enough so that @NathanKell actually looked to see if it could be kept in 1.2 (after @Arsonide earlier said it would be removed), and it turns out that he did. Expanding the auto-strutting to all other parts was unexpected, but I think it was done because putting landing gear on a rocket does look quite silly, so now existing parts on a rocket that won't look out-of-place can be used for the auto-strutting. As was said earlier, this will be off by default and will have to activated by turning on the Advanced Tweakables option, so those who don't know about this will be none the wiser...but those who DO know about MuddrTech will get to keep a very valuable tool.

Here's an example of "MuddrTech": Place a full orange tank (or any large fuel tank). Now string a bunch of girder segments to one end of it. Now put a landing gear (or a wheel, I think) on the end of the girder string, it can be left closed. The gear will auto-strut itself to the orange tank through the girders, resulting in a very rigid construct. This even works with components that get undocked and then redocked to something with a more massive part, the auto-struts will reconnect. When this capability was realized, it became quite popular with EJ_SA and Das Valdez. Now, putting landing gear on your rocket or station or whatever is rather silly...which is why @NathanKell expanded it to all other parts, so you can use something that won't look so out of place.

MuddrTech™ lives, courtesy of NathanKell! If you watch EJ_SA or Das Valdez on Twitch, "MuddrTech" is the nickname given to using the wheel auto-strutting to essentially provide KJR-lite type joint reinforcement otherwise wobbly constructs. On a Squadcast, @Arsonide suggested it would go away in 1.2 along with the other wheel workarounds, then more recently @NathanKell hinted that may not be the case, that it might be saved. Well, it survives...and is EXPANDED as well to other parts?! I mean, isn't this basically putting a form of KJR into stock? Also, great pics of the telemetry system and the new debug screen

@NecroBones, deleting the MM cache didn't do anything; in fact, I've never noticed it loading anything from the cache, all the patches go through the full loading sequence.

Yes, the stock tree IS a mess. See this tech tree by @pap1723 to see a tech tree that does make sense...that is how the stock tree should have been done in the first place...but wait, "gameplay balancing".... I don't use the stock multi-couplers and stack adapters either. At a minimum, I use the cubic struts or radial attachment points to attach multiple engines to a fuel tank (like, you know, in reality), but I usually use the thrust plates from SpaceY more often now.

I didn't think this mattered, but I'm using v1.7 of FTP, the last one you released before KSP 1.1 came out (for reasons I'm using 1.0.5). Using the mesh-switching patch above, I think what's happening is all the textures are trying to be displayed at once, resulting in the Z-fighting type glitch. The checkered mesh seems most stable, and if I look carefully I think I can see one or two of the others. I must be missing something, maybe I don't need the "ZFuelTanksPlus"; it was done for CCC, so I figured it would be needed for FTP as well.

@NecroBones, I need some help again, this time it's some of the adapter tanks in FTP that I want to clone and change into some more of my simple command pods (they sorta have the capsule shape already ). The first one I've tried is the Rockomax X200-08-FTP Adapter Tank, followed the CCC+FTP template I used for the FL-T100 conversion, but the the mesh switching isn't working, I get the usual Z-fighting type glitchiness. The part MM patch begins with "+PART[TPtank2m1mA]:AFTER[FuelTanksPlus]:BEFORE[ColorCodedCans]", the rest is standard MM stuff. And yes, I do need to add the "AFTER[ColorCodedCans] or else I get fuel-switching added, even though FTP seems to do its own end-caps color coding. The mesh-switching patch was copied straight from the FTP one: @PART[KoyuzKMAPod]:NEEDS[InterstellarFuelSwitch&FuelTanksPlus]:AFTER[ZFuelTanksPlus] @MODEL { texture = orange-jumbo-0, Squad/Parts/FuelTank/fuelTankJumbo-64/model000 texture = orange-jumbo-1, Squad/Parts/FuelTank/fuelTankJumbo-64/model001 texture = TPtank1m-Specular, FuelTanksPlus/Size1/TPtank1m-Specular } MODULE { name:NEEDS[!InterstellarFuelSwitch] = FSmeshSwitch name:NEEDS[InterstellarFuelSwitch] = InterstellarMeshSwitch objects = TPtank2m-Orange,TPtank2m-Orange2;TPtank2m-White;TPtank2m-Checkered;TPtank2m-Black;TPtank2m-Blue;TPtank2m-Red objectDisplayNames = Delta;Antares;Gemini;Black;Blue;Atlas affectColliders = false buttonName = Next Color Scheme previousButtonName = Previous Color Scheme } } Any help will be appreciated.

I forgot to add this, on last week's Squadcast, I asked if there was any furthur update they could share on Porkjet's revamp, and Mu actually replied, giving the usual "Our policy is we don't talk about future features". So, there's that.

Some weeks ago, during one of the Squadcasts before 1.1.3 came out, Mu and NathanKell said that Porkjet was almost done with the rocket part revamp, and that "they look better than his plane parts" (I watched it live and that is a direct quote). Since then, as per their policy, no one from Squad has said another word about it, nor will they, so we're just going to have to wait 'til 1.2 comes out, unless we get a teaser pic closer to release. Interestingly, the same thing is going on with the new telemetry system. For several weeks the devnotes had updates about it, and Roverdude even appeared on one of the Squadcasts to talk more about it. Now, Roverdude is working on the code optimizations, and not a word is being said anymore on the telemetry system. I think this all means tha both things are completed or near-complete, so Squad goes tight-lipped about it.

@NecroBones, maybe there is another way of doing it (this whole thing is also partly a MM learning exercise of mine), but I've found I need to add "AFTER[Squad]" (or any other mod's parts, like some of the MRS parts I've been using too) if I'm cloning, altering or moving the stock parts (in the tech tree); they don't show up or appear in their new tech nodes otherwise. That alone was sufficient, until I got to the fuel tanks; something like "+PART[SquadTankPartName]:AFTER[Squad] {stuff}" gave me the new part I wanted but with the original stock fuel types and amounts re-added, and IFS fuel-switching as well. Anyway, @Deimos Rast's config help worked perfectly, my new parts have the CCC-FTP texture-switching ability and no fuel-switching.

@Deimos Rast, Thank you! I knew there had to be a way, I don't know much how CCC and FTP do what they do with the stock tanks, so that will save me a lot of work. Oh, I also figured out why my cloned and altered tanks kept getting the original fuel amounts and switching added--CCC must be doing its thing to the stock tanks before I clone them, so they were no longer pure stock anymore. I then remembered the MM "BEFORE" command (?), so now my part patches read "AFTER[Squad]:BEFORE[ColorCodedCans]", and that solved the problem, my altered tanks stay the same way I set them up.

@NecroBones, yes, I just want to use the FTP textures the way CCC does with the stock tanks with my own modded cloned stock tanks. I do have specific textures in mind, but the CCC/FTP general mesh-switching would also work. I thought it would be sorta simple to do, but maybe not. This is the patch I made, based on my understanding of what you said, and I tried it in both my own custom parts folder and the CCC folder. It didn't work in either case, just left me with a stock FLT-100 instead of the black mesh I wanted, and oddly with fuel-switching. @PART[KoyuzUpperPod]:FOR[ZColorCodedCans]:NEEDS[!FuelTanksPlus] { node_stack_disabled = 0.0, -1000.0, 0.0, 0.0, -1.0, 0.0, 0 MODULE { name = ModuleJettison jettisonName = CCtank1m-Stock bottomNodeName = disabled isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 0.1 jettisonDirection = 0 0 1 } MODULE { name = ModuleJettison jettisonName = CCtank1m-White bottomNodeName = disabled isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 0.1 jettisonDirection = 0 0 1 } MODULE { name = ModuleJettison jettisonName = CCtank1m-Checkered bottomNodeName = disabled isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 0.1 jettisonDirection = 0 0 1 } MODULE { name = ModuleJettison jettisonName = CCtank1m-Green bottomNodeName = disabled isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 0.1 jettisonDirection = 0 0 1 } MODULE { name = ModuleJettison jettisonName = CCtank1m-Blue bottomNodeName = disabled isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 0.1 jettisonDirection = 0 0 1 } }

Well, that attempt didn't do anything. I inadvertently ran that patch with the changes I made to two of the CCC configs, the -MM-FTP-size1 and -MM-tanks patches ( I inserted the my part name into the list of the former and added another "@part" section for my part into the latter). The result was no change from before. Then I removed my changes to the CCC configs and I ended up with a stock T100 tank that had fuel switching but no mesh switching.

@NecroBones, I'm using IFS. If it helps any, two of the stock tanks I'm cloning are the FL-T100 and -200, using the Soyuz texture for them (with those I'm creating my Simple Soyuz, or Koyuz). I could just use the tanks as is and add the extra stuff like normal, but I'd rather have dedicated parts to complete the Soyuz-like configuration. One of the T100 tanks though is for a structural cap piece that goes over the MRS guidance nose cone that I've repurposed for the descent module. My WIP version looks rather nice so far. The other tank I'll be using is the Kerbodyne 7200 tank, I've found that rescaling it down to 2.5m size gives it the perfect length for an Apollo-type Service Module. I think the Vega texture (I think that was an option for the 3.75m tanks) looks better than the stock texture for this purpose. EDIT: I'm going to try this now for the upper cap piece, what exactly do I put for "newTankMeshName" and "TankDisplayName"? I'm guessing the texture object name from CCC (CCtank1m-Black in this case) and the title of the part as used in the part display list (Koyuz Upper Module in this case) and not the internal name (KoyuzUpperPod), so that's what I'm going to try first.

@NecroBones, How do I integrate some modded cloned stock fuel tanks I'm making into CCC to take advantage of the mesh switching with FTP? I'm basically turning some of them into all-in-one service modules (just add engines and RCS!), though one is a parachute/structural module without fuel. My first attempt with the latter one worked mostly okay, except fuel was added back into the part and the external tank texture was that Z-fighting glitchy kind, which went away when I switched textures but reappeared when on the launch pad. Probably missing something in the various config files. I don't actually need fuel-switching, as the parts will have specific fuel setups which I don't want to get messed up. Thanks for any help, I really love CCC with FTP, I don't even use the stock tank textures anymore.

This issue came up during the Das Valdez+EJ_SA console stream from the Intrepid musuem, I think when NathanKell was with them, and yes, the answer is that Unity doesn't support mouse-keyboard on the PS4.

This is probably a related question, but what bit values do you use for "biomeMask" and how does that correspond with the Results messages? In another thread I found, someone said that the "situationMask" values also apply to biomeMask, but just looking at the Crew Report definintion in the ScienceDefs, this doesn't seem to be the case. I'm trying to do the same thing as the OP foe one type of new experiment (a Probe Report, with a very low science base value of 1, but a high cap) I've made, making it non-biome specific when in space or on the surface.

Never mind

Ah, thank you very much, I've had it backwards then--I've been thinking PQSCity was the block of land that hold the KSC, and have been adjusting the absoluteOffset under PQSMod_MapDecalTangent instead.

Thanks, @NathanKell, but I knew about that page, could you please elaborate on a few points? For instance, what exactly is the "decal"? Is that the all the KSC facilities or the "pad" that they sit on? Is PQSCity the whole land area of the KSP? What role does each offset value have on where each is located? And what is "pure black" and "pure white"? Right now I have my varous sites sitting too high, exposing far more of the slope of the "pad" than there is in the stock KSC, and I want to know which values to adjust that brings them down to stock-level.

The Sentinel and the rest of the Asteroid Day pack will probably come in 1.2, but nothing has been confirmed yet.

Over on the 1.1.3 Release devblog thread, I replied to this same question (from someone else), and @NathanKell followed up:

What's the proper way to edit or deletes values within a specific module? For example, editing thrust and ISP values for an engine, or removing the RESOURCE ElectricCharge usage rate from MODULE Command. I had done it like this for the two listed examples: @MODULE { @name = ModuleCommand @minimumCrew = 1 -RESOURCE[ElectricCharge] } This did not actually remove the electric charge usage for what is now a manned pod. @MODULE { @name = ModuleEnginesFX @maxThrust = 125 @atmosphereCurve { @key = 0 345 } } This actually causes KSP to hang on this specifc part loading (the loading tips continue, but nothing else happens, have to Alt-F4 out), which is a cloned adapted stock engine. Sorry if this is too newb, but I'm finally making my first foray into writing MM patches to mod my KSP.