hatterson

Members
  • Content Count

    24
  • Joined

  • Last visited

Everything posted by hatterson

  1. Err, I was thinking of a different part, the probe core. Either way the concept works if you launch the command pod first and EVA off the launch pad, then launch the rover and walk back up to it.
  2. I've found it easiest to simply launch the rover, drive it off the lauchpad, then launch a command pod, eva, and walk over to the rover. My solution to this is to basically duplicate the docking ports. The part hard attached to the module is a construction port, but then attached to that is another normal docking port. Yes it adds some more parts and loses a bit of stability, but it gives you the ability to dock to it normally and when you want to construct things you just remove the doubled port and deconstruct it in space (getting some materials back). Yes the construction port and docking port are back to back (which makes the editor say it's an error, but who cares).
  3. Definitely looks like something I'll have to give a go. Would it be possible to include a few more screenshots in the OP (specifically of the tech tree and some of the new parts)?
  4. It shows because Minimus (along with all other planets/moons) are actually rotating. When you're sitting on the surface you're "orbiting" minimus at roughly 9.5m/s as that is your speed relative to the center of the planet. If you're trying to land, what you need to do is click on the blue box that has Orbit in it. That will switch the velocity mode to "Surface" That will give you your speed relative to the surface below you, which will exclude the default 10m/s that Minimus spins at. You can see a similar thing on Kerbin when launching a new ship by clicking on the same blue box (it should say surface when launching). It will go from "Surface 0m/s" to "Orbit 175m/s" because when you're on the surface of Kerbin you're moving at roughly 175m/s Let me know if you have other questions on how that works.
  5. If a modder wishes to take a finite system and use it in an infinite manner, shouldn't it be their responsibility to implement a way to expand that system? I'm not at all opposed to a system like this where a science lab is used to do actual research as opposed to simply increasing transmit value, but making the science system infinite seems to be a solution in search of a problem, especially given that it already was infinite via asteroids, contracts, and strategies.
  6. One thing that's helped me in the past is adding -force-opengl as a parameter to my KSP shortcut. Dramatically cuts down on memory usage and I haven't seen any change in performance (although admittedly I haven't rigorously tested it, just haven't noticed anything while normally playing). .25 was the last time I went really crazy with modded installs and adding that parameter turned my memory usage from ~3.6gb down to 2.1gb. On my less modded .90 install it makes the difference between 2.15gb to 1.15gb
  7. I added a comment on one of the enhancements, but am copying it here for discussion. If you move down the road of a tech tree, and to avoid duplicating a UI/hassle with a UI, does it make sense to integrate it into the stock tech tree system? Potentially making use of TechManager and/or TED - KSP Tech Tree Editor. Specifically thinking of something like anonish describes in this post where you could have the KCT tree be and addon to the rest of the overall tech tree. That would require you to progress a certain to certain milestones before various VAB/SPH upgrades can be unlocked.
  8. I'd say there's two options 1.) Only 1 happens at a time. Reconditioning has to be completed prior to rollout. 2.) Both happen at once, but you can only complete a certain percentage of rollout prior to reconditioning being complete. Part of the rollout time is literally that, rollout. Physically moving the craft from where ever it is hangered to the pad. Then the next part of rollout would be putting it onto the pad and fueling it up. Clearly you could complete most of the first part of the rollout (from storage to beside the pad) regardless of what shape the pad is in but it's pretty hard to plop down a 75ton rocket on top of a maintenance worked who is laying some new metal grate. Implementation may be to have half (or any other percentage) of the rollout able to be completed simultaneously with reconditioning, but the rest of it has to wait. Obviously #2 is more work from a development perspective, but perhaps you could solve it internally by having two 'build queues' for the launch pad. The first handles reconditioning and fueling in a first come first serve method, the second handles 'rollout' Ships have X bp of rollout, and Y bp of fueling. When they're done with the first queue they're moved to the second. If you implement option 1 above, IMO, you should have to spend time to rollback a vessel (perhaps just count the percentage back to zero at the same rate it was counting up) and then rollout the next one. If you implement option 2 above, you should be able to roll out the second second one while the first is defueling or being rolled back (pretend you have multiple movers), but again, only 1 vessel would be able to use the 'recondition and fuel' queue at a time. Lets take 2 vessels as an example. Vessel 1 takes 10 minutes to roll out and 10 minutes to fuel. Vessel 2 takes 3 minutes to roll out and 8 to fuel. You choose to launch vessel one and send it through the system, but when you go to launch you realize that you need vessel 2 in orbit first (maybe it's a com satellite that's needed for the first). At that point you choose to swap the vessels. Vessel 1 begins to unfuel, taking 10 minutes to do so. Vessel 2 begins to be towed out, taking 3 minutes to reach the pad. At that point there's still 7 minutes left of unfueling for Vessel 1 so it simply sits there and waits. Vessel 1 finally finishes unfueling and starts being towed back to storage while Vessel 2 is loaded onto the launchpad and begins fueling. 8 minutes later Vessel 2 is fully fueled. Here, you could either launch, or be forced to wait an additional 2 minutes for Vessel 1 to finish its rollback (under the guise of safety, and not having 2 things at once). Because Vessel 1 was occupying the pad the full rollout (from storage to fueled) for Vessel takes a total of 3 + 7 + 8 (+2) = 18(+2) minutes instead of the base 11 so it gives you some 'punishment' for not planning, but it's not adding a full additional 20 minutes that it would take to store Vessel 1.
  9. That's actually not that crazy from a realism perspective. A kerbal (or human) weighs an awful lot less than a command pod. Any old helicopter can fly out and pick up a kerbal or three and the few pounds of surface samples they have, but it takes a major operation to recover a 3 ton command pod. Sure you could send out one craft to do both, but if the goal is just "hey get out there and pick up Bill" there's no reason to send the behemoth lifter and all it's winches and crew out to the site, just send the cheap little copter and pick them up
  10. Will there be a way to delay recovering stages? Generally I have the funds rewards for things cranked way down, which means I wouldn't want to "waste" money on recovering a part until I actually need it. Or I may not even have the money to recover a stage if it's part of the launch of a mun exploration mission. I may have to wait until my Mun explorer returns to have money to do anything more.
  11. In a way that's what having a decreased value is. You get X number of credits back for recovering a part, but the further away it is from KSC the more it costs you to recover it, thus receiving lower number of funds in the end. Although if you're playing with an inventory system (Construction time, or the next one magico is doing) then maybe it does make sense to have a recovery cost, since you're not actually getting money back for an item, you're just getting the item back.
  12. The problem is that you don't know it's working correctly, you just know that you haven't experienced any issues yet. Maybe there never will be any, or maybe the next one will show up when you hit some obscure scenario. Now, when you yourself are modifying files (either hex editing or modifying source and recompiling) you're taking a certain level of responsibility for looking into errors. If something occurs in the future, the odds of you (as someone who modified files) thinking "hey, I remember that I had modified this to ignore the warning, maybe I should check for an update before reporting the error" is significantly higher than an 'average' user who simply installed a mod to ignore the popups. To speak to this from the position of someone who develops software for a living (although not KSP mods) and has to deal with end users. Yes, there will be some users who will ignore anything you do no matter how many warnings, bells, flashing lights, etc. you do. However there are also many who are just above that threshold. Those that will see a message that says "Hey this may not be compatible with this version, you should look for an update" and actually look for an update. The problem with hiding warning messages globally is that you take all the users who are in the "if you warn me, I'll check" category and move them into the same group as those who don't check anything. That increases the number of "bad" reports that mod writers receive. Sure, it's easy to say "just ignore the reports" but that completely ignores the issue that determining if a report is valid or not takes time and effort. A mod like this will increase the workload for modders thus it is perfectly reasonable for a modder to say "If you are going to use a mod that deliberately undermines behavior that I've programmed in, I'm going to disable my mod" Now, in the strict sense, a user can do whatever they want to disable anything a mod does, just like a modder can do whatever they want to disable their mod when they detect a user does that. The problem comes in when you lower the entrance barrier to destructively modifying other mods without really informing users of why you're doing it and what the consequences may be. It especially doesn't help when someone takes an aggressive attitude towards a community that is entirely volunteer. In the end there's nothing explicitly wrong with this mod, but it's a bit of a jerk-move towards other modders as it actively makes their lives harder and thus discourages them from continuing or new mods from being developed. Perhaps, yes, there is a small subset of users that are "helped" by this, but such an approach actively punishes the modders who put in time to make the mod in the first place and fundamentally stomps on the efforts they've gone through to limit support on their mod.
  13. I'm forgetting if this was mentioned earlier, but will we be able to sell inventory items for cash with the new system? Specifically I'm thinking along the lines of using a mod like Karbundium or Interstellar to mine/collect rare fuels and sell them for cash. Basically making a mining company to raise funds to keep exploring
  14. What about allowing simulations to land on planets without atmosphere simply by purchasing the relevant planet/moon package, but for planets *with* an atmosphere you need to have science from within it. To logic being that if a planet doesn't have atmosphere there's nothing stopping you from simming a landing short of knowing the terrain which is presumably accomplished by the probe/kerbal that returned the science, whereas if it does have an atmosphere you don't really know what it'll do to your craft or what it's made of before you've experience it. From a gameplay perspective it fits, even with mods like RT2 with signal delay, because it's still fairly easy to land an unmanned probe on a body with an atmosphere so you're not adding significant difficulty. That way you can still sim your very first minimus lander without having to put a probe down, but if you want to land on Laythe you need to at least send a probe down to get atmospheric readings of what you'll be dealing with. As far as sim "build" times, I'm not a fan of an individual sim taking time, but I do like the idea of hardware taking time to build. What about breaking it into two categories, hardware and software? Hardware costs cash and, like ordering something off newegg, it takes a bit of time to ship and then you "install" it. Simulation time on this hardware can be sold for a small amount of cash at first and you can gradually upgrade it to include more processing power/storage. Maybe for simplicity sake just leave it at a simple "upgrade" option without delving into upgrading CPUs, GPUs, RAM, disc space, etc. Then there's software packages. These would be your base sim suites. You'd have a Kerbin suite, a Mun suite, a Jool suite, etc. Each of these cost science and take a bit of time to develop but once it's complete you own that sim package. Simulations would be priced based on the size of the vessel you're simming and the package you're using. Simming a massive vessel in the Jool package would be quite expensive, but simming a tiny one in the mun package would be cheap. Additionally packages would have certain hardware limits, ie. you need at least 3 "upgrades" to your hardware to use the Jool package, or 2 "upgrades" to sim a vessel that costs over X build points. In addition, adding new sim suites would increase the value of the sim time you're selling. Perhaps you could tie this into the contract system so that a contract may appear for some other company wanting to purchase sim time for the Jool system. You'd need to provide them with X number of hours of uninterrupted sim time within Y days in return for 10x the cash you'd normally get from selling time. Failing to do so costs you reputation and a little bit of cash (a cancellation fee). Perhaps with each completed contract you have a random chance of receiving science based on its complexity (not sure if the contract system supports random rewards) Perhaps make it so that the only way you can make money selling sim time is with the contract system? Other than that it's assumed you're selling the excess processing power you have to a random bidder and basically receiving back what it costs to run the server (ie, no money change if you're sitting idle). The cost for sims is justified based on the fact that you can't sell that processing power while you're using it so you have to actually pay to upkeep the server. That also justifies the larger cost for simming in more advanced packages. If you have a massive server farm and are only simming on the Mun you can still sell most of your power, but if you're simming for Jool you need it all for yourself so you can't sell any.
  15. That's kinda the point of simulations though, at least IMO. You need to be able to test if a craft will work prior to spending days/weeks/months building it. I'd rather see simulation price/scale factor included as a setting. That way if you're really intent on not really using simulations you could jack up the cost and be forced to fork out thousands of credits. Edit: In addition to adding a scaling setting, I like the ideas Noventta posted a couple pages back about having all orbits unlocked from start, but needing to visit atmospheres (ideally do some kind of scan/science there to "learn" about it) before you can unlock that. Although it would mean you shouldn't be allowed to start a sim in orbit of Eve and then just deorbit yourself into the atmosphere, the sim should stop at that point. If you wanted to take it even a step further (I love thinking of ideas for other people to work on ) you could say that atmospheric flight requires having been there and landing requires having been to a location in the vicinity or having scanned it (possible tie in with scansat or similar). Want to sim a Moho landing? Better have a scan of the surface, otherwise your sim engine won't know what it's doing. So you'd have orbits unlocked by the fact that you have giant dishes at KSC, atmospheres unlocked by being there (either manned or unmanned), and landings unlocked by either already landing within x kilometers or having done a surface scan of the area. If you enter an area you haven't unlocked (either enter the atmosphere or get with y kilometers of the surface) you simulation is ended.
  16. Oh man, so glad there's a patch. Between this and the opengl I went from ~3.5GB (basically crash anytime I loaded a large ship) down to ~1.8GB. I can get more mods now yay! Better atmospheres here I come.
  17. http://www.filedropper.com/2014-10-02191208 That is the link to his file
  18. An interesting "workaround" (well not really a workaround, more a gameplay extension to make it feel more fun to reuse spacecraft) that I've been meaning to try is to literally re-use the same ship. Warning: I haven't actually done this in game yet (haven't had the time) but I have given it thought, and I'm pretty sure it'll work. There's a couple minor issues, but both have workarounds. Step 0: Have KAS installed, build a fuel truck (at minimum a fuel tank and some wheels to move around), and build a crane truck (something to pick up payloads and move them). Step 1: Spec out SSTO and have it and the payload built as normal. Step 2: Launch and deploy payload Step 3: Land back at KSP, but instead of recovering the vessel simply park it off to the side of the hangar. If you need to recover science simply have your pilot hop out of the cockpit, grab the data and walk back to the astronaut center (or just hit recover once he's out of the vessel). DO NOT RECOVER THE SSTO, leave it sitting off to the side. Step 4: Design and build a new payload that will work with your current SSTO, start building it. Step 5: Before your new payload is complete have your fuel truck refuel your SSTO. Drive it over, and use KAS to link them and pump fuel across. Step 6: Once payload is complete "launch" it. Not with the SSTO, just the payload on it's own, stabilize it if necessary so it doesn't fall over and blow up. It'll just sit on the runway. Move your crane truck over, pick it up, drive back to your parked SSTO and lower it into the cargo bay, securing with either docking clamps or with KAS struts. Step 7: Wheel your SSTO back out to to the runway and take off, deploying the next payload to orbit. Rinse and repeat from step 3 Obviously the limitations are that you have to land at KSC, or develop an actual recovery process via rovers or boats (certainly a non-trivial task). In addition there's two "issues" I foresee: 1.) Refueling your fuel truck. The workaround for this would be to simply build a rocket that's just a fuel tank. That would take about 2 seconds to build, at which point you could move your truck up to it and suck the fuel out. Alternatively you could build a Karbonite based mining facility beside the KSC and refuel like that. 2.) Getting a kerbal to man the SSTO after it has been parked (or a Kerbal to run the refueling via KAS). Obviously you don't want your pilot just sitting in the SSTO waiting for the next launch, so you've recovered him and he's happily relaxing in the astronaut lounge. No matter how many candy bars you promise him, he just won't leave there unless you "launch" a new vehicle for him to fly. The workaround for this would be to build a rocket that's just a command pod or a crew can. Super cheap, quick to build (even moreso if it's in inventory). Once it's done have Billybob Kermin hop out and walk to the SSTO. Recover the command pod/crew can for use in your next crew "deployment" I'm intending to do a video proof of concepting this when I get time. Hopefully later this week or early this weekend...although that also depends on getting the recording software up and running on my laptop which may prove non-trivial given my limited hard drive space at current. At the very least I'll get a series of screenshots. Shouldn't there also be a monetary cost to refurbish the parts for use again? (meaning beyond just build points). Surely at least some minor things needed to be replaced on an engine and not just polished with a rag and hit with some WD-40. Maybe something like 10% of the base cost of the item (excluding fuel) is required to refurbish a part. In addition (more for long term plans), what about marking certain parts as single use only? Things like an ablative heat shield can't really just be slapped back on the bottom of a new rocket as if they weren't used before (unless the ablative 'resource' needs to be re bought, I can't exactly recall how DRE works with that, it's been a while since I've used it in my saves). Single use only items would be recovered for funds like in the old model and multi-use items would be recovered into inventory to be refurbished (with cost and build points)
  19. I'm very happy to see that someone has been able to do this without (at least it sounds) a massive headache. My .24 save is on KSPI-l and I'd ideally like to move it to KSPI without resorting to rebuilding the ships and hyperediting them into their respective places. Given that I've yet to get too far into this playthrough, I don't believe I have many of the higher ups techs deployed yet (I really can't keep my saves straight sometimes ) I suppose worst case scenario would be to just restart, although it's annoying to re-do all the initial missions since I now have to figure out cost of items.
  20. I would try active texture management, if that fails the only other option would be to eliminate mods until you can fit in the RAM window. In regards to the two new stars added. I can't test it out right now, but based on the video in the OP they orbit Kerbol, is that correct? Is there any way to have them free floating in space or is that a limitation to the way that KSP is designed?
  21. Anyone else notice their in game time jump forward? I probably wouldn't have except for the fact that a friend and I are having a competition (fastest to do stuff in kerbal time). Last time I exited the game (Sunday) I was at about 15.5 hours passed in game. When I sign in now I'm just a hair over 3 days. My mission execution times also saw an increase but I haven't been able to find a common theme for how much it went up (either multiplier or static amount).