rynak

I would recommend to not add even more "hack". The squad code is an ugly bruteforce kludge. Your solution is an ugly bruteforce counterkludge. Try to keep things horrible, instead of turning them into a lost case.

And total commander thinks so too. Wrong filename extension maybe?

Well, you can do sync orbits and get them sufficient range by using the smallest dish for neighbour comms, instead of an omni.... inefficient and pointless, but it would work. The major downside however, isn't comms with neighbours, but instead comms with vessels: if the sats are this far away from the planet, then then the other party needs rather big antennas too - after all, remember that for communication, BOTH parties must be able to reach each other. This being said, one problem i couldn't solve efficiently yet, is giving vehicles in the atmosphere a link to KSC almost all the time: If i put sats lower than 1000km, i start approaching the point where 4 sats are no longer safe - i'd need five sats or have to place them VERY precisely. If i put them sufficiently high instead, then a plane somewhere in the atmosphere cannot uplink to the sat, because the atmo-safe antenna has not enough range. That reminds me: Where is it defined anyways, how a model reacts to atmospheric pressure? I've seen almost everything editable, except of that. Is it part of the model file? Or is it in the compiled code?

Not to be the killjoy, i'm not sure if you folks got your priorities right: 1. You're asking them to make water MORE complex, BEFORE they fix its embarassing performance? 2. You're asking them to have proper water physics, while kerbals still randombly crash into planets by merely walking on them? 3. While rover physics require rather weird design decisions (or hacked parts) to behave like... wheeled vehicles on kerbin? You know, one of my modulemanager scripts has this in it: // KILL IT WITH FIRE!!!!!!!!!!!!!!!! !PART[roverWheel2] {} You cannot drive 10 metres with this thing, without calling the kraken - and this is the first stock wheel you get in the game. Problem? 4. Aerodynamics. Nuff said. Long story short: Yes, i agree that "someday", water should get a very simple physics model, but saying that this discussion is premature, would be the understatement of the month.

Personally speaking, no popular mod should use :FINAL - it should be exclusive to custom user scripts - similiar to !important in CSS. Of course, this is assuming that MM has proper alternatives to :FINAL, for devs.... and i'm not sure if it has.... the official docs don't even mention loadorder directives at all - without picking up rumors on the forum, i wouldn't even know about :FINAL. Someway, i've seen :BEFORE and :AFTER in other threads... i guess those are meant to define execution should happend after a certain part.... or directory.... or..... something.... is loaded.... or modified? Who knows....

Wait, i CAN fire kerbals without enabling permadeath and killing them? Even Jeb and Co? Those three annoy the heck out of me - i don't want to pay for crew i'm only having because i'm forced to. On the other hand, if this mod DOES let me fire them without them returning as zombies - i might actually be willing to pay for just that, by paying my other crew.

I know that multiple copies do get along, if they are the same version - the problem is that this is forced provocation of version hell: If the plugin expects a lib to be at a specific path, then one is forced to keep multiple copies of the same lib - and has to keep them all redundantly updated to avoid version SNAFU! That is trouble waiting to happen. Compare this to the user simply being able to keep one updated version of shared libs in ksp/gamedata/. Anyways, since i recently had to learn how to use a C# IDE and how to compile on it, i now understand what the smartparts dev was talking about. Apparently, all he did was to define the reference to use a "local copy" before compiling. The IDE will copy the DLL into the release dir, but you can just ignore it - all that matters is, that this way apparently DLL-refs aren't hardcoded to specific paths - at least, that's how i understand what happened. EDIT: Will now DL and try current IR version. EDIT2: Works now! No more hardcoded DLL paths.

This might be false alarm, but i might have some hints about stuff not showing up on the monitor, even though they're available. I first noticed this with DMagic's Orbital Science. Weeks ago in 0.23.5, everything worked fine. Then sometime during the upgrade mania of 0.24, apparently he changed his approach on how his experiments work - for example, his partfiles now have situation and biome flags in the module metadata, while the sciencedefs instead have their situationflags and biomeflags zeroed. At this point, experiments did no longer show up in science monitor. Then i went and edited the sciencedefs, to give them back the proper situation and biomeflags - now everything works again, except of one part: the laser scanner. I can operate it manually via rightclick, but it no longer appears as available experiment on the monitor. Though, maybe i made a mistake somewhere, not sure.

Thanks for this! This seems awesome - i can't remember how often i had to fiddle around with stuff when setting up staging. This should or something equivalent should be stock - after all, stock already colors parts on hover, just so subtle that one can barely see it, and certainly not when the part is obscured - which happens all the time for radial decouplers.

Thanks for the quick info shaw About squares.... i checked the readme again - the statement is under the visor section. Sorry, i didn't figure out that it only applies to those.

Well, since you're putting it like this, nereid - which is a reaction i really wasn't expecting: Plugin deleted. I won't bother you anymore - permanently.

Errr, again: Did you THINK about what people say - in this case me? I wasn't refering to gamdata, but putting files in "gamedata/nereid/FinalFrontier" as opposed to "gamedata/FinalFrontier" or if you want to avoid naming collisions "gamedata/nereid_FinalFrontier". Oh god... What the hell? First you're breaking the PURPOSE OF A FILESYSTEM, and then you're inventing ADDITIONAL software to manage, to deal with what you broke? Do you like to CAUSE problems, so that patches to the SYMPTOMS can be justified? What is this - pharma? I'm sorry for putting it like this - i respect you a lot for your work on KSP, nereid. Your plugins greatly add to my and other's game experience. Still, what you wrote above, is quite simply retarded. Who cares when the user cannot even find the plugin he's looking for??? Unless one memorizes which "vendor" made which "product", one has to browse through EVERY GODDAMN DIRECTORY by trial and error, to find the "product" one is looking for. THAT is confusing, and most of the devs you mentioned in the quote are doing this crap. Again, anyone responding to such criticism with "namespaces!" i can only call devoid of any creativity: You want your oh so important name as a unique identifier (namespace)? Then just make it part of the directoryname! gamedata/Vendorname_Productname/ <-- was that so hard?

You're looking for the wrong icon. That FB icon isn't the icon to do fuel balancing. It's a red one without letters.

Got two simple questions: 1. Does TextureReplacer replace textures (old ones removed from RAM), or reassign textures (old and new are in RAM, but only new one is used)? And is it the same for those in gamedata as well as ksp_data? 2. The docs say only to use square textures. Does it actually mean square only, or does it mean powers of two? Some of the squad textures aren't squares.

The way he phrased it might not have been appropriate, but i don't really see why forcing a button onto the users screen is a reasonable choice, unless that button is strictly needed for proper function of the mod. After all, others have mentioned this before. You might not want to implement toolbar integration, but at least a way to permanently disable a not-strictly-needed UI element wouldn't be too much work? Or is the hide-setting remembered in the configuration? If yes, then forget everything i wrote - don't see what people are complaining about then - except maybe more prominently telling them about how to disable the button - after all, since it is a "frequently asked question"... well....

FYI, the is/was definatelly a problem with kspapiextensions.dll or the way you linked to it. I reported this already in the smartparts thread, because it had the same issue. How it became visible to me was, that IR as well as smartparts suddenly cared about the exact location of the DLL - i.e. moving kspapextensions.dll to /gamedata/ would make KSP freeze when loading the IR parts (or smartparts parts for that matter). You might want to check the last few pages of the smartparts thread, because he solved it somehow - mentioned something about locally linking them, or similiar - i'm not too familiar with C#/Unity terms regarding compiling/linking, so can't explain what the smartparts dev did.

While the new common font certainly looks more stylish, it is less functional because at small sizes/low resolutions it performs much worse in readability. My estimate is, that this is so, because it is taller/narrower than the old font. The problem can be best seen with the most heavily used inflight widget of all: The navball. Or more specifically the speed readout. To restore the old readability, the font would have to become taller than the old one - because right now the readout has the same height, but less width compared to the old font. Other places are affected in the same way, but the navball is where the problem is most obvious (and because of its frequent use, disruptive to gameplay). In short, the old font was more readable at a given size - to maintain the old readability, fontsizes would have to become 0.5-1.0pt larger in many places. That's the cost of choosing a font based on style, rather than function.

Not only do two wrongs not make a right (but they DO "compensate" - there's a difference , the stock behavior is much weirder than compensating wrongs: In stock, the drag depends on weight.... WET WEIGHT. That's right, in stock, drag changes as you empty your fueltanks. This makes launching vehicles experience much stronger drag, than landing vehicles. If in stock you fly with almost empty tanks, you get similiar drag to that in FAR, NEAR and SDF.

That is what Kerbal ISP Difficulty Scaler is for. The stock drag values are wrong, but fixing them in turn makes engines too powerful and deltaV too abundance - KIDS fixes the thrust and ISP issue.

I have updated it...... a lot..... i don't think my customized version remotely resembles the original gameplay (Resistorjets? Gone. I repurposed the models to play the role of a hybrid eletric/rocket thruster tech instead). So why'd i even bother? Well, a few reasons: - It includes engine sets for three electrical technologies - Each set has a small, radial and medium engine - All of those visually follow a consistent design - They look nice and have sounds, yet aren't bloated with high polycounts In short, even if you completely ignore gamemechanics, it just generally is a really well designed set of engines. The problem of course is, that i'm taking someone elses models and sounds, and then use them for my own idea of eletric engines. That's fine for personal use - but doesn't exactly make it good for public distribution. Then again, i could simply distribute the configfiles alone, without the art. But again, as i said: This doesn't play like original RLA eletric anymore at all - its something else.

I don't know if -everything- works perfectly, but i do know this for the 32bit version: 1. The monitor button properly shows up 2. The monitor window properly displays experiments while landed on the runway 3. The buttons to quickly perform experiments, work on the runway

The reuploaded version now works with the updated kspapiextensions.dll in /gamedata/. Here's something for those adventureous: // instead of having seperate fuel breakers, just add the functionality // to all decouplers and seperators - which are the reason in the first place, // why you need such a feature. // mini @PART[stackDecouplerMini] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // mk1 @PART[stackDecoupler] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // s2 @PART[decoupler1-2] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // radial @PART[radialDecoupler] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // radial extra clearance @PART[radialDecoupler2] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // radial strong @PART[radialDecoupler1-2] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // mini @PART[stackSeperatorMini] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // mk1 @PART[stackSeperator] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // s2 @PART[stackSeperatorBig] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } // pylon @PART[structuralPylon] { %fuelCrossFeed = False %MODULE[KM_FuelController] { %flowEnabled = false } } I did NOT test this extensively - just checked if the tweakables are there on the runway. It only includes decouplers/seperators for mini, mk1 and S2 - as well as the structural pylon. S3 and the like, you'd have to add yourself - the repetitive pattern in the code should be obvious - just copy'n paste and change the name of the target part. @dtobi: It is quite limiting, that one cannot set the initial crossfeed state in the editor - the tweakables are only accessable once launched. Would be great if you could address this small but important limitation.

Heh. Thanks for the info - didn't know this. Why on earth is this.... oh nevermind... why do i even ask anymore.

Ya don't say - that was my point, because YOU were argueing just that >.> Not going to reply to your other questions - you seem a bit too confused for my taste (i don't even know where to start correcting all your wrong assumptions in your post.... mass assymetry? Did you even check if thickness influences mass? (It doesn't, heh) And even if it would - what makes you think that parts can have their CoM elsewhere than at their center? *grin*

Update: It is not the version of kspapiextensions that seems to be the problem. Rather, here it seems as if..... don't ask me how..... that this version of smartparts hardcodes the path to kspapiextensions. If i move the updated version of the lib to where it was in the archive (thus, having two redundant copies of the same lib version, at different locations), then KSP loads fine. EDIT: The same behavior seems to apply to the current (EDIT CORRECTION) Infernal Robotics release! What crap is this - forced version hell?