• Content Count

  • Joined

  • Last visited

Community Reputation

16 Good

About hatterson

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

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

  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.