HarvesteR
-
Posts
3,542 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by HarvesteR
-
-
That is very cool. Thank you for sharing those with us!
Cheers
-
One thing I've found can cause losing control during a takeoff run is to have a misaligned wheelbase. That can happen if your landing gears aren't all parallel to each other (and aligned in the general direction you want to go towards). If it's a minor misalignment, it can cause some wobbling, but if it's significant, the wheels will get dragged slightly sideways and the skidding could tear your craft apart.
Try to reattach your gear with angle snap turned on (or off), or move them somewhere else. If they're converging or diverging, they'll likely be unstable. You want to make sure they are parallel, as much as possible.
Cheers
-
The big thing with R&D isn't to impose a grind where parts are unlocked as a reward for something. What I want to get out of it is a mechanic through which the game presents itself gradually to players, to not welcome you with an overwhelming wall of content right from the start.
As with the content, the tree itself is being designed to expand the further you get. At, first, you get a few general technologies to research, which in turn open up new nodes which are more specialized, and so on until you're getting to some really specialized stuff towards the higher levels.
We're assigning parts to each of these nodes now with this idea in mind, and so far I think it's going rather well. Each part seems to find its place nicely in the tree we have here.
As for how nodes will be researched, here are my thoughts:
We can't impose any amount of time to unlock something. You could just sit on the pad and timewarp if that were the case, and that's not the sort of gameplay we'd like to see.
I also don't like the idea of spending money directly to research something, as that would reduce R&D to be just a shop catalog.
Instead, I think the most authentic mechanic would be for nodes to require a 'science' rating, which you earn through experimentation (flying) and gathering data (packing science gear aboard possibly). This system opens up a lot of very cool possibilies for later, which will give a lot of meaning to what you can do out there on your missions, even before we have an actual game economy or contracts.
To paraphrase a friend developer, it's not about realism, it's about authenticity. Realism means putting you into a simulator cockpit and making you wait around for months to reach another planet. Authenticity means making sure what the game lets you do feels right, even if it's presented with some degree of abstraction, like using a numerical value to represent a more complicated process.
Cheers
-
I'm kind of nervous about this I hope when they add it it's not mandatory because there are some persistent files I have that revolve around nervas
No need to worry about that. R&D is probably only going to be available in Career Mode.
For Sandbox saves, it wouldn't make much sense to have R&D anyway. The R&D Facility will be at the space center but it won't open the R&D screen.
This is the best solution IMO. It leaves existing saves unmodified, and means everyone will get a clean start with R&D.
Cheers
-
Aren't we too low on part counts to make a really cool Tech tree? Or maybe the tech tree will also work to improve Weight, ISP or even impact?
We currently have over 160 stock parts in the game. It's definitely enough to have a tech tree.
That said, yes, we are still missing a few parts to fill some particular niche here and there. The Tech Tree is actually helping out a lot in finding where those 'gaps' are, so we'll know a lot better over the coming weeks which parts we need to work on next.
Also, don't expect whatever we release on the next update to be a final, unchangeable version of the tree. As with everything else we do, this is only a first implementation, so it's very likely it'll be revised again and again until we're completely happy with it.
That's about as much as I feel ok with discussing at the moment, it's still very early to get into detail on it.
Cheers
-
I do have a theory on why some people were affected while others weren't. The drifting issue was related to how the SAS would release attitude lock when input was detected, and that could have been getting interference from joystick axes with zero deadzone.
We corrected that by setting a minimum deadzone that's independent of the joystick deadzone, so if you have joysticks with no deadzone, it will still properly ignore the jitter from the analog inputs.
I think those who didn't have this issue either didn't have any noise on their input axes (as detected by unity), or had deadzones set for their joystick assignments. Not sure... That's just my theory of how it could affect some and not everyone.
Cheers
-
We did tweak the lighting on this patch. As a whole the lighting was too strong, and there were several places where you'd get complete white-out.
Lighting for rendering is a complicated thing. There is no single solution that mirrors what you'd see with your own eyes (your eyes adapt), unless you use HDR (high dynamic range) techniques to simulate this adaptation, which alas, isn't something Unity does very easily at the moment.
That said, we're always trying to find ways to improve the looks of the game, and we found that by lowering the main sunlight intensity, we got a much nicer tone distribution throughout the lighting range, which means you get to see more tone variation, which is good.
This shot shows it pretty well. Where now you see pretty splash lighting, before you'd only see a white blob.
As for the Mun itself, my opinion on it varies from shot to shot... Sometimes I think it's too dark, other times I think it's ok... I guess it's one of those things that will keep getting tweaked over time.
Cheers
-
I think a slightly critical piece of info slipped past untold... Whether or not crews can respawn is a toggleable difficulty setting now, which admittedly lacks a UI toggle switch, but is already definable on the save file. Have a look at the Parameters section and you'll find it.
The default setting (for now) does allow crews to respawn, so even if you do end up with a favorite Kerbal on the "lost" list, if the game parameters allow it, they'll come back to life eventually.
Cheers
-
Thanks! It's very nice to see someone noticing our backend work, outside of a bug report.
It really was an insane amount of code reshuffling that we needed to do to make it happen... Verging on stupid almost, but I'm very glad we managed to pull it off, because now we have a much neater solution for elements that are shared between multiple scenes.
As for other similar systems. One game I know does something along these lines is ArmA. Once you load a map on it, that map will stay loaded until you exit the game or load a new map, even if you quit to the main menu (there are background cutscenes for each map). That cuts down on loading times while you're doing missions on the same map.
The same happens for KSP now with PSystem. We don't have discrete maps, but you'll notice that if you're just playing around Kerbin, especially near KSC, the transition time between the space center, VAB and launch is drastically reduced, because the terrain can just remain unmodified while we switch scenes now. We only have to rebuild now if you're returning from somewhere far away.
Cheers
-
Well this is weird, how do some people have working SASs and others not? I know, how about we all post pictures of the ships we are using to find out if there is a problem or not. Because I'm convinced that there really is something wrong.
Now this is much more like it!
I'm also suspecting from all the reports that something, could be a mod, could be a bad settings file, could be old parts lingering about the KSP/Parts folder, might be interfering with normal SAS operation.
The new SAS might be a lot of things, but it most definitely isn't a thing that requires constant input to maintain attitude. It's been pretty consistently doing that on all the test cases we did here, and there were a lot of them.
If the SAS isn't holding attitude properly for you, then it very well may be in a buggy state, because that is certainly not the intended behaviour.
First things first though, we need a proper baseline to compare different cases here. So how about we use the Aeris 3A spaceplane as a benchmark? It's easy to fly and it's got a few particular flight characteristics that are easy to spot.
So, the test is as follows.
* Launch a new Aeris 3A from the runway, set it at full throttle and try to maintain level flight.
* Do not adjust trim. On neutral trim, the 3A has a slight tendency to pitch down when the tanks are full.
* Climb out to 1000m altitude and verify that it's doing that. Let go of the controls and make sure this tendency to drop the nose is there.
* Ok, that's our control. If you've observed anything else at this point, something is already wrong with your game and you should be doing a complete reinstall.
* Now, let's test the SAS. From level flight, engage it with T and don't apply any input. Verify that it's maintaining attitude.
* If that didn't happen, then something is wrong with your game. Reinstall.
* Now, a few more tests. Apply some slight pitch up input without disengaging SAS. Pitch up to about 30° and watch the aircraft maintain the new attitude.
* If that didn't happen, then something is wrong with your game. Reinstall.
If you spotted something wrong by doing this test, please list all your mods if any, and check the KSP/Parts folder to see if there's anything in there (on a stock install it should be empty). Also, try deleting your settings.cfg file and running the game again. It's unlikely, but not impossible that a bad config would mess things up.
That should be enough to spot most cases where things are very obviously wrong. We can start with that for now.
Cheers
-
Planets being small was one of the most important design decisions we made. The Kerbal system is scaled (roughly) to 1:11 of real-life.
This allows for a number of "improvements" over the real thing:
You can orbit Kerbin in around 30 mins, instead of the 90+ it takes to orbit the Earth;
Launching into orbit takes around 4-5 minutes, as opposed to 10-15;
Orbital velocity at 100km altitude on Kerbin is around 2300 m/s, around the Earth it's over 7000;
With everything scaled down, things happen faster, and you also get a better understanding of what exactly happens as you orbit. It's a much more dynamic experience this way, and consequently more fun.
Others have said it already, and it's very true: KSP is a game first, a simulation second. If some aspect of the real thing is boring or too complex, we will do all we can to minimize time spent doing it or making it simpler. Examples of that are how Mun is at 0° inclination to Kerbin (you can get there thinking in 2D), or how the galactic plane is aligned to the ecliptic and equatorial plane, creating a unified space "horizon".
We take such liberties wherever we find that there's no fun to be gained in making it more realistic. Because really, if complete realism were the most fun you could have, we'd all be outside playing.
Cheers
-
You're always falling, even when orbiting.
The reason you feel weightless in orbit is that you're in perpetual freefall because of your orbital path. The vomit comet flies a parabolic path that in effect gives a few moments of "weightlessness" because you are the one falling in the parabola, and the airplane flies around you. Since it can't really stop flying, it has to fly the parabola that you're "falling" in.
Make sense?
But you're not going to feel weightless in an aircraft approaching orbital speeds unless that aircraft is flying a parabolic arc. It's not the speed alone that makes you "weightless" it's also the trajectory.
Very true. In fact, the Vomit Comet needs to be piloted just right to maintain that parabolic trajectory, which isn't that easy on a craft specifically built to not free-fall.
But you don't have to be perfectly parabolic to start to feel weightless. Close enough will do, and this is what happens if you fly close to orbital speeds while maintaining altitude. You're not perfectly in free-fall, so you experience something in between zero and 1G.
Cheers
-
A "chip in your brain" is a very vague proposition... What are the specifics of it?
Would it be connected to anything in the brain? Would it have a power source of its own or be powered by induction from an external source? would it have any sort of network interface, and if so, would you be able to configure it? Or is it just a random piece of electronics I found in my head after waking up in a bathtub full of ice one day?
IMO, I understand a "chip in the brain" by the notion that it is a complete computer, only with a very very 'user-friendly' human interface system. No keyboards, touchscreens or anything, just a straight connection by what you will it to do (somehow). The outputs could be visual, or audio, or just a mental image.
The issue then becomes a much more familiar one. What sort of Operating System are you willing to install or have installed? Will it let you tweak it to your liking ala Linux (with the possiblity you might zap your own brain by botching up a tweak), or will it be an in-brain version of iOS?
Computers do what we tell them to do, nothing more and nothing less, and most certainly not necessarily what we want them to do. Whether or not you want one in your head is actually besides the point...
Cheers
-
Ok, so, I'm going by the assumption that the OP question was this: If you take an aircraft that can go fast enough in the atmosphere, does it experience less G force as it approaches orbital velocity?
Yes. I've had this happen here myself.
This has nothing to do with centrifugal force and whether or not it exists (it does in a rotating reference frame), it's simply the fact that the mechanics of orbiting don't switch off just because you're in the atmosphere.
I built a space plane one day that had enough engine power to fly at an appreciable fraction of orbital velocity. IIRC, it could do over 1000m/s at around 20km altitude, which is nearly 50% of orbital speed at Kerbin. Flying level above the surface (0 vertical speed), I noted the G meter indicated around 0.5 G.
I was perplexed by that for a while, until I realized that we really were flying at almost half the speed it takes to orbit the planet, and it makes sense then that if you're moving that fast and maintaining altitude, the G force will tend to zero as you approach vCirc.
Note though, that this is G force I'm talking about, not the gravitational pull of the planet. The force of gravity acting on the ship is still the same (or roughly the same as at the surface, because 20km is peanuts to space).
Zero-G is achieved once your acceleration matches that of gravity. We experience 1G at the surface because we are opposing gravity already just by the fact that we're not falling through the ground. Orbiting however, isn't opposing gravity, it's falling along with it.
As you fly forward very fast then (assuming level flight in relation to the surface), you experience less G force on you because you're approaching a state where your acceleration matches that of gravity. You don't experience zero G immediately however, because you're still opposing it by maintaining level flight. The closer you are to orbital speed then, the closer to zero G you get, and the less wing load is required to stay level.
If you go faster than vCirc then, you actually have to pitch down to maintain level flight, because that trajectory would send you away from the surface. You then experience G force again as you have to oppose the acceleration of gravity.
I hope this explanation made sense... I tried to explain it by as many angles as possible, but there's only so much you can do without having to start drawing up charts (I'm not going to start drawing up charts).
Cheers
-
It's nothing to get excited about I'm afraid... The server simply seems to be down.
We're scrambling to fix it and will resume normality as soon as possible.
Cheers
-
That map is an example provided in one of the Libnoise tutorials, which is an opensource numerical noise library we still use to generate terrain in KSP.
The very earliest versions of Kerbin were using the map as a placeholder, and after the game went public people started founding countries and creating all sorts of stories around it. We didn't have the heart to replace it by a unique one, even though it was a few tweaked seed values away.
These days, the original map isn't used at all anymore, but we've generated our height maps from it (and from that generate the planetary surface maps), so the continental layout remains very similar.
Cheers
-
Craft files are still compatible. The only thing that needed to break was save compatibility.
Your creations should be safe... Assuming of course it's not using mods that might themselves break, or something else... compatiblity is never simple.
In any case I've been using the same stock ships here as always for testing, and they didn't give us any trouble so far.
Cheers
-
While we've been able to maintain compatibility over the last couple of updates, unfortunately this one isn't such a case. The new crew management system changed the format for saving crews (to something much better), and the new format isn't compatible with the old version. Instead of risking breaking things even more by writing some sort of upgrade logic, we decided it was better to just break compatiblity and start fresh.
This also gives us a nice opportunity to do other tweaks that we can't usually do, exactly because they tend to break saves. Because we're going to break it anyway, we can push in a lot of other little tweaks that wouldn't have gone in otherwise, so hopefully they will make it worthwhile.
You can always manually edit your save so it matches the new format, but that can cause other issues, so we really don't recommend it.
Stay tuned for a dev blog soon about new things that we got to add because we decided to break compatiblity.
Cheers
-
Threads like this are the reason we started the Science Labs board. It's just awesome to see such an aggregation of brain power come together to tackle a difficult and interesting problem.
So, what I would consider to be the ideal solution to SAS is this: When enabled, it would hold the vessel's attitude to what it was when it was engaged (as it tries to do now), but if any input is applied by the player, it would allow you to command the attitude setpoint.
I think any solution to the SAS system will involve some sort of adaptive scheme. It could start off with default values, and by noting the input it's applying versus the reponse it's getting, it could adapt its parameters to something more suitable.
The problem is that this response might be buried in noise, or it might only become measurable after a delay, so grabbing good data isn't easy. Factor in the vibration from the vessel's own geometry, and it gets even worse.
I do have a few ideas about how to exclude the vibration from the input... We know where the CoM is in relation to the vessel transform, so we can take a cross vector of that against a 'pristine' CoM, calculated using the stored pristine coords for each part, instead of the actual part positions. That difference is your 'flex' vector, and we can exclude that from the vessel's actual rotation to get a 'rotation at CoM' value, and derive the angular velocity at CoM from that.
Excluding flex, we can hopefully have the true angular velocity for the vessel, with makes for a much more reliable input to any PID scheme.
EDIT: Better yet, instead of a cross vector, we can take a from-to quaternion, and use it to directly exclude the wobble from the vessel's rotation. The resulting rotation can then be used to find the flex-free angular velocity.
Cheers
-
You know how we say we're amazed every day by what you guys manage to pull off?
This is a whole new level of that.
Hats off to you sir! I'm properly amazed.
Cheers
-
These extreme loading times appear to be caused by a new unity bug (introduced on the latest version and exposed by a tweak on 20.2). There is a known workaround, which is to disable any unconnected network adapters you may have.
I can't guarantee it'll work for everyone, but it appears to have been effective for many.
Cheers
-
Ah, I see you found the source. That post was the very first public announcement about KSP. Everything else sprouted from that (there was a post on Unity forums and on GameDev as well, but those didn't catch on).
Heh, quite a blast from the past, certainly. And at a most auspicious time too, we're a few days away from the 2nd anniversary of that post.
Cheers
-
Also, if you press space while holding shift, you'll jump off the ladder in the direction you're leaning towards, instead of just letting go. It's called a push-off, works best in very low gravity.
Cheers
-
In real life, the centrifugal force would probably throw everything out, and the planet would disintegrate... but that's a pretty boring answer.
I tried this in KSP once, where such trivial matters aren't an issue, and sped up Kerbin's rotation to see the effects.
Assuming the planet is able to hold in one piece (as Kerbin did), yes, the rotating frame forces would effectively work to cancel out gravity. Throwing a baseball eastwards would send it on a slightly higher orbit than your own (you'd be orbiting too), and throwing it westward would send it on an impact course.
Of course, all that fun would only happen at the equator... As latitudes get higher, this effect becomes less pronounced, and at the pole you'd probably just get motion sickness from looking at the stars
Cheers
About the Tech tree
in KSP1 Discussion
Posted
Concerning mods and the tech tree, this is how it works:
All parts now have a "TechRequired" parameter in their cfg files, which is set to the ID of the technology node which unlocks it. IDs are unique, so there's no worry about branches or dependencies there. You just set, for instance, radial decouplers to the "generalConstruction" tech. Doesn't matter what other techs you need to get to general construction, the radial decoupler will be there when you get there.
This means mod parts will have to be updated to appear in the parts list on a Career mode game, which is actually a very good thing. This requires mods to be updated to fit into the R&D tree, which means they can be added to the techs that best suit each part.
Plugin-only mods should be unaffected. The R&D implementation just hides unresearched content, it doesn't keep it from loading.
There is another new parameter on the part cfgs to define a part's 'entry cost'. The entry cost is an amount required to have the part available in the parts list. This means when you research a tech, the parts it makes available aren't made automatically available to you. You'll also have to put down some cash (game cash of course) to have the part. Without a working budget implementation however, it might not be possible to finish up this entry cost mechanic for this update, but it's easily disableable (word?) in case we need to go without it for now.
That's about it for now.
Cheers