• Content Count

  • Joined

  • Last visited

Community Reputation

334 Excellent

About damerell

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

2,891 profile views
  1. Well, it takes off without disintegrating into pieces (although you do have to taxi it off the runway using the aerospikes, because the runway immediately explodes if you use it), so I guess it's viable and safe enough, although its stall speed is about Mach 0.7 at ground level. I fly it with Atmosphere Autopilot. It doesn't have much yaw authority, but it doesn't really need any because it flies in a straight line all the way into space. Once it's in space, it's covered in RCS (particularly, eight double-scale Space-Y LF/O ports) to make it point in the right direction. Executing manuevers precisely is a bit tricky because one pair of 5 kilotonne pulse units applies about 15m/s delta-v, so the bomb size for the last pulse of a maneuver has to be carefully judged.
  2. Because I already bolted all the nice things to my magnificently dangerous spaceplane... right?
  3. After a series of seaplane launches (well, most of the debris landed in the sea) and general failures to go anywhere, I've essentially finished the Behemoth III, a (hopefully) go-anywhere SSTO. The engine pods can detach and redock to a landing module for airless worlds; the nose cone is also a docking port so Behemoth can shove a large habitat and the airless landing module around the Kerbol system. It is largely dependent on PWB Fuel Balancer to keep the vertical centre of mass directly ahead of the engine pods. It does fly with FAR! Who says one Orion unit should be enough for anyone?
  4. I've been asking myself the same question, but from the point of view of someone who's tried IR - and I'm generally content with it as long as I stay small, but I want a way to build chunkier structures and with IR everything gets a bit floppy over a certain size. If anyone knows if BG addresses that, I'd be interested.
  5. I forgot about ion engines, yes, thanks. The other thing that might be interesting to look at is reaction wheels - now obviously they're a bit magic, and worse yet on larger vessels IRL you have CMGs (but perhaps the way the large wheel uses less EC per unit torque touches on that) - but at a very brief glimpse, IRL reaction wheels pull somewhere between about 10 and 50 W per kg. The small wheel can use 0.75 EC/s, the medium one 1.35 EC/s, and the large one 1.80; between 0.009 and 0.015 EC/s/kg. This gives us anywhere between 660J and 5.5kJ per EC. Given that reaction wheels are magic anyway, I'm inclined to say "this doesn't contradict 1 EC = 1 kJ" and leave dealing with their magical effects to other modders. (In practice, I don't fit reaction wheels and set the ones that come built in to other parts to "SAS only", to require me to use RCS more prototypically). (Other things to consider: LFO engine alternators. Stock wheels, probably with a view to just reviewing the old Kerbal Foundries configs for them.)
  6. A list of things CKAN doesn't do. So what's your point? (Also, please don't quote the GPL at me; I first read it - well, I read the pre-GPL licences that became it. I'm quite familiar with it.) [snip] Obviously you can't tell CKAN that because CKAN doesn't publish mods at all, the fundamental fact you are failing to grasp. The licences imply restrictions on activities CKAN doesn't do and that a mod forker doesn't do when CKAN asks them about indexing their mod. Please answer this question without dodging it - remember that this was written in response to "So the author is not allowed to refuse a consent to the work be republished", so you need to explain why that is relevant when CKAN doesn't republish anything.
  7. You don't need to reiterate this argument. I understand it; it's just nonsense. CKAN wouldn't be claiming that, because CKAN doesn't modify or distribute software, so the author could not be forbidding them from modifying or distributing the software. This has also been explained to you several times already. I wrote "github distribute software. To do that, they need permission from the copyright holder(s). CKAN don't distribute software." not because I failed to understand you, but because you appeared to be trying to draw an analogy between "Bob writes something, Alice uploads a modified version to github" and "Bob writes something, Alice modifies it, CKAN indexes Alice's version". [snip] And since CKAN doesn't republish anything, this is relevant to an author making an (unenforceable) request to CKAN not to do something else because...?
  8. It struck me on the way home that for many purposes, the power to mass ratio of a solar panel is what matters, even if the area looks funny. It is also quite hard to find figures on the mass of solar panels, but each ISS "wing" is around 1,100kg (and is 1/8 of the overall output) for 27 W/kg. A Gigantor produces 0.08 EC/s/kg. This would make an EC around 340J. However, I think I'm willing to say that the ISS solar array (which also has a low output compared to what you'd expect from a naive assessment of its size, solar flux, and typical efficiency) is more robust than a Gigantor (which, after all, shatters into a million pieces if you look at it funny) and the power/mass ratio isn't a total outlier compared to the power/area ratio.
  9. github distribute software. To do that, they need permission from the copyright holder(s). CKAN don't distribute software. github users upload software to github. To do that they need permission from the other copyright holder(s). People who write CKAN metadata don't upload software anywhere. A mod author doesn't upload software anywhere because CKAN indexes their mod. The distinction here has been explained to you several times already.
  10. I think you want to be careful about desperately Googling up links in a hurry which look vaguely plausible, but the difficulty with this kind of "anyone might sue anyone" argument is, well, CKAN doesn't change anything there. If Alice forks Bob's mod, Alice always runs the risk that Bob will decide she has done something wrong and take action (imposing the "burden of proof" on Alice), even if Alice has not done anything which was not permitted. Whether or not Alice said CKAN could do something doesn't change that, especially when that thing is something which doesn't involve Bob's copyright and isn't something Alice can actually require CKAN not to do, as opposed to requesting they not do it.
  11. I'm back after a few years away and wondering about something that's been bugging me for a while. The apparent value of a unit of ElectricCharge varies wildly depending on what kind of part one looks at. I was thinking of doing a mod with a ModuleManager rune that would adjust (eg) all parts' energy storage by a like factor so if they were balanced relative to stock parts, they would remain balanced in that way. (Then, presumably, it would turn out to break some specific mod parts which would need special treatment). So, we ask ourselves, how much is a unit of ElectricCharge? (In particular, I bet there is at least one hilarious error in what follows - point it out to me?) Solar energy flux near Earth (and hence near Kerbin?) is circa 1400W/m^2; 30% efficiency would give us 400W/m^2. However, the ISS's arrays produce 100W/m^2 when it is not eclipsed. An OX-STAT is 0.3*0.5m and puts out 0.35 EC/s; that would make a unit of EC between circa 40J and 170J. This implies that probe cores draw somewhere between 1 and 5 W (not counting torque). This doesn't seem implausible - it's in Raspberry Pi territory, say. Presumably most of the volume is reaction wheels and leftover Snacks wrappers. Let's pretend a unit of EC is 100J, somewhere in the middle. But round batteries have an energy density of 4 EC/kg. That's... 2kJ/kg. This is quite low compared to, say, a Tesla 85kWh (sigh units) battery which holds 560kJ/kg! (Lithium thionyl chloride batteries, actually used in aerospace, do better, but it's not a rechargable chemistry). Let's be generous and say kerbals engineer really superb solar panels and so a unit of EC on the solar scale is _200J_; now round batteries do 4kJ/kg. We would need to multiply up battery capacities by a hundred to get them into the same general efficency range as solar. Conversely, battery weights want one EC to be around 20kJ... but then that probe core draws 500W! Aerospace fuel cells provide c. 500 W/kg. A KSP fuel cell array (different chemistry, mind) provides 0.075 EC/s/kg. This would make an EC around 6.6 kJ - closer to the battery scale. A SNAP-27 RTG as used on the Apollo missions provided about 3.3 W/kg (and this is not an atypical figure). A PB-NUK provides about 0.01 EC/s/kg, suggesting an EC is about 3kJ. Not a bad deal compared to the fuel cells, especially given you never have to refuel it. A USILS kerbal uses 0.01 EC/s for their life support needs. On the solar scale, that's 2W - pretty generous for an astronaut. On the battery scale, it's a perhaps more plausible 200W. (TACLS used 1 EC = 1kJ and on that scale a kerbal uses circa 20W with TACLS consumption, 10W with USILS). Humans are bigger than kerbals, and Skylab seems to have used circa 400W per astronaut over and above its uncrewed power consumption, so that's at least in the right ballpark. So, any errors in that, and any thoughts on which direction the adjustment should be done? There is something to be said for adjusting everything towards the 1kJ = 1EC convention which at least some modders have used.
  12. Only if the author actually denied them consent to modify or distribute the mod; which has nothing to do with the question of what the author said about constructing metadata about the mod. (Furthermore, the latter obviously isn't a matter where the author can forbid CKAN to do that, anymore than you can forbid me to write down the size of a file you have created; asking them not to construct metadata is a request.)
  13. I've tried the F5-F9 thing. (I was already turning it cautiously, because in my 1.9 game the part being rotated is extremely heavy). Not many Krakenings... but the second pair of ports still doesn't rotate. (It strikes me that maybe it doesn't for you either and that is what you are investigating, in which case, sorry for effectively a duplicate bug report). I can't replicate the second oddity either. I suspect it's another one of those intermittent issues.
  14. I'm back playing KSP after some years. I've just discovered that when I did the RPM IVA for the Karibou, I didn't take account of the way male kerbals are slightly taller than female kerbals. As it happens my test driver was female, and so the bottom seat's instrument panel (which is above the driver) is nicely positioned for a female kerbal, but if the driver is male it means you can barely see above the vessel's centreline at all. Sorry about that. I could move it up so it is correctly positioned for a male kerbal. This won't create a similar problem; a female kerbal can pan the view up to see a panel that's too high by default (seeing slightly less of the ground passing under the rover; and this won't be _super_ convenient, but it's even less convenient for male kerbals now) but as it is now a male kerbal can't pan the view in any way to stop the panel blocking his forward view. Would that be useful enough to be accepted? I'll not make promises; I'd have to dig out all the tools I used last time and remember how to do it, and I might just decide I'll let women do all the rover driving.
  15. I'm back playing KSP after, er, some years away. Pleased to find this is still going, and how nice the parts look now; and the ability to see in the editor which way the tracks actually think is forward saves a lot of headaches.