Octa

[quote name='Talavar']Just a suggestion to make the batteries, etc "upgrade-able". Rather than having 24 batteries wrapped around the ship, and tons of solar panels.. You could simply pay extra to "upgrade" the item at the same cost of the initial item. Each upgrade would lift the capabilities of the part by 1x. hence a 1000 capacity battery would become a 2000 capacity battery, then upgrading it again would make it a 3000 capacity battery, etc.. Would cut down on part counts, and help out a lot when constructing bases that end up having crap-loads of parts in the end, which slow down calculations. I know batteries and the such are physics-less, but they still seem to have an impact on performance, regardless. Cheers. :)[/QUOTE] I don't like this idea, it'd be better to have other "heavy duty"-parts than to make the parts indistingishable by their looks. "Did he use a normal small battery or did he upgrade it?" Also, scaling up leads to worse stats for the solar panels: 1 x Gigantor: 3000 funds, 0,3t, 24,4 electr./s, 81,33 electr./ton 70x small solar panel: 5250 funds, 0,35t, 24,5 electr./s, 70 electr./ton almost twice as expensive, a bit heavier and overall less efficient for the same elecftrical output. Plus: You have the same electrical output in a much, MUCH smaller panel, which is absolutely unrealisitc. Even in the current game, there are enough ways to work around a part limit. Less overengineering is a good start. You don't need battery capacity to keep an ISRU, science data transmission, lab, drills, lights and SAS running 24/7 for 10 years. usually, it's 1 night. :confused:

[quote name='pTrevTrevs'] The F-35, on the other hand, will lose [I][U]all[/U][/I] of its instruments if it gets hit, and you can't fly a plane without instruments. In addition, it uses fly-by-wire instead of hydraulic controls, so lightning would kill that too, so you wouldn't be able to fly it at all, really.[/QUOTE] I recall that many modern aircrafts (Eurofighter?) are aerodymic unstable and rely on a avionic-computer to stay in the air, so this problem is not exclusive to the F35.

With all the drag and re-entry heat, i wonder how to get bulky payloads like base parts or rovers (imagine a large rover with a 2,5m outline with a cupola module) to the ground of duna or kerbin without blowing up. It was rather easy before 0.90 :D Do all have to be occluded by a heat shield? With that rover design i described, the wheels wouldn't be occluded by a 2,5m heat shield, so it'd have to use a 3,75 heat shield then where the rover fits in? Do cargo bays work? Bonus question: How would i get an empty SLS-tank (the largest one, S3-14400) with wheels to duna? Not that it would make sense, but this is where i can't simply attach a heat shield in front of it anymore. PS: i had only sent rather small probes to duna until now. Very light, short and streamlined with a 1,25m or 2,5m heat shield. My configuration always has an upper stage with retrograde rockets, drogues and normal chutes. After heat effects disappear, i start the rockets to slow me down to safe chute deployment speed. After the chutes deployed and the fall gets slow enough i jettison the heat shield and use the rockets again just before touchdown, if my vertical speed is to high for a soft landing. After touchdown, i power up again, so the whole thing is _just_ before lifting of again and decouple the upper stage, so it flys off (and with some F5+F9ing, the lander stage doesn't flip around). I doubt i can adapt this 1:1 for much larger and heavier payloads.

[quote name='sardia']Follow up question, how can I adjust the design so the rover can lift off and land with stability? Or should I send another ship to come pick up the fuel?[/QUOTE] Afaik, ore is lighter than the fuel you generate of it. If you have an ISRU in space, use that and get only the ore up. If not, i guess a separate vessel for resource transport (may it be ore or fuel) would still be better. This ship could be a few tons lighter, because the rover (the all in one solution) would have to lift and land many unnecessary parts: Radiators, ISRU, Drills, wheels, fuel cells. All stuff you'd carry with you but you don't need when you want to transfer fuel.

A sticky ball to throw at rockets...that's what KSP is about.

Best thing i could imagine would be a documentary-style movie from the POV of an engineer(-team?) who tries to get to best out of the STS, but can't because management decisions make the shuttle FUBAR, which ultimately leads to the accident. Begins with Moon landing/end of apollo program, main part would be the STS-Program itself with the launch of the columbia at the very end. The movie could deal with NASAs struggle with budget vs. safety vs. requirements for the shuttle... Of course, this could only work out if the shuttle would have turned out much better if NASA would've had more money or could have changed the design goals (iirc the air force had a huge say on the requirements)

If the default setting of the ascent autopilot can get a rocket into space, i think "mission accomplished", as the rocket is fool proof and manual piloting can only make it more efficient. I like the insta-planning for maneuvers. Even for manual launches, "circularize at Ap" is a nice feature, because the finetuning of the maneuvers is annoying to me. I perform the actual maneuvers for myself, it's mainly the planning itself which is left for MJ. For transfer-burns for rendezvous or interplanetary transfers, i tend to plan the maneuvers for myself and finetune them using MJ (once again because of the frickling when doing it manually) With DPAI, docking became something fun for me, so i do it manually most of the time. But for a fuel station, where 12 tanks were added, i only docked the first 2 tanks (as a proof of concept) and the last one completely manually, because it became to repetative. Hence, the insta-planning ("Match velocities at closest approach") is still nice to have. MJ just takes out the boring stuff out of the game which i done a thousand times before.

[quote name='ExtremeSquared']That's probably a half ton of pointless mass then. Bring down the mass by tweaking ablator, the ship density will go down, and you'll use even less ablator aerobraking. Energy to dissipate is proportional to m * v²[/QUOTE] I know how tweakables work and i already do it, but still thanks :wink: I just keep wondering why the shield carries that much ablator by default in the first place, or if there are situations where you really need 200 units of it.

[quote name='stormdot5']-> Less trim required, but not actually adjusted -> Pitch up due to trim[/QUOTE] oh, yeah....i forgot the last steps in the equation. From what i read about autopilots IRL, keeping a plane at a constant altitude or speed is rather simple, but requires constant adjustments. Constant altitude [B]and[/B] speed is where the fun starts.

Is "Supported KSP Version 1.0.99" just a workaround for the developer to say that the mod should work until 1.1/in all 1.0.x-versions? Also a few mods haven't been updated yet and not listed as compatible, but accorrding to the threads they work in 1.0.5. Can i force the installation via CLI? Edit: I support BlackHats suggestion. We already have a "Recently added"-Filter, so a "Recently updated" filter would be a nice addition.

[quote name='ExtremeSquared']Tweak the heat shield ablator down a bit. Unused ablator is unnecessary craft density and higher terminal velocity. I usually tweak it to 25-50%. Any re-entry that uses over 50% ablator has proven utterly suicidal anyway.[/QUOTE] I rarely ablate 15 of 200 units of the heatshield :confused: The amount of ablator is totally overkill for capsule re-entries. May be different for return vehicles or other bodies like Eve.

May i suggest a third explaination: :sticktongue: Fuel consumption -> less mass -> higher TWR -> higher accelaration and speed -> more lift Edit: Try Pilot Assistant, i use it to keep heading and vertical speed/altitude

[quote name='Clear Air Turbulence']Hmm. Interesting. So hat would mean that mining rig and orbital refinery around Duna could be quite a good way of opening up the path to Dres and Jool. I like the idea of a process of planetary explanation with lots of ships that never need to touch down on Kerbin. I am saving Eve for last, I guess.[/QUOTE] I just typed in some numbers in the online launch window planner to compare direct flights to the outer planets and flights with a refuel on duna. Turned out the direct flights to Jool and Eeloo are cheaper by 1000 m/s, except for Dres. There you can save 700m/s, but you arrive 4 years and 200 days later than with a direct flight for kerbin, you actually turn a lot of time into a delta save of 700 m/s. Every flight assumed a 100km orbit at departure and and arrival. Now the question for the ones who actually know how to do the math: How can this be turned into a gain? As far as i understand, this can only turn out to be efficient on paper if you take all aspects of the missions into consideration: - The Ships can be lighter, as the longest burn is 700-2500 m/s cheaper than a direct flight - Lighter payload means less fuel und funds spent. For the payload itself and most important for the launcher - You must bring a ressource miner, refinery and storage to duna, which means 1-2 aidditional launches (they can fly with along with the first vessel to duna, if a 500 day stay is enough to get fill up the other vessel) When using vacuum engines like terrier, poodle or nukes, it looks hard that a fuel station can actually save funds. Just a few m/s as safety margin and it can turn out you need another mission which refuels there to get a plus. Should anyone be interested, i saved the calculated flights into a text file.

@fisfis did you read my last post (last post on the previous page, so i assume it went under the radar)? I mentioned some of the points you did: Software devolopment, versioning, adding new content or bugfixes... TLDR: Semantic versioning version looks nice, but does not appear to be a thing, especially in game development. Even bugfixes can break current missions. I dunno why KSP is currently >1.0, i certainly don't like that but i don't care while playing.

[quote name='MaxL_1023']I thought his problem wasn't burning hot, but not bleeding off enough speed before hitting the ground. A shallower angle gives your pod more time to slow down when your heatshield can take it. Maybe I am used to the RP-0 heatshields - one of those is almost as heavy as your pod.[/QUOTE] I've read on another thread (the one discussing the eve re-entry i think), that there's always one problem with wrong entry angles: Too steep: Obviously, you come in way to fast. You either burn up or hit hard, because the atmosphere cannot slow you down enough in that short time. Too shallow: You spend too much time in the upper atmosphere: You might lose enough horizontal speed up here, but that happens way too high. Then, you get into the drop (where your prograde marker begins falling down significantly) pretty high from the ground and you start to gain vertical velocity. Once your falling speed exceeds 200m/s (and i guess this can happen while your overall speed is above safe chute deployment) and you don't have drougue chutes, you fall trough the lower atmosphere like a brick. A fast brick. This explaination might be wrong, but it sounds intuitive for me. Some other User might correct me.

I once built a fuel station in a 250km orbit (sandbox, just because to see if i can). I imagined to set up a similar station in career mode with an ISRU and a vessel that drills and delivers ore from minmus. For larger interplanetary missions, i'd launch the payload with empty tanks and refuel them at the station before leaving kerbin. Worth a try or uttlery inefficient? How does it look on other celestial bodies (Ike/Duna or Eve/Gilly)?

[quote name='fisfis']This is his decision. I would expect bit different approach from Squad, especially in versioning, patching, releasing new versions and compatibili [/QUOTE] Well, as far as i remember, the series started before 1.0. Anyway, even if they'd stick to that and they don't [I]intentionally[/I] break something, there's still a chance that even a small bugfix will change something small that is important for you. Let's say that wrong parameters of some parts make aerodynamic be applied at wrong places. They fix it and now your launcher won't get into space or your capsule back to ground anymore. [QUOTE] Where is this written? I haven't seen it anywhere. [/QUOTE] Let's say....the changelogs? [QUOTE] Exactly. This is what I would expect since 1.0.0. Bugs are fixed, patches released at least for those worst ones, parts which does not need to change the game mechanics are added in minor versions and everything else including changing API for mods in major versions.[/QUOTE] So if the update was called KSP 1.1 or KSP 2.0 (besides there's no actual sequel) or the whole game is still <1.0, you'd go "Ok, everythings fine..."? [QUOTE] Squad team said (and it was also mentioned in this thread): We are proud to announce we are going out of beta and releasing 1.0.0 version of KSP. So I expected they started a normal development lifecycle with standard versioning approach. [/QUOTE] While you expected that, i expected something else. Looking at the previews and from the last updates, how KSP did grow from 0.17 over 0.25 to 0.90, i thought that SQUAD was far from completion gameplay wise. [QUOTE] For those who don't know what we are talking about: [URL]http://semver.org/[/URL] In short. Everything below 1.0.0 is beta, everything can be changed anytime. Everything with postfix -beta is beta. Same case as above. (usually used with new major versions) Major version (first number) means it brings major changes. Such as API changes, game mechanics changes, file format incompatibility and so on. Minor version (second number) means that something was added, bugs fixed, but the behaviour is still the same Patch version (third number) means that only bugs were fixed.[/QUOTE] After the release of 1.0 directly after one official beta release, i thought that the official release was rushed, and i still do. They changed aero, added heat, ressources, changed existing parts and so on. Personally, i handle the game as it never really left beta so we're at 0.95. In comes down to how the numbers the developer likes to put on the build look for you, and while semver might work well on commercial software projects (where almost 100% of the feature set can be determined even before start, if they want to) and AAA-Games, i don't believe it matches the "spirit" of continous indie development. And for commercial projects: I'm working in a lvl1/2-ish support for a rather expensive commercial business software. The versioning is completely off: User Interface was modernized between 7.2.3 and 7.3.0, and it was completely overhauled beween 8.0.3 and 8.1.0. New features added in patch releases, combined with CLI-incompatibilities (The 7.3 branch is more consistent to 8.0 than it is to 7.2), if i write something more i'd have to clean my screen and keyboard afterwards. We have to handle every patch release for itself and we actually cannot make any predictions what will change and how it will change. I don't disagree with you. It's a shame that version number are pretty useless. But on the other hand: I like the continuing development of the game. I like that the developer can add new features as they think they're ready for the players. I think feature freeze is in alpha in the classical development cycle, and that does not judge KSP well, as for an alpha there's too few bugs in it. for a beta, too much changes apart from tweaking and for gold.....well, there's not only bugfixes. But: Releasing 1.0 in this state may be troubling for new players, but for me, nothing really. Just change the version number of the release: Yay, now where back in beta, but nothing actually changes. The update still messed with your mission. I know that feel. Here's my craft engineering cycle: - plan something complex to build (colony, SSTO, space station) - experiment with various designs - Settle on the design which seems to work best for the task - tweak a bit, several test flights - Find that the chosen approach was broken by design and start over with other design - for the next 3 weeks, play around once more - see the previews of the update - get that thing where it's supposed to be. - lean back statisfied, with the mission accomplished and a good looking craft - 2 weeks later, be totally hyped while steam upgrades KSP - find out that after the upgrade, that thing won't even get close to space anymore. And now for the end, a small meme: [IMG]http://cdn.meme.am/instances2/500x/2941261.jpg[/IMG]

[quote name='fisfis'] I wrote it many times. Don't update = live with existing bugs. Man. Do you think I'll sit in front of computer for 3 years and wait till the ship reaches designed destination when there is a warp bug in the game? Wake up please. As there atre no patches released at all only the one option is to update.[/QUOTE] You know what Scott Manley did with his "Interstellar Quest" -Series? He set it up with a recent KSP-Version and a more or less staple set of mods and did not upgrade. Fully aware that an upgrade of KSP might break mods and change gameplay mechanics. If your current mission works in 1.0.4, there's no garantuee that it'll work in 1.0.5. And well...you set this mission up in a version which is affected by a timewarp bug in the first place, how did you expect this will work out? That the update will only fix this bug, maybe adds new parts and does not change anything else that was already in the game? The problem is, although according to a "classical" versioning scheme the number 1.0.5 tells otherwise, this game is still beta, so expect things to change. Newly added mechanics will require changes in the old mechanics and adding new parts might require rebalancing the exisiting ones so there are no uttlery useless or overpowered things.

Rovers would be way more useful if the penalty for transmitting science would be much lower. For me, using a rover (small automatic ones like on mars) or probes for exploration is roleplay only, but it's not useful gamplay wise. Why again is it more useful to send a kerbal to have a look at a thermometer than to send a few bits and bytes through the ether? Lets say 10 bit for the temperature, 32 bit for coordinates, 16 bits for attitude and for the sake of getting an even number 6 bit for several flags makes 64 Bit . Even Voyager can handle that (from googling i found that it sent with 21 kbps from neptun). Doing kerballed missions only is way more effecient gameplay wise. I never did it but i guess it's pretty "easy" to do a kerballed duna return mission without leaving Kerbins SOI once before, somwhere in the middle of the tech tree. Please tell me if this is undoable, but from what i see what some players can do, that's not totally of the grid to me.

[quote name='parameciumkid'] And I suppose we don't need the old cockpit back specifically, but a new version of it that keeps the same basic theme - "fighter" looking, and with the hatch on the top.[/QUOTE] This. It looks great on planes, but somehow it looks "bigger" than the old one. For small jets, fighters and spaceplanes, it does not look right. Maybe because of the large windows and because the tip is offset from the center axis.

Oh Jesus, this is compicated math. I would have guessed that the worst case darkness time of an elliptical orbit would be in a situation where Sun, PE, Body and AP where aligned in that order (like in the green area) but now with seeing the picture, i'd like to correct my opionion on that, may i take a guess, just to verify i got that right: - Ap is the where you move the slowest in your orbit. - in the green area (all points of interest in one line), you do spend 50% of your darkness time losing speed (until Ap) and the other 50% gaining speed (after Ap) So the worst case would be where the Ap is right at the end of your darkness time, because i keep losing speed during all my time in darkness? (Assuming a clockwise orbit in the picture above) As im writing, i start to wonder what average speed/time i spend in those areas, because the speed where i enter the shadow is higher in the red area. So i have to consider which is slower/longer in total: getting slower from a higher speed until you reach your lowest velocity (red), or a decreasing and increasing velocity, but starting from a slower speed). This, gentlemen is the point where my brain slowly starts melting, because the longer i think about it, the more factors i see that have to be considered.

Granted, he's a licensed lawyer from alaska (Like him) I wish it'd be easier for me to build SSTOs that are still usable after an update.

Life Support: Snack Delivery Service

Sooooo...if the wiki is right, you get the basic ones with the 1st and the custom ones with the 2nd upgrade? Sounds rather fair, as advanced crafts should need a more advanced building. There's stuff like deploying solar panels, antennas or radiators after in space. If this is time critical, you're doing something wrong. Then there's stuff like modeswitching during atmospheric flight or, toggling engines or managing intakes. For Jets/SSTOs, you need the action groups for that, sure. But why would it be "immersive" that one of the most complex things in KSP could be build and launched with less than a Lvl 3 SPH?

I thought that booster was made of obsidian. Who whouldn't hit that with an pickaxe? During SSTO-Reentry, something explodes at 40km height and the Flight Computer reports "Small Delta Wing collided with LaunchPad".