Fraktal

Members
  • Content Count

    206
  • Joined

  • Last visited

Everything posted by Fraktal

  1. That's not the problem. It's an entirely reasonable expectation. The problem is when the threshold where customers consider it "complete" is being moved all the time. For example, you're contracted to develop software to download and import orders in a webshop system into the customer's offline system and half a year later, the customer suddenly asks for the same software to also automatically submit orders for shipping, generate and download the shipping label and package number and email-notify the destination, even though the webshop has no API for such functionality so you now have to chew your way through the HTML code of the webshop's admin UI page to figure out how to emulate manual submission with raw HTTP requests. Not to mention that they also want receipt confirmations for the notification emails and automatic re-send if the target doesn't read it, even though email service providers are not guaranteed to comply with that functionality so what they're asking is theoretically possible but actually impossible. Nothing of that sort was ever talked about in the initial feature request when the development contract was signed, but the customer suddenly thought it'd be nice to have and won't take no for an answer because they are fully aware that unlike a car or refrigerator, software can be upgraded and expanded at any time if they want. So they want it upgraded and expanded, far beyond the originally agreed upon requirements.
  2. No amount of planning and forethought will ever fully compensate for every use-case ever, not to mention end-user idiocy. Doesn't matter how accurately the end result will reflect customer expectations, they will always ask for additions later on, whining that it doesn't work and blaming you for having done a terrible job, rather than remember and admit that nobody frakking said anything about that particular use-case when requirements were hammered out before development even began. Developers aren't omniscient.
  3. YES!!! Thank you! Backwards compatibility with saves from previous versions.
  4. Started assembly of what will eventually be a spacedock in medium (300 km) Kerbin orbit. Took about three hours to successfully pull off the first launch, containing the core module, the fuel module, the propulsion module and the control module with Bill at the controls of a HECS core, as the six-axis core module was highly un-aerodynamic and too wide to fit inside a fairing. I had to resort to an almost vertical ascent until I was well into the upper atmosphere because whenever I tried a normal gravity turn, the rocket flipped at 8 km during the tail end of the transsonic region. I was also slowed down by my own idiocy because I actually had the payload in low orbit when I reverted because I wanted to put lights on the station core to be found easier during night flights and it took me another hour and a half to find the sweet spot where the rocket didn't flip during ascent. Second launch will contain the ventral power module and the starboard docking module. I was actually about to launch this when the game crashed, so tomorrow. Third launch will be the portside antenna and a short-range shuttle pod, the latter of which will eventually be followed by at least one more shuttle. Separate escape pods are not currently planned because the station's location means the shuttles can theoretically survive reentry with minor damage. While the construction is taking place in a science mode game I use for prototyping things, for the final design I'm thinking of outfitting every single module with RCS thrusters. Would it be worth it for scenarios like chasing down drifting undocked modules during refits or should I rely entirely on the propulsion module's Poodle engine for such things? Even the Poodle feels like overkill: with the propulsion engine's fuel tank and the fuel module, the station has over 4000 dV available (though the fuel module isn't intended for that, only for refueling ships that come in for docking).
  5. The aero drag on takeoff. Being awesome at reentry doesn't quite mean anything if you can't get it up there in the first place. The only workable configuration I can think of that does not require a fairing is using the stage carrying the pod as the core of a short but wide asparagus configuration. My questions about these three pods: If all three are supposed to be launched exclusively inside fairings, then why put two of them before the first fairing in the tech tree? Why make the Onion require an external reaction wheel, then put the Pea on the same tech tree node as the first RW so that by the time you actually have what you need to use the Onion, it's already obsolete? In order for these to be properly usable, I feel the Onion should be moved to the same node as the Pea (where the first reaction wheel is), the Pea should be moved to the same node as the Mk1 Lander Can (available around the same time as the first fairing so that aero is no longer a problem) and the Pomegranate should move to the same node as the Mk1-3 pod.
  6. More organization today. Question to you folks: is it worth it to sacrifice efficiency for safety? I'm asking because I took a look at one of my munar lander designs for improvement purposes and I think I may have overkilled it a bit. It used to have one FL-T400 tank which was fine for a suicide burn landing and return, but the narrow tank meant the legs couldn't extend far enough out to keep the lander from tipping over if landing on a >10° slope. So I decided to do some fuel rearrangement to lower the center of mass and spread out the landing gear and in the end, I ended up with a single T200 tank and three T100 drop tanks, the extra fuel being required to offset the dV loss from the drop tanks' nosecones. Good news is that the lander casually landed on an 18° slope without even trying to tip over, which the old design couldn't have managed. Bad news is that the extra weight meant I had to add more fuel and a second Terrier to the transfer stage (which is now heavy enough to turn like a sloth with reaction wheeling only), which meant I had to add even more fuel and thrust to the launcher stage. It still flies with minimal trouble and gets back to Kerbin with 400 m/s to spare after a non-ideal equatorial landing and retrograde takeoff, but I feel I sacrificed too much in the way of efficiency just to not have to worry about tipping over. Frankly, an early-game low-tech single-person lander shouldn't require three SRBs, three Reliants and a Swivel on the first stage alone (the previous designed needed one less SRB and one less Reliant).
  7. Today a new era has dawned, as the 8 gig RAM module I ordered back in August finally arrived, allowing me to at last experience KSP the smooth and responsive way it was meant to be experienced. Seriously, startup and shutdown times dropped to something like a tenth of what they used to be, with scene changes finally taking seconds rather than minutes. No big construction happened, just a reorganization of my inventory of boosters. Also finished a mission that consisted of Jeb and Bob prototyping the MH Mk2 command pod to fetch some science from Minmus for processing in the lab at Kerbin Gateway Station. Problem is, they got greedy and visited a second biome to double the data. By the time they got back to a 275 km orbit around Kerbin in preparation for a rendezvous with the station, they didn't have enough fuel to pull off the rendezvous and match orbital velocity on arrival. So they instead burned to an equatorial inclination so that Val launching from the KSC in a single-seat pod could fetch the data and take it to the station. The second complication arrived from the fact that after the transaction was carried out, Jeb and Bob didn't even have enough fuel left to deorbit (shouldn't have wasted the fuel on an inclination change when Val had enough to spare). It took them about 20 packs of EVA fuel to manually deorbit their vessel, by which time Val also missed her rendezvous burn with the station by six minutes and was forced to take a more aggressive approach. In the end, the data was delivered and everyone came home safely, with the station's lab now producing slightly more than 0.1 science per day. More hardware reorganization is planned, followed by a major expansion of Kerbin Gateway Station with fuel storage and a docking grid to serve as the eventual assembly point of a Duna mission at the next transfer window (over a year away), while waiting for an Eve/Ike probe to arrive in ninety days. Also thinking of building a second station far out at the edge of Kerbin's SOI as a future launch point for interplanetary missions.
  8. So you don't need to upgrade the Mission Control as well?
  9. Both of these are very good advice. I always had trouble keeping a science payload launched before I had the 1.25m service bay surviving through reentry, even when I offset it into the capsule as much as aesthetics allowed. But following this advice, I experimented with hanging goo canisters off a girder between the top of a Mk1 capsule and a parachute and it was perfect, with the canisters never even showing the overheat bar. For an added bonus, it also made the final stage's silhouette resemble that of a Mercury capsule. While this tower configuration adds some stabilization as well, it's sadly still not enough to make a KV-1 usable beyond a short atmospheric hop.
  10. Are you gonna build more AC aircraft? The Morgan and possibly the Raven is a no-brainer, Wyvern would need Breaking Ground for the wings.
  11. Considering that I won't have a rig capable of running KSP 2 for at least five more years, absolutely.
  12. It it looks like and quacks like Kerbin's equivalent of a duck...
  13. Turning a hamster wheel with high-pressure monoprop, perhaps?
  14. Flatspin is usually caused by too small/too few vertical stabilizers. One of the mods out there contains a static stability analysis graph tool, you may want to consult with that. I found that it helps during reentry if your shuttle has way more reaction wheel torque (and battery power) than what it would normally need. I have a 10-ton passenger shuttle with three small reaction wheels and four 100 EC batteries stuffed into a service bay at the aft, thing's rock-solid stable during reentry as long as I leave maintaining a 20° reentry angle completely to SAS and don't touch the controls until after I'm gliding mostly horizontal.
  15. The only way to get fuel through a heatshield without turning off "Resource Transfer Obeys Crossfeed Rules" in the difficulty options is an External Fuel Duct attached above and below the shield. It'll automatically disconnect when you stage off whatever is below the heatshield (since I presume you've got a decoupler immediately below the shield that you'll fire prior to reentry).
  16. Nope, 64. And as of this noon, I have another 8 GB of RAM ordered and on the way. We'll see in a few weeks if this will improve performance (though I doubt it, as CPU is also 98% during flight with a constantly yellow mission timer; back in 1.4, it used to be green without physics warp).
  17. Because if you don't, the wheels have a habit of kicking out like a horse if they touch the ground at an angle far from "straight down". ---- As for me, doing some testing on a three-seater ground-to-LKO passenger shuttle. She's ugly on the ground, but she does the job, able to make it to orbit only by following prograde and varying throttle to keep apoapse 60 seconds ahead (thank you for the idea, @OhioBob !). Just needs a very careful transition from surface navball mode because it's a mite aerodynamically unstable during takeoff due to a pair of diagonal winglets on the bottom to shield the two ventral Junos' intakes from reentry heat (there are four Junos and two Terriers on the shuttle itself). In fact, during this particular test flight, it actually spun out of control in the upper atmosphere but still made it to orbit after I cut the engines and let it drift a bit for the SAS to stabilize it. And for reentry, I gave it three small reaction wheels and 400 power, which allows it to maintain a 20° descent AoA and go into a horizontal glide at 30 km altitude without engine power or me touching the controls. Doesn't really fly well at subsonic speeds, though, as I can't use trim without making it backflip during takeoff.
  18. Um... UAC has nothing to do with RAM. UAC stops programs from starting with admin permissions without the user's say-so while an access violation is a piece of already running code touching memory outside of what it asked the OS to be allowed to use, causing the OS to instantly banhammer it out of existence not only because it could break other programs or even the OS itself by overwriting someone else's memory, but also because reading someone else's memory is a security risk (since it could be used to steal passwords and the like).
  19. My mistake. I meant 1.7. And I ran the game today with Task Manager open on a second monitor. The results are here, since my game didn't crash this time and as such I don't want to muck this thread up.
  20. Did a session today with a second display plugged in and Task Manager open on second display to monitor resource usage. Observations: While KSP is running, average system RAM usage is 94%, climbing no higher than 98%. Literally nothing other than KSP and Steam is running. So I'm definitely RAM-bottlenecked here and should really put in an order for that 8 GB RAM module I've been eyeing on Ebay for the past three days. KSP_x64.exe's peak RAM usage is just below 2.7 GB, seen in the VAB. Note that I've got 3.8 GB RAM in my laptop. Being in the VAB uses about 200 MB more RAM than being in flight. I'm guessing the garbage collector throws out the models and textures my current craft isn't using? Upon entering the main menu, KSP's HDD usage spikes massively. Understandable when starting the game, but it also happens when I'm quitting my current session and going back to the main menu, with over a minute of continuous double-digit MB/s usage, followed by a few more minutes of single-digit, before the menu finally becomes responsive. What's it loading from the disk that time? The main menu is also using as much RAM as being in the VAB. During loading screens, Task Manager commonly shows KSP as "Not responding". Every now and then, the game window and Windows taskbar begin rapidly flickering, with KSP's taskbar icon rapidly appearing, disappearing and showing twice, coupled with Task Manager momentarily reclassifying KSP from App to Background process. It stops when I click on KSP's taskbar button, which leaves the taskbar rendered in front of the game window and forces me to Alt-Enter twice to make it go away. However, the Alt-Enter doesn't make the taskbar go away when I'm in the main menu, only when I'm further in. At one point, pressing Space to start my first stage caused a "KSP_x64.exe is not responding" to pop up even as my rocket was very much rising behind said popup! And closing said popup left the Windows taskbar rendered in front of the game again. Upon confirming the exit dialogue, RAM usage stays at 2.6+ GB for several minutes, then drops to 500 MB, then climbs back up to nearly 1 GB while HDD usage once again goes into the double-digits before gradually dropping down to 300 GB. It hovers there for a short while, then drops to 0.1 MB and Windows declares it "Suspended" for about half a minute, then the game window finally disappears and the executable disappears from Task Manager, leaving me at 28% total system RAM usage. Why the sudden resource loading while the game is in the process of exiting?
  21. Okay, this problem has gone on long enough for me to ask. For the past few weeks, I've been having serious problems with starting the game, starting a while after I got MH. More often than not, it either crashes to desktop from the main menu or just freezes my laptop so badly that I'm forced to hard reboot (via power button held down) due to being unable to reach Task Manager. I'm suspecting Windows 10 memory compression acting up, as whenever the game does crash to desktop, I can see it hogging the hard drive at 100% for several minutes afterwards. I disabled it for now and we arrive to our current situation. Last night went like this. After running a Steam cache verification which replaced 83 files (I had autoLOC strings in the VAB since installing MH), I first attempted to start the game slightly after 9 PM but the Windows taskbar refused to not render in front of the game window and my attempts at trying to make it go away somehow resulted in me starting a second instance of the game, which completely killed my system and forced me to power-cycle. Next attempt at 9:32 PM, loading screen appeared at 9:33, main menu appeared at 9:43 but remained unresponsive for about five more minutes. Then I loaded my save with took another several minutes (not just the loading screen but to even display the loading screen). Got into VAB, click Open, game hangs for 10 minutes. Pick a small (~17 parts) craft, Load, game hangs for 10 more minutes and the screen turns completely black with only the Windows cursor visible for most of that. Then everything works fine with completely normal loading times up until I tried shutting the game down. Keyword, tried. I quit the KSC at around 12:44 AM. The main menu showed up but never became responsive; instead, the screen turned completely black again and didn't come back up this time. I let it stew for a while, hoping it would come around but after half an hour, nothing happened. So I tried Alt-Tabbing out, no dice. Ctrl-Alt-Delete, no dice. Start button, Windows taskbar showed up but unresponsive and disappeared after a few minutes (Windows event log says dwm.exe crashed with a stack buffer overflow and pulled explorer.exe with it). I finally power-cycled the laptop off at 1:33 AM. What's causing this? It can't be the fact that I installed MH, can it? No crash log was left behind. The end of output_log is as follows: System specs are a bit anemic, with a quad-core 1.1 GHz CPU and 4 GB RAM (which I'm thinking of expanding with another 8 GB), but it hasn't been a problem so far. Installed mod list: [x] Science! 000_ClickThroughBlocker 000_Toolbar 001_ToolbarControl AntennaHelper AutoAction BetterCrewAssignment ClickThroughBlocker CommunityResourcePack CommunityTraitIcons ControlSurfaceToggle CorrectCOL CraftManager CrewLight DistantObject DockRotate EditorExtensionsRedux EditorTime EngineLight ExtensiveEngineerReport KEI KerbalEngineer KerbalImprovedSaveSystem KermangeddonIndustries (Inline Ballutes) KSP-AVC KXAPI ManeuverNodeEvolved MK1CabinHatch NavyFish (Docking Part Alignment Indicator) OLDD (science part extended information in the VAB) PartAngleDisplay PatchManager PlanetShine QuickMods (Quick Revert) RCSBuildAid ReCoupler ReentryParticleEffect ScienceRelay ShipManifest TriggerTech (KAC and Alternate Resource Panel) VABReorienter XyphosAerospace (Deflatable Heat Shield) unBlur
  22. Mine only exceeds 1 minute at about 50 km altitude. I go with 1.7 myself and dial the engines down in the VAB to be no more than that at 100% throttle. Sometimes it's less, when I'm launching a heavier payload that doesn't merit using a bigger launcher. I start gravity turning at 100 m/s vertical speed and target a parking orbit just above 120 km (for time warp convenience). I'm completely incapable of launching on the same trajectory twice but I usually hit the target apoapse altitude while prograde is between 10-20 degrees above the horizon and either cut the engines then circularize at apoapse, or I pitch down and start burning somewhere halfway between prograde and radial-in to try and maintain apoapse while circularizing if I'm still far away.
  23. That sounds familiar. Is the issue you're talking about occurring during reentry and has the shuttle start rhythmically pitching-yawing an 8-figure with its nose if not going in full-prograde before finally going into a full flatspin? Because that happens to all of my SSTO designs and if you find the solution, please let me know.
  24. Give Bob an OKTO core as absolute minimum. As the others said, SAS will work and you can set maneuver nodes while in contact with the KSC. If you go out of contact, SAS will still work, you just can't set maneuver nodes. Also, don't forget to pack an extra battery or two (or bring a solar panel, if you have one unlocked) and set the OKTO to auto-hibernate during warp (it doesn't by default).
  25. Um... all of my designs do 800-900 m/s circularization burns. If I don't, I spend too much fuel while in the atmosphere.