HarvesteR
-
Posts
3,542 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by HarvesteR
-
-
How old are those monitors?! Haha, they just look like something from 2007.
In all seriousness, I love HarvesteR and that rig is way better let's say different than my cozy rig. Sweet setup and I'm jealous!
Heh, they actually are from 2007. They're the oldest things in the setup at the moment. The TH2Go was the only way to have triple contiguous displays back then, Surround and Eyefinity weren't a thing yet. I still like the TH2Go better than a GPU-based setup, because it means the GPU is freely replaceable, and there's no need to fuss about with drivers... As far as the GPU knows, there is only one triple-wide display hooked into the primary output port.
What really bugs me is the TrackIR. It bugs me because the man obviously must know how great headtracking is for any kind of flying game; how superior it is to looking around with the mouse. So why doesn't TrackIR work with KSP?I know, and I would very much like to add TIR support here too, but there's always something of higher priority that needs to get done first. We'll get there eventually...
Cheers
-
From the tracking station, Backspace will focus you back to Kerbin also, as that's the camera 'home' target in that scene (as opposed to the active ship while in flight)
Cheers
-
This is something we can't really take full credit for. The Unity 4.3 update was a MASSIVE performance boost for us as well, not just in builds, the editor itself is running significantly faster also.
So let me add my own thanks to the Unity team, for a crackin' update! Hats off to you sirs!
On our end, the one thing I think helps improve performance is the new part joints, and even the new parts, not necessarily because they are more optimized themselves, but because with much less need to spam hundreds of struts, and heavier parts that can do the job of several smaller ones, your ships are more "optimized" as well, at a design level.
Anyhow, I'm very glad to hear everyone is enjoying a nice performance boost. Most times these things tend to affect only a subset of cases, but on this update, everyone seems to be reporting nicely improved performance, so very happy to see that!
Cheers
-
That should do it! Thanks for posting that.
We've got a hotfix patch on the way already, shouldn't be much longer now.
Cheers
-
I have tested multiple grapples against the vessel, or even to a single object. They should work, just as docking nodes do. If they come in contact with a part that is on the same vessel, they create a joint in a way similar to struts, they link the objects physically, without modifying the already existing hierarchy.
As for grabbing the ground, that is the one thing the grabbers can't grab. It would require a completely different set of states and rules for that to happen... One thing at a time.
Cheers
-
The didn't speak through a PR guy before, (No offense Rowdowser, you do your job fine.) they were even more transparent. What ever happened to dev blogs? I kind of wish the devs went back to being a part of the community instead of being all hush-hush for no reason.
Those took on average half a day to write, revise and grab screenshots for... so even though we'd love to do those, there simply aren't that many hours in the day. The weekly devblog works nicely for us because it lets us each just write a few lines in a couple of minutes, then Rowsdower takes care of putting it all together in a nicely formatted post.
Cheers
-
I think that they're adding a few "required" things from .24 for the NASA update
Ah yes, we forgot to mention that. The support features that we announced as part of 0.24 are now going to be in the ARM patch, so everything needed to properly play the asteroid mission and all the related usability improvements are all going to be contained in the ARM patch itself.
Cheers
-
found a new test bed celestial body
Harvester is giving a lecture at unite 2013.
Its called mun 2.... probably the base of minmus.
That was, in fact, just a second celestial body I added to the test scene I used to test out the patched conics. That was well after Minmus had been added, IIRC.
That screenshot comes from a totally separate project however. KSP is much too big and takes a good deal of time to compile and load, so when we're writing big features, we usually do it in a separate, cleaner environment first, then move all the new stuff in once it's ready to integrate. Think of it as taking a part off your car's engine to work on it on the bench, instead of having to do the same work lying under a greasy underside.
Cheers
-
I hope the later will work unless the last few times.
And a request does the devnote tuesday entirely replace the devblogs??? There weren't any for some time now.
Not entirely, but think of it like this: If two of us (myself included) were so busy yesterday we couldn't take five minutes to write down a few lines about our week, having the opportunity to take about an hour or so to do a complete write-up of something has become a very rare thing these days.
That said, I am going to do my devblog still, stay tuned.
Cheers
-
The key thing you have to do to nail a landing with zero lateral movement is this: Chase the Retrograde Marker.
As you begin your powered descent, you'll notice that by thrusting laterally to the surface (initially pointing retrograde but not changing attitude), your retrograde marker on the navball will start to go up into the blue half. This happens because as you lose lateral speed, your vertical speed component will become ever more dominant.
It's tempting at this point to just flip perfectly vertical and try to hover into a landing, but the easiest way to make sure you're thrusting towards the direction that will most definitely slow you to a stop, is to always chase the retrograde marker.
Now, keep in mind the speed reading on your navball can read relative to the surface (which takes into account the rotation of the planet), or relative to orbit (which doesn't). For the Mun, which only has about 9m/s surface speed at the equator, this may not seem important, but those 9m/s when touching down can very much tip you over, if not even smear you across a patch of surface.
So, make sure your navball is reading 'surface' as you're about to touch down. This usually happens automatically, but you may inadvertently click the speed reading sometimes and disable the auto mode switch, which is why you have to keep an eye for that sort of thing. The speed reading also affects the velocity markers, so this is very important for final touchdown, otherwise you won't be slowing to a complete stop as you near the surface.
With all that in mind, you have everything you need at your disposal to pull off perfect landings. Keep SAS on to make your life easier (mind the batteries if you don't have solar panels though, or engines large enough to have alternators), and chase that retrograde marker until it is dead center on the navball's zenith point (straight up).
TL;DR:
Keeping it short though, as long as you're in surface speed mode and always decelerating while pointing towards your retrograde vector, you're bound to pull off a dead-stop landing.
Hope this helps
Cheers
-
What is the exact requirement for receiving the 'recovery of a vessel that ...'? As in, what part of a vessel that visited a given location needs to return to kerbin?
That would be any part which is considered by itself a control source. Or more technically speaking, any part that contains a ModuleTripLogger component attached (by default those are added at load time to all parts for which isControlSource = true, but if you add it through the cfg the loader won't remove it).
The Trip Log is built off the recovered vessel by compiling together the output of all ModuleTripLoggers on its parts. Then the trip log is read though to find the most impressive (highest subject value) place that vessel has been to, and that then is used to calculate the science value for recovering a vessel.
So in a nutshell, you should almost always be able to get recovery science for a ship you bring back, since it's generally fair to assume that if you were indeed able to pilot a ship back home, that ship had to have some part that could provide input to it.
It has a reasonable analogue too, because you can imagine that finding a piece of debris that landed back on Kerbin wouldn't tell you much about where it came from. We assume probe cores and command pods have some form of flight recorder device that actually stores where they've been, so the recovery team at Kerbin can tell where it came from. And in practice, that really is the case, since ModuleTripLogger is for all intents and purposes, a flight recorder.
Cheers
-
These test results are consistent with the PhysX documentation tips about joint stability. The problem with wonky joints comes from a single source. The rigidbody solver has issues converging (finding a stable solution within the allowed iteration steps) when you have very high mass objects constraining low mass objects. On the test here, this was happening with the base of the test craft, which was constrained between the ground and an ever increasing load from the top of the craft.
Try this for confirmation. Have the base object of the rocket be heavier, say, a large tank. Then stack the same test rig on top, and check the stability of the system in the same way. My prediction is that it will either take a lot more mass to make it start to wobble, or that the wobble will be happening between other joints.
Lastly, there is another situation which we can already say will be wholly cured with the new joints system. When you have long objects linked together, like a long truss or tank, up until now, that meant attached objects would end up creating a long joint between their attach point and the long object's center of mass. That means you'd see on many occasions, objects dancing around on top of each other. With the new joints system, we have solved that. Now the attachment points are linked node-to-node, or in case of surface attachments, node-to-wherever-the-node-is-relative-to-the-surface... That means the joint itself is kept as short as possible, so that 'dancing wobble' effect is gone now.
There are a few cases still where we see flexing in the current state of the new system, some of those are intended, because we do want attachments that look flimsy to behave flimsy. We're still working to ensure those are the only cases where attachments are allowed to bend, but in any case, from what we can test here, there's already been a very noticeable improvement over the old system.
Cheers
-
The estimated burn time does factor in the changing TWR, as it gets calculated based on the vessel's current acceleration (and expecting full throttle).
What it doesn't do is antecipate how much that burn time is going to change as your TWR increases, so while it may start out saying 20 seconds for a burn, if you were to time the burn with a chronometer you'd notice the estimated seconds go by slightly faster than real-time, since it's recalculating as the craft mass decreases and your acceleration increases.
It does work out to zero burn time at zero dV remaining though, which is the essential bit.
Doing a single braking burn to stop at a very precise spot is a VERY tricky stunt to pull off though, hence the name of the maneuver. In fact, it's probably a good thing if you're coming up short... the alternative would be far less desirable.
You can try not burning at 100% though, maybe leave it at 90-ish to compensate, and you'll end up closer to the ground.
Do keep in mind you're essentially playing a game of chicken with the ground, and the ground doesn't care nearly as much about losing.
Cheers
-
The original idea (and implementation) was indeed that the Kerbals would use the monoprop from the pods to fuel themselves.
During experimental testing however, we noticed everyone was getting frustrated with it because those tanks, being just normal mono containers, would get drained out using RCS, and when it was time to EVA there would be no more fuel left for them. It didn't work as well in practice as it did in theory, and without a total rewrite of the RCS flow logic, which we just didn't have the time for, we had to think of something else.
In the end, this feature was causing more aggravation than enjoyment.
There were other issues as well, for instance, the mono on EVA suits had to be 'hacked' to zero density, otherwise the added weight would make Kerbals unable to walk properly (just those 5 units of mono was several times heavier than they are themselves). The EVA propellant resource can have its own defined properties, so it works without having to resort to hacky fixes.
The switch to EVA prop solved all those issues without having to do a full reversal back to the old system. Now they have all the advantages of having a proper resource-based pack propellant, without the problems that arose from that fuel being the same as the one used for RCS.
I decided to leave the RCS containers on the pods however, because that did prove very useful for minimal craft designs, as you noticed as well.
Cheers
-
All Kerbals enjoy feeling weightless. That wait for the circ burn is all zero-g, so he was probably stoked about that.
Usually other factors like velocity and spin contribute to terrify that grin off their faces, but Bob is slower to catch on than the others, so conditions were probably just right to put a smile on his face, for a while.
Cheers
-
I changed the default max delta-time per frame to 0.04, as you all noticed. It was already possible to tweak manually, of course, but the reason I changed it was because I noticed most players didn't know this tweak existed, and at it's old default of 0.1, you needed to be lagging pretty horribly already (10 fps is nigh on unplayable) before the game would start to slow down. That made the whole feature a lot less useful than it had the potential to be.
Setting the new default at 0.04 means it'll start to kick in at around 25 fps, which means it'll always try to keep performance to a reasonable level. But more importantly, this will now happen to everyone regardless of whether they know of the setting's existence.
Oh, and thank you for the thank you thread! It's always great to see that people appreciate the work we do.
Cheers
-
That was an idea I had considered at first, but it would circle back to a grind, where you run an experiment, then EVA out to reset it, then go back in to re-do it, and repeat over and over for infinite re-uses. In the end it just becomes a chore that you have to do.
Having the labs be able to reset experiments worked out better, because the labs themselves are large and have high resource and crew requirements, so that tends to balance out better, and it's possible to do it internally, which makes it more convenient too.
Cheers
-
My only concern is if there is a limit to how many experiments a lander can store. The most I've had is 8 at once, so I'm not sure if there is any limit. If not then this should work great and is a perfect use for the lab module, otherwise I'd have to carry one Material Bay and Goo for every biome.
There's no limit to how many samples you can store, as long as they're not repeats of an already stored subject.
And yes, that's one of the best ways to use the Labs, as a science 'base' to return to after sending out expeditions.
Cheers
-
I don't know if it's possible, but has anyone tried using the science bay for storing experiments? For instance, take a sciece lab, a scientific lander and a ton of fuel to the moon and then use the lander to ferry the science from the moon to the lab and then afterwards return the entire lab home and deorbit it carrying all the science for all the biomes you've visited.
Can you do that? I think that'd be a fair use for a lab.
Yeah, that's totally possible. You can store experiments in a lab just as you can on other pods and cabins.
And yes, the best way to use the labs is to have them as part of a base or station. Carrying them around with you wherever you go isn't very practical.
Their best uses come from being able to send out expeditions from them into other areas, to find new biomes and new ways to do science, then return with the new data to have it processed before transmission, and have one-shot experiments cleaned out to work again.
Cheers
-
I like how they fixed things, but you can reset the experiment as many times as you want if you dont transmit, that to me seems odd. Personally I would like the notice to show the science info but say "Run Experiment" instead of "Keep Data" and make it impossible to reset. That way we can still check to see if its worth it, but only able to run it once for the reasons already stated in this thread. Because right now, its the act of transmitting not running the experiment that makes it non-operable. That just seems odd.
My initial idea was in fact to have the experiments become inoperable immediately after use. I set it up that way, tried it for 15 minutes, and absolutely hated it.
What happened there is that if the experiments went inop after any use, they would become spent before you even got to see if there was any good science to be done at that spot. It felt very frustrating to have to 'guess' at a good spot to deploy, and risk losing a good experiment if you missed.
I realized then that it was because the game wasn't giving me a choice. When you run an experiment now, it will only become inoperable once the data is 'consumed' for transmission. So it's not so much like litmus paper anymore, but it still makes sense if you consider that the sample 'tray' or whatever the data gathering apparatus inside the module is will get destroyed in the process of being converted into something that can be transmitted.
This then became a good way to separate the 'physical' experiments from the more 'digital' ones. The goo container and materials bay do have physical samples inside, so those have to be destroyed to be processed into transmittable data. The other experiments are either abstract, like reports, or are somewhat 'digital' in nature, like a temperature or gravity scan, so those can be freely reused since their data is already transmittable.
From a gameplay standpoint, I like how this means you now have to manage your science 'cargo'. If you're doing a mission across several new subject types, you now have the choice to dump a less valuable experiment for a possibly more valuable one, and making informed choices is a key element of fun gameplay. This is why the initial idea also didn't work. You had to make a choice, but you didn't have any information to let you weigh the options, so that became frustrating. Being able to see what you got, how much it's worth, and weigh that against your limited uses of the experiment and the promise of more valuable data ahead, that makes it very interesting.
Cheers
-
I've thought about this feature too. It sounds like it would be a lot of fun to code, basically taking the g-force vector from vessels and transforming it into IVA coordinate space to be applied onto loose objects floating around.
The main issue though, is that there are many many other features that out-prioritize a purely for-kicks one like this that need to get added first. Not to mention that such a purely aesthetical feature needs to be disableable through settings to not eat up CPU time for low-spec computers.
Would be fun though, can't disagree there.
Cheers
-
As the original resources chart showed us, there were many single-purpose modules for the different of materials that would have needed to be deployed, then refineries, and all that just basically boiled down to making fuel.
After all that it would almost be easier to just launch a giant fuel tank. Single purpose science experiments at least get to be used in multiple places and gain you science, the mining modules were for specific resources only.
Don't forget the contract system along with science, both of which will allow you to earn reputation; both could be expanded to include nearly anything that resource mining might have done but not as bloated.
I'm sure another solution along those lines will come up after we see how the rest of career mode works, it just needs to find a spot to fit in.
Brainstorming ideas for it is about the best thing we can do.
I think you've explained it better than I did.
Cheers
-
I think there is a large amount of inaccurate overlap here between what the top-end of KSP gameplay needs and what the old resources system was supposed to add.
I agree that once you master the challenge of spaceflight and are able to get anywhere and pretty much do anything, you start to feel there isn't much left to do. This is true of any game. However, most games at that point just end and you get to watch the credits roll by. With KSP, you are free to continue playing until you've exhausted all possibilities, and beyond. This "end-game lull" is a frequent issue with sandbox games.
However, I disagree that resource mining-- especially the idea for resource mining that we proposed last year-- is the best solution to improve end-game activities. There are a lot of other cool things that we could add there, that would be a lot more interesting and fun, and that wouldn't require an overly complicated and honestly, very tedious system to give you new cool things to do.
What those things are aren't something we want to discuss yet. For all we know at this point, whatever new idea we disclose now might end up turning into a new 'resources', that later needs to get scrapped, so let's not get into that discussion now.
One thing that needs to be made clear though, is that a game in Early Access, while it shares a lot in common with the usual MMO-style development process (without any regard to payment model either, that's an entirely separate and off topic thing here), it is different in that while the MMO is essentially complete from the start, and receives new updates to extend the content for players who have done everything, the Early Access game is still incomplete, and must devote its development time to adding features that maybe might not seem important to experienced players, but that make it easier to be picked up by new players, or that make the overall game experience more complete even if that doesn't make it more lengthy.
That's not saying we won't ever add more things to do on the end-game level... However, you may notice it's even been mentioned several times here that the key thing is that people feel that once you land on another planet, there isn't much else to do. That does not imply the solution to that is to get out the shovels and start mining. Especially if you were supposed to remember to pack the shovels in the first place and didn't realize it until after touchdown.
My point is, that old plan we had for resources is most certainly not the right solution. It doesn't fit organically with the rest of the game, it requires you to remember to attach a bunch of single-purpose parts to a vessel (forgetting any of which would render a mission a complete failure), and really, that's just not how we want the game to play out.
I think this is the crux of the issue then. The resources plan being shelved is, by all means, a good thing. It wasn't any fun once we got down to it, so we're not losing anything that was worth keeping here. However, that does not mean there isn't a need (and budding plans) for more end-game activities. I'm just saying that old plan for resource mining wasn't it.
Cheers
-
Wow, there are some seriously insightful posts on this thread.. I wholeheartedly agree on the notion that a game is something you should be enjoying as you play, not suffering through for the promise of some indeterminate reward further ahead.
That said, there seems to be a balance to strike here (as with all things), because following this argument to its logical conclusion would lead to the idea that games should not be persistent at all, and we're back to how coin-operated arcade gaming worked.
There is merit in working towards a higher goal in a near future, most definitely. But games, like many other things, are about the journey, not the destination. With KSP, that's actually quite literal an analogy.
Musings aside though, there's nothing in 0.23 that has caused compatibility issues with previous saves. My test saves here are all from 0.22 or even earlier, and they are all working normally. A key thing to understand about compatibility in KSP is that when something makes a save incompatible, that doesn't mean the game will outright treat old files as unloadable. To make that happen, we here have to manually set a new "last-compatible" version number for the file formats that broke, so the game throws error messages and disables the incompatible ones. Unless we do that, the game will allow you to load the save and treat it as a fully compatible file.
Note though, I can't say the same for modded installs. If a plugin breaks because of changes to the game code, then there's no telling what it could do... In that case, you'll have to wait until the plugin is updated to work on 0.23, but unless your game was corrupted as a result of the plugin failure, once the mod is updated you should be good to go again.
Long story short, we haven't had to up the last-compatible version on any of the file formats here so far, so compatibility is preserved as far as we can tell.
Cheers
HarvesteR Shows Off His Rig On PC Gamer
in KSP1 The Daily Kerbal
Posted
Actually, a lot less than I would like to... Lately, it's been more like if I want to put in gaming hours, I have to also sleep less.
Cheers