BudgetHedgehog

Ooh, a rotatable view would be lovely! If implemented, would all cameras have it?

Another quick question - does this effect the rework parts at all?

And voila: Part list after clean up: I haven't touched the recyclers because I saw they have different conversion amounts and TweakScaling them would change that. All the sizes available: 0.625 to 5m on the containers and the hexcans.. there's a quite a lot more variety there. From memory, you can limit the amount of sizes but I don't know why you'd want to do that here. Why take extra stuff you don't need? Resource amounts: Containers: 30, 240, 1920, 6480, 15360 Hexcans: 3.75, 10.29, 30, 82.32, 240, 659, 1920 As far as I can tell, those are pretty well balanced. The containers have exactly the same amount as the 'stock' ones of them, so.. success! I have used the 1.25m version of the containers and the Normal sized hexcan to tweak, so the others should be removed (all Large and Small versions of both). And here's the link: https://www./?kpf1t719cn2pvk9 I hope you like it P.S. - this hasn't been tested on any of the retextures or other models, this is literally just made from/for a 'stock' TACLS install. But if they are literally just textures, there's no reason this wouldn't work on them too.

Ok, thanks. I don't use any of them aside from the docking washers and gantry rails, so it looks like a complete reinstall is needed. I'll not to delete the plugin this time EDIT: I get that sometimes - if you check your debug log, you'll see a ton of NREs. It's easily fixed by saving the craft, exiting the editor and then entering again. Not sure what causes it, but I think it's editor itself borking out, not IR.

Excellent news! As far as updating goes, is it fine to just replace the .dlls?

Ohhhhhhhh! I see now... thanks. That makes sense. Thank you

To be honest, I really do think that this thread at least made Harv & Co sit up and see that x64 is entirely doable with Unity. Given the amount of bugs, uncertainty and YMMV with this hack, it's for sure not going to be anything close to official but at least it shows that it can be done and if it's a stock game, then it's stable. Also, not unrelated to the above, I think it's the plugins that crash this hack. That is probably a 'well, duh..' moment for me, but part packs seem to handle fine but once you start adding in things that change the gameplay, that's when you get YMMV crashes.

Hooray! Tell you what, tomorrow, I'll whip up a cfg that will allow some kind of TweakScaling of TACLS hexcans and if it's to your (and mine) satisfaction, would you be ok with me posting it? I'm glad to hear you're open to the idea at least

Boom: 10 characters

My mistake, I must;ve misunderstood - there was some serious bugginess around 2.1.0-3 or something that meant that loading crafts with modules out of order thanks to MM would break things spectacularly - I thought this what you were referring to.

I believe that bug has been fixed. But still, just put OPs cfgs in a folder called 'zblah' and make them say :BEFORE[zblah]. If they delete the mod it modifes, delete that cfg too. Not terribly difficult. Also, no hard feelings, man

Sometimes, I feel like I don't exist.

Like I literally just said, it's the FINAL pass - I'm not sure if it's ordered or anything but I think, in essence, it's run after all :FOR, :NEEDS and :BEFORE patches are run. This means that all :Final passes are done after those and the ordering of those configs shouldn't matter. If it's vitally important that your :Final is run after someone elses :Final, why not edit their cfg to say :BEFORE[MyMod] or yours to say :AFTER[TheirMod]?

:Final will be fine. I can't remember off by heart, but looking at the output_log will tell you in what order those :Final patches are applied. If alphabetically, then naming your patch 'zblah.cfg' would be the thing to do. If there's no apparent order, then you can name it whatever - it'll still get applied. I can't remember off the top of my head how MM orders the :Final patches though, so it's best to look first.

What he said. As long as your Duna AP is just inside Ikes SoI, you'll have very little velocity with regards to Ike so you can either burn radially to push your P to the "correct" side or you can just land as normal - Ike is pretty similar to Mun and has only a slightly faster sidereal rotational period so you won't be losing much if you land "retrograde", possibly a couple hundred m/s or more, but seeing as you have 5k to begin with, I'd say you're safe. If you really want to do things properly and land "prograde", then yes, a bi-elliptic inclination change transfer is your best bet - burn until your Duna Ap is almost escaping and once you get to it, burn retrograde until your PE is at the desired height then re-circularise at the desired altitude. This could require more fuel than just transferring to Ike directly though. Alt+F5 before you do anything so you can go back to this spot before you try, just to be sure.

Is this where I post my 'realism vs believability' post? Because I totally should. Northstar even posted in it. I'm totally down for the first few ideas - sure, have Science or Cost multiplier, but the further I go down that list, the less important they seem to get. ISP Scaling? Fuel Realism? They both seem like a lot of work that would only really interest a certain portion of the players and not be used by the others. I don't care what that fuel kerbals use - it's different planet, they could be using liquid flooby for all I know or care - the point is it's fuel and it's liquid. It gets the job done and it doesn't bog me down with details or realism. Even here on Earth, we don't say "and the Space Shuttles SRBs are close to running out of Ammonium Perchlorate Composite Propellant, or APCP", they're just running out of fuel. It's fuel, it burns and provides thrust, that's all I need and want to know. Any more than that is wasted on me because I honestly don't care about it. The most I need to know is that I have enough of it. Planetary scaling? Like I said in my post, yeah, Kerbins atmosphere/size is pretty unrealistic but it is, after all, a different planet. Who knows what it's made of... Could be almost entirely made of osmium, who knows.. This is my biggest problem with people trying to apply realistic ideas to a game. It takes place on another planet that is entirely unlike Earth. Basic laws of physics apply (aerodynamics, re-entry heating etc) but stuff like 'realistic fuels' and 'realistic size/gravity' have no place in stock KSP because it is, simply put, not supposed to be realistic. It's a different planet altogether and I have no problem suspending my disbelief for that. Forcing kerosene or Earths gravity well on it just feels.. wrong.

Hehe, You saying that just made me wish for this mod days ago when a decoupler failed to decouple and no-one helped me.. If only I could've chopped it off! Sigh.. As it was, I just sent a rescue rescue mission to grab everyone and the Science but yeah... being able to actually detach something that should've detached would've been a lot of help then.. This mod is one of my 'won't play without it' now

Out of those, I'd guess Soundtrack Editor, as from memory that changes the Mono file used by KSP.

Are you doubly sure the TACLS plugin is installed? I recently had a brainfart where all Infernal Robotics parts were available, but I couldn't move them - turns out I'd accidentally deleted the plugin somehow.

It's possible I have asked ferram in the past to disable all flight assistance once out of the atmosphere, but nothing's come of it yet, or he didn't see it. I know Manley got caught out by it once and so have I - any flight assist toggles left on can make your craft behave extremely erratically.

I'd go with this one - the CactEye, while a good idea it being EVA-servicable, requires HullCam, if you so much as look near the sun the processor explodes which means you need to replace it which removes any action group you had assigned to it. Also, HullCam has a couple of telescopes too, but they don't give you science.

So I've been thinking about TACLS for a bit now.. the one thing that has stopped me installing it is the sheer number of parts included. Tiny, small and medium hexcans of 4 different flavours, and then the inline ones too.. It makes the part list crowded in a stock install, let alone a modded one with IR, Near Future, KAS etc. So here's my idea - TweakScale. Infernal Robotics recently made the switch and dramatically reduced the amount of parts, instead having one part that can be resized in the VAB, with updated stats to match (increased weight, resource etc). By my calculations, you'd only need 5 parts for the basic life support cans - one hexcan of each resource and 1 inline one. Of course, it can't help the recyclers but it'll cut down the hexcans (with each size looking similar to each other in the part list) from 16 to 4. I've no idea if this is planned or whatever, but it would really be worth taking a look at. Biotronic would, I'm sure, help you and it's just a case of making a cfg for the scale but supporting it by default would a great idea. Thoughts?

I believe the craft is still in the persistent.sfs and stays there until the game is saved. Since you're notified right at the start, you can exit, reinstall the missing parts, start back up again and the vessel will still be there. At least, I think so.

You downloaded the source from Github, not the plugin from Curse.

Sadly, I don't think either the stock game or FAR take into account variable-geometry wings. Not with stock because that's just stock but I'm not sure why not with FAR, as it'd change the lift coefficient if the wings were rotated from yawing or whatever... I think more tests are needed (my original tests weren't in a controlled environment and other things were changing as well as the wing angle). Once I can stay in the SPH for more than 3 seconds without getting StackOverflowExceptions, I'll make a better version of it. But yeah, all thanks to VapourTrail, I hadn't thought to hide the IR hinge/seam with Procedural Wings. That's a marvellous idea.