HarvesteR
-
Posts
3,542 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by HarvesteR
-
-
Yay, another devotes! A small suggestion, it seems like it'll be easier to load interior SPH/VAB scenes, so would it be possible to reflect the time of day outside the KSC within those buildings? It's always irked me that it could be the dead of night but as soon as I enter either building, it's glorious sunshine. Otherwise, things look like there're shaping up really nicely! Thanks for the tons of work you guys are putting in.
Possible, yes. Feasible in the time available, much less so. The interior scenes are one of the few (and very few indeed) places where we use static lightmapping to light up the scene. The outside light plays a large part in this, so creating a dynamic time-of-day effect in the editors would require us to either drop lightmapping altogether, something I really wouldn't like to do, or set up many variations for the scene lighting and switch between those too.
That would be another ton on top of the tons of work we're already doing. Not saying it couldn't look cool, but there are probably more interesting features to add given a finite amount of time and manpower.
Cheers
-
I sure don't miss it either. The new struts are much more reliable, not just in physics stability, also in much less arcane and obscure configuration. We can easily tune them now, to get more or less stiffness as needed, and to do much more advanced things also (like the claw's pivoting joint).
The amount of wobble still present we left in deliberately. We didn't want to make ships so stable there would be no cause for concern over their structural 'sanity'. Now, struts are needed mostly only to beef up places where you really need extra stability, and usually a couple of struts are quite enough to take care of the problem, as opposed to the dozens required before.
So yeah, I'm definitely on the not-missing-the-wobble side too.
Cheers
-
Eu ja vi isso acontecer! Alguém conseguiu pegar o momento em video, isso faz um bom tempo... na época da versão 0.14 mais ou menos...
A chance é impossivelmente pequena, mas pode acontecer, e é totalmente destrutivo quando acontece.
Cheers!
-
If such a thing exists in the API it's not documented.
Part.GetConnectedResources() should be the method you need. It also walks the hierarchy internally, but it's 'canon'
Cheers
-
What is git? or is that just a typo?
Git is a particularly awesome Version Control system. It lets us all work at the same time over the project without stepping on each other's toes all the time.
What Marco called Git QA here is the first stage of QA testing all features go through. This is something we do for every new feature, to make sure nothing we add is going to break the game for everyone else. (if you think a broken game is tough to play, try developing over broken software.
) Once the most serious issues are worked out, the feature branch is deemed worthy to be integrated into the main development branch (aptly named 'develop'). Once all our planned features make their way into develop, we start experimental testing on a branch that eventually becomes the new public release version.
Cheers
-
I think the basic criteria for being officially in an orbital trajectory is that your spacecraft should be able to simply 'coast' its way entirely around the planet. No thrust applied by the spacecraft. Decay from external perturbations wouldn't void this criteria unless the forces are strong enough to cause a free-falling body to decelerate quickly enough that it doesn't manage to complete a single revolution, something very much like what being inside the atmosphere would do to you.
If you can manage to establish an orbit just inside the very edge of the cut-off point to Kerbin's atmosphere (around 69,750m altitude), you might be able to complete a full revolution before that tiny amount of atmosphere slows you down into a sub-orbital state again. That would be quite tricky, as even the lowest edge of the atmosphere still exerts some drag... Not sure if enough to decelerate you down into the no-return altitudes over the 30 minutes or so it takes to go around Kerbin, but as you lose altitude (and you will), the drag also increases, which lowers your periapsis yet more...
Actually, I'd love to see someone try... Now I'm intrigued.
Cheers
-
So, no actual mesh mirroring, just part rotation? You're making spaceplane panda sad.
Not sure what you mean. Mesh mirroring does in fact happen when using mirror symmetry. This mirroring is along the X axis though, so it's possible some parts are aligned in such a way that you wouldn't see it. This was the case with some spaceplane parts when we integrated the SP+ pack, but we fixed those so they would be flipped along the Vector3.right axis.
Cheers
-
:Envious: Is it a 3DConnexion one? I've been seriously considering one of these when I build a new computer but there doesn't seem to be a compatibility list of what works and what doesn't.
Yep. I've got a SpaceNavigator and a SpaceMouse here, both work very well using the beta drivers (which support more than one device at a time). I can't say I've tested other devices (not having other devices presents quite a challenge on that front), but even if your device isn't supported, you could be able to emulate recognizable 6DOF input using GlovePIE to translate the input from your device into 3D mouse input (I think, haven't tested, but similar kludges have worked for me in the past on other games).
I definitely recommend getting one, and not just for KSP. If you do any sort of 3D work at all (even Google Earth in fact), a 3D mouse is a very good tool to have. Having broken the wheel off a mouse once midway through a grueling overnight 3Ds Max animation project, I can give you a first-hand account of just how much better it is to be able to navigate a 3D scene using a proper 3D device.
Cheers
-
Mostly mouse and keyboard here too, in fact. Although I also use the 3D mouse a lot (especially suitable for EVA and docking).
I'm aware that joystick mapping is problematic atm, so that makes using joysticks less practical than would be desired. Hopefully during Beta we'll get a chance to improve input mapping and the input layout in general. (emphasis on 'hopefully')
But when I do, I set up my trusty X52 Pro and Pro Flight Rudder Pedals. They're showing signs of age these days, but still up to the job.
Can't say I've ever tried using a steering wheel though. I have a Driving Force GT here, but I get the feeling it would fall short in the amount of axes available.
As for control panels... man, I dream of the day I'll have the amounts of free time building one of those requires.
Cheers
-
I will just say carreer is sandbox with funds. Squad should focus first on sandbox (planets, making biomes different, clouds, aerodynamics etc.) and then they should make that carrer.
Just a quick reminder here, that the state of Career Mode by the time we enter Beta will be roughly the same, in terms of completion, than the current state of Sandbox. Sandbox just happened to reach that state first, but both are going to be equally incomplete.
Scope Complete != Feature Complete.
Also, see here for my opinion on threads like these.
Cheers
-
One thing I find strange from threads like these (or the other one, whichever way), is that it seems very obvious to me that the consensus should be that it's all good, because all game modes are still available.
If we had removed sandbox and imposed Career mode, sure, I'd be peeved if I were in team sandbox too, and understandably so. Same if I were on the Career team. In fact, so loath were we to replace a game mode with the addition of new features, we created Science mode to preserve the pre-0.24 style of career gameplay. The idea here is to cater to all sides.
Personally though, I'm on neither side. I play all modes more or less evenly. Sandbox is nice when you get that urge to build something ludicrous and see where you can go with it (also very useful for dev testing), and Career provides the much needed structure a game needs so it can be called a game.
Sure, Sandbox reached a state of completion first, so we now have devoted a lot of dev time into Career. Does that mean we consider Career as a superior game mode? Of course not! It's merely a matter of timing, and that Career depends on an existing sandbox to work (going the other way around would have been quite awkward, to say the least).
I get the feeling this is something like the discussion among rollercoaster enthusiasts about wooden vs steel coasters... It's kind of pointless, since there is quite enough room for both.
But before I go here, consider this: About a year ago, if you went out on the internets to gauge opinions of non-players (those can't be found in the forums), as to why they didn't want to get into KSP, the main arguments were that it was either too hard to get into (too high an entry barrier), or that they didn't care for a game without goals to pursue (lack of structure). However, if you go out today to gauge those same opinions, you'll find that those arguments are very largely gone. I'd say as far as the primary purpose of Career Mode goes, in a single-purchase standalone game that is still under development, it seems to be doing its job very well.
Cheers
-
Samssonart's note broke my brain though. The vectors are different on the IVA navball somehow?
Yep. Internal Space is a separate coordinate system, where the vessel is static both in translation and rotation. That means for anything inside IVA space, the coordinates of things from the outside world have to be converted to the IVA coordinate frame. The navball and its vectors are by far the most complicated objects in there, as you can imagine.
Vector math is fun, but it can be a major headache sometimes.
Cheers
-
'Kerbal-miles', wow.
That's just a coincidence, admittedly a very surprising one indeed, but the name 'Kerbal' was invented as a random cobbling together of syllables, as far as I remember.
It actually used to be spelled 'Kerbo' back in the day, but over the years it evolved into 'Kerbal' as we know it.
There isn't much else to the origin of the name I'm afraid.... That was quite a find though!
Cheers
-
I wouldn't go as far as calling this a bug, although it is a pretty impossible proposition. This is why we also have a 'decline' button...
Actually, the impossibleness of the proposal is by no means unrealistic... if you ever worked in software development, you'll know that sort of request is actually pretty mild, considering...
Cheers
-
I'm not entirely sure what this thread is about, or even what the OP is about either... For one, 'The Kraken' is really not descriptive of any bug we know of at the moment.
Also, bugs aren't a thing you can just pick up and remove, or even see clearly for that matter. Most often, bugs are caused by things which aren't happening when they should have, instead of things which do happen when they shouldn't. Even the examples given here are greatly oversimplified compared to the average bugs we get.
I think there is nothing left to say on this. I'm closing this thread before it devolves into something worse.
For future reference though, here's a good rule of thumb for any questions related to software development: If your question contains the words 'can't you just', the answer is automatically 'no'.
(if we could just, we would have done it long ago wouldn't we?)
Cheers
-
It's a good thing if the contracts system is over-rewarding you slightly at the moment. This is what we were aiming for during balance testing actually.
That may sound weird at first, but remember there are other things that will require funds, which are still not being accounted for. Hiring/assigning crews, R&D tech purchasing, and some other stuff that I'll talk about later.... Those things will all require funds in the near future, so if you've got a surplus now, that's a good thing in the long run.
And in any case, even without these upcoming cash drains, this is the first iteration of budgets in the game, and we much preferred to err on the side of caution here and over-reward a bit, than leave you stranded without means of continuing as a consequence of under-rewarding contracts.
We did, IIRC, 5 or more passes over the contract outputs during experimental testing. First to achieve consistency (the earlier versions had some contracts rewarding orders of magnitude higher or lower than the average), and after consistency was reached, we carefully tuned the costs of parts (probably still missed a few, but we did go over hundreds of them), and made sure that if you played it right, cash wouldn't be a restrictive factor.
Game balance is a finicky subject, to say the least, and it's not an exact science. There aren't any calculations or methods you can use to pre-analyze the resulting fun-ness of a game mechanic other than sitting a large group of people down to playtest it, give feedback, tweak something, and repeat until most agree you've got something that works. This is true of any game in fact, but it happens mostly behind closed doors, during early closed beta mostly, and some final adjustments over open beta. In our case, there is no such thing. Our closed testing is to speed up the discovering and fixing of bugs, but the final release isn't really final at all.
We've been following the community closely these last few days, picking up feedback from everyone to see how the balancing is working out. We've seen some players who did get stuck with no cash to continue, and many others who have made enough to not have to worry about it. That's not bad at all from a first iteration.
Cheers
-
Isn't there an Internet "rule" that a thread is over once someone mentions n*z*s?
I think the rule is that you're never more than 6 connections away from it. But do stay away from that kind of topic, or this thread will quickly be sporting a shiny grey padlock icon which, while stylish, also disables the 'reply' button.
Cheers
-
I did tweak the Kerbin day slightly here so that 6h is now the length of a solar day, not a sidereal one. As a result, the sidereal days are now 51 seconds shorter, and you may get an eastward launch velocity boost of around 0.01 m/s.
However, over many days, the time of 'noon' still drifts. I suspect that this is related to the year not really being an integer number of days, and there being no accounting for leap years...
Anyhow, 6h for solar or sidereal doesn't really matter in any case, becuase the UT clock doens't measure local time. It measures time elapsed since game start, which is the only solid epoch really, in a game where you not only have a planetful of timezones, you have several planets, each with different day/year lengths...
Really, it's much much easier to just measure local time at your position as a function of sun angle. UT time is useful though, not because it relates to any particular natural cycle, but because it is consistent.
Cheers
-
There seems to be some confusion about what recovery means for Career and Test contracts, let me clarify:
Recovery exists all the time, even in Sandbox in fact. What it is able to recover depends on the game mode, of course.
For Sandbox, the only thing you can recover are crewmembers. There being no funding or science in sandbox, it wouldn't make sense to recover anything else.
In Career Games, you can recover experiments (as usual), parts, and crew.
Parts are always recovered, regardless of them being something you have researched already, or being an 'experimental' part, offered by a test contract.
For normal parts, recovering them means you get some of its value back, which also factors in any resources you burned. So recovering an empty SRB, for instance, will yield a lot less funds than recovering an unlit one. Given that the SRB's cost is about 75% fuel, that is a sizable difference.
For experimental parts, two things may happen. If you completed the contract that offered it, the part will no longer be classed as experimental, so you'll get the recovery funds for having returned it, but it won't be available anymore in the parts list until you properly research it in R&D (or you take up another contract that offers it). If you haven't yet completed the contract however, recovering the experimental part will add it back so you can launch it again for a second try. The cost of the part is independent of its status in R&D.
As for the value of the recovered parts, that is still a work in progress. Currently, there isn't anything deducing the recovery value of a part other than figuring out the value of the part and the remaining resources in it, but that will likely change before release. There should always be some loss of value in recovering parts, even if you don't use it.
For recovering Crew, well, this has been in the game in an understated way ever since persistence was implemented. The only difference is that now you get to see exactly who was in the vessel you recovered as part of the summary screen.
Hopefully that clears up how the whole thing works.
Of course, this is a first iteration for these systems, so don't expect everything to be final as if it were fully implemented yet. There will most likely be a lot of other things to add on later updates.... as with everything else.
Cheers
-
The value in question would be Part.inverseStage.
And yes, staging is a deceivingly complicated piece of logic. You'd think it would be something as simple as recursing through the ship and handling it as a simple tree structure, and then you get to the edge cases, and you feel like you just walked into a room full of zombies.
Having the main 'pod' section of the spacecraft not share the same stage as the root of the ship (the first part you placed) causes a number of mind-bending situations... What happens to the vessel when you drop the main bits that were controlling it?
That's something we call 'root-dropping', although it is a bit of a misnomer. You're dropping the core of your spacecraft, but the root of the vessel was not part of that core, so from the core's perspecting, you've 'dropped' the root of your hierarchy.
We work around that by detecting whether the ship you're now in control of is still more than a piece of debris. If it's not, then we switch focus to the jettisoned bit. You can see that happen sometimes as the camera tends to jump slightly instead of flowing smoothly towards the new center of mass.
Hierarchy shifts happen all the time as you play. Docking is what got that whole thing started, as as you docked, the 'docker' side of the pair would shift its internal part hierarchy so that the docking port itself was the root of the vessel, and everything from there down became children of it. Then upon undocking (assuming the vessel still contained its original root part... man, 0.18 was a pain to debug), we flip the hierarchy back again so the old root is now the parent for everybody else.
Now, with the whole 'we can now shift hierarchies' thing added, we saw that there was no need to enforce that a pod be the initial part on a ship. As long as it was something you could attach other parts to, there was no reason why anything couldn't be the root, but it did create the new problem in which the command pods now were not only optional, they also were possibly placed after decouplers. Hence, root-dropping.
Anyhow, I should get back to work here. Best of luck with your mod.
Cheers
-
Harv, while you're here, a question I've always wondered: Why don't you use mod stuff (with permission of course), with code already written for you?
This question has popped up in varying degrees of aggressiveness quite a few times... Thanks for asking it straight and simple.
'Merging' mods is one of those things that one the surface would appear simple, but it's actually quite a lot more complicated than it would seem.
Consider that even commercial assets from Unity's asset store, which are packages made specifically to be dropped in and used in existing projects, will, for the most part, require some drastic reworking to fit them into KSP. Granted, the mods are done already over our existing codebase, and that does make the initial integration easier, but there's more to it than that.
If we had a complete game, and someone came up with an awesome new mod that everybody wanted, and we had permission to fold it into the game (another issue in itself), that would probably be the end of the story... Assuming also that we wouldn't have to make any changes to the mod itself (another tall order, since mods are exactly meant to modify the game experience, by definition).
That's obviously not the case here. The game is still growing, and as it grows, it's very common for us to come across bits of old code that now need to be refactored to make it work again. And that's with our own code. Now, consider how frequently mods become incompatible when we release a new update. We are blessed with a modding community here that is so solid, you're likely going to see your broken mods fixed in a short amount of time. That's done by the mod authors themselves, because they care about their projects and they put in a lot of effort to keep it nicely maintained.
Now suppose we were to fold a mod into the game... That author support would now become our own burden, and given that we have our own systems to maintain as we develop already, imagine what it would be like if we started to suddenly plop down chunks containing thousands, or tens of thousands of new, unknown to us, lines of code. We'd end up with an unmaintainable mess of code.
In the end, we're happiest as we are right now. The gist of the problem is that neither the game nor the mods are carven-in-stone, unchanging pieces of code. Both are living, evolving projects, which evolve alongside each other, and it takes the combined efforts of everyone to keep this organism alive.
You can put it like this:
A bird needs a tree to nest in and survive... But try gluing the bird to the tree to see what happens. (actually, don't try that).
Cheers
-
Kasuha has done an analysis of this flow type in his fuel flow thread and it appears to show that Harvester's description is not correct. Rather than the stage number, it appears to use the count of decouplers between the tank and the root part and this value could have little relation to the stage number.
Is there any chance one of the core devs could give us an official description of how this mode works?
Ah, indeed, there is a bit of a catch there. The new stage drain logic does use the staging indices for the part, but the thing is, tanks and such are usually not the kind of parts you would see in the staging list, since they have very little to 'activate' by engaging a new stage.
The thing to keep in mind here is that even though the tanks are not present in the staging list, they are still bound by the rules that control the default assignment of stage numbers to every part. That said, there may be a subtle bug here, which I would rather not poke at without having a better understanding of what's really going on internally. In that other thread, you can see that while the tanks are clearly on different stages, they appear to not have inherited the proper stage index after the decoupler. It's hard to tell any more without knowing in which order those tanks were put together, if they were placed before or after the decouplers, or if that happened before or after stages were edited, or even if you copied the other decouplers instead of using fresh ones, all that could be potentially influencing the situation.
I'll try some experimenting here in any case, ideally, I would expect any part that has no purpose in staging to just inherit the staging indexing from the parent part, manually modified or not. With staging related issues, however, well... let's just say if I could pick any part of the game to go back in time and do over... staging would be right there on top on the list.
Another one for when it's time to pave the tunnel, I suppose.
Cheers
-
Regardless of when there will be time for it, an update focused on community-sourced improvement suggestions is a great idea.
EVE Online had major success with this a few years ago when one of the dev teams started the "The Little Things That Kill" project. Following the idea that sometimes it can be really minor design oversights that crop up over and over in day-to-day gameplay, rather than high profile but rare bugs, that cause players to feel annoyed, they opened up a thread on the forums and just asked for the community to brainstorm. Everyone was asked to contribute anything they thought could be fixed in no more than 20 minutes of work by a single person. Of course, not everyone can judge these things correctly, but the team still received a gigantic amount of suggestions. Things as simple as "reorder the items in this right-click menu because the most used choice is in the least convenient place possible right now" and "please let me hit enter to confirm entering a name in this field, instead of having to use the mouse to click OK" and "take this feature you already have implemented in screen A and also make it available in screen B". Over the course of several patches and expansions, over 400 such "little things" got fixed.
That is actually a great idea, and taking care of those 'little things that kill' (great name for it) is something that we always try to do, whenever we get a chance. For the ARM update, in fact, I did devote an entire week to cleaning up loose ends, mainly concerning how maneuver nodes and map view features were handled...
But therein also lies the catch:
If you can sink an entire week in just that one area, take a step back to look at the entirety of the game. How much of the scope of the game would you say the map view and maneuver nodes represent? 10%, 15% maybe, I wouldn't dare call it any higher, what with the space center career features, craft construction, part logic, part physics (not the same), scenery, map scenery (also not the same as map view itself), persistence, and not least and probably forgetting a bunch of other bits, the UI on each scene also.... In fact, after listing thing... even 10% seems like a gross overestimation.
I don't mean to complain, just to give a sense of the enormity of the job that's ahead of us to tidy up these little things.
The good news is that as soon as we're done implementing the last stages of career mode, the plan is to devote more and more time to improving and tweaking everything that was left behind as we pushed forward. Things like what you suggested here will become increasingly more important.
If we were building a tunnel, you wouldn't expect the road to be fully paved up to rear end of the tunnel-boring machine. The whole tunnel would be closed to traffic in fact. It's pretty much the same principle here, with the advantage you get to visit the job site and drive in it already. (ok, that's quite enough stretch on that analogy, any more and it will collapse)
Cheers
-
Sorry for being late as crap with this. I've actually stopped using it for KSP. The reason is with a KSP-win glitch. The x52 has ultra-sensitive sensors that register some ungodly number of positions. win KSP will only register up to so many, and this cap is about a fourth of what an x52 has. As a result, you can push the stick tiny amounts and get full range of motion in the game. This was still an issue as of .22. Untested in .23. I was able to combat it to a degree with a lot of sensitivity lowering in both KSP and in the saitek control panel (plus some dead zone movement and some other things). It is my hope that since HarvesteR has one on his desk, that proper support for high end analog controls is coming soon.
By default, the X52 does seem to be way too sensitive, but you can drag the sensitivity sliders on the input settings down so they respond better. Those sliders affect the response curve, so you can have less response near the center, and still max out the axis at full deflection. Sliding to the left will make it less responsive. For the x52, I've found that you probably want it toned down to around 15% or so, except for the throttle axis, which should be kept linear (same for the rotaries).
In 0.23, there was an important bugfix done to joystick indexing, which affected axis mapping when multiple devices were present. That's much improved now, although there are more tweaks to do there still... like everything else.
As for recognizing the buttons, that's something we don't have much control over. Unity will read up to 20 buttons from a single device. The X52, IIRC, has 39 (everything counts, Hat switches, scroll wheels, even the mode switch), so several buttons won't be mappable directly in KSP... That's why all high end devices have profiling software, very few engines are able to read every single button on an input device.
Cheers
) Once the most serious issues are worked out, the feature branch is deemed worthy to be integrated into the main development branch (aptly named 'develop').
Term for the height of a craft from wheelbase to top of rudder
in Science & Spaceflight
Posted
Hi,
So, this struck me as a peculiar thing. I've been searching here for a term by which to call the size of a craft along its yaw axis, that is, the 'runway height' of a craft, or the 'cross section height' of a rocket sitting at the pad, and I thought it was very strange that I could find no specific term for that dimension.
This seems particularly odd in a field like aerospace, where each and every possible measurement seems to have a particular name (like dihedral, chord, wingspan, and so on), that such a basic dimension of an aircraft must be referred to by the ambiguous word 'height', or by a long name like 'cross section height' or something like that.
So, looking for the largest aggregation of savvy minds in this field brought me here.
Does anyone know if there is a specific name for this measurement?
Thanks in advance for any input.
Cheers