AetherGoddess

Here's something i learned recently. KSP is case sensitive about the extension. i.e. "Blah.cfg" will work, "Blah.CFG" or "Blah.Cfg" will not be read at all by KSP. Not sure if this is relevant here, but it certainly confused me for a while troubleshooting my last patch.

Here's a complication you might not be thinking about: if you have two samples on your ship, you get science credit for both. i.e. if you take a gravity reading, and store it in one command pod, and then take THE SAME GRAVITY READING and leave it in the detector, and then recover that vessel, you get the same credit as if you had recovered both of them in separate missions. this is why xEvilReeperx specified:

Update! i have mistakes and fix them! also agencies!

i'd like to humbly suggest that Hyperedit already has a lot of orbit editing tools, and this mod should focus on what it already does very well, that is, communications and control. BMW doesn't make petrol, even thou every single one of it's products needs it.

i'm kind of a completionist, so I usually set the global limit to 1 science. anything less then that, even if i'm recovering, it's worth the hassle, and the squelches all of the "you have .00000009 of a science point to do right now" type alerts.

Very cool. more instrumentation is always better. Thanks for all your hard work.

This is a module manager patch. put it anywhere in GameData and module manager will read it and make the corrections. you should probably put it in a folder seperate from both ScanSAT and RSS, so you don't lose it in updates.

you have already exceeded the quota of support for Win x64 with this post. yes, you can get the source and turn off the disabling code, and then recompile it and use it. that task works as a sorting filter. if you can make that minor code change and compile it for yourself, then you are certainly knowledgeable enough to tell the difference between a crash caused by FAR and a crash caused by KSP_x64. if you can't, then it doesn't mean you are dumb, and it doesn't mean that you are somehow unworthy, it just means that we can't be sure that you have the necessary skills to run and troubleshoot an unstable version. you can think of it as a driving test: if you can download the zip and install it, then you can drive an automatic passenger car. if you want to drive a F-18, then you need to pass a higher bar. He did one on FAR. the entire script of the video on NEAR could be "like FAR<annotation link> but simpler <outro>".

there is a post immediately above you where the poster PUT A VIDEO of it working in .25. there is literally nothing else that can be shown to prove it works. video of it working is probably the highest form of proof available that it works.

i'm pretty sure this is exactly what KSPi antimatter collector does, but it requires extra plugin magic to generate the resource at the correct rates. specifically, i believe the collector part checks the local magnetic flux values, and then generates antimatter at the correct rate. i THINK(?) ORSX could PROBABLY(?) be used to generate the resource while outside in the sun's sphere at certain altitudes, but that's something rover would need to address. Alternatively, you could have your collector require the electric charge you want to collect and compress the resource and have it output the resource we already have. remember, KSP is a simulation, it doesn't understand that Gaseous hydrogen and liquid hydrogen are the same thing with different states, all it knows is part 18723 takes 1 unit of resource 221 and 1 unit of resource 300 and produces 1 unit of resource 321. if you have a part that you want to produce hydrogen as if it was collecting it from space, then just have it take the right amount of electric charge and output the right amount of hydrogen. this is all going to be in the balancing, not the modeling. you could simulate every possible interaction between every molecule, but if your requirements are off by 10%, then it's impossibly easy to get hydrogen. on the other hand, if you simplify the model, and just accept that you are simulating, and work hard to get the numbers right, then your "magical hydrogen generator" will be scientifically accurate.

i have always just accepted that it's not going to be perfect and i just put extra nodes in the network and use omni's to keep them linked, rather then dishes

seems like insufficient lift for level flight.

So a little bit about the way 64-bit versions of windows allocates ram to 32-bit processes. the 32-bit part of that is the largest number the program can understand. with a 32-bit number, you can reach almost exactly 4 gb of ram. in this 4 GB address space (the technical term) windows must fit all of the functions that the program needs, and all of the textures, images, models, code, mapped files etc that the program uses to run itself. this 4 GB address space must cover everything the program needs, because the program simply doesn't have numbers large enough to look anywhere else. This 4 GB address space is why 32-bit versions of KSP crash with an out-of-memory error around 3.5 GB, even when you have 8 or 12 GB available to the operating system. the program is using 3.5-ish, and relocated windows APIs, hardware interfaces, and other system things that the programs needs to use are using the remained. this is also the reason why the community pushed so hard for a 64-bit version, and why we're all so disappointed in it's stability. 64-bit numbers can address something on the order of 16 million terabytes, well in excess of any currently existing system. Something is using that ram, but it doesn't appear to be KSPs memory allocation. Ya, this would not work. because it's running out of address space, the program would need to release the files as well, which would force them to be reloaded from disk just like during startup. basically you would see the same loading screen at boot time whenever you change scenes between the VAB and the launchpad.

not necessarily. Treeloader is used to generate the new research nodes that go beyond the stock tree. some parts could be moved into stock trees, but some parts of the plugins look for these specific nodes to be researched to (among other things) enable retrofits and advanced behaviors. The lack of treeloader definitely closes off science and career modes, but sandbox works normally, and all that would really be required would be another plug-in that controls research nodes. treeloader has been so good at what it did for so long (ever since .22 when science was first added) that there are no alternatives yet.

i doubt this is the issue. modulemanager has a long history of safely disabling older versions of itself. Definitely remove it, but there's something else going on. Your log clearly shows an out of address space condition: namicHeapAllocator out of memory - Could not get memory for large allocationCould not allocate memory: System out of memory!Trying to allocate: 1398104B with 32 alignment. MemoryLabel: Texture Allocation happend at: Line:411 in Memory overview [ ALLOC_DEFAULT ] used: 298914531B | peak: 0B | reserved: 326705928B [ ALLOC_GFX ] used: 728248622B | peak: 0B | reserved: 755820230B [ ALLOC_CACHEOBJECTS ] used: 193832B | peak: 0B | reserved: 12582912B [ ALLOC_TYPETREE ] used: 0B | peak: 0B | reserved: 0B [ ALLOC_PROFILER ] used: 536076B | peak: 0B | reserved: 8388608B Oddly, the memory summary shows 2032 MBs in use and reserved. are you running on a 32-bit version of windows?

Yes, absolutely. my intention is to create new parts, and the first step in that is giving the new copy a unique ID. This is ideal, actually, because i can convert from modifying the provided parts to creating my own copies that won't step on the originals. it also gives me a nice easy way to modularize the project, which is something that I've been struggling with.

The behavior does appear in FAR, but again, it also appears in stock. stock doesn't model aerodynamics in any real way, so the rotational force that is applied has the same effect as it would in vacuume, a slow rotation that poses no real risk to the spacecraft. FAR does model aerodynamics, so a small change in the pitch angle has a huge effect on the stability of the ejected booster. In short, FAR is correctly modeling the physics, and the stock decoupler rotational force bug puts the SRB into a configuration where it will rotate into the spacecraft, instead of away from it. This is why tweaking the force to zero corrects the issue, because if there is no force on the decoupler, then there is no rotation, and the part drops away as expected.

Yes, that +PART[] syntax was exactly what i was looking for, i'll have to go play with that.

this is odd, recent versions of ScanSAT use ORSX, and no longer use ORS.

i'm really not in a position to speculate on how busy Snjo is, or how much effort is required to produce a "quick fix". the rumor running around that Squad's new found space plane love has made several changes to the flight code that affect Firespitter, but i haven't seen that confirmed. the long and short of it is that the new version will come when it's ready, which, hopefully, will be as soon as Snjo can produce it.

Here's a thing: I've been thinking about extension mods; mods that modify other mods. Specifically, i want to be able to write a MM patch that will "clone" and existing part, make a number of modifications to the clone (including identifiers, like Name, etc) without modifying the original, and then add it into the database parallel to the original with all of the values from the original plus my modifications. i'd rather not statically copy the original part, because the original mod maker may make adjustments, and i want these adjustments to happen in the cloned part, unless i have specific reason to override. i haven't though too much about it, but i suspect there is already quick and easy syntax to do this that i simply am not seeing.

unfortunately, this is the case for almost everyone, regardless of the mods they use. i think you might find, that if you take out the mods you are running with now, and put in a equal number of "bad" mods, you'll have the same stability. the crashyness of Win x64 isn't due to mod behavior, it's crashes inside unity or squad code that only become apparent when the memory exceeds squads default part set. i'll prognosticate one step further, and say that if you look at the crash logs, you'll see the stack trace ends in something like "((module-name not available)): (filename not available): (function-name not available) + 0x0". this means the exception occurred in some module, file, and function for which we don't have debug symbols. almost every mod maker complies with debug symbols built in, because it makes it SOOO much easier to find exceptions in the logs, which is often all mod makers have for troubleshooting. this means that the exception occurred somewhere on squads side of the wall, either KSP or Unity... posts like your last one (specifically "If I take out those troublesome mods, I have no crashes at all.") are exactly the reason why a lot of mod makers have stopped supporting Win x64. they're being blamed for failures that aren't theirs and they can't do anything about.

while i agree with you, there is nothing the B9 team can do about that, and i don't think Squad is willing to take ownership of that code, even if Snjo would release it to them. it's very unhelpful to tell B9 that the parts they depend that are produced by a 3rd party should be included in a 4th party's release.

to be fair, this mod includes something like 9 experiements? i'm not sure if it's more then all of the stock parts combined, but it's certainly close (and i'm too lazy to do more then a fermi estimation on that).

my intention was not to patronize, and i'm sorry it came off that way. i have been answering the exact same question in about 30 threads since the .25 release, so i'm a bit frayed in that area, but i still shouldn't have let that affect our conversation.