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.

Important : i forgot to say, that this "peculiarity" was/is not present in the demo ! There this design behaves normally

ok, I saw your update with the image. I'll try it I'll also check out these thing with the albums, thanks

Hmmm, maybe there is some bug enabling a ship that doesn't consume fuel ? Just kidding...

"peculiarities" is a very nice word for a bug, I must admit which are the "long I-beams" ? I think I don't have researched them up to now. But I'll try it, thanks.

I just realise that my "ASCII-arts" illustrating how the rocket should be build is constantly corrupted by the -oh so smart- editor, removing these unneccessary leading blanks in front of each line. Really clever ! I hope you can nevertheless figure out how it is meant...

But now, as I "promised" yesterday, another one. Look at that : Got it ? The engines are OFF after the second image, speed is negligible. Where does the energy come from, causing the wobbling of the tanks to increase steadily until the rocket decomposes (long since the engines where shut down) ? Same happens outside the atmosphere btw. Try yourself : capsule | tri-coupler | | | 800 800 800 | | | 800 800 800 | | | LV-T30 LV-T30 LV-T30 where "800" = FLT-800 fuel-tank. The answer to my question (where does energy come from) is likely : negative damping, maybe due to a sign-error. Thought it looks funny, these are things that are totally ruining my confidence that the physics are modeled correctly. I mean, this is not a bloated fancy design with hundrets of components, it is very basic instead. I don't understand how one can miss that (as a developer). I'm now at a point where I cannot happily play around with different designs, examining how they perform, but instead are constantly afraid that e.g. adding one more strut to a working design might lead to unforseeable changes in its behavior. That is annoying and kills most of the fun. Ok, complained enought for the time beeing... what do you think of this ?

Thats not correct, the radial decouplers do absorb torque. In my example (without struts) the boosters don't touch the tank, so bending is stopped due to the torque beeing absorbed by the decouplers. @Kasuha : I think the decouplers are modeled as a >>set of<< sticks, otherwise they couln't absorb torque, right ? Anyway, you're right that the decouplers leave a lot of room for movement (up/down and left/right, I studied it today) and this could explain why the tanks gets forced to one side even with struts at the bottom. But as I said, even thought your explanations make perfect sense, I'm not sure if this is the (only) reason of the oberved behaviour, as the angled struts didn't alleviate it. Btw.: I forgot to say, thanks for reading my post carefully and picking up the point with the ">>>struts at the bottom<<<", both marvin and kasuha.

@Marvin, Kashua Ok, I got you. I had the same thoughts already so I perfectly understand, you don't need to apply your MSpint-skills, Marvin I also tried to approve it visually but couldn't see it (I watched the Rocket from straight above, cam in "chase" mode but couldn't see the tank move) Also, I tried your suggestions for improvements of the design, but unfortunately none of them worked really well. I tried two angled struts (see Image), I tried two nearly vertical struts (thought I don't understand how they should improve things), I tried putting the decoupler to the very top and have a single strut at the bottom (suggestion from Marvins first post I think) and also having the boosters connected to each other, at the top with a single strut (no connection to central part) because the improvement -using two angled struts- also didn't work I discarded the idea you are describing (that the reason of the observed bahaviour is that the decouplers are modeled as sticks by the physics engine and have a lot of "give" to the side). Ah, as you can see I've put the angled struts at the top, where they work on pressure an stiffness against [moving to the side] is neccessary, so that the decouplers (which are sticks) only have tension applied. But as I said : no success. So, I'm still sceptical, especially since I discouvered another -definite- bug, which may be related. More on that tomorow... I'm very tired now and writing to this forum puts a heavy load on my brain since english isn't my native language. cu

@DrMonte Of course, even my symetrised struts aren't totally perfect. But the effekt I'm speaking about is strong, and it manifests on a lot of different rockets, some build normally, others symetrised by hand, its always the same and it always vanishes, as soon as the struts are removed. Of course, even without struts the rocket won't go perfectly straight up, the SAS always needs to correct a little bit because of imperfections of the construction. But there is a big difference in 1.) the SAS doing some corrections 2.) the SAS running constantly and still not beeing able to hold the rocket straight. So, I want to stress again that it is not a question of some minor imperfections but instead it is related to the struts. Just remove the struts (leave the rest the same) and it is gone. Damn, I'd like to up my Rocket so you can try yourself. I also did a tri-symetrical design. Its even worse then : at the end of the burning-phase of the boosters the rocket flips over.

update : I've put the whole rocket on a giantic lifter, capable of delivering >50 tons to space, and voila : the problem persists. It also wants to flip in space. So it has nothing to do with aerodynamics.