Renegrade
-
Posts
2,419 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Renegrade
-
-
Just now, wumpus said:
And having engine gimballing being cheaper than ailerons is oh so much more realistic? Even the kickers don't get beyond the atmosphere.
Compared to the reaction wheels, yes, yes it is. The next logical step for the reaction wheels is to give them a mana bar, and let them teleport you from place to place with a goddamn spell.
Not to say that there aren't some serious cost errors in the aero section of the game, of course (I think most of the parts are basically 500 funds because that's the default value from Harv's cut-and-paste or whatever fubar was going on at that time). But the error is probably what, 5x? 10x? That's a very serious error, but the reaction wheel error is something like 100x to 1000x (depending on whether they're actually CMGs or reaction wheels)...
-
1 minute ago, OhioBob said:
I think it is a really good exercise for somebody to figure out how to do all of that. I'm all for learning. But once somebody learns it, it seems rather pointless to have to go through the grind time after time. I love math, but for even me having to do all that detracted from the enjoyment of the game.
Yeah, once you've learned it and .. well, grok it, there's no need to keep on doing it. My main points where A) it's possible and not too onerous to do it, and B) it's a good learning experience. Well, and once you know it, it can help when your utility of choice doesn't understand a rapier in LF/OX mode or isn't available in the current version (Hello 1.1 bug squishing party!) etc.
I started doing it by hand, then I moved to scripts I wrote, then I used KER, then KER+VOID, and now just VOID with the occasional assistance from my script or quick calculation by hand if VOID gets confused or I'm trying to do something weird like calculate remaining RCS delta-v... (the script has built-in constants for LF/OX from either an LF or OX readout, monoprop, solid fuel, xenon, and even Karbonite for some reason heh)
BTW, VOID might not be as capable, but it's HUDs are much more compact and are less uh.. intrusive than KER's...
-
28 minutes ago, numerobis said:
Among bipropellent engines, the reliant is the cheapest engine per vacuum kN (5.12 funds per kN). So don't knock it as a launch engine! It's way cheaper per kN than the mainsail (but slightly worse Isp), and a bit cheaper than the twin-boar with identical Isp.
Totally agree - the price/performance keeps the low-tier engines in play long after higher nodes have been purchased. Also, it's kinda fun to use a LV-T30 or 45 in an upper stage for some crazy TWR from time to time.
2 hours ago, panzer1b said:In sandbox well yeah, certain engines (unless you actually want to use them due to aesthetics or something) are redundant and you really only use the aerospike and lv909 for 1.25m craft, all other 1.25m engines are redundant or inferior to these 2 (only if you need a gimbal would the lvt45 come in handy, but i rely on reaction wheels anyways so not useful).
^ this and this v
1 hour ago, wumpus said:The biggest issue with the reliant/swivel is that you can typically get cheaper delta-v via SRBs (especially at that tech level). Typically the rockets are small enough that the capsule torque can control SRBs, and once they burn out there often isn't a window where the LV-909 isn't the better choice.
I hope y'all realize how #lolfake the reaction wheel torque in KSP is.. >.>
-
2 hours ago, soulsource said:
What is now missing to get the form of the Rocket Equation given above, is that the specific impulse is just a way to measure exhaust velocity in a unit that is part of both, the international unit system (as used by NASA) and the old unit system (used by some of NASA's component suppliers). It's related to the exhaust velocity simply by
, where g is the gravitational acceleration at sea level of earth (measured in whatever fancy units one uses).
Actually, it's g0, or standard gravity, which is a defined number that may or may not be like gravity at sea level, depending on where you are. It won't make a big difference in hand calculations, but the correct value for any programs, scripts, or spreadsheets is 9.80665 (in metric/SI units - meters/sec^2). KSP used to use 9.82 for some boneheaded reason, but that was corrected back in 0.90 or earlier.
-
13 hours ago, OhioBob said:
Solving the Tsiolkovsky rocket is the easy part, getting the numbers to enter into the Tsiolkovsky rocket equation is the hard part. The VAB tool that comes with the stock game provides the total vehicle mass only. It doesn't break it down by stage and it doesn't give the propellant mass. To get the stage breakdown we have to start disassembling the rocket stage by stage and note how much the mass changes. The mass is also given only to the nearest 0.1-ton, which many times isn't precise enough. And the propellant mass must be added up by hand from the contents of each fuel tank. In other words, it's a real pain in the neck to do it without using something like KER. KER not only computes the dV, but it also adds up all the bits and pieces that goes into the calculation. It's the latter part that is the biggest convenience and time saver.
That's true, but it's not that hard to add up the propellant masses - the tanks are doubling in a binary fashion until you get into the NASA parts. In upper stages, it's quite easy. When you get to the lower stages, it does get to be a bit of a pain, but that can be amortized by re-using those launch stages. Improvements to the subassembly system makes this a lot easier. I played this way at first for a long time until I understood the way the equation worked, and it wasn't particularly onerous.
Note also that when I started, there was no mass indicator in the VAB at all, but it was quite easy to launch to launchpad, take notes there, and recover the vehicle. The indicator in flight (map->craft info) is significantly more accurate. That's not really necessary though, as one can simply add 0.1 to the mass of the craft and over-engineer slightly. Note that my example craft above with a .1 added to it goes from 1728 to 1684 - a three percent difference.
That being said, I wouldn't mind a more accurate readout that also gave wet/dry mass per stage..might actually be workable post-1.1 as I understand staging has been re-written (it was a Charlie Foxtrot in the past, which can confuse said mods at times).
-
+1 to all the suggestions of starting in Science mode. I'm probably biased as I started KSP in 0.22, when science mode was the ONLY non-sandbox mode, but it does serve as a passable (although not good) introduction. Definitely better than full-up career at first.
I'd advise against reading tutorials and such on the forums/watching youtube videos. I pretty much learned everything aside from efficient interplanetary transfer (and a handful of other tricks that I don't use very often) on my own via experimentation (I did have a home-grown interplanetary system, but it was awful, took forever, and a lot of fuel), plus some recollection of NASA techniques. It's much more satisfying to figure something out for yourself, or turn some dusty old NASA document into an actual KSP mission -- and I feel that this is the real magic of KSP. That being said, the INTERFACE of KSP could use a lot more tutorialization, as there's some EXTREMELY handy things that aren't necessarily immediately apparent:
- You can drag maneuver nodes along orbits by left clicking and dragging the circle in the middle of the maneuver node. This makes it trivial to get to the Mun or Minmus when used properly. NB: in 1.0 and earlier, the dragging action can be a little crappy in certain circumstances (hyperbolic orbits come to mind). It's still useful and may work better in 1.1.
- To transfer fuel/resources from one craft to another, right click one tank, and then alt-right click another, and click the in/out buttons to move the resource (I believe it's shift for the Linux editions for the second click).
- Struts are applied by clicking once to place it, and then clicking again to place the other end. Note that the mass of the strut is associated with the first click, cuz reasons.
- Kerbals on EVA can move science experiments around with right click.
- Unique experiments can be stored in any command pod (ie, you can store a seismic scan from mun highlands in the same pod as an eva report from the mun highlands, and/or a seismic scan from mun midlands, but not another seismic scan from mun highlands again).
There's some other points I'm forgetting, I'm certain... If anybody else has any control/interface tips, please feel free to chime in.
11 minutes ago, Armisael said:the pad and VAB upgrades do a good job of organically encouraging the player to build small efficient rockets
Uhh... no. They briefly encourage efficient design, and then the first upgrade pretty much opens up everything aside from Jool5 challenges and large+ stations/bases. There really needs to be more tiers.. like at least twice as many, and they should be a lot smaller increments in the early stages.
-
16 minutes ago, bewing said:
One thing nobody has seemed to mention so far is: since your rocket gets lighter as you burn its fuel -- the real deltaV of your rocket is always a bit more than what the instantaneous readouts tell you.
Uh, no, the Tsiolkovsky rocket equation is taking that into account. If it did not, they would be HORRIBLY wrong. That's why it has a natural logarithm with a mass ratio stuck in the middle - that's the calculation.
The calculation is correct. It's the maneuver nodes which are somewhat optimistic about a typical craft acceleration (wildly optimistic when ions are involved).
NB: One does not require a read-out to calculate delta-v. The Tsiolkovsky rocket equation is rather trivial to enter into a calculator - just pre-multiply the specific impulse in seconds with 9.80665 (9.8 for laziness, but I never want to see any scripts or programs that aren't 9.80665), and then multiply that by the current mass divided by dry mass (for an LF/OX rocket, every 90 units of fuel is 1t with it's accompanying 110 oxidizer). That can be updated at will when the current (or wet) mass changes.
Example:
5t ship with 180 fuel = 5t wet, 5t - (180 fuel / 90 fuel/ton=2 tons of fuel) 2 = 3t dry. Say the ship has a 909, which gives it 345 specific impulse, and thus (345*9.80665) ~ 3,383.3 exhaust velocity. 3,383.3 * ln(5/3) =~ 1728.3 delta-v.
-
6 minutes ago, ainurakne said:
I'm not really sure myself either about how it actually works, but I hope they don't just wait for the other one to get stalled and instead they're execution is more or less interleaved without the cost of context switches (and rescheduling). Getting to do your job while the other one is stalled is just bonus. Also, as I have understood, stalls are actually quite frequent.
Hyperthreaded execution is indeed generally interleaved. It doesn't have to wait for a stall to happen (although you're right in that they do happen fairly frequently), but it also means that two threads running on the same core via hyperthreading are always in contention for the shared assets of that core, and thus will be slower than the classic SMP example of running on two separate cores.
(note that 'hyperthreading' is an Intel trademark and that the generic term is 'SMT' or symmetrical multithreading)
Most of the stuff involving 'multi' is really just the chip makers scrambling desperately to justify new product sales, as single-thread performance-per-cycle is largely the same since the Pentium Pro era (like, 1996), and they haven't been able to scale up clock rate since the late P4* era (err... 2003? 2004?). There are a lot of gotchas and caveats with SMP/multi-core/SMT programming, and no magical silver bullet to solve 'em. I've posted extensively on these drawbacks before, and someone else made an excellent post about the problems with optimizing scheduling.
It's gotten so bad recently that there's no real upgrade path from my i7-3820, and that I'm looking very seriously at simply changing to watercooling and increasing my overclock as the next upgrade instead of any new core components. The only real improvement that a 6xxx series CPU would offer me is DDR4, and my quad-channel DDR3 can easily give dual-channel DDR4 a run for it's money. The 6600K I assembled for the lil lady is actually slower than my system at stock speeds (ignoring my current mild 4200mhz overclock), with only very small advantage in the DDR4 memory system.
I do kinda feel a bit sorry for 'em CPU makers though. They DO have to earn money to stay in business, and it's not like they could assess people a monthly "because we're cool" fee or some crap (unlike the new CaaS idiots -- Adobe, Microsoft, etc).
* - of course a 3000mhz p4 is more like a 1500mhz PPro-equivalent (like an Athlon XP or Pentium M or Core/Core2 etc), but the Core series chips quickly regained the 3000mhz+ clockrate of the final-stage P4s.
-
1 hour ago, Temeter said:
Did you try same size crafts to compare?
E.g. on stream was just a 250+ parts craft that ran full real time. Pretty much impossible now.
The stream I saw was flickering yellow for like forty part ships - my atom-powered netbook, which doesn't have enough CPU power to run notepad.exe, could handle a forty part ship in the yellow-red. My main desktop can handle a 125 part ship while being in the green all the time. Some of that is undoubtedly overhead from the screencapture and encoding software necessary for twitch (OBS or whatever is being used) but that's still not a strong indication of massive improvement.
Thus so far, I don't see any reason to say that Harv was wrong to be conservative (which is odd, especially after his EVA debacle). We won't know for sure until we have it in our grubby little hands, but until then, Harv's position seems wise and sound to me.
-
37 minutes ago, Temeter said:
Good ol' Harvester being conservative. :3
Btw: This is not necro, but retrospection. Please take the guns down, mods.
Actually, that remains to be seen. Nothing I saw in the first 1.1 video suggested massive improvement, and a lot of the KSP issues are intrinsic to the KSP side of the code anyways.
Also any post older than 15 milliseconds (90% of one 60hz frame) is a necro in these forums~ ARM THE BANHAMMER! NOW FOR WRATH! NOW FOR RUIN!! AND THE RED DAWN!!!! (just kiddin'~)
-
7 hours ago, something said:
So I really hope the unity 5 engine will boost the performance on my i5 integrated graphics 64bit linux system... would be a shame if it didn't. Are there any news regarding the Linux versions of the game?
This is really indirect, but on another forum, someone commented that Unity 5 entailed optimization to the OpenGL render path. That suggests that performance under Linux should improve where graphics are an issue.
It's always amazed me how bad Unity's OpenGL render path is, as Unity's two big features are 'cheap' and 'portable', and DirectX is compatible with exactly zero of those goals (DX is a heavy, moving-target API that involves a lot of programmer time overhead, and ports to exactly ONE platform - Windows). If Unity had been designed to be only available on Windows, the DirectX focus might have made more sense, but it's designed to run pretty much everywhere, allegedly...
-
8 minutes ago, zarakon said:
Will 1.1 finally fix the encounter plotting bugs?
I don't mean when you barely have an encounter and your craft's rotation or floating point precision makes it go back and forth.
I mean when I have a 100km periapsis on a Duna encounter and it's flickering between that and a complete miss for no reason. Or when I'm bringing the periapsis in closer, and the encounter just disappears even if I'm actually going to slam straight into the planet.
The second aspect you mention there is more important than the first. The rotation induced inaccuracy is unavoidable given KSP's data model, but I'm pretty sure that the slam-into-the-planet-not-showing-an-encounter issue is some special case that isn't being handled correctly that COULD be fixed...
-
Meh, the vector's not bad, but it's not some magical engine. It's only really outlying data point is the thrust-to-size ratio.
I do agree that the kickbacks feel kinda weak. If a trio of vectors and a pair of kickbacks are supposed to represent the Space Shuttle, then the ratio is way off. The KSP version has only 1.34MN from SRBs and 3MN from liquid engines, whereas the old Space Shuttle had 25MN from SRBs and only 5.25MN from liquid engines..
-
2 hours ago, GregroxMun said:
Trains don't have steering wheels. They follow tracks. You can't steer tracks. Fun story though.
Er, the only steering wheel in there seemed to be part of the Jeep unless I'm mistaken...?
-
Just now, cubinator said:
But is it still 9.82 in KSP?
Nope - that's that I was talking about -- in KSP.
-
18 minutes ago, KasperVld said:
Yay! /hype!
-
38 minutes ago, cubinator said:
deltaV = 9.82 * Isp * ln(Mfull / Mdry)
Actually, that annoying 9.82 g0 error was fixed some time ago... it's properly 9.80665 now AFAIK.
-
If you're willing (or your friend is willing) to put up with what will undoubtedly be some slow sim speeds and lack of mods etc, I'm certain they'll release it eventually.
Remember that Squad is a fervent believer in the religion of Soon™ and thus it might take quite some time for it to be released.
-
5 hours ago, nosirrbro said:
THEY WONT TELL US!!!!!!
Sure they do! They said, and I quote, "Soon™".
-
21 minutes ago, purpleivan said:
Even aliens know what's coming.
My god, it's full of hype!
-
2 hours ago, Perry210174 said:
- no fuel dumping
- no assistance for modular planetary bases (adjustable landing gears / wheels, you must drive them together and hope it will fit somehow)
Fuel dumping would be really nice (and would be trivial to implement), and I've been maintaining for a long time that the core game needs KAS/KIS for maximum EVA and base-building enjoyment.
-
15 minutes ago, bewing said:
For every centimeter, there's 10 millimeters. Why 10? 10 is a completely stupid number. "Because most humans have 10 fingers." So what? There's nothing special about base 10. Base 12 is better (if you look at it rationally). Base 16 is better still. People need to get out of their human-centric worldviews.
I like how you're accusing us of a 'human-centric worldview' while using base 10 to describe other bases to us. There's no real inherit advantage to any of the bases, aside that 99% of people will understand base 10, 9% of people will understand base 16, and a whole nine people will understand base 12.
10 hours ago, Engineering101 said:There are 12 inches (why 12?) in one foot. Theres 5280 feet in one mile (WHY THOUGH?) and 63360 inches in a mile...WHAT?
Actually it's 12 inches per foot, 3 feet per yard, 22 yards per chain, 10 chains per furlong, and 8 furlongs to the mile. It all makes perfect sense! And by perfect sense, I mean is laden with irrational legacy and is ravingly insane. Granted that modern usage tends to drop the chain and furlong and just state a mile as being 1760 yards.. Y'know, for um, reasons and uh, stuff.
(Don't forget, there's three miles to the league. Also, outside of a handful of agreements, most regions used a different length of 'mile' - some nearly as long as 15km)
I'm not a fan of progress-for-the-sake-of-yay-new-shiny, but this is one seriously rusty old system that needs to violently die.
23 hours ago, Kerbart said:Oh boy. I’d hate to sit through one of your presentations…
The benefit is “not losing your audience.” The whole point of the video is to explain something to a certain audience. An audience that has no clue what you’re talking about when you're using SI units. “Then they should learn the SI System” (note that I will not call it “metric”, that’s just as incorrect as using miles and inches). Well yes, and they should also exercise daily and stop smoking. But is that the responsibility of the video makers?
I'd hate to sit through one of YOUR presentations then. I'd have to convert the legacy units in YOUR presentation. Most of the world lives outside of the US and uses non-US measurements, eh?
-
Yes, moar news please!
News is HypeCoal to the HypeTrain! And I guess HypeWater too...
-
7 hours ago, Archgeek said:
A devnotes from a bit ago indicated that the current editor (both VAB and SPH) is comprised of like 5 competing scenes in unity, all fighting for control of the cursor, the focus, and ownership of various assets. This lead to stuff like annoying click-through, and the insane bug that cropped up when one clicked-thru the staging diagram to the exit button (KSC camera spawned low to the ground pointing in an odd direction and was completely unresponsive). It's also responsible for an amount of the editor's rampant squirreliness, like parts left floating about after undoing or struts/fuel lines sometimes deciding not to be attached anymore.
The big rebuild for U5 should bring that down to just one scene, unless it was two, I don't quite remember.
Ah, yes, I recall that now. I'm definitely on board for fewer clickthrough issues and bugs and such. That improves my hype a bit, thanks!
Delta V question
in KSP1 Discussion
Posted
Since the specific impulse / thrust relationships in KSP were fixed (in uh.... 0.90? 1.0? I forget when), it's a lot simpler now to calculate a hybrid rocket - fuel flow is now invariant with altitude for non-jets. Just average out the thrust and ISP for as long as the SRBs are burning, and then calculate from there as a discrete staging event (er, well, I guess it IS a staging event). Although with some designs I've seen and used, if the SRBs are a small enough percentage of the stage mass-wise, you can pretty much ignore 'em and be happy that you have an extra 50 m/s from 'nowhere'.
Um re: your latest post - I don't see that as craft delta-v changing due to gravity drag/losses. I see that as the delta-v requirement changing instead.
Nice chart BTW, but if you're doing plane changes in LKO to go to Minmus, you're doing it wrong, heh. It's better to do the plane change out beyond the Mun's orbit, or wait until KSC is at Minmus' AN or DN and then launch directly into Minmus' inclination (I prefer the former technique myself as I don't like waiting on AN/DNs, as that might result in an evening or before-sunrise launch, and/or might result in over-warping. KAC doesn't exactly have a "warp until KSC is at Minmus' DN" button AFAIK).
Here's a really hastily thrown together example of a post-Munar plane change (it's actually a terrible example, but it should illustrate the point I'm making well enough):
Ditto - totally agree here too
I've actually done some missions that are like that (early Mun tech BTSM missions pretty much require a semi-Apollo approach. It's only a single stage lander, but you don't bring it back), and the utilities did indeed fall short there.