AetherGoddess

Quick FYI: Unity on Windows is Fully case sensitive. i found this out the hard way when playing with textures for my ART expansions.

Same as it ever was. -OpenGL doesn't change any limits, it just fails to load the code allocate extra texture memory to support DX9/10/11, so memory USAGE goes down.

i'd like to throw in here that the Win64 specific code JUST shows the nyancat, and then does nothing else. all other code is identical between x64 and x86; there is no other changes to the behavior. you are given "a choice and one warning". the warning is just cute.

i'll be a smartsas: B9 is a parts mod. it doesn't have any code that could be incompatable with Win64. Granted B9 has plenty of plugins it depends upon, like Crossfeedenabler, Firespitter, JSI,KineTech, Klockheed, ResGen, Virgin Kalactic, etc. and some prerequisites that explicitly don't support Win64, like FAR & NEAR, but the way Unity (actually .Net) handles plugins, there isn't any difference between x64 and x86 code. All of this is immaterial when compared against the known Win64 instability. the Win64 version has some unknown memory allocation bug that fails spectacularly when allocation approaches the 32-bit line. this is why Ferram, among others, don't support Win64. it's too hard to sift through the default bugs to find actual bugs caused by the mods. in summary, as you already know, B9 has A LOT of stuff in it, and by itself it can crash a 32-bit version with an out of memory error. so if we have a known stock bug when you get past the 32-bit line, and a mod that can push memory over the 32-bit line by itself, then that mod will trigger the stock bug regardless, and make it seem like it was the mod's fault, when really the same amount of memory with ANY mods will trigger that bug.

So the reason that Win64 warning is there is because Win64 is unstable. like, really unstable. fortunately, the source is available and you can disable it and recompile for yourself. if you can do that, then you've proven you understand code well enough that can tell the difference between a crash from MM and a crash because of stock Win64 weirdness, and you aren't going to come back here with bad bug reports. otherwise, considering ATM as a way to reduce memory pressure. i run 35-ish mods, including B9, on Win-32 with no problems.

this is a known issue with Firespitter. go over to Firespitter's thread and get the loose DLL experimental version. SNJO hasn't had time to properly test it, which is why it isn't a regular release.

for this particular instance, read my insightful commentary, then move on since it's a false alarm. for the general case, Virus Total is a good way to check out if it's a false alarm in your scanner, or something worth worrying on.

in polite society, "please don't" and "do not" are very much the same thing. the space between "you're allowed, but don't" "don't" and "you're not allowed" isn't much unless you're willing to ignore the other parties wishes. the prisoner's delema and the tragedy of the commons is an interesting comment on this.

the problem with PWings is that you can't be sure how large it is at patch time, so you'd need a runtime plugin to do some dynamic mathmagics to get the fuel capacity right. if you wanted to just add a static value to all PWings, then you could do an easy MM patch to add the resource amount and a crossfeed enabler node, but then every Pwing, no matter how big, would have 150 fuel, or whatever.

Given region coding, it would need to be then: @MODEL[NAME]:NEEDS[Prerequisite]{ @texture,0 ^= ^.*)Squad/(.*$):$1SquadB/$2: @texture,1 ^= ^.*)Squad/(.*$):$1SquadB/$2: @texture,2 ^= ^.*)Squad/(.*$):$1SquadB/$2: [...] @texture,N ^= ^.*)Squad/(.*$):$1SquadB/$2: } since we want to copy the prefix bit unmodified.

well, this should be an interesting fist fight, considering how we JUST got over the CC fiasco. +10 points for checking with the authors before posting, -15 for ignoring what they told you.

your life was too easy before. have some bugged textures. GOOD LUCK! Features for next version: texture files are now in UTF-15 as an un-ordered list of radial coordinates and Pantone Color names.

i'll give you the general case, you can extrapolate the specific one: download and install the basic mod as normal (skip this step as needed) Download the DLL in question Find the identical DLL in your mod's directory Put the new DLL in the same directory, allowing it to overwrite ... prophet (possibly Sir Jeb of the graceful crashes?) ??? Enjoy KSP+Mod+Updated DLL

Hurray for joint solutions. Final Answer: @MODEL[NAME]:NEEDS[Prerequisite] { @texture,0 ^= :^Squad/(.*$):SquadB/$1: @texture,1 ^= :^Squad/(.*$):SquadB/$1: @texture,2 ^= :^Squad/(.*$):SquadB/$1: [...] @texture,[I]N[/I] ^= :^Squad/(.*$):SquadB/$1: }

Do i need to add Rock to the ART for CRP? seems redundant. let me know.

Thermal rockets require Thermal Power and something to heat. Thermal power requires a reactor with it's own fuel (i.e. Antimatter) and radiators. remember that all reactors in .13 do not have their own internal storage, so you have to add a fuel tank and set the fuel mode of the reactor accordingly. something to heat can be LFO, LF, Argon, Xenon, etc, all of which have their own ISP:Thrust trade-offs. if you right click the rocket, you should be able to toggle the fuel mode between various fuels on the ship. if you are using Thermal Turbojets or Thermal Hybrids, then one of those fuel options will be intake air or intake atmosphere.

I have personally used this with both Kethane and Fine Print. i would avoid any mods that use the CRP, however, as some resources are used in both this mod and the CRP. if you use any CRP mods, then consider using either Wave's KSPiLITE release, which already has CRP integrated, or undercoveryankee's adaptation pack that fixes KSPi to play nice with the CRP.

Liquid Fuel and Oxidizer: essentially the same stuff that most regular rockets use. Most of the Thermal nozzles are explicitly marked as such. the Thermal engines use Thermal power, which requires a reactor and they break down into two classes: Thermal rockets, which heat and expel fuels without atmosphere, and Thermal Turbojets, which heat and expel only atmosphere. Thermal turbojets can be upgraded to be Thermal Hybrid rockets, which can use intake air, LFO, LF, or sometimes more exotic fuels. Make sure you have 1) enough fuel for the reactor in the form of Uranium, thorium, deuterium, tritium, or antimatter 2) enough thermal reactant, in the form of Liquid fuel, LFO, or intake air, and 3) enough radiators that your reactor doesn't melt. thermal engines throw off waste heat, but not generally enough to keep the reactor cooled in vacuum. related, there are three classes of Electric engines, Plasma rockets, Arcjets and Magnetic Nozzles, all of these require megajoules, not thermal power. Plazma jets are essentially high-thrust Ion engines, that expel high temperature charged plasma. Arcjets use electical arcing to add energy to the propellent. Magnetic Nozzles take advantage of focused charged particles put off by reactors to create thrust for the craft. all of these require a generator attached to a reactor, and the magnetic nozzles require a charged particle source, such as a fusion reactor.

try this: @MODEL[NAME]:NEEDS[Prerequisite] { @texture ^= :^Squad/(.*$):SquadB/$1: } the @Property syntax is edit, the : is your section seperator, carat ^ in the equals means use regex, carat in the string means start of string, ( and ) denote input Region 1 and $ in the string means the end of the string, and the second bit shows the output. with $1 meaning whatever was in input region 1. of course, since the properties are identically named, you'd have to index them (i think? never had to do that, wasn't even sure it was possibly). someone else is going to have to help with that. Related: THIS is a great regex test tool

i don't think they're on the same spectrum. NFT is things that exist now (in proof of concept at least) implemented in a realistic way (ref: Capacitors as EC usage limits), KSPi is things that are not conclusively ruled out by conventional physics implemented in a realistic way (ref: fuel cycles and tank designs that assume an associates degree in nuclear chemistry), and KSPiLITE is not conclusively ruled out implemented in a game-play focused way (Ref: Simplistic reactor cycles, CRP resource sharing, closer to stock balancing). not only is there space for all three, there is good reason for a lite implementation: letting the users chose how far into the fiddly details they want their gameplay to reach. FAR has NEAR; Real Fuels vs Near Fuels; TAC-LS, Interstellar LS, and Snacks are all different positions on that axis; MKS even acts as it's own: with or without life support. Mechjeb is probably the best example of fiddly-detail-be-gone mods, as it has methods to automate almost all of orbital navigation, allowing gameplay to focus on planning, logistics, operations and other "higher-level" concepts. i'm obviously biased, but i really hope Wave continues to release his private version for the rest of us. it seems like he spends much more effort on balance and polish the the default release, and that effort shows in easier usage and more meaningful gameplay choices.

added bonus with the needs syntax, anything under that mod will not be added if the dependancy isn't there. you could easily define the part as a static stock PART {} and then have a seperate MM patch that adds remote tech and be fully operational with or without remotetech.

i'm sooo excited! i've been waiting for someone to solve the tech tree problem so i could break back into my .24 KSPiLITE .12 save. do we know if .12.3 works with .25? is wave planning an update? giddy like a schoolgirl.

i've been considering this for a while, as a counterpoint for my CRP resources mod, but i don't use RealFuels, so i don;t know what i should concentrate on and what colors make sense. would you be willing to throw out some guidance so i can make sane textures?

Nothing is really compatible with Win x64. Unity doesn't much care what architecture it's running on, since all of the plugins are mono (Microsoft's .Net architecture agnostic bytecode) and are interpreted in real time. where most things will disable themselves or not support x64 is because Win x64 itself is not stable. like, really not stable. Like, "log rolling championships during a hurricane" not stable. the unmodded release runs ok, almost, mostly, but adding even one mod, gives you a much higher chance of crashing due to memory access issues, and the closer you get to the 32-bit memory limit, the more likely it is to blow itself up, regardless of what mods you use. Linux x64 and Mac x64 SHOULD run ok.

On Winx64, practically: This isn't really feasible, as each of those mods have their own disabling code, usually within their own classes. this trick with this was that Khatharr was overwriting the CC class, which lots of plugins call. in order to do this for FAR, for example, an author would need to replicate all of FAR with that one line disabled. while this is technically possible, and even doable for some mods with permissive licensing, the workload would be DRASTICALLY higher, and it's a much much more direct F-U to the mod maker, who is 1) largely doing it to improve the game for you in the first place and 2) now much more likely to lock down their licensing to prevent rogue editions they have to support (Ref: Treeloader in .25). On Winx64, Philosophically: there is a reason these mods disable themselves, and it's WAY bigger a deal then a compatibility warning. the CC warning was a "FYI: we don't know what's gonna happen. you're on your own". the Winx64 shutdown is "we KNOW this doesn't work. you ARE going to experience issues. IF you want to take your life into your own hands, you need to disable the safety features in a way that proves you understand the potential risks and problems". to extend a previous analogy: breaking CC is disabling the check engine light on your neighbors car for their convenience, enabling Winx64 is like removing all the control and throttle limits, so if they steer too hard or push the gas too hard the undercarriage or engine will shake themselves apart, for your neighbors convenience.