HarvesteR
-
Posts
3,542 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by HarvesteR
-
-
1 minute ago, Streetwind said:
Wow, that's unexpected!
Are there any plans for future activities that you're willing to share, or do you just want to disappear out of the spotlight?
And at the risk of making this thread read like a broken record: Thank you for building this one-of-a-kind game.
There are certainly plans for the future, but it's far too early to talk about any of that.
Fear not though, there will be new tidings soon enough.
Cheers
-
2 minutes ago, Ultimate Steve said:
I believe this may be an appropriate place for this, the origin of KSP:
[snip]
Good luck for the future!
It sure has come a long way, hasn't it? Those character graphics have been much improved!
Cheers
-
Hi,
There’s no good way to ease into news like this, so here it is: I’m stepping down as Lead Developer of KSP.
For the last five and a half years, I put all my work, my thoughts and my time into KSP. I’ve watched it grow from this little unassuming idea for a 2D game in which you’d put together rocket parts to see how high you could get, into a complete spaceflight simulator, a space agency tycoon, a planetarium of truly astronomical scale, a home for little green men and their space program, a Kerbal space program.
KSP has become far more than the game I imagined half a decade ago. When we first set out to take on this project, I could not have expected anything even remotely close to what it ended up becoming. To say KSP surpassed my every expectation would be, at best, a colossal understatement.
There was a time, years ago, when any single design decision of mine had the power to drastically change the direction of the project. There was the danger that by even moving ahead on development of one area instead of another, the entire feel of the game, the intent it carried, could be morphed into something else. There was a fine line we needed to stay on, lest we let the project slip and become something other than what we intended. That is no longer the case, and that’s a very good thing. It means that conceptually, the game is complete.
This isn’t to say KSP’s development is complete, however. Far from it. Plans for KSP reach far into the future, and there are enough ideas to keep us all going for years. The console versions are coming up, there are new updates in development, the list goes on. For myself, however, I desperately need to have something new, to create more than one game in my life.
I need to make one thing perfectly clear: development on KSP will continue as always. No features, upgrades, bugfixes or anything of the sort are being discontinued because of my leaving.
This I say with absolute confidence, because I have complete trust in every member of the KSP team, and I know they are fully capable of handling anything that comes their way.
The KSP team deserves more praise than I can give them. This is a band of outstanding people, all brilliant and excellent at what they do, never tiring, never doing anything less than their best. I’m very proud of what we have accomplished together. It’s something I’ll carry with me for ever. I also know beyond any question that KSP would not have become what it is without every single one of them. I am forever grateful and in awe of all the work they put in.
And of course, I must give all my thanks to the founders at Squad, Ezequiel and Adrian, who took this wild leap of faith with me, putting their unconditional trust in me without ever requiring any failsafes or guarantees of success. We all know games are a notoriously risky proposition in the best of times, and they nonetheless extended their full support to me, at a time when none could tell what lay ahead.
Lastly, but most certainly not least, I have to thank every single one of you, the community, our players, kerbalnauts, space enthusiasts, reckless rocket engineers, our friends. All of you, who like us, believed in our weird little game and supported us throughout the years with your ever-inspired ideas, your unparalleled willingness to help, your relentless honesty and your unfailing loyalty. I cannot thank you enough for all of it, and I can only hope I am so lucky to see you again in whatever comes next.
This isn’t goodbye. It’s just farewell for now. In the meantime, however, I hope you all enjoy playing KSP as much as I enjoyed being part of its making.
Signing off,
Felipe Falanghe, aka HarvesteR
-
I did. I had to upgrade my rig to work properly on KSP, so I think that counts.
Went from a Core i7 920 to a Core i7 4790K, OC'ed to 4.6GHz (stock 4GHz). Also upgraded the mobo to an Asus Sabertooth. That is definitely a badS piece of hardware.
Compile times went from 1min+ to less than 30 seconds!
Cheers
-
13 minutes ago, Tipped said:
Where in here does it say why the wheels need their own logic to detect when they're landed? Shouldn't raycasting in the direction of gravity projected onto the perpendicular plane of a parts movement be enough to detect if a part is landed? Or is it just done differently for different parts for efficiency reasons?
Parts don't use raycasting to detect collisions. For normal colliders, collision events are sent up directly from the physics engine, and parts listen for those to manage their collision states.
Wheels, on the other hand, are a totally different thing. The wheel raycast is the main source of contact information, so it needs an entirely separate ground detection logic.
Mind though, that the ground detection logic I'm talking about is KSP's own logic, used to figure out vessel situations and so on. The wheels have their own internal 'grounded' flag used in the wheel simulation. The code I wrote here was essentially the 'bridge' between those two things.
Cheers
-
You can also rest assured knowing that every one of us has read your letter now, and I'm fairly sure I speak for everyone when I say it was truly moving. This goes well above and beyond what we set out to do when we first started this project, and I really can't express how it feels to know something we've done has had such an impact on others.
I'm very glad to hear KSP has had such a positive effect on you.
All the best, from the entire KSP team.
Cheers!
-
This leads to another interesting question, before DDS texture loading was implemented in stock, it spent ~30x as long laboriously converting the textures during load into DDS (DXT1/DXT5) for use, so is there a similarly functioning audio format which can be directly loaded (skipping the conversion step) like DDS now is on the graphics side?
Essentially can you pre-compute the audio loading so it can be dropped right in (i.e. what format does Unity hold the audio in internally)?
IIRC, audio assets are already loaded in parallel. I recently added (dev) controls here to bypass loading every type of asset, even parts, so audio assets can also be bypassed, mostly for the sake of completion. I don't think audio asset loading takes up a very significant chunk of time in any case.
Cheers
-
With the revamping of the map gui system, will we be getting improved useability? Like the ability to sticky the inclination nodes?
All map nodes can be made sticky now, we just have to decide which. Ascending/Descending nodes should definitely be stickiable.
Only on their overclocked 4ghz monster of a dev machine.4.0GHz is the stock clock on this CPU. I'm running it at 4.6GHz here
And like Kasper said, 12 seconds to load skipping every texture and audio asset. But still, I'm very pleased with the speeds I'm getting now. It's a quality-of-life thing if you consider our work hinges entirely on our workstation performance.
Cheers
-
Praying to the great Kraken that the infamous click-through bug gets fixed with this work.
I have to say I haven't encountered that one so far, but I can see how it would be very annoying indeed.
The new UI system is native to Unity, so problems like input passing through controls and hitting stuff behind them should be much improved indeed. I can't guarantee this will be an implicit fix, but I'll definitely be keeping an eye out for just that sort of stuff.
Cheers
-
I'm surprised, nobody guessed it right so far!
I'm not going to spoil it though, but I'll debunk a few assumptions:
* It's not something I've been working on in the backburner (I wish I had that kind of spare time).
* It really was implemented from scratch in the span of 2 days.
And a little hint: Try to imagine it's your first time playing. Everyone's ideas are way too advanced.
Have fun!
Cheers
-
Is this information available easily in-flight? I know you guys prefer to starve the player of information but obscuring useful, available information away from where it might be useful is ... cruel.
Just open the info panel for the vessel in map view. It's available just when it needs to be. When closing in on an intersect, the time for the closest passage is shown in the map view, the panel is also there, so you can pull it up and see how long the vessel is estimated to take to slow down to match orbits with the target. Then just point retro (to target) and burn.
Cheers
-
You turned my favorite fuel tank into xenon storage! Aww. I loved that little tank for satellites and tiny probe landers. Thank goodness I know how to reverse this travesty.
Looking at the ROUND8's stats, it was redundant with the Oscar-Tank, except in terms of design. We needed an inline Xenon tank much more than we needed another low-capacity LFO tank for probes.
You are, of course, free to mod it back to its original specs if you want to, or create another cfg to have both variants.
Cheers
-
toggle please.
Not just a toggle. There is a scaling tweak in the game settings screen. Set it to 0 for no wobble at all, or if you're brave (and very tolerant to motion sickness) set it to >1.
In any case, this isn't a gratuitous shaky-cam effect. The camera isn't going to be constantly wobbling about just for show. The movement is always based on something, like pulling Gs, or atmospheric flight at very high speeds.
Cheers
-
I'm not going to say I said this was possible a year ago...
It certainly was possible a year ago... I've been wanting to get this done since I first noticed the issue, which was sometime around version 0.17 or so...
However, between wanting to fix something and taking the time to do it lies the big hurdle, which until now, has always been insurmountably obstructed by the myriad other things that needed to get done.
I'm very glad to have gotten a chance to do this one at last!
Cheers
-
Think hard about this:
"Instead of arbitrarily deciding on a new tech tree layout, we’re going to do this in a more ‘scientific’ way. I’ve created a new version of the tech tree which features absolutely no dependencies between nodes. This means all notes are researchable from the start. Also, all nodes have the exact same cost. This tech tree will be included on the QA builds, and during testing, we will ask the testers to note down the order in which they went on unlocking the nodes. From that data, we should be able to run some statistical analysis to help us determine which parts are needed first, and how we should better organize the tech tree. This process can also be repeated multiple times, to refine the tech tree layout more and more. We hope that at the very least, this method will give us more accurate insights than just relying on anecdotal feedback."
because i dont think it will do what you expect.
If you are gaming the system, i would unlock the most useful things first, which means the least useful things last if ever, even though they argueably go on the tech tree first. For example, I'm going to unlock a science lab, and science modules near the begining, and go science my way to a complete tech tree. In reality, both the current order, and what I would do in your world, are both wrong from teh game perspective. It should go simple scientific instruments (thermometer, barometer) - more complicated instruments - simple experiments - complicated experiments - science labs.
Similarly, why would i ever unlock the stupid drone core, when I can unlock the good one with sas and node pointing and such? Why would i unlock the inefficient engines when I can go straight to the best ones?
Counter-suggestion - open a thread asking people for suggestions on what the tech tree should look like and why, and use those as inputs.
-Seyv
Yes, that would be the case if you were intent on gaming the system. However, we're not doing this in an open environment, but in the controlled group that is the QA team. We can instruct the testers to select nodes in a well-paced progression, selecting not the best and shiniest parts first, but what seems fit to be the next logical step.
With the assurance everyone is collecting their data with the intention of creating a logical, incremental progression, we should get some useful information. This can only happen with a very small, communicative test group, but we just happen to have such a group... (Who by the way, are outdoing themselves again this time around. Major props to them, they've done an immense amount of work these last few weeks!)
Cheers
-
So will a single fairing that's 10 "pieces" tall and 4 "pieces" around count as 40 parts, 4 parts, or 1 part?
There's only one part, which is the fairing as a whole. Fairing panels aren't independent parts, they're sub-objects of the fairing until you deploy them. A fairing that is 10 sections high and divided into 4 sides would have 40 panels, yes. How many objects this will produce on deployment depends on how they group together (that's next up on my to-do list actually).
As for how the broken-off bits behave after deployment, they are handled as solar panel pieces or engine fairings. They aren't fully persistent (which is good if you like your framerates to be a two-digit number). That doesn't mean they aren't solid objects, however. Point away from face.
Cheers
-
Could enterprising modders access the procedural mesh generation system to make... other things?
I see no reason why it shouldn't be possible. Just bear in mind the proc mesh code was written with fairings in mind, so it might not be ideally suited for unforeseen usages... But then again, making a system that is ideally suited for unforeseen uses would render those uses foreseen, or require time travel. (Do let me know if you have a working implementation of the latter).
As for the fairings, sounds good. Reading between the lines it seems like the user experience will be simple, but there's a lot of under-the-hood power for modders to provide more complicated fairings with.Indeed, the usability is something we want to keep as simple as possible, but the proc mesh system is made to work as independently of the module workflow as possible.. And vice-versa as well. There should be (hopefully) minimal coupling between the two systems. The functional bit (the actual enclosing of the volume) is handled by yet another system, so coupling should also be minimal for the functionality of these procedural parts and their procedural-ness.
Excited about fairings! Will we be able to do interstages with the new procedural fairings? Or will I have to keep doing this with wings?Interstage fairings are something we've discussed here to quite an extent. The current system doesn't support them completely at the moment, but it doesn't preclude them either. They're just not accounted for yet, and we're probably going to have to do some playtesting to figure out how (and if) the fairings would work in between two chunks of spacecraft. We might be able to adapt the current module to do both, or we might require a separate module to handle those cases. The short answer is, we're not quite there yet.
Cheers
-
I think it's important to make it clear that Unity 5 is very unlikely to be the magical silver bullet people are making it out to be.
When we moved from unity 3 to 4, we had to deal with a LOT (and I do mean a LOT) of upgrade-related bugs which we didn't expect. Furthermore, the earlier versions of Unity 4 had quite a few bugs of their own which we had to work around (or hang tight) until fixes came along.
My point is, moving to Unity 5 is very unlikely to be a straightforward transition, and by no means I expect KSP to be stable or even playable (let alone improved) after simply upgrading the project over. I would be very happy to be wrong in that one, I must add, but historically, every time we upgraded to a new major version of unity, we came across new issues we had to contend with, so please don't get overexcited about Unity 5 just yet.
This late in a project, most games tend to freeze engine versions when they find something stable that fits their needs. Regression issues is in fact the main reason why Unity stuck with PhysX 2.8 until now. If breaking mods and saves is an issue for us, imagine their case, where instead of mods and saves, they risk breaking hundreds of commercial projects. We have it easy by comparison really...
Anyhow, we don't plan to freeze engines, but I just wanted to clarify that moving to Unity 5 may not be as simple and so immediately beneficial as it may seem. At the very least, we don't plan to upgrade until A: The 1.0 release is out, and B: Until U5 is out of beta and confirmed stable.
Cheers
-
I had that thought as well. However, I thought the choice of words: "I also revised the fuel flow logic for air-breathing engines" and "turbine engines now drain resources evenly from all tanks in a stage" was significant. It implies that the choice of engine determines the fuel flow, rather than fuel flow being determined by the resource. As such, 'turbine engines' could draw evenly from LF or LFO tanks.
Or I might be over-analysing...
That's actually quite right. The engine modules are now able to override the default flow logic as defined by the resource with their own, so even though turbines use the same module as SRBs and Liquid Engines, they set up their own flow logic for LiquidFuel, so that in their case, the lookup method used is the STAGE_PRIORITY method.
For other modules/propellant configs which don't define a particular method, the resource default is used.
As for the necessity that prompted this change, other than the improvement in long-term stability as tanks drain out, this is very much essential to support wet wings and drop tanks. Using the default stack-based flow logic means tanks in child parts (as wings tend to be) will be unaccessible unless a fuel line links them to some spot in the drainage route of the engines. Quite a chore for something that would be expected to just work.
And yes, closing off tanks does still work as always. If you don't want a tank being used, you can close the valves and it'll be left unused.
Cheers
-
The scaled-space version of a planet (aka, the far-away version of it) is always rendered. In fact, the atmosphere is only present in scaled space, so even at the surface, the scaled-space version is active. Being just a static mesh, it's got minimal overhead to it.
The noticeable increase in performance is indeed very likely the PQS (Procedural Quadtree Sphere) surface being turned off after completely fading out of view. The crossfading is quite necessary for the transition to not look terrible, but once fully faded out, the terrain turns itself off and stops updating. This definitely would help increase performance quite a bit, especially if you're already running on the low end of framerate, so good tip there. If you plan to build big, build it at a high(er) orbit.
Cheers
-
I voted 'Dinosaurs', because I have no idea what that's supposed to mean.
Anyhow, this will soon no longer be an issue. With the offset and rotate gizmos added, plus the longstanding issues with parts that don't attach properly becuase they are just-oh-so-slightly in contact with others, part clipping grew into such a bother that I decided to simply remove it by default. All attachments, as long as you are attaching a part to another part of the ship, are valid. If the ship explodes into a million when you detach, that's a design fault on your end.
Mind though, that allowing attachments isn't the same as enabling the debug cheat. The cheat also allows you to place multiple parts on the same attach nodes. This is still not allowed because it actually adds a good risk of running into big bugs later.
But really, with the new gizmos and construction modes coming, having the game deny a part from being placed just because it's clipping into another was being too much of a restriction to design. What with costs, size, part count and mass limits to deal with, there are quite enough limitations already to contend with.
Cheers
-
Question regarding upgradeable facilities: Is there a "Stage 0" of upgrades where there are no buildings and just an empty field?
There used to be a level '0' for the Spaceplane hangar, but it was one of the ones we removed during the big overhaul from a few weeks ago. We removed it because it was too restrictive on players' freedom to choose a progression path.
Having an empty field to start with is still an interesting idea, but I think it would require all facilities to start out that way to be a fair mechanic, and that much we don't have time to do.
Keep in mind that the upgradeable facilities are still just making their first appearance. Just because this is the last gameplay system before Beta, it doesn't mean it has to be more complete than other systems were when they were first added. Beta is exactly the time when adding more content to existing systems will be our main goal (I personally can't wait).
Cheers
-
I don't think so.
I used aeronavigational charts a lot, and never saw "height" for any sort of altitude. It's always altitude ASL (above sea level) and altitue AGL (above ground level), the latter shown in parethesis (or vice-versa if I'm confused, but the distinction is like this).
Height ALWAYS applies to obstacles height, and always shown unambigously, either ASL or AGL in parens.
Ground always has elevation to it.
That's how terms are used.
(I think it should be the same in Portuguese, no? altura vs altutude)
Yes, what I meant was, I assume height to mean the distance from the base (ground) to the topmost point of whatever you are measuring, as opposed to altitude which (unless specified otherwise) is the distance of this topmost point to sea level.
It is ambiguous when the tail height of an aircraft must be factored in with another height, like flight height though, but more importantly, when the yaw axis of the craft doesn't point 'up', as is the case of a rocket at the pad.. hence my search for a better term.
In any case, the point is now moot. The craft size uses AABBs (axis-aligned bounding boxes) so the Y axis is always going to be 'height' in this context. Be it tail height sitting at the runway, or stack height at the launch pad. The Z axis I renamed to Length, so that's that I guess.
Thanks for the help everyone!
Cheers
-
I'm using tail height here ('T-Hgt' actually) for the time being, for want of a better term, and to fit in the UI space available for it...
I'm surprised that there is no actual term for it though, 'height' I always assume to mean flight height above ground (as opposed to altitude), so calling the tail height of an aircraft 'height' as well is oddly ambiguous for a field so particularly specific as aeronautical engineering.
Oh well. I suppose 'height' at SPH or X-section at the VAB will do then.
Cheers
My farewell to Kerbal Space Program
in KSP1 The Daily Kerbal
Posted
It's much too early to talk about what's coming next, but rest assured there is something coming. You'll hear of it in time.
As for the team, I'm leaving on the best of terms with everyone. I'm going to keep in touch with all of them.
Cheers