Lisias

About the Item 2, it depends more of the engines you are using. RAPIERs use a lot of fuel, but have excellent thrust at high speeds. So, if you use them, it's better to reach the maximum speed you manage to get without barbecuing your vessel at low altitude (where it's easier to get the oxidizer from the atmosphere), and then pull up - taking full advantage of the engine on ascension. On item 3, the best way is to use Kerbal Engineer. It shows you that on the screen. On item 4, it helps more in order to prevent the landing gear to be torn out due dynamic pressure or blown due temperature. I didn't noticed a serious drag on the stock gears - but, granted, I didn't tried enough. Now, about the X-Wing design, it's a somewhat wild guess, but the W-Wing when extended would be nice for having tons of lift, as they used on the biplanes (besides a bit being "wasted" as the wing are twisted, and a fraction of the force vector is not used to lift up - but would help on turns). High speeds don't need so much lifting-surface, and surely don't like the extra drag. But since the X-Wing can folder the wings, halfing the surfaces and so , the drag, I think that the X-Wing could be a good design for a atmospheric vessel - if one manages to get gears and motors strong and light enough. :-)

try this: open your browser type "steam://nav/console" type (use enter to finish the command) download_depot 220200 220202 333878936698232953 if you use OSX download_depot 220200 220203 2817888699278877812 if you use linux download_depot 220200 220204 1261045722296694888 if you use Windows 64 bits Wait until the message "Depot download complete : "<some_path>/Steam/Contents/MacOS\steamapps\content\app_220200\depot_220202" (2341 files, manifest 333878936698232953)" (slightly different if you use linux or windows). That huge path is where the files are. Move it to where you want them.

Hi. This is to advise that I just opened this issue on GitHub.

Hi. I found a typo in one of your configurations file. In GameData/Endurance/MiniAVC.xml , there's a value with "True", instead of "true", and this is raising exceptions on KSP.log: [LOG 14:59:17.966] MiniAVC -> System.FormatException: True is not a valid boolean value at System.Xml.XmlConvert.ToBoolean (System.String s) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlCustomFormatter.FromXmlString (System.Xml.Serialization.TypeData type, System.String value) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.GetValueFromXmlString (System.String value, System.Xml.Serialization.TypeData typeData, System.Xml.Serialization.XmlTypeMapping typeMap) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadPrimitiveValue (System.Xml.Serialization.XmlTypeMapElementInfo elem) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadObjectElement (System.Xml.Serialization.XmlTypeMapElementInfo elem) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadMembers (System.Xml.Serialization.ClassMap map, System.Object ob, Boolean isValueList, Boolean readByOrder) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadClassInstanceMembers (System.Xml.Serialization.XmlTypeMapping typeMap, System.Object ob) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadClassInstance (System.Xml.Serialization.XmlTypeMapping typeMap, Boolean isNullable, Boolean checkType) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadObject (System.Xml.Serialization.XmlTypeMapping typeMap, Boolean isNullable, Boolean checkType) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadRoot (System.Xml.Serialization.XmlTypeMapping rootMap) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadRoot () [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializer.Deserialize (System.Xml.Serialization.XmlSerializationReader reader) [0x00000] in <filename unknown>:0 [LOG 14:59:17.967] MiniAVC -> Executing: MiniAVC - 1.0.3.3 [LOG 14:59:17.967] MiniAVC -> Assembly: /Users/lisias/Applications/Steam/steamapps/common/Kerbal Space Program/GameData/Endurance/MiniAVC.dll [LOG 14:59:17.967] MiniAVC -> Starter was created. [LOG 14:59:17.967] MiniAVC -> System.FormatException: True is not a valid boolean value at System.Xml.XmlConvert.ToBoolean (System.String s) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlCustomFormatter.FromXmlString (System.Xml.Serialization.TypeData type, System.String value) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.GetValueFromXmlString (System.String value, System.Xml.Serialization.TypeData typeData, System.Xml.Serialization.XmlTypeMapping typeMap) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadPrimitiveValue (System.Xml.Serialization.XmlTypeMapElementInfo elem) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadObjectElement (System.Xml.Serialization.XmlTypeMapElementInfo elem) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadMembers (System.Xml.Serialization.ClassMap map, System.Object ob, Boolean isValueList, Boolean readByOrder) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadClassInstanceMembers (System.Xml.Serialization.XmlTypeMapping typeMap, System.Object ob) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadClassInstance (System.Xml.Serialization.XmlTypeMapping typeMap, Boolean isNullable, Boolean checkType) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadObject (System.Xml.Serialization.XmlTypeMapping typeMap, Boolean isNullable, Boolean checkType) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadRoot (System.Xml.Serialization.XmlTypeMapping rootMap) [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializationReaderInterpreter.ReadRoot () [0x00000] in <filename unknown>:0 at System.Xml.Serialization.XmlSerializer.Deserialize (System.Xml.Serialization.XmlSerializationReader reader) [0x00000] in <filename unknown>:0 On a side note, MiniAVC has a bug: a faulty configuration file on some Mod breaks the chain, and prevents the MiniAVC from working for the remaining ones! As a workaround, I edited my local file but I would advise to fix it on the code repository. Thanks.

Some deletions and perhaps CFG editing will fix this. I like the Kerbin Kampus, but I prefer your approach lights. :-)

Answering to myself, in the hope to be useful to someone else later: yes, you can have both (classic and remastered) Kerbin Side installed. Until the moment, no glitches but some overlapping buildings on KSC.

And I explained why this is not needed nowadays, even on C#. This is a public forum, you're not the only one reading. I tried to explain the issue in terms that everybody would understand, and not only you - to tell the true, I'm pretty sure that you are the one that can explain a lot of things to me, and not vice versa. :-) I saw your interjection as a rhetoric, in the meaning "this is nuts". Experienced people like us would understand it promptly, because we have the technical and historical knowledge of the thing. Younger people rarely have the historic, and contextualization is a good way to help remembering things. In time, this was not bad coding practice in the time. It was bad not to do it. It's a anti-pattern now, but not then. And this make a lot of difference: it's a lot easier to convince someone that he's only need to update this knowledge a bit, instead of saying "you are nuts" and that's it. :-) And, by the way, there's a lot of old time coders around that did such coding in the past but are not professional developers since long time. They're also reading this.

I don't see a problem on "rebuying" major releases. To be honest, I think it's more cost effective. Monthly subscriptions have transactions costs that pile up. So, essentially,, making a single 12USD transaction is more lucrative than making 12 at 1USD each. Of course, they can do annual subscription - what would be essentially "rebuying major releases" with another name. :-)

Credit must be given when credit is due. This version is not just a "patch", some serious development appears to be made. I was using 1.4.1 due some glitch I got on 1.4.2 on editor, and one of my (really, really) stupidly big vessels were making KSP eating about 10 to 11G of RAM on my MacOS. Since my KSP is awfully full of mods =P, it probably be something on the mods themselves - so, I'm not claiming anything on KSP. Well... I'm giving 1.4.3 a ride, and KSP, on the very same vessel, is now using 6G of RAM, with somewhat better framerate (what's not a surprise, due the nasty memory compression thing on MacOS). Again, it could be something related to a Mod, but since I (maliciously =P) just did a copy from the whole GameData (without Squad's, obviously) to the new installation and fire it up to see what happens... Yes, I'm good impressed. :-) This is the kind of improvement that "forces me" to tolerate some glitches (as the one that made me stick with 1.4.1). I'm hoping that glitch is gone, but I would complain a lot less about it now. :-)

In the beginning of time, when ANSI C compilers were a lot dumber, there was very little optimisations available while code generating. So you had to do it yourself. Knowing that for (int i = 0; i < n; ++i) { something(i); } is kind of a shortcut to { int i; for (i = 0; o < n; ++i) { something(i); } } , and knowing that scoped variables are allocated on the thread's stack at the declaration and the stack is cleaned on the end of the scope, you used to get significantly speed gains (by preventing such code to be generated) by using this stunt. Even nowadays it's a issue. But nowadays the compilers automatically detects these situations, reusing the stackspace when successive scopes declares variables and/or delaying the stack cleaning, doing it out of loops. Google for "Variable coalescence" or "variable graph coloring". Old school guys from that era that didn't got an update on his training usually tend to stick to that practice, Some embedded toolchains, old but still widely used, still needs it - but this is niche specific.

Yes, I meant a decrement! :-) Thanks! But not, it's not an infinite loop - since I used int, and not unsigned int, sooner or later it would happen a integer overflow, the value would be "incremented" to (-(MAXINT+1)) and the loop would end after raising a really awful amount of exceptions. :-) This is not an optimization. This is the way it's intended to be used. Using the postfixed operator in these cases is an anti-pattern, just it. And when you are dealing with objects that properly overloaded the ++ and -- operators, you end up flooding the GC with garbage - so, far, far away from being pointless. Using things the right away helps to prevent such hogs, be it the Unity, be it the language features. Not fixing a small error because you are doing worst errors on your code just pile up the errors.

It's a wild guess, but perhaps the event in which the drill would be shutdown would be in the middle of that "100 secs deltaT", and so not detected. Something like: In the simulation time 100000 (in game secs), you have 90 U of eletricity, your solar panels feed 5U por sec and your drill eats 6. So you will run out of E in 90 game secs You set warp to 1000. Now each tick is 100 game secs Now the physics will calculate the world for the simulation time 100100 You run out of E in 100090, but since this is "inside" one of that "dead zones" of deltaT, the event was not issued so the drill continued to work The game calculate the solar panel production, adds the E to the battery, and subtracts what the drill consumed But the drill theoretically had run out of juice in 100090, so it didn't subtract this 10 secs of consumption. Congrats! You just earn 60 U of Electricity for free! :-)

I don't mind paying 15USD once a year to keep funding the development. I would prefer getting it for free =D of course, but since I don't know a development/production model that delivers decent software for free (real free, no strings attached)... Well... I pay the 15 bucks and I ok with it. What I'm not OK is having to pay 15 bucks for bug fixes. Now, that I can't abide.

There's also the calculation errors due the acceleration. KSP, in normal time, runs things 10 times per second (or at least it's what I understood). So, each "tick" of its simulation clock (we call it a "heart bit") has a deltaT of 1/10 sec, 100 milliseconds. Anything that would happen in 150 ms would be "trimmed" to 100ms or 200ms, and we get a 50ms error on the event. No big deal. On a 1 to 1 basis. When we accelerate time, KSP raises that deltaT. So instead of calculating 10 times a 100ms quantum, we do with a 200ms in time warp 2x. Now, each tick is 200ms, and the maximum error on events are now 100ms and not 50 anymore. Again, no big deal. But in Warp 10x, that deltaT is now 1 "human second". So the error on the calculations can be, now, anything less than a second. On 1000x, things gets really interesting: on 1000x, each tick is now 100 seconds! So anything that would happen in a 99 seconds time frame is "moved" down or up by 100 seconds - or not detected at all: if a collision is going to happen in the next 50 "real seconds" at 1000x, the vessel will just pass through and nothing happens. This rounding errors on physics take a toll on the electrics modeling too. Disclaimer: KSP uses a "simplified physics model" on high time warps, so the figures I depicted above are not exact.

Something like this: "how many seconds I get by burning 1KG of this fuel and getting 1KG of thrust on this engine". So, higher is better. Talking about weight is counterproductive, however, because weight depends of the gravity, and gravity changes on altitude (or distance to the body) and nobody wants to deal with a huge table of a fuel's ISP varying on the current G force. So we use Mass and Thrust, then "technically" we should talk "how many seconds I get by burning 1 kilogram of mass of this fuel while getting 1kN of thrust". We use seconds on ISP because using Mass and Thrust is cumbersome: some countries use the Imperial Units while others use the Metric System, and we end having to convert Pounds, Kilograms and Newtons all the time. But everybody agrees about what it's a second, so twisting the formulas to get numbers in seconds make life easier for everybody. The ISP model of KSP is very simplified. If you want a full explanation, go NASA. Or see this video. :-)

I learnt something today, Besides the absolutely idiotic sizing (KSP style! MOAR BALLONS), another thing that was crashing the vessels on launching is that I mistakenly was attaching the launch clamps on the Fligth Deck, and not on the Dirigible Section! X-P The Flight Deck, obviously, didn't uphold all the weight, snaps and the Section weight was fully transferred to the neighbours, starting a (nice looking!) chain reaction. Below, in red the wrong way, and in green the right way of clamping a blimp with a flight dec. :-)

It's the @$%$#@%!@$%¨#$@%¨Mono. God damned half baked of a VM, and I can't say more without breaking some forum rules. Java would be a better technical decision, but I don't blame them for going Mono since Oracle took over. No one, in his sanity, would want to stick with Oracle if there's any, absolutely any alternative.

On the botton line, it's a way to simplify the bug hunting on the dev side. Getting rid of anything that even remotely could cause the problem, there's a lot of fewer places to look on. And having fewer places to look on raises the chances of finding it in the (finite and usualy small) timeframe they have to it.

I think we reached a point where such hints should be better advertised, including on the game itself! A big, nice button that is always being shown that would walkthrough the user to the trouble shooting, that can be disabled by user at will and is re-enabled by default on every KSP update! :-)

I don't like these terms as (almost) anybody else. But you can't win this fight, at least for now - and ditching KSP will not help you on this. Some years ago I tried in the most paranoid way to preserve my privacy online. Had one email for each main service (and an semi-thowaway one for the minor ones), *never* shared my private data (as security number, phone number or even my personal email, etc). But then Android happens. People that know me gladly fed Google's and Facebook's databases with what they know about me, and so they reached me: one nice day Google offered me to use my not so anymore private number to use as two factor auth one my google plus (that *was not* used on the same email I use on Android,). Few weeks later, Facebook asked confirmation of personal info that *I NEVER* shared online. The war is over, I lost. I'm a Steam user now, so all these data is already in TTI's hands anyway - what include my real identity, as I use Credit Cards on Steam. =/ I don't need to worry about these EULA terms. TTI already have access to everything through third parties, they just don't need me to agree with this.

You can say it again. :-) On the bright side, this monsters survivability is better than I expected! :-D

Made a good landing on a blimp. (you know, I think I need better runways....)

just to address a minor issue that got trough: a "clean install" is one where every older file (save, mod, anything) is previously deleted (or moved to another place where they do not interfere). So the new installed software is on a known, "pristine" state. Usually, we install updates over a previous "dirty" install. Steam does that for default. So if anything is broken, or became broken by the update, it will... break when the updated software runs.

Now I have more um mod to install: one that prints Kerbucks!

Nuff said.... =P