Operation40

I know this mod probably isn't aiming for aerodynamics, but wanted to share some weird stuff indicating some of the parts aren't the same size (sorry if this is a known issue, I admit, I didn't read this whole thread) http://steamcommunity.com/sharedfiles/filedetails/?id=913048723 the fuel tank connected to the small adapter should probably be both YP=0 and YN=0 (shows YP=.1, which is pretty close) then the service bay attached to that fuel tank is the same size but has YP=.53 the K&K drill attached to the service bay is fine (YP and YN 0) but then it gets super nasty with the storage unit.. not only is the first item on the storage stack showing like it's in front, but the next item is also showing the same. Probably because they are connecting on "X" instead of "Y" again, I know it's not an aerodynamic part pack, just wanted to share this data. I may try to tweak the storage units to work like a cargo bay for YN/YP -- but try to keep XP, ZP, and ZN.. erm somehow..

I don't see any issues with the shoulder engines -- keep in mind, for the tailbay, I did not add/modify the drag_cube -- it's missing that definition and I left it alone. the changes I made were the closedPosition=1 and adding the interior node tailbay shoulder engine test, tailbay closed: http://steamcommunity.com/sharedfiles/filedetails/?id=898003899 tailbay shoulder engine test, tailbay open: http://steamcommunity.com/sharedfiles/filedetails/?id=898003945

did some tailbay testing with my updated settings tail bay closed: http://steamcommunity.com/sharedfiles/filedetails/?id=897075114 tail bay open: http://steamcommunity.com/sharedfiles/filedetails/?id=897075261 looks pretty good.. arguably a couple of those dawn engines should clip outside but.. meh.. it's Kerbal tradition to have a little room to cheese part placement.

I have my tailbay shielding working!!! without the Drone Core in-between it and the other bays, and without toggling all bays at the same time: http://steamcommunity.com/sharedfiles/filedetails/?id=896494089 mk4cargotail-1.cfg node_stack_bottom2 = 0.0, -2.162734, 0.00, 0.0, 1.0, 0.0, 3 ... MODULE { name = ModuleCargoBay DeployModuleIndex = 0 closedPosition = 1 lookupRadius = 4 nodeOuterForeID = bottom1 nodeInnerForeID = bottom2 } I updated closedPosition to "1" instead of "0", which I think is what fixed it also added an "inner" connection node that was missing This cfg is missing a drag_cube definition.. not sure it makes a huge difference but the mk3 tail bay has a cube "a" and "b"

You nailed it.. I went back to the numbers from my earlier post and it cleared up the high drag I was seeing adjacent the bays.. re-tested occlusion, looks good : http://steamcommunity.com/sharedfiles/filedetails/?id=896484022

Great point -- I'll take another look to see if I broke that. Before I do that though, seems I was going about that the hard way. The game auto generates the correct cube "a" and "b" and puts it in PartDatabase.cfg.. PartsDatabase.cfg url = MarkIVSystem/Parts/Fuselage/mk4cargo-3/mk4cargo-3 DRAG_CUBE { cube = A, 10.25,0.6837,6.393, 10.29,0.6793,6.393, 5.926,0.956,1.356, 5.926,0.9526,1.356, 19.63,0.897,1.774, 19.63,0.8474,2.534, -0.0003664,0.002363,-0.3822, 7.87,2.522,4.108 cube = B, 12.39,0.7291,10.74, 12.44,0.7287,10.74, 6.065,0.9554,1.356, 6.065,0.952,1.356, 26.41,0.8319,4.929, 26.43,0.8792,5.509, -0.0009923,0.002363,-1.072, 10.72,2.522,5.487 } This is quite a bit different than what I had, but it produces good results (drag coefficient increases with doors open, decreases with them closed). I think I'm going to refresh the numbers for all bays from the PartsDatabase.cfg, then yah, double check the occlusion. I'm also looking at this possible issue: http://steamcommunity.com/sharedfiles/filedetails/?id=896257108 any part attached to a cargo bay (except another bay) acts like it's at the front of the stack (almost).. For instance, using a Drone Core for the tail workaround was showing 400kN+ of drag @ 300m/s (under 1km). That's not quite as bad as if it were at the front, but waaay too much for being an aerodynamic piece on a stack the same size. My suspicion is it is a "3 node stack" problem.. Imagine a stack of 5m tanks with 1.25 shoulder tanks, but instead of connecting nodes end-to-end on the shoulders you have them all connected radially to each's 5m tank.. of course given that these are just 1 piece parts and I can't connect 3 nodes at once, I'm going to disable the shoulder nodes all thru a craft to test the theory...

ok here's all my updated numbers for those interested (I'm only showing the first 2 triplets from each set, the rest are unchanged): mk4cargo-1.cfg cube = A, 41.11,0.68,3.767, 41.11,0.6784,3.767, cube = B, 29.11958,0.68,3.767, 29.11958,0.6784,3.767, mk4cargo-2.cfg cube = A, 20.64,0.6766,4.019, 20.64,0.6748,4.019, cube = B, 14.5147,0.6766,4.019, 14.5147,0.6748,4.019, and of course mk4cargo-3.cfg I posted earlier: cube = A, 10.29,0.6791,4.019, 10.29,0.6774,4.019, cube = B, 7.0965,0.6791,4.019, 7.0965,0.6774,4.019, this means there's a difference now in drag when you close the bay vs having the doors open. I extrapolated numbers from the mk3 cargo set.. I imagine the tail bay and service bay need some love too

ahh I think I found it (without complicated math) DRAG_CUBE "A" and "B" are the same for all mk4 cargo bay sizes.. So.. (not talking shielded/unshielded here), but the drag coefficient (a.CD) does not change when you open the bay vs closing it. .. from mk4cargo-3.cfg.. CUBE A and B *were* both the same, I updated CUBE B, now the "A.CD" number drops a good bit when I close the bay cube = A, 10.29,0.6791,4.019, 10.29,0.6774,4.019, 23.47,0.9617,0.3096, 23.47,0.9611,0.2989, 19.63,0.8969,1.774, 19.63,0.8502,2.534, -0.0003667,0.002363,-0.3819, 7.87,2.522,4.108 cube = B, 7.0965,0.6791,4.019, 7.0965,0.6774,4.019, 23.47,0.9617,0.3096, 23.47,0.9611,0.2989, 19.63,0.8969,1.774, 19.63,0.8502,2.534, -0.0003667,0.002363,-0.3819, 7.87,2.522,4.108

I'm going to comment on drag (sorry!) Working on some math, but I suspect drag is up to 30% too high on mk4 parts. Right now, it seems roughly double the equivalent mk3 parts http://steamcommunity.com/sharedfiles/filedetails/?id=895659075 The VAB is also reporting the mk4 bay is 10.7m wide.. This might be the cause of drag too? (edit - oh duh, it is 10.7m wide, with the bay doors open.. doh) Currently looking for an online calculator that will help me prove me theory with MATH ! (queue dramatic music)

cool.. good to hear! btw: I did put my broadsword cfg at 8.0t / 420 / 720 so, math-wise that's no apparent gain over 4x rapiers, but really there is, if you consider the 200kg quad-coupler I'd use to mount those on a 2.5m stack.. I didn't mess with drag or fuel at all, and was happy with the results If I understand you right; I don't mind simplifying the tank types (lobes?) at all.. " Just one tweakable for main tank (LF, LF/O) and one for the lobe tanks (Structural, LF, LF/O, Mono)" .. sounds perfect to me, indeed I see no reason not to do this... *edit* oh,, breaking existing crafts.. I don't mind.. bring it on!

thank you for this mod! I went and did what is specifically warned not to do and it's fantastic http://steamcommunity.com/sharedfiles/filedetails/?id=894943000 some .cfg / plume editing was required.. but those ion clusters are saving me 200+ parts.. TY!

i've been having lots of fun with this mod. I hope Nertea sticks with it having logged a few hours in it, i'm going to have to agree with an earlier poster -- the Broadsword engine feels overpowered.. I'm going to try to retune the cfg so it has only marginal benefit vs 4x rapiers. Right now it seems like it produces the thrust of 5 rapiers but at the mass of 3 (ish).. I'll have to check the math on that lol.. .. edit.. for anyone interested... (anyone?) mass maxthrust air maxthrust closed rapier 2.0t 105 180 broadsword 7.6t 530 820 I can't decide if I want it to weigh more or produce less thrust.. or both..

workaround for the tail bay: I put a mk4 control core between my tail bay and cargo bay and was able to get my stuff shielded. I still need to toggle doors. so from tail forward I'm doing: tail bay -> mk4 control core -> mk4 cargo bay -> etc, etc also, the tail bay doesn't shield as big an area as it takes up visually. I had dawn engines packed in one, and while none visually poked outside, the outer row all the way around the cluster was left "unshielded" in this picture I've already moved the engines to a mk4 cargo bay but you can see the cluster layout http://steamcommunity.com/sharedfiles/filedetails/?id=891836445 there's about a .625m area edge of the tail bay that is unusable/unshielded ... 1 last thing the smallest ventral bay has the same drag as the largest cargo bay. I did try to toggle doors open/closed http://steamcommunity.com/sharedfiles/filedetails/?id=891855440 this seems like a copy/paste issue from the cfg files -- going to try to copy the drag data from the small cargo bay cfg over to small ventral and see if that brings it more in line with the other parts..

it looks like the experiment polling process of this mod has to change. in a post 1.1 world you can't test every science experiment on every frame update -- it's way too laggy (or maybe I'm doing it wrong?). it's just not a simple update / recompile .. from what I can see.. someone please, prove me wrong

I'm inclined to agree with Bloody Looser, though if you want to take that a step further.. everything you dig is dirt so it needs seperated / refined: drill -> refinery -> ISRU

you can peek inside the old DLL to see what he's dealing with.. it has to "poll" each experiment and figure out which one still has value (vs what's already in storage vs what's in labs vs what's already been done, etc etc).. all of which seemed to change with the update.. What seems like a simple mod actually has a lot of code behind it. that's on top of all the UI changes and other annoying updates he's got to make.. I have an idea of what he's up against, cause.. I tried .. it didn't end well lol.

So death is working in the "hack" version? I'll admit I didn't really test it, though it seemed like I had run out of electricity a few times while ferrying Kerbals and they were fine. Electricity in general in 1.1 seems weird with respect to time warp. LIke 100x warp will be fine (generating electric) and then the next increment I'll be totally out of electricity just to recharge again on the lower time warp setting.

I have dozens of hours on the "hacked" version http://steamcommunity.com/sharedfiles/filedetails/?id=673468487 http://steamcommunity.com/sharedfiles/filedetails/?id=671054072 got it running with TAC-Declutter from 1.0.5 -- just needs the updated Fuel Switch mod.. I did have an issue with the .6m life support container being im-mobile on the launch pad -- my 1.6TWR rocket literally swiveled around the container.. but unsure where the fault lies there -- I just avoid the .6m container now lol..

Thanks!! That version seems to be working well for me with the updated blizzy toolbar default consumption rates seem much lower than I remember though? the 1.25m life support container is supporting 5 kerbals for over 60 days now, instead of ~30 that it did before. I suppose that's a cfg setting somewhere?

thank you!!! I really like this mod and looking forward to your update for 1.1

It was relatively easy to fix the offending line.. registry.InstalledDlls vs registry.get_InstalledDlls() .. if the OP doesn't mind, I can post the fixed DLL for everyone?