toadicus Posted June 26, 2015 Share Posted June 26, 2015 NecroBones, please forgive the stupid question... but I'm trying to test my TweakableEngineFairings fix, and I'm not sure I get how your parts are supposed to work.Considering your part SYplate2m1mX0. You've got four stack nodes:node_stack_bottom = 0.0, -0.2, 0.0, 0.0, -1.0, 0.0, 1node_stack_bottom1 = 0.0, -2.0, 0.0, 0.0, -1.0, 0.0, 2node_stack_bottom2 = 0.0, -1004.3, 0.0, 0.0, -1.0, 0.0, 2node_stack_top = 0.0, 0.2, 0.0, 0.0, 1.0, 0.0, 2In the editor, I see three of these, which I am interpreting as follows: "top", on top as expected; "bottom", flush against the bottom of the part; "bottom1", 2 meters below the part. I think I do not see "bottom2" at all, which makes sense since it's a good kilometer away.You have two ModuleJettison definitions:MODULE{ name = ModuleJettison jettisonName = SYplate2m1mX1shroud0 bottomNodeName = bottom1 isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1}MODULE{ name = ModuleJettison jettisonName = SYplate2m1mX1shroud1 bottomNodeName = bottom2 isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1}As far as I know, that means the first module will have a fairing when there is a part on "bottom1". The second module will have a fairing when there is a part on "bottom2". Things are working correctly for me in the former case, but I can't figure out how to test the latter case.TIA! Quote Link to comment Share on other sites More sharing options...
NecroBones Posted June 26, 2015 Author Share Posted June 26, 2015 (edited) NecroBones, please forgive the stupid question... but I'm trying to test my TweakableEngineFairings fix, and I'm not sure I get how your parts are supposed to work.Considering your part SYplate2m1mX0. You've got four stack nodes:node_stack_bottom = 0.0, -0.2, 0.0, 0.0, -1.0, 0.0, 1node_stack_bottom1 = 0.0, -2.0, 0.0, 0.0, -1.0, 0.0, 2node_stack_bottom2 = 0.0, -1004.3, 0.0, 0.0, -1.0, 0.0, 2node_stack_top = 0.0, 0.2, 0.0, 0.0, 1.0, 0.0, 2In the editor, I see three of these, which I am interpreting as follows: "top", on top as expected; "bottom", flush against the bottom of the part; "bottom1", 2 meters below the part. I think I do not see "bottom2" at all, which makes sense since it's a good kilometer away.https://imgrush.com/PPY2jkv_8cat.pngYou have two ModuleJettison definitions:-snip-As far as I know, that means the first module will have a fairing when there is a part on "bottom1". The second module will have a fairing when there is a part on "bottom2". Things are working correctly for me in the former case, but I can't figure out how to test the latter case.TIA!Yep, I know it looks confusing, but there's a good reason for it. It's just model-sharing. Both the "A2-1" (SYplate2m1mX0, short fairing) and "A2-1X" (SYplate2m1mX1, long fairing) parts use the same model file. The nodes that are kilometer away are set up that way so that they're unusable for that part, but exists for the other part that shares that model. So basically, to test the other node, you just need to grab the other part.I forget why this one is split out like that, where others are shared. I think at the time I was trying to add another length without breaking people's saves. KSP 1.0.4's "bug fix" fixed the issue with save-breaking from adding new nodes. But now I'm stuck with two separate part IDs in people's saves, so consolidating them might not be possible now. EDIT: I remember now. They're split & shared because the existence of the other node was making it impossible to use engines of certain lengths, since the engine would want to stick to the bottom nodes in the VAB instead of attaching correctly.For an example of a part with lots of nodes that are all accessible, you can also look at "A5-123" (SYadapter4-2-1), which has three different top nodes to choose from, none of which are disabled via distance. Edited June 26, 2015 by NecroBones Quote Link to comment Share on other sites More sharing options...
toadicus Posted June 26, 2015 Share Posted June 26, 2015 So to clarify, the SYplate2m1mX0 is not intended to display variably-configured shrouds? Will check on the A5-123 shortly. Quote Link to comment Share on other sites More sharing options...
toadicus Posted June 26, 2015 Share Posted June 26, 2015 For the interested; I've got a TweakableEverything dev build available that adds proper support for parts built like this. Quote Link to comment Share on other sites More sharing options...
NecroBones Posted June 26, 2015 Author Share Posted June 26, 2015 So to clarify, the SYplate2m1mX0 is not intended to display variably-configured shrouds? Will check on the A5-123 shortly.yes, that's right. That one only uses one at a time, but two are built into the model to support two different "parts", rather than variable length shrouds on the same part.The A5-123 is a good example of one that has variable lengths. Quote Link to comment Share on other sites More sharing options...
NecroBones Posted June 27, 2015 Author Share Posted June 27, 2015 I figured I'd go ahead and get this out for the weekend:0.17.3 (2015-06-26) - M1 update. - Added a middle-length, 2.5m "straight" cylindrical fairing to the M1 Moa engine. (requires KSP 1.0.4 to not be save-breaking) Quote Link to comment Share on other sites More sharing options...
mikegarrison Posted June 27, 2015 Share Posted June 27, 2015 Hey, I decided to try this Moa fairing for myself tonight. (I don't usually use the Moa engine.) I could put the 3.75m fuel tank onto the Moa attach node and it would make a 2.5m to 3.75m fairing. Nice. But that was mounting a fuel tank directly to the engine.When I grabbed the 3.75m decoupler, though, it wouldn't work. The fairing wouldn't form. I don't know if I was doing something wrong or what. So I grabbed the 3.75m separator from the SpaceY pack, and it worked just fine. Why didn't the stock decoupler work? Is this intended behavior, a known bug, or just something I did wrong? Quote Link to comment Share on other sites More sharing options...
NecroBones Posted June 27, 2015 Author Share Posted June 27, 2015 (edited) Hey, I decided to try this Moa fairing for myself tonight. (I don't usually use the Moa engine.) I could put the 3.75m fuel tank onto the Moa attach node and it would make a 2.5m to 3.75m fairing. Nice. But that was mounting a fuel tank directly to the engine.When I grabbed the 3.75m decoupler, though, it wouldn't work. The fairing wouldn't form. I don't know if I was doing something wrong or what. So I grabbed the 3.75m separator from the SpaceY pack, and it worked just fine. Why didn't the stock decoupler work? Is this intended behavior, a known bug, or just something I did wrong?That's what happens when I don't test it with EVERYTHING... Grrr. What's happening is that the decoupler has just the right height, that it's trying to attach with the lower node even when the upper node is in the right place, which it can't do. KSP still has a bug where it will still attempt to snap to nodes that are pointed in the wrong way, even though it now enforces the direction and won't actually attach.The problem is really that I have the nodes too close together. What I should do is simply remove the 5m cone (I doubt anyone uses this anyway), and make the 2.5m straight fairing go to that length.I'll try to get a hot fix out.- - - Updated - - -OK, I've pushed out a fix.This is strictly affecting the M1 Moa engine:For anyone who grabbed 0.17.3 (in the last 12 hours), anything you flew with the straight fairing, will have an invisible fairing now. Also, things saved in the VAB will require detaching and reattaching the engine, and probably the part above it.For anyone who skipped over 0.17.3 (most people), the only change you should see is if you used the 3.75-5m conical fairing, that's been replaced with the straight fairing, which is what you'll see on your rockets. The 3.75-5m conical fairing is deprecated.0.17.4 (2015-06-27) - M1 update, continued/hotfix - Addressed a problem with new straight fairing in M1 Moa engine: - Removed middle attachment node that was added. - Replaced the 3.75m->5m cone fairing with the 2.5m straight fairing. (doubtful many people use that one anyway). - KNOWN ISSUE: If you used the new fairing in 0.17.3 (during the 12 hours or so it was available), the fairing will be invisible on ships already constructed. - requires KSP 1.0.4 to not be save-breaking Edited June 27, 2015 by NecroBones Quote Link to comment Share on other sites More sharing options...
NecroBones Posted June 27, 2015 Author Share Posted June 27, 2015 Oh, forgot to mention-- Part of the reason that particular decoupler (stock size 3 decoupler) was so problematic, is that it defines the attachment nodes in the opposite order of all of the other "flat" stock parts, and gives preferential attachment to its bottom node... so trying to use the middle or upper nodes on the M1 in SpaceY-0.17.3 resulted in it snapping in place but unable to attach.All of this would clear up if Squad would stop letting things snap to nodes that it can't attach to. But for now, my easy fix was to just get rid of the 5m conical fairing and replace it with the new 2.5m cylindrical one. Quote Link to comment Share on other sites More sharing options...
cipherpunks Posted June 29, 2015 Share Posted June 29, 2015 (edited) Dibamus engine/RCS block has slanted RCS transforms, despite model shows that RCS nozzles are straight. This implies cosine losses (and -25% RCS dV!). Please fix.Also, for some reason, the amount I put into ModuleRCS thrusterPower is doubled - are RCStransforms doubled too?... Edited June 29, 2015 by cipherpunks Quote Link to comment Share on other sites More sharing options...
NecroBones Posted June 29, 2015 Author Share Posted June 29, 2015 Dibamus engine/RCS block has slanted RCS transforms, despite model shows that RCS nozzles are straight. This implies cosine losses. Please fix.Also, for some reason, the amount I put into ModuleRCS thrusterPower is doubled - are RCStransforms doubled too?...Actually, the thrust transforms match the orientation of the nozzles in the model. They're offset by 5 degrees, with the idea of being slightly more "realistic" (since on a real vessel, you'd want it offset to limit the effect of the exhaust interacting with the hull). KSP doesn't have such a drawback of course, so there wouldn't be any harm in "correcting" it. Maybe I'll do that and leave the model alone. It won't line up precisely anymore, but probably no one will look that closely.And no, the transforms are not doubled up. Or are you talking about the "super dibamous"? That has two transforms in each direction due to having two nozzles pointed each way. But everything else I said above applies to both engines. Quote Link to comment Share on other sites More sharing options...
cipherpunks Posted June 29, 2015 Share Posted June 29, 2015 (edited) No, I'm not talking about "Super Dibamus" - that one indeed has slanted RCS nozzles on its model, I have no problems with its usage pattern and its realism (but I doubt that in reality slanted RCS thrusters are used like in KSP - that is, even if the nozzle is 89.9 degrees from needed vector, it will fire anyway, and waste precious propellant...)Now that You said the model indeed has canting, I can see it too - on a first glance I thought those were straight; bad sight, or maybe it's just miniscule canting amount :-DDo as You please.Me, I just googled some, and then rescaled both to be like SpaceX-SuperDraco-and-a-bunch-of-Aerojet-R-40B-combos, one with shell and one without. I play (or try to play) only RSS, though.//8 SuperDracos will consume around 250 kg/s of propellant at full throttle. We've been told that the DragonFly will contain 400 gallons of propellant which works out to be ~1500 kg or 6 seconds of 8 engine, full-throttle fun.//Musk mentioned once that these things could take a Dragon from 0 through the sound barrier in about 3 seconds. Given the 120 klb figure EchoLogic posted above, if a Dragon V2 weighs 6000 kg (a guess. Do we know?), then the maximum acceleration is about 9 g's.@PART[SYoms1] { // SpaceY "Dibamus" RCS/OMS Thrust Block @title = SuperDraco twin rocket engine and RCS (Deep Space version) @manufacturer = SpaceX @rescaleFactor = 0.7 // Nozzle Exit Diameter 20 cm (8 in) @mass = 0.12} // PART@PART[SYoms2] { // SpaceY "Super Dibamus" RCS/OMS Thrust Block @title = SuperDraco twin rocket engine and RCS (Aerodynamic version) @manufacturer = SpaceX @rescaleFactor = 0.53 // Nozzle Exit Diameter 20 cm (8 in); at 1 nozzle is 38 cm @mass = 0.15 // has 8 4kN thrusters (~6kg each) + 2 SuperDracos + shell} // PART@PART[SYoms1,SYoms2]:FINAL { // SpaceY "Dibamus" RCS/OMS Thrust Block, "Super Dibamus" RCS/OMS Thrust Block @manufacturer = SpaceX @MODULE[ModuleEngines] { @maxThrust = 174.5 // 145.9 at SL; IRL it is programmatically limited to around 136.336 for a pair at SL @atmosphereCurve { @key,0 = 0 281 @key,1 = 1 235 // official } // atmosphereCurve } // ModuleEngines @MODULE[ModuleRCS] { @thrusterPower = 2 // let's say it's Aerojet's R-40B @atmosphereCurve { @key,0 = 0 293 @key,1 = 1 170 } // atmosphereCurve } // ModuleRCS %MODULE[TweakScale]:NEEDS[TweakScale] { %type = surface }} // PART//8 Superdracos will have an axial thrust of 570kN. The current dragon has a dry mass of 4200kg, propellant mass of 1290kg, and maximum cargo mass of 7200kg, totalling 12690kg. Let's just leave that figure at that because if it were carrying people, I doubt cargo and added life support and people would total 7200kg, but Dragon 2 will likely be heavier. That gives us an acceleration of about 44m/s2 or about 4.5G'sNote that @thrusterPower = 2 makes it 4kN according to RCSBuildAid, as that R-40B should be. Edited June 30, 2015 by cipherpunks add MM cfg Quote Link to comment Share on other sites More sharing options...
mikegarrison Posted June 29, 2015 Share Posted June 29, 2015 Oh, forgot to mention-- Part of the reason that particular decoupler (stock size 3 decoupler) was so problematic, is that it defines the attachment nodes in the opposite order of all of the other "flat" stock parts, and gives preferential attachment to its bottom node... so trying to use the middle or upper nodes on the M1 in SpaceY-0.17.3 resulted in it snapping in place but unable to attach.All of this would clear up if Squad would stop letting things snap to nodes that it can't attach to. But for now, my easy fix was to just get rid of the 5m conical fairing and replace it with the new 2.5m cylindrical one.I should report back. I tried this again and what happens now is that the stock decoupler sort of snaps into what looks like the right place, but is still grayed out. However, a little nudge up on the mouse now convinces it to attach to the correct node. So it's fiddly, but it works. Unfortunately, people who don't try fiddling with it may still come back reporting that it doesn't work. But it does work now. Quote Link to comment Share on other sites More sharing options...
cipherpunks Posted June 29, 2015 Share Posted June 29, 2015 For me, great many parts are like so - hesitant to attach at first. Many simple parts from many mods. For example 2.5m BOMP. Quote Link to comment Share on other sites More sharing options...
NecroBones Posted July 1, 2015 Author Share Posted July 1, 2015 I should report back. I tried this again and what happens now is that the stock decoupler sort of snaps into what looks like the right place, but is still grayed out. However, a little nudge up on the mouse now convinces it to attach to the correct node. So it's fiddly, but it works. Unfortunately, people who don't try fiddling with it may still come back reporting that it doesn't work. But it does work now.For me, great many parts are like so - hesitant to attach at first. Many simple parts from many mods. For example 2.5m BOMP.Yeah, most of the time it's just KSP snapping things to nodes that are disallowed. Squad really needs to add a check for that before snapping. Quote Link to comment Share on other sites More sharing options...
passman Posted July 3, 2015 Share Posted July 3, 2015 seems there's a bug with the 10R radial boosterdouble stacking them with the TT38k decoupler causes massive overheatingthis illustrates ithttp://i.imgur.com/uW6UBpY.jpg- - - Updated - - -oh also 10/10 mod never play without it Quote Link to comment Share on other sites More sharing options...
damerell Posted July 3, 2015 Share Posted July 3, 2015 seems there's a bug with the 10R radial booster; double stacking them with the TT38k decoupler causes massive overheatingIt seems to me that 1.0.3/4 heat is a bit buggy. Mods seem often to have curious consequences. But turning on thermal debug and seeing in the right-click menu where heat comes from would be useful? Quote Link to comment Share on other sites More sharing options...
NecroBones Posted July 3, 2015 Author Share Posted July 3, 2015 seems there's a bug with the 10R radial boosterdouble stacking them with the TT38k decoupler causes massive overheatingthis illustrates ithttp://i.imgur.com/uW6UBpY.jpg- - - Updated - - -oh also 10/10 mod never play without itIt seems to me that 1.0.3/4 heat is a bit buggy. Mods seem often to have curious consequences. But turning on thermal debug and seeing in the right-click menu where heat comes from would be useful?Yep, I'm pretty sure it's a KSP bug. I've seen it demonstrated with stock parts too. It has something to do with parts connected through smaller parts, with phantom heat being generated. This particular SRB has nothing special about it, and it has the same thermal settings as my other SRBs, and the stock SRBs. I think something that influences it is the relative sizes of the object and the small part that it's attached to. Quote Link to comment Share on other sites More sharing options...
ick98 Posted July 4, 2015 Share Posted July 4, 2015 Some liquid fuel engines and SRB are muted. I do not know what happened, because all other versions of Space Y always worked normally. Let me know what happened? Quote Link to comment Share on other sites More sharing options...
NecroBones Posted July 4, 2015 Author Share Posted July 4, 2015 Some liquid fuel engines and SRB are muted. I do not know what happened, because all other versions of Space Y always worked normally. Let me know what happened?Muted, you mean the sounds aren't working? I added some custom sounds a few releases back. They're just in WAV format. It might be useful to see if your game log shows these files not being found or something. Maybe also try completely deleting and then re-installing SpaceY. As long as everything goes in the right folder, the sounds should work. Quote Link to comment Share on other sites More sharing options...
ick98 Posted July 5, 2015 Share Posted July 5, 2015 I uninstalled and installed again the Space Y, I downloaded an older version and so I changed the sound folder, I downloaded again and still not worked. I did not understand until now what's going on. Quote Link to comment Share on other sites More sharing options...
NecroBones Posted July 6, 2015 Author Share Posted July 6, 2015 I uninstalled and installed again the Space Y, I downloaded an older version and so I changed the sound folder, I downloaded again and still not worked. I did not understand until now what's going on.I'm still curious to see what your log shows. Did you rename the folder or anything? It expects to find the sounds in "GameData/SpaceY-Lifters/Sounds"I'm working on moving the custom sound definitions to a separate MM config file, so that you can just disable the custom sounds by deleting that one file. I should be able to get that out pretty soon. Quote Link to comment Share on other sites More sharing options...
NecroBones Posted July 6, 2015 Author Share Posted July 6, 2015 Alright, I pushed the update out. To disable the custom sounds (and go back to the default KSP sounds), you can just delete the "SpaceY_CustomSounds.cfg" file. I moved the custom sound settings to that.0.17.5 (2015-07-05) - Tweaks. - Added ConductionFactor/convectionflux settings for petal bay. - Adjusted OMS/RCS blocks' RCS thrust vectors to remove 5-degree offset (and thus minimize cosine losses). - Moved custom engine sounds to separate "SpaceY_CustomSounds.cfg" ModuleManager file, for easy removal. Quote Link to comment Share on other sites More sharing options...
mikegarrison Posted July 6, 2015 Share Posted July 6, 2015 Alright, I pushed the update out. To disable the custom sounds (and go back to the default KSP sounds), you can just delete the "SpaceY_CustomSounds.cfg" file. I moved the custom sound settings to that.0.17.5 (2015-07-05) - Tweaks. - Added ConductionFactor/convectionflux settings for petal bay. - Adjusted OMS/RCS blocks' RCS thrust vectors to remove 5-degree offset (and thus minimize cosine losses). - Moved custom engine sounds to separate "SpaceY_CustomSounds.cfg" ModuleManager file, for easy removal.For the record, I didn't mind the 5 degree cosine losses, but I don't mind this change either. Quote Link to comment Share on other sites More sharing options...
NecroBones Posted July 6, 2015 Author Share Posted July 6, 2015 For the record, I didn't mind the 5 degree cosine losses, but I don't mind this change either.Yeah, it's subtle enough that most people don't notice one way or the other. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.