Starman4308

There may have been more diplomatic ways of handling the situation, but as I saw it, it nowhere approached harassment. It may have been a negative assessment of his skills and choices, but it was an honest negative assessment. It's like being upset that a novice pilot was told "I don't think you're ready to fly an F-22 yet". I feel you are grossly over-reacting to what happened there, and are trying to enforce standards which would amount to walking on eggshells. It is completely unhealthy to have an environment where no criticism can be offered. If delivered constructively, it helps the person grow. What went down in that thread does not even remotely approach harassment: it was not intended to hurt the would-be modder in any way, but instead to steer him away from what was believed to be a foolish choice. It was not the best way; there could have been more offers of compromise and assistance, but I do not see how it came to any inappropriate level.

Have you considered a 5m to 37x 0.625m adapter? I am sure there are plenty of reasons to use such a part.

NecroBones's Modular Rocket Systems has larger xenon tanks: one is a 0.625m sphere (1400 xenon), and the other is a 1.25m sphere (12500 xenon). They're also RealFuels compliant now, if you use that mod.

That can only be meaningful for a given rocket at a specific instant. For each unit of fuel, the amount of velocity change you get depends on the current mass of the rocket and the efficiency (Isp) of your engine. As you burn fuel, the mass of your rocket changes. Thus, you can have an instantaneous dV per kg of propellant for any given rocket at any given time in its burn. It's still a kinda nonsensical question though: what you should be looking into is the Tsiolkovsky rocket equation. Just note that ve (exhaust velocity) is equal to Isp (specific impulse) * g (Earth/Kerbin surface gravity): the use of g * Isp is because engineers got tired of converting between exhaust velocity in m/s and ft/s. I'm going to take exception with that one: in theory, specific impulse is completely independent of thrust and engine mass. Specific impulse is mostly a function of propellant chemistry, though other factors like nozzle shape and how complete the combustion is also factor into there in ways I'm not particularly familiar with. It has nothing to do with the tyranny of the rocket equation, and has much more to do with the tyranny of trying to design efficient, high-thrust engines on a ridiculously tiny mass budget. In practice, you can generally get Isp a bit higher with a heavier engine, or with less thrust, because you can devote more of your engineering attention to squeezing out every bit of kinetic energy from your propellant as possible, but most engines are already within a few percent of the theoretical maximum for their propellant chemistry.

First off, no basic jets. Turbojets will get you off the runway, and will give you far more power during the crucial high-altitude acceleration to orbital velocity, at which point basic jets are dead mass. RAPIERs are about as good: if you have a dedicated circularization rocket, turbojets probably have the edge, while RAPIERs are good if you don't want to carry a separate engine for orbital maneuvers. Second, turbojet dV is so weird that you shouldn't pay much attention to it. More important is to have an appropriate ratio of jet engines per tonne of spaceplane mass, an appropriate ratio of intakes per jet, and an appropriate number of wing sections per tonne of aircraft: after that, it's trial-and-error to see how much LF you need to dedicate for the atmospheric section of your ascent. EDIT: Also, basic spaceplane profile: dash up to 20 km (out of le soup), and then go horizontal. Try to balance climb rate with intake air needed and drag: the higher you are, the less drag you get, but the less intake air you get. You can somewhat compensate for low intake air with high velocity (the faster you go, the faster air is rammed into the intakes), but at some point, you can't go higher without a lack of intake air choking off jet thrust to below drag.

Plus, given the experiences I've had with DRE and FAR, you don't want to brake too much in very high atmosphere. If you do, you will lose just enough velocity to send you screaming towards lower atmosphere: what you really want to do is "skip*" off mid-atmosphere, and maintain a 3-4G deceleration for as long as possible. *Not to be confused with a full skip reentry: what I aim for is to reach 0 vertical velocity (and potentially start going back up for a bit) in mid-atmosphere, where it's thick enough for large amounts of braking, but not so thick as to cause fatal G-forces or strip off my heatshield. If I can get 2-3 minutes at steady 3-4G deceleration, I've just about nailed my preferred reentry profile.

Thanks: had I not already seen the pattern I'm using from another contract science modifier, I probably would've adopted the general structure from your mod. Two suggestions: you might be able to use HighLogic.CurrentGame.Title to determine if the game has changed, and if nothing works, I am 99% sure what I've got going (also MIT-licensed) is robust and functional. The only change I'm thinking of making to that end is ensuring both the dictionary of previously encountered contracts, and the multiplier code, ignore contracts which have been completed, failed, or declined (which would further reduce the chance of two contracts sharing a GUID).

Procedural Fairings should work. Slap down an interstage fairing ring and extend down (or up) until it covers everything, or sandwich the cluster between two regular fairing bases facing opposite directions.

I think I may have conflated you with Dragon01, who was beating a dead horse. I apologize: on re-reading the conversation, you did indeed back down when Chris said "not really possible without a hugely complicated project involving cloth and string physics".

If all you want is stage recovery, well then... There is StageRecovery.

Dragon, the problem is that while both N-body physics and cloth physics are wickedly difficult to implement in a mod, the sole effect of cloth physics is to force people to cut chutes early. You know a much easier way to solve that problem? Cut your chutes early! You're one of maybe a tiny handful of people who would care, and programmer time is limited. Why bother with this, when there is such an easy in-game workaround? It's not like N-body physics, which would have to be integrated directly into the game engine, because there's no way for a player to mimic the effects of N-body. You are asking for a modder to spend a huge amount of time catering to a very niche audience who have a very easy in-game workaround. Hell, if you wanted, you could write an addon which disables probe cores if you land with uncut parachutes: that'd be a much easier hack than cloth physics.

Nope! RSS only changes planets. You've got a few options for getting engine performance up. The one I favor is to install RealFuels and Raptor's stockalike engine config for it. That'll knock tank dry masses and engine masses way down, give you the option of the wonderfully efficient LH2/LOX mix for upper atmospheric stages, and still let you keep the a lot of the KSP sandbox intact. You can also use the 6.4x Kerbin config for RSS, which in combination with RF/FAR/DRE, makes a pretty decent RO-lite. If you're up for a more realistic experience, you can try Realism Overhaul. Unfortunately, it doesn't do career very well yet (the RP0 project is very much WIP), and it can be a nasty shock to new players, because RO comes with a lot of other changes (major reaction wheel nerfs, command pods rescaled, stock engines replaced by real engines*). I'll probably come around to trying RO again in the future: while I talk the talk, I'll admit I'm still a bit of a novice to KSP, thus my use of 6.4x/RF/FAR/DRE instead of RO. *I think some part packs like Soviet Engines have RO configs which help fill in the awkward blanks in the RO engine lineup, fortunately. Unfortunately, hello 32-bit memory limits. You can also use KIDS (KSP Isp Difficulty Scaler) to knock Isp way up, though that leads to weird stage times. Almost all x64-disabled mods do so in their source code. You can eliminate the check from the source code and recompile, or in some cases, ask the mod author politely. Don't expect support from them, though: some of them cannot test on x64, and others are simply too fed up with trying to discern real bugs from x64 instability to care.

The only things I can think of: do you have different resolution texture packs for the visual mods (like Better Atmospheres)? Does this install have a newer version of a rocket part pack with more memory-devouring textures? The only fix I can think of is to prune down your memory usage a bit: I can't explain the difference in memory usage, but the crashes are likely to be KSP running out of memory.

Hey Ser: replication was simple. While I suppose there might be interference from my mod, which I forgot to uninstall (though I doubt it), all I had to do was start a new career game. The first 4 had the multiplier properly applied (100x, so it would be easy to see). I then accepted and completed the "launch new vessel" contract, and the new ones which popped up did not have properly applied modifiers. Log file.

Are you sure that works? I copied the logic, and while it worked for the first four contracts offered, it didn't do so for subsequent contracts. What I suspect may be happening is that the onDestroy() method is being called the moment you change scenes, and I suspect trying to fix that would just cause even worse problems, because you might get accumulation of multiple copies of your addon running around. In any case, I started my own thread, and it's back to "make a log of previously encountered contract GUIDs, and skip those when iterating over contracts each time the list changes" for now. EDIT: Hallelujah, I've gotten my dictionary to work. My thread (and the GitHub source) is here: the mod still doesn't do anything useful, but AFAIK, it is functional and robust in modifying contracts once and only once. I swear I'll document it better later.

Are you clipping the heatshield into the pod? If you do that, it really confuses FAR's drag calculation. The entire heatshield model should be outside the pod, such that its top node connects to the pod's bottom node; if you connect bottom-to-bottom, you get weird drag issues.

Beyond mods and modding, you could also start imposing restrictions on yourself, start RPing, etc. You could play a career game as though you were a real space agency, writing up mission goals, using standard boosters, requiring escape systems on all manned capsules, etc. You could try replicating real-world missions, build yourself a space shuttle, etc. If you are still bored by KSP, set it aside, play some Skyrim or Civ, and come back later if you want. Nobody's going to point a gun to your head and force you to play KSP.

Around 7-8ish. I'm (slowly) running a 6.4x Kerbin career with RealFuels, Raptor's stockalike RF config, FAR, and a few dozen other mods. Linux-64 Intel 2.4 GHz quad-core NVIDIA GTX 660M 16 GB RAM

Speaking from very recent experience: Config files, and other file I/O. Events, and generally how to get your stuff to trigger when you want it. Finding other classes and files (I refuse to believe that having a static reference to an instance of yourself is the best way to do this). Potentially also useful: licensing, how to deal with other peoples' licenses, and the art of finding solutions in open-source code.

Huh. The ContractID, from the limited test I ran, was persistent through closing and re-opening KSP, though if ContractGUID works for you, I'll probably just use that. To avoid clogging up other peoples' threads any further, I've established a dedicated thread in the development subforum. I really wanted to have at least a demonstrator finished by then, but the problems are mounting.

Ever been annoyed at how hard it is to make contract payouts to make sense in Real Solar System? Well, now there's a mod to fix that... or at least a demo version thereof. Renegotiator can apply different multipliers for every body and every situation, such as landing on the Mun vs. getting science data from Laythe. Remaining major issues No sensible config file for any possible situation (what is provided was intended solely for debugging). No automatic parametrization. Does not fix suborbital and orbital contract altitudes for RSS. Unlikely to work with mod contracts: I have a hook in my code for that, but haven't implemented specific support for any mods. This includes the Fine Print contracts which are going stock in 0.90. Remaining features to implement Nuke nonsensical contracts like "test Basic Jet Engine on Minmus" For a bit of RSS scale: Source on Github Release version also at Github. License: MIT (included at Github repo) Significant assistance (or code adapted from) so far from: NathanKell Ferram4 nightingale DMagic Eggrobin Acerola TriggerAU

Thanks for the help: the dictionary idea is promising. GetHashString() won't work: it keeps on changing when the scene changes. More testing is required, but I think Contract.ContractID is going to work better. EDIT: Contract.ContractID does seem to be unique, and persistent between reloading the game. Now to figure out where to steal some code for keeping a dictionary persistent for a save game, probably from KAC.

Control surfaces have to be far from the CoM in the appropriate axis to be effective. Many ailerons, for example, are not very far from center-of-mass for pitch: trying to use them for pitch will mostly just cause greater drag, while providing very little pitch authority. Elevators aren't used for roll authority for the same reason: they're too close to centerline. Now, if you had a long delta design, you could have elevons (elevator-ailerons), but with traditional wing and tail layouts, there's a good reason that ailerons and elevators are separate.

Either botched mod installations, conflicting mods, or you ran into the 3.5 GB limit imposed by 32-bit KSP. The last can be ameliorated by using OpenGL or a texture management mod. 64-bit solves the memory issue completely (assuming your computer has enough RAM installed), but you either have to install Linux, or deal with the instability of the Windows version, and the number of mods which are disabled for Windows x64.

I know there's a mod (ZeroScienceContracts) which zeros out science for people who think science from contracts is cheaty. I know the question is a bit out-of-scope, but in the process of writing the mod, have you found a way to get a reference to each contract as it is offered? I'm trying to do blanket editing of contracts, and what ZeroScience does won't work for me*. *ZeroScience zeroes out the science on all contracts each time the list changes, whereas what I'm doing needs to be a one-time multiplier of funds. I've tried adding a dummy parameter to mark ones I've already visited, and it caused odd behavior with the scripted contracts: I think the parameter list is part of how KSP recognizes those scripted contracts.