Tiron
-
Posts
939 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Tiron
-
-
Unfortunately there is no such thing as a deteorating orbit in KSP. Well almost ... your orbit has to have Pe under 22km on Kerbin otherwise it will never deteriorate.
Unless you focus the piece of debris in question while it's in the atmosphere(Less than about 69.2km)...the tracking station has a 'debris' category for a reason. Focused = simulated = drag, even if you can't control what it is you're focusing. Anything within 2.4km or so gets simulated too, in the event you have a cluster of junk.
Edit: For the record, the ~20km limit you noticed isn't because the orbit actually deteriorates, it's because anything on rails below that altitude is automatically despawned. This is most visible if you eject something while below that altitude and then get more than 2.4km away from it. It'll disappear the instant it passes out of simulation range. On rails parts do not simulate physics and as such can't collide with anything, including planets. If they weren't despawned, they'd fall through the surface, loop around the center of the planet, and then come flying back up out of it.
Note that the 'no physics' means that debris can't hit debris, but this won't protect your active ship: The instant the debris gets within the 2.4km simulation limit, it's taken off rails and regains physics, and thus is perfectly able to smash you flat.
-
I think the main point of this thread is that a rebalancing is in order. Parts have been added over time and without a hard-set rule for determining stats. Since Squad went through all the trouble to model these parts, it would be nice if each part had a niche that it could fill. This will be much more important with the release of career mode (this game will not remain strictly a sandbox forever, or for much longer based on the dev's latest pushes).
For example, engine clusters outperform some of the bigger engines. This encourages higher part-counts, which the game does not like at all. Every part (especially nonstructural parts) should be pareto-optimal for some specific situation (ie the Ant engine gives the highest dV for very light vessels despite possessing abysmal ISP and TWR).
Almost all of the parts ARE optimal for some situation or another, dependent on what the player is going for. Some of them are pretty niche, but there's nearly ALWAYS something they're better at than another part.
For example: the Cylindrified RCS tank has the same dry weight as the Size 1 inline tank with 50% higher Monopropellant capacity. The Cylindrified weighs more total because of the greater amount of fuel it starts with. It's also hard to mount just one of the Cylindrified ones without unbalancing your rocket to some degree, so the inline has some merit for overall weight savings, at the cost of a worse mass fraction(monoprop wise, anyway).
One thing to keep in mind is that the parts aren't INTENDED to be balanced for Sandbox play, they're intended to be balanced for Career mode play. With no career mode in yet, some of them are bound to be less useful than others. But when the more useful part is farther up the tech tree, or costs too much, those 'lesser' parts will look a whole lot more attractive.
Also, bear in mind that the current SAS system is still in testing in many ways (C7 is looking at doing more adjustments on it now he's back), and some of the currently useless SAS parts are probably going to regain a point in the future. Right now, with all the problems the new SAS has, getting those fixed is taking precedence.
So yeah, I bet you could name just about any set of parts where one seems to be superior to the other, and I could name some thing the 'inferior' one is actually better at. It might only be cosmetic or reducing part count or something, but hey, those things matter to some people. Except for the Inline Advanced Stabilizer and Avionics Package, which probably will get fixed at some point in the future, and the AV-T1 fin, which I suspect will probably initially be the only available fin in career mode (otherwise it WILL be useless even then, unless it's made cheaper than the Tail Fin).
-
A thing to consider is that even if objects do not add to lag beyond 2.25kms, the more objects of any kind that exist in your game, the longer quick/autosaves and quickloads take.
As he says. It's mostly a memory thing: Once they're outside of about 2.4 KM or so they go 'on rails', and cease to have physics calculations performed on them. This means there's a minimal performance hit, but it still has to be loaded and tracked. The tracking is easy because the orbit is strictly defined, but if you have enough of them it could spike your memory usage beyond the 4GB limit and then you're in crashville.
-
Panels cannot be fixed
*Snip*
Try dropping out to space center and then loading back in. This used to fix the OX-STATs if they were 'broken'. They're REALLY fragile, though, and break at the slightest touch. Of anything. At all. A kerbal walking on it will break it.
-
The gimbal range is useless with the new SAS stacking. You can turn a rocket on a dime with non gimballing engines now. Also, the high thrust means nothing; the radial Rockomax has a higher thrust to weight ratio, place 6 of those, and they perform better than the standard radial engine.
No, the avionics provides no torque whatsoever. The avionics is just a SAS flight computer (which all command pods and probe cores have already pre-installed since 0.21).
The ladder's heat sink ability is more of a game bug rather than an actual legitimate use of what it's meant for. The pretend drill is nice, but it's still a pretend aesthetic feature that has nothing to do with the ladder's actual intended use.
Also, your rocket would be able to go much higher if you replace the radial engines with other engines that provide higher TWR, higher ISP and with less fuel.
Six of the small ones might work better in every way...except one. Six parts instead of one, on a part you have to mount in at LEAST pairs? That makes a minimum of 12 engines. That's gonna push the partcount straight to lagville in a hurry.
As for the ladder, the yellow one at least does have one feature that can make it more useful than the big one: the container that holds the folded up ladder is much longer on the big ladder. So much so, in fact, that if you try to mount it onto most parts of a Mark 1 cockpit, it clips through the other side.
Probably the only part that's completely useless right now is the AV-T1 fin, and that's only because there's a lighter-weight part that otherwise has the exact same stats. There's no other two parts where it's that clear-cut, that I can think of anyway.
-
Avionics is completely useless now since all pods come with the smooth SAS built in. Also, the avionics doesn't even have reaction wheels.
All the three ladders weigh the same, so you might as well use the longest one wherever you go.
The radial engine has the lousiest ISP, lousy thrust and overall completely pointless. Plus other radially mounted engines does the job better.
It's also the first radial engine ever added to the game, has Isp similar to the Mainsail (added at the same time), and the highest gimbal range of any engine which coupled with its radial placement gives it the strongest control forces of any engine. It also has higher thrust than any other radial engine.
So yeah.
-
And here I was thinking of KSC2 as the Baikonur analogue...
-
Some things to consider on this subject:
The 'Drag Model' is very unfinished and completely unrealistic. It works by multiplying the weight by the 'drag' stat of the part, which is more like a coefficient than an actual amount of drag. There's no accounting for shape or parts being blocked by other parts. The only thing it takes account of are speed, atmospheric pressure, weight, and the drag stat of the parts.
This means, for a start, that both of your 'nosecone' setups are presently less efficient than *using no nosecone at all*. You're ADDING drag on top of the additional weight. This isn't the case if you use the FAR mod, but in stock it very much is.
That said, the general idea goes a lot further: The new cylindrical radial RCS tanks have the same dry weight as the size 1 inline tank, but holds half again as much monopropellant. This means two cylindrical radial tanks hold as much monopropellant as three inline tanks, for the dry weight of only two inline tanks. The Delta-Deluxe winglets provide more lift than the AV-R8s for the same weight and drag (although possibly weaker control force, I'm not sure). The Canards provide stronger control forces, for twice the weight and twice the drag. The Ram Air Intake provides more intakeair than any other intake, and is tied for the lightest (which should negate its higher drag coefficient), and has the same cap on the extra drag as all the rest of them (it just gets there faster, but if you're hitting the super to hyper sonic regime they ALL get there anyway). The AV-T1 has more than twice the weight (and thus drag) as the Tail Fin, for the same effect.
The list goes on and on.
But as one of my friends points you, you have to remember there are other balancing factors here we don't have yet. In Career mode, you're not just going to be able to use every part. You'll have to worry about things like how much the parts cost, if you have the tech that allows you to use them, etc.
Career mode being one of the primary design goals right from the start, you have to keep in mind that it's been planned for since the beginning. Yes, there's parts that seem to be useless, but if it was what you had available, or all you could afford, you'd use it. That's going to come up, eventually, and make some of these 'useless' parts a lot more useful.
Edit:
Well, take a look at the engine colling unit. It doesn't do anything and it's just for asthetic purposes. That's a useless part.It's the lightest and lowest drag radially attachable cylindrical part, and as such is absolutely ideal for providing non-fuel-carrying mounting points for engines and air intakes, with the advantage that it provides a mounting point for both simultaneously. The air-intake version provides very little intakeair but STILL gets drag-capped at speed, thus adding a lot of drag for very little benefit.
-
*A bunch of Stuff*
You can avoid camera confusion by using the 'change camera' button (Default: v) to go into chase mode: This causes the camera to orient so that up-down-left-right for your craft are all correct relative to the camera, making moving in the right direction easier. It also causes the camera to move with your craft, which can be a bit motion sickness inducing at times, so be careful!
Rather than going to the space center, you can use the 'cycle backward/forward through active vessels' buttons, default [ and ]. This only works within close range. Going to the space center has the advantage of packing the ships up and then unpacking them, which stops any rotations, but you can do that just by blipping up to 5x time warp for a fraction of a second.
His control notes are for 'Staging Mode': IJKL are the defaults for the translation controls in Staging mode, which can be easier to use than swapping WASD between translation and rotation in docking mode. Note he's kinda half left two keys out, however: In staging mode, H uses RCS to translate forward, and N uses RCS to translate backward. It's frequently far easier while docking to use this rather than primary engine thrust for small directional adjustments.
You can switch into 'fine control' mode (default: caps lock) also: It's apparently now set up so that fine control mode will use the same logic the SAS uses in determining which thrusters to use. So fine control mode can potentially REALLY cut down on Monopropellant usage by using only the best thrusters. I don't have a lot of experience with it yet, but people are already swearing by it. You can tell if you're in fine or instant control mode by the color of the arrows on the Pitch/Roll/Yaw indicators in the bottom left corner of the screen: They're yellow in instant mode and blue in fine mode.
The key thing, in all phases, is PATIENCE. There's no friction, so your inertia will continue to carry you indefinitely, no matter how slowly you're moving. It's an excellent idea to take advantage of this by using slow movements rather than fast ones. Slower movements are easier to stop and easier to correct, with less change of overshoot (and less overshoot if you manage it anyway. It DOES happen.) It also uses less fuel both to initiate and to stop. Just being patient and taking it slowly and carefully will save you a lot of fuel and frustration.
-
Docking in the game is easy (a lot easier than in a real spacecraft I'd imagine!).
You might as well spend your time more productively on other things old chap.
It's very different IRL. For one, no super powerful magnetic attraction between ports. For two, the ports aren't genderless: There's male and female ends. There's SOME wiggle room built in, but you have to get the alignment far, far closer to perfect in order to successfully dock than you do in KSP. Which isn't as hard as you might think, if you're careful. Hell, the *Russians* made an auto-docking system.
-
I use Kerbal Engineer Redux; folks also use MechJeb. Before KER, I did stuff by hand, and still do when I'm bored at work.
Aerobraking tips: quicksave when you enter your target world's SOI. You will probably screw it up the first time in.
Aerobraking is largely a guessing game; too high and you fly out into interplanetary space, too low and you're liable to go lithobraking. I don't have a comprehensive chart in front of me at the moment for good aerobraking altitudes......IIRC (and this is off of memory, mind you), Eve's about 72,000 for aerobraking and Duna is just 15k. Basic principle is the same though; just get your periapsis down to that height and let the atmosphere do the rest. If you have to burn at all to get captured, you've done it wrong...whole reason why my first two Duna missions failed.
Mechjeb's landing module also features realtime, accurate aerobraking prediction. If you hit the 'show landing prediction' button, that activates the re-entry simulation feature. If the simulation indicates you're going to re-enter and land, it indicates where (or times out if it's a really shallow trajectory). If you're going to rise up out of the atmosphere afterwards, it instead shows the predicted orbit that will result after one pass (and can even set up a maneuver node for the aerobrake!)
I also saw that someone did some kind of external aerobraking calculator, but so far as I know only Mechjeb's landing module can do it ingame, in real time.
-
I did.
I think I'm going to have to go back to the drawing board for this craft anyways as i never saved the first design properly... so getting further additions to align 3 ways would be near impossible. I'm still wondering if this particular docking port has a life of it's own.
Both the VAB and SPH automatically save the most recently launched craft. It's listed as 'Auto-Saved Craft' in whichever you launched it from(they each have an auto-save that's separate from the other's). If you've launched something else from that same hangar since, it will have been overwritten. If you haven't, it's sitting there, saved, waiting...
-
I actually agree with a good chunk of what the OP is saying. By no means are we going to have a picture-perfect-runs-fine-on-a-plugged-in-toaster game in alpha, but there are still steps that could be taken to improve it. A poster above said that as each version comes out the FPS goes down and down, and whilst the complexity is increasing, with some updates the changes are quite a step.
Also, as a question, as I am completely incompetent on the issue: Will Unity ever become more than single-threaded? Because if it won't, in KSP's forecasted development period, isn't it worth thinking of a switch or fix now? Or we'll be restrained forever.
A switch would require completely redoing everything from scratch, more or less, so it's already too late for that. A 'fix' requires that someone recode it in a way that allows the physics to be multithreaded. Ideally, the fix for that would also clear up some of the numeric imprecision problems it has trying to deal with the huge numbers involved (despite the Kerbol system being tremendously size compressed), which would clear up all kinds of minor physics glitches we run into.
-
Definitely, I wouldn't go by that "tutorial" at all. Anyway, like people said, I'd give the Lazor Docking Cam a try, it really helps a lot. I learned docking before installing it and now I just feel like I'm cheating.
A couple of my friends swear by it, but I've never used it. Although the fairly new 'Docking Alignment Indicator' mod looks like it may be best of all, since it just adds new UI elements to help you line up the ports without requiring any new parts. Apparently it's even able to indicate relative rotation, so it might be an absolute godsend if you're trying to be precise.
Another possible alternative is to use KAS instead, although this won't work for all situations. KAS connections are a bit floppy even when 'locked', so for structural assembly it's terrible. But if you're just refueling say, there are some theoretical advantages (which I've honestly never tested myself, fair warning.)
For a start, almost all the weight is concentrated on the winch side: a non-detachable radial connector port only weighs 0.0075t, less than half what a Clamp-o-Tron Jr weighs(0.02t). The winch weighs 0.1t (the same a shielded Clamp-o-Tron, or two regular Clamp-o-Trons), and the connector is another 0.0075t, so the total weight of a KAS dock including all parts on both sides is 0.115, so it's a little heavier than a stock dock. But again, it does concentrate almost all the weight on one side, which is a huge advantage for say, an SSTO spaceplane.
It also doesn't have to get the ports precisely lined up in the first place: The cable's 50m long. This does have the potential disadvantage of the docked craft drifting around on the end of a 50m cable, but if you retract it all the way, it'll go into 'locked' mode which only allows some flopping about (which is curable with docking or quantum struts). I can see retracting the cable all the way being a bit tricky, as KAS has a habit of yanking on things rather hard when the cable initially runs out, which could very well send the docked craft flying at the station faster than the cable can actually retract. You CAN avoid this if you're careful and patient, though. (I may not have KAS Docked in orbit before, but I *have* used a grappling hook to grab a piece of debris before. That was...educational.)
The main disadvantage, however, is that you need an EVA Kerbal to plug the connector into the port in the first place, so it doesn't work on completely unmanned things. You could use a grappling hook unmanned, but it can't dock craft, just connect them.
-
Waste of time even responding to this nonsense.. but what the heck, its friday.
quite a few people have already posted a "workaround"... a multi threaded plugin for unity.... can't squad program one?
But no, its not the responsibility of the people actually reaping the rewards of this game (the money)..
this actually cracks me up the more I think about it.. here is what you are saying.
Squad can't optimize the game and there are no work arounds..
unless Dewm ports a good physics engine to work as a Unity plugin.
So what your telling me is....
----> Squad can't do it
then
----> tells me logical way of doing it.
is squad not capable of logic?
.....like I said before, the problem is they are spending their time on "fluff" like career mode.. instead of actually getting a stable platform working. I'm assuming they are pretty capable programmers, Shouldn't take to long to write up a physics engine for Unity. Thats all I'm sayin.
Squad are in the business of making a GAME, not in the business of reprogramming an engine. They're not a major development studio with millions of dollars and thousands of employees to throw at such a task. They're a small, indie development studio, many of whom were formerly modders that did exceptionally good quality work.
They'd have to all but stop development on the game for a period of time to do it, and that's assuming they even have anyone with the proper type of programming knowledge in the first place. And if they do, it's probably only a few, and it would sharply limit what the rest of them were able to do with those few completely tied up redesigning the engine.
Given their circumstances it's not really possible for them to devote a lot of resources to something of that magnitude with so little of a return.
As for expecting you to do it, you basically said all along that you could, did you not? We're challenging you to put your money where your mouth is. The fact that it would enormously benefit everyone involved (including you, since Unity plugins generally have to be Paid For) is a complicating factor.
If it's as easy as you say, why are you continuing to troll up the forums rather than just doing it and selling the results?
-
Have you tried Dock Align Indicator? I haven't had a chance to yet, but I gather it's pretty good. (I'm held up by the rover problems.)
-
Actually, the game is already multithreaded. The real problem is because Unity does not allow most things to be thread safe. This mean, threads can't be separated across multiple cores. The biggest thread right now is physics, and for now it can only be treated by one core, the other stuff is being treated by other cores, but there's barely no calculations left to do. You end up with one core overloaded and the others breezing through. So yes the devs do their very best to optimize the game, but there's not much to do until we get further support from Unity. And no, an engine change is out of question. I'll also remember everyone at the same time that when the last two times the devs did structural and optimization updates (I.E. 0.19 and 0.20) there was a massive uproar of "why is there nothing in this update?"
Also, although no one has been over the top for now, I'll just give a friendly reminder to everyone to keep things civil, I can feel the heat rising out of this thread.
...Did not know that. Interesting. I'm honestly not surprised, though.
But everything I'd heard was the Unity was strictly limiting it to one core. Oh well, the more you know I guess
-
This....
A) When can we expect your release of a multi-threading plugin to Unity? Have you emailed Squad to request they subscribe to your Unity-workaround newsletter?
Well there IS a multithreading plugin for Unity now, but from looking at it, it didn't really sound like it'd be able to do the Physics, and without the physics being multithreaded, well, it wouldn't do much for us.
-
What you are most likely eluding to is Knuth's "Premature optimization is the root of all evil in programming". That often used structured programming canon, even though widely accepted, is not without its detractors. By contrast there are professional programmers that contend that late optimization implies slipshod design.
Joe Duffy, a Microsoft architect and developer: "I have heard the "premature optimization is the root of all evil" statement used by programmers of varying experience at every stage of the software lifecycle, to defend all sorts of choices, ranging from poor architectures, to gratuitous memory allocations, to inappropriate choices of data structures and algorithms, to complete disregard for variable latency in latency-sensitive situations, among others."
As I see it Squad's prioritization on what game elements are to be included, and when, is the problem. Wasting valuable coding time down the road in an effort to optimize "all of it" may not be viable, and as a result some of those labor intensive KSP features may have to be trimmed or entirely dropped.
The problem is that it's not an 'Optimization Problem' (they have, in fact, done some optimization already), it's a 'the Unity engine does not support that feature' problem. You can't 'optimize' something you can't DO in the first place.
The only way multithreaded physics in KSP will ever happen is if a multithreaded physics system is made available for Unity.
Unity themselves have no particular incentive to do it themselves, because honestly, how many of their customers need it?
This means that most likely, in order for this to happen a third party needs to make an alternate physics system available as a unity add-on.
Note that third party means 'Not Unity' and 'Not Squad'.
In other words, unless you're going to go port a physics engine that isn't ancient crap to Unity, there's nothing to discuss here.
-
Not in my saves, they don't.
There's a reason I said 'by Default', not everyone realizes this.
-
DO Keep in mind they respawn after a bit by default.
-
On the subject of Apollo Hoaxes:
The Mouseover Text: "Ok, so Spirit and Opportunity are pretty awesome. And Kepler. And New Horizons, Cassini, Curiosity, TiME, and Project M. But c'mon, if the Earth were a basketball, in 40 years no human's been more than half an inch from the surface."
-
While agree I could minimize my building style.. whats the fun in that?
Shoot you can get everywhere in the solar system on 100 parts.. but then what? the game is about BUILDING.
And alot of people are using this arguement that "it needs to be optimized after everything is added in.. I'm assuming most of you that use that argument haven't seen a piece of code..ever..
Do you think that big games like Halo add in sounds textures guns, maps ships etc.. before they get the engine running smoothly on multiple cores? HA! not a chance..
Truth is there is a difference between "cleaning up code" and actually coding the engine to work on normal computers.
Problem is, Squad isn't 'Coding the Engine' and doesn't have the capability to do so. As such they're limited to the capabilities available in the Engine. Multithreading in any capacity is not one of them. There IS a Unity plugin now to do multithreading for some things, but my understanding is that it wouldn't work for the physics, which means it wouldn't help us much.
If you want to see this happen, port a better physics engine (PhysX 3 or Bullet, for example) as a Unity plugin. Until someone does that there's basically zero chance of it happening (because Unity has no particular reason to spend a lot of time on Multithreading).
-
I have noticed that when I get this bug, the wheels are all the way out on their suspension. The whole rover goes rigid and it just jitters along until it reaches a change in terrain or flips over and makes me quickload.
Yep. I'm pretty sure the suspension is actually the cause, and is exerting actual force on the rover to try to lift it off the ground.
But seriously: Don't just post about it here, go on the bugtracker, and post it there by hitting the 'Update' button. This is the most recent (and best) bugtracker item on the subject:
How does one manage to break these?
in KSP1 Discussion
Posted
Seriously, has anyone tried Reloading the Scene? Because last time I checked (admittedly back in 0.19 or so), the OX-STATs would repair themselves if the scene was reloaded.