hatterson
-
Posts
134 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by hatterson
-
-
I looked for ways to circumvent the CC popup only when I knew the mod worked correctly, but was somehow still passing the incompatibility message to me.
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.
@Roverdude: Im sorry Rover, but you are missing the point. Its gonna be the exact same thing no matter what. People that dont read threads, that dont search for themselves, are not gonna change or stop asking the same questions in your threads, no matter how many warnings popups and other contraptions you put them through.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.
-
And the whole switch to the other inventory backend is still like halfway done and not anywhere near functional.
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
-
Valid points. One of the reasons I made simulations in orbit was so you could test lander designs BEFORE trying to actually land. I'll let you land/enter atmosphere, but may restrict SOI only to ones you've purchased the package for. You'd have to have landed science to start a simulation landed on another body still, so that seems fair to me.
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.
-
This is just an idea, and probably not a very good one, but you could consider linking the availability or price of simulations somehow to the difficulty settings, more specifically the options to enable/disable reverting and quicksaves. Although it's not realistic, from a gameplay point of view it might make sense that simulations on a save where reverting isn't enabled are (much?) more expensive than for a save where the player could (on stock KSP) simply press the revert to VAB button if something goes wrong.
I guess I'm not the only one who started a "hard" difficulty game (no reverting), but later on at some point could not resist the temptation of the simulate button, just to see if FAR aerodynamics would kill an expensive craft...
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.
-
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.
-
does anyone have a fix for the fact that treeloader is currently having issues because the site that it checks is down? I can't load the interstellar tree on new career saves.
You have to manually do it:
Make sure you're in Career mode and not Science mode. Make sure Treeloader is installed. Copy tree.cfg from GameData/WarpPlugin to your save folder, overwriting any previous tree.cfg in your save. If notree.cfg exists in your save, delete it. -
Hey can you please fix your link? The forum does not support HTML code on posts, we use BBCode here
http://www.filedropper.com/2014-10-02191208
That is the link to his file
-
For the first suggestion: I am planning on adding something like that in a future update since I've had so many people request it. You'll be able to recover and refuel, but likely won't be able to add any parts to the vessel (so no new payloads). I haven't finalized anything on it though, so I may be able to come up with something that allows you to add parts as well. I had originally planned on making the EXACT vessel (plus fuel) be put out immediately, but I might be able to force you into the SPH/VAB to make any changes and forbid editing afterward.
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.
Speaking of funds, with the next update there will be a radical change to how funds work (as a result of integration into the Scrapyard API/developing a common base with Kerbal 4X). You no longer will receive funds for recovering vessels but only pay once for a part. Once it's in the inventory you never have to pay for it again. You'll also be able to sell parts. Oh, this also includes Fuel and other resources. So basically we (SiriusSam and I) are rewriting how Stock does recovery.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)
-
If that would have happened, I had backup saves. Also, I could always just stick with Lite or start with full from scratch. It's not the end of the world if KSP crashes once.
Also, I did a bit of investigating on my own and matched up the radiators with their cousins from the lite version. That and one power reciever, and I was in the clear. A couple of ships have oversized receivers now, but I'll phase them out and replace them eventually. No explosions, no crashes, and KSP is happy as a clam.
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.
-
Everything will be fine, the project will continue. I will never forget about KSP, I am already planning a new mission (because the one to Kydros cannot be continued). I think the Verviedi's moon is a fine idea. I still don't know which one is better.
P.S. Do you have 64bit Windows installed? My small laptop, wich I used for all the missions you've seen is running on 64-bit one. The game is lagy and low-fps, but it runs. I've tryed to run a game on my decktop computer, it's much more powerful. But I didn't realise it runs 32-bit so KSP runs out of memory every time I try to load it. Any suggestions?
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?
-
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).
) 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.
)
[1.4] StageRecovery - Recover Funds+ from Dropped Stages - v1.8.0 (March 11, 2018)
in KSP1 Mod Releases
Posted
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.