Dieter_G

@lincourtl What I said is simplified a lot. I didn't account for different trajetories. I'm just comparing two cases, both with e.g. a pure vertikal trajectory, where you do a "suicide burn" in one case and a [slow, gradual burn] in the other. Of course, theoretically the most ideal trajectory for landing should be the same than the [ideal trajectory for ascending into an orbit], just reverse. The [ideal trajectory for ascending into an orbit] involves gradually turning your thrust-vector from [pure vertical] to [pure horizontal]. At the end of this process the centrifugal forces compensate gravity, so you don't have to "fight" it anymore. So, basically, at the beginning of such a trajectory you are affected by 100% of gravity. Then, by building up horizontal velocity, gravity starts to become gradually offset by the centrifugal forces. Thus you only need to "fight" like 100% ... 90% ... 80% ...... 10% ... 0% of gravity over time. I hope you know what I mean... Thats what makes such a trajectory the most economical one. But that is a different topic, and of course you are right. As I said, I just talked about a pure vertical path, suicide burn vs. nromal burn. Also, when I said that "gravity is subtracted from your engines thrust", thats somewhat misleading. In fact, it doesn't matter if your engine is activated or shut down. You need to shorten the time where gravity acts upon your ship (without accelerating towards the planet/moon of course) : Fly through the gravitational field as fast a nature provides (not artificially accelerating toward the plantet/moon!), then do a hard brake at the very, very end. if you break to early (so your ships stops e.g. 200m above the surface and you have to do an additional burn shortly after) you'll also need more fuel, because for every second you are in the gravitational field (e.g.) 10m/s of vertical velocity will be added to your "bill"... Damn... could we switch over to german language for a second ? Its really hard to explain it in a clean and proper manner.

I must admit, I didn't read through all of this thread, so maybe someone already explained it... The easiest way of thinking about it (for me) is as follows : Your engine generates a certain ammount of thrust. When burning retrograde your effective thrust (that is going to slow down your ship) however is : EngineThrust - GravitationalForce. So "gravity" is always subtracted from your engines thrust. Only what remains will go into slowing down your ship. So it will be a good idea to get as much of that remaining thrust as possible. In other words : the thrust needed to counter gravity is wasted. E.g. hovering 10m above the surface for 1 minute yields zero physical work, but needs a lot of fuel anyway. So, by suicide burning, one shortens the time where your engine must fight gravity by as much as possible, thats why it saves fuel. Your consideration : is also correct, if applied to the "effective thrust" (after gravity is subtracted).

Update .: Ok, its solved now ! I did some reserach (using science-points to unlock things in the tech tree, not gathering science points) and all of a sudden 6 new contracts are offered to me. So [not reserching things for a while] seems to be a factor limiting the number of contracts beeing offered to you. Again, thank you all

So that never happens to me at the moement, it is clearly a "one by one thing" : solve one : get one new The save is here btw.: http://www./download/ij0ids203f12qnc/Death_0037.sfs

@Frank_G thank you very much ! The debug-console may prove to be very usefull in the future. Regarding my "problem", I was a bit overhasty, obviously : I tried completeing other contracts, like Claw suggested and I got new ones. So I'm definitely not stuck in a deadlock, everything is fine. What makes me still wonder a bit is that the number of [active + offered] contracts seems to be stuck at a total of 9 (maybe sometimes 10) contracts at the moment (4 offered, 5 active). In the past, the list of offered contracts had way more entries, sometimes I even had to scroll a bit. Is this normal ?

Very interesting ! Maybe I'm experiencing also one of this "times". That calmes me a bit. I was concerned, because in the meantime I did indeed find an entry at the Bugtracker : Here http://bugs.kerbalspaceprogram.com/issues/3157 a guy claims, that recovering a kerbal only (in EVA, outside of the vessel), triggers a bug causing no more "random-contracts" (thats parts-testing and the like) to be generated (if I got it right). However his description (some contracts beeing offered again) doesn't fit what I observe, so hopefully "his" bug didn't hit me. Also, I cannot remember to have recovered a Kerbal only, but I'm not entirely sure. Yes, I'll try that. I can provide the save also, but later as I don't have it at hands right now. Thank you both

Which ones exactly ? Do I have to go to Minmus for example (thereby completing a "fixed" contract ?) As I said, I already completed some parts-testing-contract but nothing happened

Hi all, it sems like there are no new contracts generated anymore in my game (ver. 0.24.2, win-32, no mods, carrier-mode). I have been to Mun and have accepted contracts for Minmus, Ike and [oneMore]. In recent times I did wonder as to why the list with offered contracts got shorter and shorter (because I accepted some of them). In the past, plenty of contracts have been added frequently, but aren't anymore now. I warped time, letting pass by about 70days : nothing. Completed a parts-test-contract, passed some time : nothing. Is there a known bug causing this ? I couln't find any indication for a bug of that kind, neither here in the forum, nor in the bug-tracker. What causes new contracts to be generated normally ? Do I need to complete old ones or just let time pass by ? Remark : AFAIK, there are two "kinds" of contracts : "random generated" ones (parts testing) which seem to be generated infinitely over time, and the regular/fixed ones, like "escape the atmosphere", "explore the mun" and so on. The observed behavior pertains the "random" ones at least. Not sure if the fixed ones are also affected, since I didn't make remarkable progress in the game lastly. Anyone knowing something about that ?

hmmmpf... so nobody is suprised by the results ???

Ok, here are the results : First up, thats the Test setup. A tank attached to four launch stabiliser. Another tank (9t) is suspended to it with a number of small stack decouplers. As you may know these are very labile, highly compressible and highly strechable; to make it short they behave like a long and weak spring. They idea behind using them is to minimise their mechanical impact because lastly what I want to test, is a strut (but the game doesn't allow to mount the tank on a strut only - you know). The test is based on the fact that initially (after going to the launch pad) the rocket is in kind of "stasis" where no gravity ect. is applied. After a few seconds, the "stasis" is voided and gravity applies. It is then, when the rockets "settles". With my slow computer I got about 5 seconds to quickly adjust the cam and take a first screenshot (entitled "before" in the images). I take a second one after gravity is applied (entitled "after" in the images). So by comparing the two shots per setup you can see how the (single) strut is deformed by the weight of the tank. Test 1 : no strut. Here you can see how the decouplers alone are doing. The tank falls down, more or less, thought it is still barely hovering over ground in the end. Test 2 : strut up. Here the strut is mounted upwards to the tank. As you can see it is very strong, not bending visibly, just getting a bit compressed (shortened). The tank moves a bit to the left and maybe/most likely also a bit down. Unfortunately, the cam also moves a bit after "stasis" is voided, thus making it hard to judge about vertikal movement of the tank. Test 3 : strut horizontally. Ok, the strut can take an awful lot of torque, obviously. Its really awful, as the last two images will show... But what is that ? It is still moving to the left, as if the strut was still beeing compressed and thus squeezed. That makes me really skeptikal. It shouldn't move to the left in this case, so here must be something wrong already. I think by analysing the cause of the tank moving to the left, one will find the bug. Test 4 : strut down. basically same as before. Tank moves to the left. With this setup, the movement to the left would be explainable by the strut beeing bend a little downwards, therby moving a bit on an arc (hope you know what I...), however, as the strut barely does bend, it looks to much. Test 5 : strut even more downwards at this point we get perpetual motion again. Test 6 : see what a strut can take Here you can see what a strut can take. Yes, gravity already applies ! The second image shows the poor stack decouplers alone. They seem to be overloaded However, even thought the strut might look almighty here, it isn't. Put on more tanks and it does clearly bend. last two images (Updated) Here another issue/maybeBug : connecting a strut [to a decoupler] instead of [to the tank] weakens it significantly. Don't know if this is by intension. Could be related with above behavior thought, thats why I put it in. Of course, again first of the two images is before gravity apllies, second one is after. Now the conclusions (which aren't that conclusive at all) : -------------------------------------------------------- 1.) At some point I thought the error was, that all forces (tensile or thrust) are handled as beeing thrust (even if they should be tensile) and thus the strut always was compressed, shortening it and thus moving the tank to the left all the time. However I failed in proving this with other setups. So it isn't exactly that but >>> for some reason there are phantom forces compressing the strut in the horizontal setup (Test 3). Those are perhaps also the reason for the perpetual motion observed in Test 5<<< I couldn't figure out what is going on in more detail, but there is something wrong. Maybe shear forces or torque is mistaken as compression or something weird. 2.) The struts have properties that (I think) most people wouldn't have expected. Most importantly, they can be loaded with torque like hell. Not only do they withstand it, they are also very stiff and thus bend very little, even when subject to heavy loads. They are indeed much more stiff, than the "girder segment"(or whatever it is called). I think that will suprise many. Also they are much more stable than I would have expected. None did ever break during all testing. Ok, enough for today. c u

Ah, thanks alot ! ...

ok, I wanted to show my results but for some reason am to dumb to get the imgur-album embedded. I got <iframe class="imgur-album" width="100%" height="550" frameborder="0" src="//imgur.com/a/IT0T5/embed"></iframe> Can someone tell me how to use that in order to have the album embedded in my post like with claws post ?

OK, after finding that this rocket (only one asymetrically placed strut at the top of each booster) doesn't spiral, thought it should (similiar to your findings, Claw) and that ... this piece of crap (one strut at bottom, two totally asymetrical at top for each booster) goes straight "as an arrow", even with SAS disabled (!!!)... I decided to give up using rockets to get an understanding of the behavior of the struts. Instead, I did set up some synthetical tests... [next post, may take an hour to complete]

@ToTheMun I don't understand completely. What does "not getting theirs physics loaded" mean ? You mean the thing with setting their 'PhysicsSignificance = 0', so then they don't have mass, drag ect. anymore ? So basically what you are saying is that they don't account to the weight of the rocket ? @RW-1, Claw Yes struts at the top and the bottom seem to be the solution for this problem. See next post. Ok, on my next two posts, I'll expose some astonishing properties of the struts. Be curious !

Ok, this may be your opinion, but for sure isn't mine. From my experience, when designing a rocket I get most of the simple designs done without any problems of strange behavior. Lastly however, all new designs suffered strange penomenons (because they were bigger, had more parts). So what you claim to be just 1% looks more like 80% to me. Also, it seems like a lot of other people are experiencing problems with larger designs. Most often they then put on loads of struts (some of which likely make things even worse, see later post) and RCS-Trusters in order to get the beast back under control. I think if these issues were fixed, people would 1.) experience a much more steady and comprehensible behaiviour of their rockets 2.) be able to realise a lot more designs wich are made impossible/hindered by strange bugs now. Just one more example. This one needs the lower boosters to be connected with struts (as is in left image) because otherwise the boosters are spread apart by the weigth (right image) The problem now is that having the struts attached results in perpetual wobbling/resonance of the boosters making the rocket uncontrollable. Funnily, the central three tanks are also connected by struts but don't expose that behavior. Instead they start perpetual wobbling (till destruction) when the struts are removed (I used the central part of this rocket as a previous example). Now, where is the logic ? How should I plan for a next design ? Resembling real physics (at least its fundamentals, NOT down to 1% accuracy of course) is at the heart of this game. I'll let em get away with second-class graphics, I'll let them get away with second-class sound but not with second-class physics.