Jump to content


  • Posts

  • Joined

  • Last visited


477 Excellent

1 Follower

Profile Information

  • About me
    Bottle Rocketeer
  • Location
    Paris, France

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm sorry but this really isn't true. It's also not very relevant to the question of arbitration for consumer contracts... What you've been talking about (such as that Article 5 you quoted) are consitutionally protected rights. They exist in all legal systems in one form or another. Often referred to as fundamental rights and freedoms, human rights and so on. It is absolutely not true to say that you don't have these rights if they don't appear in your constitution or some other document. They exist as such. There is a whole slew of philosophies, and especially legal philosophies, that try to provide a logical basis to what most people would call "common sense": the right to breathe, move around, speak to people and so on. The whole issue of "natural law" tries to deal with this, but there are plenty of ways of attacking the logic of each of these philosophies, so there is definitely no consensus there. And that lack of consensus as to how to determine your basic rights is exactly what prompts this sort of consitutional provision: your freedom of movement is desirable; you cannot be certain that future governments won't try to limit it unreasonably based on some odd logic; therefore you enshrine that right in your constitution. There is no way you can claim that enshrined rights exist where others don't (which is basically what your subtractive/additive comparison is saying); however it is certainly true that unenshrined rights can be much more easily taken away from you. And the US is a perfect example of a common law system where the enshrined rights (additive, in your terms) form a huge part of the ordinary non-lawyer person's understanding of his "rights". The first, second, fourth and fifth amendments to the US constitution are constantly mentioned, cited, debated, argued, challenged and asserted by non-lawyery people both inside and outside the US. Still, to get back on topic ... There are two issues to this whole consumer arbitration thing. - conflict of laws: part of "international private law" which is only "international" in that it deals with a domestic legal system's approach to dealing with international subjects. This breaks down into rules on choice of law, and rules on jurisdiction and enforcement. Arbitration comes into it as it can have a complicated relationship with both choice of law and jurisdiction. - unfair contract terms: part of the protective laws of all legal systems, but with vastly differing rules from one system to another. One of the most important questions that runs through both issues is "are you acting in an informed professional capacity?". If yes, then many of the protective provisions in both areas (privilege of jurisdiction, for example, which consumers certainly have, employees may have, and mere citizens of some States may also have) no longer apply. If not, then there are lots of rights that you cannot easily sign away, even if someone clearly tells you that will do so by signing or clicking a link or whatever. So under European Regulations, you can freely choose a foreign law but that will never exclude the "mandatory provisions" of the laws of your place of residence - and protecting consumers from arbitration clauses is one of those mandatory provisions for many countries, including Germany, France and probably the UK). You can give jurisdiction to a foreign court but a non-professional's privilege of suing a professional before his home courts may be protected. You can agree to arbitration after a dispute arises but, in many legal systems, never beforehand if you are a consumer. And purporting to add a clause to a contract with a non-professional that contradicts these rights is, again in many but not necessarily all legal systems, simply null and void. And as the VKI v Amazon case shows, trying to impose your own preferred laws on a European consumer to the exclusion of all others is itself misleading and therefore an unfair contract term. So by doing so, you fail and you also get "misleading consumers" tacked on to your reputation... Incidentally, the New York Convention is fairly irrelevant. Yes, it is the basis by which arbitration as such is recognised internationally as a form of dispute settlement and therefore allows international enforcement... but it cannot affect the question of whether it is even possible for a person to consent to arbitration. In much of Europe (maybe all?), the answer is no, as a consumer you cannot consent to arbitration before the fact, and quite possibly not after the fact either.
  2. Haha, love the idea of forced "arbitration" for forum users. Would I ever accept it? No. Except maybe in China, since China is basically the opposite to everywhere else as far as arbitration is concerned (at least it used to be, basically the opposite of the sort of private arrangement that arbitration is in the west). Not that I'm surprised. It sounds suspiciously similar to the standard NDA that TTI imposes on beta testers. I had to refuse their outrageous demands (arbitration, ownership of every passing thought I might have during the beta-testing period), so I never got to beta test (Not that they actually accepted the modified NDA I sent them, so no I am not bound by it at all... and no, they can't sign it now and claim I'm bound by it: that would be pure fraud). So I feel a bit sorry for all you US users, since you aren't protected by the sort of laws that absolutely prohibit this sort of thing in Europe. I was intrigued to see someone say that TTI's lawyers must be good and wouldn't impose something on its users that would be unenforceable. I have to say that that is a very optimistic view; I'd suspect instead that the lawyers who decided it would be a good idea to draft this sort of mumbo-jumbo were more of the school of thought that says you try to impose endless insane terms because at the end of the day, some of them might stick, and that's a positive result. If it can work in 5% of cases, that's still 5% more than if you didn't try. 5% of utterly undeserved benefits is always better than 0. Still, I'm a bit sad to see where we are now. I first came here and tested the demo because of XKCD. I bought the game because of that certain esprit. I've contributed to the forums and played every version because of it. And now I'm thinking I might just stop checking the forums at all, at all, because I don't want to seem to support money-grabbing, idea-grabbing, jurisdiction-grabbing insanity.
  3. Quite simply, each rocket engine is "sized" for the type of loads that fit its profile. The only real exception is the Vector, which is hugely overpowered (it's heavy, but arguably not heavy enough for what it can do), basically because it's designed to fit as one of 3 on the back of a Shuttle-sized vehicle. Mostly, though, the bigger the engine, the heavier. Also (generally): the bigger, the more efficient. Also, bigger engines generate some electricity, which can be a life-saver, but none of the smaller engines (Terrier and smaller) do. So it makes sense to build bigger rockets, but they become expensive and harder to control. And a bigger rocket in space means a much bigger rocket on the launchpad. The idea is therefore to reduce the size until you start losing more in inefficiency than you're gaining in ease of use and ease of getting the thing into orbit. So if you have 60kN thrust from a Terrier, you can produce 1g of acceleration on 6 tonnes of craft (roughly). Since the Terrier weighs half a tonne already, that means the engine is 1/12th of the total craft mass if you want a TWR of one, under Kerbin's gravity. Since the Mun has a sixth the gravity of Kerbin, then that 6-tonne, one-Terrier craft has a local TWR of 6. That's much more than you need to land comfortably, so you could easily double the size of the craft if you have to, but I wouldn't drop the TWR any further down than that (remember 0.5g acceleration means that you need to burn for 2 minutes to slow down before you hit the ground). That means that on the Mun, a single Terrier can happily carry about 3 or 4 FL-T400 tanks, plus a couple of tonnes of lander can, batteries etc. If you're using a Rockomax X200-16, that's 9 tonnes of fuel tank already, meaning your craft is going to be at the limit of what is comfortable with a single Terrier. Therefore, a single Terrier can feasibly power a 2-man landing craft for the Mun using 2.5m parts... but it's about at the limit. Two Terriers would be much more comfortable. The Poodle, with 250kN thrust, is arguably a bit too much engine for this purpose, but it would give you much more comfort while carrying a very decent fuel load. If you drop down to the Spark, you get 20kN thrust. Therefore a 2-tonne craft for 1g acceleration. The Spark only masses 0.1t, so therefore the engine only counts for 1/20th of the total mass of the vehicle (the Spark is arguably a touch too light, compared to the Terrier, and should instead mass closer to 0.2t). Again, double the mass for 0.5g acceleration, that gives you 4 tonnes to play with. Considering that the lightest 1-man lander can is two thirds of a tonne, you can see that a single Spark is going to be about right for a one-man craft and a reasonable amount of fuel. But again, it's nearing the limit. A pair of Sparks, however, would be perfect for a one-man pod.
  4. Along the bottom, there is a dV symbol (next to the engineer button that turns orange when you have problems). Click on that and switch to vacuum (button on the right). It jumped hugely going from a Terrier to a Spark because the Spark is not all that bad in an atmosphere. The Terrier and the Poodle, on the other hand, are really optimised for vacuum and are next to useless down in the lower atmosphere. It isn't the thrust that changes anything for dV - it's purely the rocket's ISP. From one atmosphere to vacuum, the Spark goes from 270s to 320s ISP. Meanwhile the Terrier goes from 85s to 345s, and the Poodle from 90s to 350s, which is enormous. edit: ok, looks like I'm about 3 posts too late with all this. Dang.
  5. Going from the Mun to Minmus is a bit tricky. It is also extremely slow - you should count on about 8-10 days transit time. In fact, it's very much like a small-scale version of what you'd do to go from Kerbin to Duna, Dres or Jool. You need to leave the Mun's SOI going prograde, while the Mun is about a quarter orbit or so behind Minmus. You eject from the Mun into a broad orbit and catch Minmus on the other side of Kerbin. You'll almost certainly have to drag the manouvre node around the orbit a bit to get the right ejection angle. The way to do it is: Check that Minmus is ahead of the Mun. About a quarter turn should be fine, maybe a bit less, but you can compensate for error by accepting a less efficient trajectory. In any event you are unlikely to get the exact angle, since the Mun moves so much each time you complete an orbit around it, so both your ejection angle and the difference in positions between the Mun and Minmus will vary enormously from one orbit to the next. Set Minmus as target. Drop a node and set it up for a prograde ejection from the Mun to give a resulting orbit remaining within Kerbin's SOI (assuming a standard prograde low orbit, that probably means a node on the far side of the Mun, with roughly a 350m/s burn (pure guess for that number, don't count on it!)). Drop a second node about halfway to Minmus so that you get intercept "close approach" markers. If you need a plane-change correction (and you probably will), add a bit of normal or antinormal to that second node to get a better approach, but don't try to do too much yet. You need to improve the ejection burn first. Go back to your first node, add or subtract prograde and drag it around your orbit until you get a very close approach. If your closest approach has Minmus relatively far ahead of you, you need to either wait an orbit or two around the Mun (since the Mun will be catching up) or you need to head more towards Kerbin so that you dip down and then rise back up to meet Minmus. In the latter case, your ejection burn and your capture burn at Minmus will be higher. If your closest approach has Minmus relatively far behind you, you've left it a bit too late and you'll need to head out away from Kerbin (i.e. you need to drag the node back along the orbit around the Mun) with a significantly harder burn, and a significantly higher capture burn at Minmus. The only advantage is that it'll be a much quicker transfer. Go back to your second node and fine-tune your intercept.
  6. Thanks to @Zhetaan for responding to this. I'd just add that this is 8k vacuum dV we're talking about, and assuming that your choice of engine is an efficient one. Orbital velocity in low Eve orbit is not all that high. I seem to remember it's something like 3500 m/s. Therefore, assuming you "lose" about 2k m/s dV just getting out of the lower atmosphere, and then lose another 1k m/s completing your gravity turn much like you would on Kerbin, then your theoretical dV cost is actually more like 6.5k m/s. However, there is no way to calculate that in stock or with mods like KER, since your ISP is changing dramatically all the way up. You can make a rough guess, for example by setting altitude to 1km and checking the dV numbers for your first stage, then setting altitude at 20km and checking the second stage, etc. You might end up with a number of around 6k dV... or not...
  7. @Foxster beat me to it... but yes, getting the encounter right will make a big difference. The other thing is when you get there. Dres's orbit is not circular. Therefore Dres is going faster in lower orbit around the sun (nearer to Kerbin) and slower at its higher orbit. Since you are approaching from a lower orbit, your ship is going at its slowest when it encounters Dres. Capturing at Dres therefore means speeding up to reduce the difference in velocity (yes, of course you are inside Dres's SOI so therefore your solar orbit is irrelevant... but it comes to the same thing in fact: your Dres-relative velocity on entering Dres's SOI is a function of the difference between your and Dres's orbital velocities around the sun). So the best time to capture cheaply at Dres is when it is furthest from the sun. This rule applies the same way for Eeloo (much cheaper to capture far from the sun), and conversely for Moho (it is lower down than you are, so you are going faster than Moho when you meet it, therefore you want to meet it as close to the sun as possible). If you check Alex Moon's trajectory planner, you'll see that you can leave Dres for a return to Kerbin for about 1300 m/s. It should therefore be perfectly possible to capture at Dres for that exact same amount, at that time.
  8. Definitely follow @Zhetaan's advice: use IJKL/HN translation controls without using "docking mode" which doesn't help. Use SAS stability mode only other than in exceptional cases. In addition to that, the most natural thing (for me anyway) is to use "Locked" view mode. You really get a feel for exactly what your craft is doing, and it also reinforces the link between your movement and the change in position of the icons on the NavBall.
  9. Essentially, yes. Theoretically, there are any number of possible solutions. Practically, though, you need a ship with a minimum vacuum dV of about 8k m/s. And of that, the first 2k m/s or so dV has to be provided by one of only 3 engines that you need to get up to an altitude of about 20km or so: the Aerospike, the Vector or the Mammoth. No other engines provide enough thrust at Eve sea level. If you were to start on a mountain, you might be able to use a Mainsail, Twin Boar, maybe even Thuds on your first stage. Once you get up to about 15 km, atmospheric pressure is about equal to sea level on Kerbin, so you can use any combination of engines that would work there. The trouble is that for efficiency, you really should be continuing to use whatever engines got you up there to start with, or at least a couple of them. Your ship is either truly massive and Mammoth-based, or a cluster of 1.25m cores propelled by a mix of Vectors/Aerospikes. And to get out of the thick lower atmosphere, you need to stay as sleek as possible. Adding wings is probably not a great idea... To get all that down to the surface to start with, you again have any number of options. You can do a powered slow-ish entry into the atmosphere then refuel using drills and ISRU. You might be able to make it down on wings. However, you really need a way to ditch excess weight and drag before trying to make it back up out of the atmosphere. And so, again, your options are limited. I find it hard to imagine a ship that would let you glide and land on wings, and maybe even take off on wings, but let you ditch the wings so you can power out of the lower atmosphere. Similarly, trying to carry drills and ISRU back up to orbit is going to be a huge handicap, so you need to ditch them... and so it would be simpler to start by just landing with a spare fuel tank rather than spending all that effort with mining equipment... So essentially that takes us back to "dropping everything with parachutes"...
  10. That Alex Moon calculator really does work exactly as advertised. You just have to fiddle a bit. This is a sandbox attempt using roughly your date. I get an intercept with a single 1400 m/s burn... Basically, the manouvre node is at about 90°, heading retrograde. You do need a slight normal addition (upwards) because otherwise you cross Kerbin's orbit at the wrong time. That normal addition means that you dip down a bit further than Kerbin's orbit and then meet Kerbin as you are heading back up. This is a bit clearer here: So yes, you can definitely get home on less than 1700 m/s. This is from a 40 km orbit, but with Dres's weak gravity, a higher or lower orbit won't make all that much of a difference. edit: After more fiddling, I got a better intercept with lower dV cost, meeting Kerbin exactly at the right place (at solar Pe), with about 1380 m/s total. Still not perfect compared to the Alex Moon calculator, but close. That "88° to retrograde" angle you are supposed to use is a bit confusing. In any event, as @Reactordrone said, it necessarily has to be almost directly between Dres and the sun since you need to exit almost directly retrograde. As I understand it, "88° to retrograde" means you start at retrograde (with reference to Dres's solar orbit) and count back 88°... And so your exit from Dres's SOI will be heading slightly out and away from the sun. It didn't quite work for me because the closest approach I managed to get was when it was more like 95° to retrograde. Dres is hard.
  11. Do you have the small grey tanks unlocked? If so, the easiest thing is to add a pair of drop tanks. Add a pair of the small decouplers to the top stage, just under the batteries would be fine. Add a pair of those grey tanks, then pile a couple more on top and under those. If you have the small nosecones unlocked, add them top and bottom. Make sure the decouplers are set to stage after your Terrier fires. Enable crossfeed on the decouplers, then check that the fuel priority on the drop tanks is a higher number than the core tank (or use fuel lines if you aren't using advanced tweakables).
  12. The simple answer is: you can't. In the stock game, there is no way to display anything other than the AN/DN of the target orbit. Since you're using KER, you can see all the details of your current orbit using the floating KER window. The longitude of the AN of the orbit is, as I understand it, with reference to the game's absolute coordinates which you cannot see. I'm guessing that there is maybe part of the starscape background that you could identify as the direction of "zero longitude", but I doubt it would really help much. So the only way to do the satellite contracts, as far as I know, is to eyeball it. The tolerances for completing the contracts are generally quite generous. The only real problems people generally have are (a) getting the orbit the wrong way round, and (b) eyeballing the intersect points for solar orbits which are particularly fiddly to view. Still, I'm a bit confused with your image there. I don't see any target orbit... and I don't understand those "fast forward" arrows on Ap/Pe. Is this a mod, and is the contract part of the mod?
  13. As @Aegolius13 says, an alternative to the two lander cans would be a good idea. By far the best solution - from a weight and aerodynamic perspective - is to use a crew cabin (1.25m, 0.5 tonnes per occupant) instead. The disadvantage is that you then have only one way in to the vessel (via the top pod) and will need to shuffle crew around inside and on EVA to get the rescuees in, and you no longer have the lander cans' reaction wheels to help manoeuvering (which also means you absolutely must keep perfect retrograde hold on "surface mode" on re-entry). Agreed also for the asparagus staging: place and stage the boosters in pairs, with fuel lines from the first pair to drop to the second, then from the second to the core. An alternative that might get you further is to replace one pair or both pairs with SRBs. You can still add small fuel tanks to the top and keep the fuel lines, so that when the SRBs are ready to drop, their associated tanks have emptied. It's a bit tricky to time without using mods, but as an example one Reliant will empty one FL-T400 in almost exactly the time it takes for one Hammer to burn out at 95% thrust... Since you have steering fins, you could also get away with replacing the Swivel with a Reliant and an additional small tank on the core. And you could replace those fins with elevons (elevon 1) to reduce the weight a touch. Also there is no need for two struts per booster on that size of craft. I've found that one strut is fine until you get really massive and complicated boosters (or specifically, for inner boosters where they themselves have outer boosters strutted to them).
  14. Yes, starting the burn a little later around would have worked. Still, to get a retrograde orbit you will always have to burn a little harder than to get a prograde orbit. Picture what is happening when you reach the "top" of your orbit around Kerbin. You are far out on an eliptical orbit, so going slowly. If your Ap is slightly closer in to Kerbin than the Mun is (you didn't quite burn hard enough), the Mun comes sailing past above you and picks you up with its gravity. You therefore get dragged in and whipped around behind the Mun... giving a prograde flyby. You then burn against the direction the Mun is dragging you, to circularise into a prograde orbit. If, on the other hand, you burn harder out from Kerbin, so that your Ap is higher than the Mun's orbit, the opposite happens. The Mun comes racing up behind and below you, between your ship and Kerbin. It picks you up and drags you along again, but you've already passed in front of the Mun by the time it arrives. As the Mun drags you behind it, this time you're going clockwise. So yes, you need to start a bit further ahead to get a retrograde intercept, but the most important thing is getting your Ap slightly higher than the Mun to start with. Remember that whatever happens, you will always be going very slowly out there as you approach your Kerbin-relative Ap, so you are basically just waiting around in the right bit of space so that the Mun can swing by and scoop you up the right way.
  15. Meeting something in orbit is actually a lot easier than it looks, especially if you simply use the NavBall and the map. Definitely use the tutorial to get the hang of intercepts. Then, when coming from far outside the orbit of your target craft, just remember that tiny changes at a distance can make a huge change in the time of arrival in orbit. Therefore you can always combine a little prograde/retrograde and a little radial in/out to make sure that you meet the target craft exactly at your Pe as it touches (or, ideally, very very slightly crosses) the target's orbit. Always. If you're having trouble with the tutorial, keep playing with the maneuvre node until it twigs for you. And once you have that intercept set up (to less than 1km, touching or crossing orbits), you can do all of the rest simply with the NavBall and map view without any planning required. You need to know your approximate acceleration. A small craft with a single Terrier probably has an acceleration of around 15-20 m/s2. In the map, click on the intercept chevron to see your "time to". Click on the NavBall to get target mode. Line up with the retrograde vector to target. Check velocity to target, and divide by your acceleration to get maximum burn time to match orbits. Start burning when you're about 2/3 of that time away from intercept (absolute minimum is 1/2 your velocity divided by acceleration, but you want a little room for error and therefore the ability to throttle). While burning, notice how if you aim off to one side of the retrograde vector, it will move away from where you are aiming. Use that "pushing the marble" effect to push the retrograde vector exactly over the anti-target (pink cross) marker. If your intercept was relatively close to start with, it will get closer and closer as you do this. Throttle down if the "time to" countdown stops counting down or slows too much. Stop burning altogether when the intercept chevron starts getting further away from your current location. Just by doing the above, you will perfectly match orbits at maximum efficiency in a minimum of time and effort. You can easily end up dozens of metres from your target at nearly zero difference in velocity with a single burn. Then you can switch to outside view for the docking procedure, which is way harder to start with
  • Create New...