AetherGoddess

ya, i just felt it necessary to reiterate this. i have come to rely on KSP Alarm Clock for pretty much every flight. the close approach alarm is pretty much the only way i know to plan intercepts, and the once or twice that the node alarm has failed have been the only times where i blew past nodes since i started using KAC back in .22. On a related note, Alternate Resource Panel is the only mod i use more then alarm clock. Thanks for all your hard work.

This is a much better argument against violating the license then the legal one. ya, no one is going to prison, but disrespecting the wishes of developers who put time and effort into their code is going to result in less people willing to put effort in, because they suspect that effort will, similarly, not be respected. the value of one plug-in pales in comparison to the effort of all the people that action could have a chilling effect on. this pretty much solidifies it for me: don't do it.

For those of you that don't, my company employs a lot of outsourced development work: for GOOD developers in western countries that can do complex development like this, the correct range is "hundreds of (US dollars/Euros/Pounds Sterling) per hour" .

in the strictest sense, you've already violated the license on treeloader, since the only right granted was "reference only", and compiling isn't reference. now, realistically, i don't think anyone would complain too much, but you'd be "in the wrong", legally speaking, if anyone at all did download and use your instructions, the would also be violating the original license, so would also be "in the wrong".

it's probably time i posted this again: Ah! the perennial question: My answer over anyone who had any real contribution. who's the queen now?

Consider my thing: ART Hatches for CRP </plug>

No. Snjo is aware of the .25 update, but is busy. he'll get to it as soon as he can, so just show a bit of gratitude, have a bit of patience, and let the awesome come to you when it can.

as has been stated many many many times in this thread and in the Lite thread, Treeloader, the method with which KSPi creates new research nodes, is unmaintained and has some blocking issues with the .25 update. the author hasn't been around much recently, the last update was for .23.5, and the license is "all rights reserved, for reference only", so we can't even fix it in his absence. very likely, this will continue to be a problem until a clean room replacement is mature enough, which might be a while, since there aren't even any development projects right now that could eventually grow into something like treeloader.

considering the maintainers last post was the one quoted above, i don't think anyone has tried it, or they have tried and haven't expressed a problem. The mod does contain plug-ins so there is a real possibility that they won't work, or at least will require a recompile for the new references. The source repository hasn't been updated in 2 months, so it probably isn't ready or tested. License is CC, so feel free to try it, and if you can make it work, post your working version with credit.

there's a fun little easter egg if you run the Win x64 executable. people were complaining at mod makers about bugs in the x64 edition, and those complaints made it impossible to get any real bug reports, so a lot of mod makers, like ferram, just shut down their plugins if they detect win x64. ModuleManager takes a slightly more.... internet libertarian approach.

the disable is not to protect you from bugs, it's to protect ferram when you come back and complain about squad bugs as if they were ferram's fault. what you sugguest is exactly what a lot of mod makers did in .24, but 1) it didn't stop them getting complained at, and 2)the problem has gotten worse in .25. Linux x64 seems to be operating normally, and all the crashy is on the squad side of the wall, so modders just stopped letting their mods run at all in win x64.

That hammerhead pod. very cool. guess i'm going to be able to make a Correllian mining corvette once all the .25 mod-i-ness settles out.

it is, but the FAR/NEAR drag model correctly models the behavior of the part when it's orientation changes, so the "nose" of the ejected booster suffers pretty sever torque due to wind resistance, where as the stock model causes the ejected part to just rotate at something like 1 deg per second, slow enough for it to drift away before scything your engines. you can see this by taking a similar booster up above the atmosphere and ejecting it. it won't whip around like snake, it'll just drift away, turning gently.

If you're running into the same issues i was, consider using Caps lock (aka Fine control mode) to slow down your control inputs. this "slowly" ramps the power of the push up the longer you hold the button down, rather then the default behavior of going all the way to 100% torque the second you push the button. also, disable as many reaction wheels as you can. Assuming you have only one of the high tech surface GRUs from this pack, you should be able to apply something like .025 n torque, which should be enough to move any sufficiently large telescope slowly enough to get stable pictures of almost everything.

None of this is helping the situation. the makers of all of your favorite mods are aware of the update, and in most cases are already urgently working. it takes time to respond to the changes Squad made, test those responses, test all the other features to find any new bugs, and fix all those issues. B9 is an especially large mod, with lots of interactions and dependencies. those interactions have to be tested, and the providers of all those dependencies must update themselves. ALL of those self same mod makers are volunteers, who balance their own lives, families, work and their own amusement against this unpaid work to increase your video game amusement. have a little gratitude and show a little patience.

and the B9 team has already said their next release will use the new Mk2 standard from these parts. again with the demands thou.

Decouplers in .24 started producing their force against the part in an uneven way. this leads to at least a small part of the ejection force being transfered as rotation, meaning the part will flip over and smash into your ship before it's far enough away. my favorite fix is to use TweakableEverything to adjust the ejection force to 0, which allows the part to gracefully fall straight away, rather then being pushed off and flipping out. this only works if there is a clear route straight from your dropped part against the direction of thrust.

or, you could use B9's. Or Cacteye's surface attach parts. Or literally any of the other parts. do not demand others create what you are unwilling to search for.

This is something that spins my head around. the only thing that changes (as far as KSP is concerned) in phase transitions is volume/mole, but internal volume for resources aren't tracked in KSP, so the difference between a container of 1 mole liquid 1H+ and 1 mole gasious 1H+ is the size of the container's model. resource mass is unchanged, since the mass of the resource is 1 g (from definition of mole), and resource amount is unchanged (from definition of mole). Unless there is a reason to track phase changes, like, say, requiring electricty to convert gasious 1H+ into liquid coolant, then it shouldn't matter what state it's in, because you have 1 mole of it, and it's in a part that doesn't care how big 1 mole is. Even for that use case, the cooling part can just directly use EC to account for that and make everyone else's life easier.

The "Trashcan-o-explosives" SRBs? the ones that are super overpowered and are dropped early in the tech tree in order to make up for the horrible drag system? Ya, been there. or Firespitter/B9 Air breaks.

abandon all hope. not kidding. the Windows x64 version of .24.2 would crash randomly when memory accesses started happening anywhere near the 32-bit line, and the .25 version is far far worse. Here is an accounting of my last Win x64 experience: if you're running Linux x64, then carry on, apparently that's working normally.

i think the correct response here is blame squad. the reason Ferram (and a few other modders also) has dropped support for Win-64 is that it is very, very, VERY, fragile. it frustrates me to no end, because i have 12 unused gigabytes with which to store textures. My Video card has 2GB of ram by itself. 32-bit numbers are just not large enough to store all the collected awesome of this modding community. in testing .24's x64, i quickly came to the conclusion that, once mods were installed, there was no longer consistency in the causes that operated in the natural world, reason only sometimes worked, logic was a lie, and large memory access is governed by the old ones. i felt like James Mickens was laughing at me. This was my world while i tried to figure out what mods worked and what failed. i tried .25 x64 once. it crashed during the nyancat.

who said anything about marking it as dead. it's still going into my critical mods list. this mod is all parts, textures, and models; it should work fine once we get the dependencies up.

You are correct. the depenancies (mainly firespitter and KSPi/KSPiLITE) will need to be rebuilt and tested.

yes, and if you are reporting mods that work, or bugs, or patches, then you are adding to the meta; you are signal. if you asking apropos of nothing and bringing nothing, then you are not adding to the meta; you are noise. i am the squelch. i'm only useful if there is too much noise, and i mess up the flow in small ways to prevent greater damage. you'll note that i was quiet all night and over the morning, and this is the first post since yesterday, and since people are generally not asking "WHERE'S MY TOYS?!?!?!?! AREN'T YOU DONE YET?!?!?!?!", i'll probably go quiet for a while.