Renegrade
-
Posts
2,419 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Renegrade
-
-
I'd personally like to see a proper Pluto-analog. Eeloo is way too close* (6.3 Kerbin AU vs 39.5 Earth AU semi-major axis) and lacks Pluto's small moons/large rocks collection. So, let's throw Eeloo into a much larger orbit, give it some friends, and make us some serious deep space / New Horizons-type fun.
(I'd also like to see more/better details of the existing planets too, plus some fixes, like eliminating the invisible walls on Pol and gaps in the meshes of all worlds..)
* - Eeloo tickles Jool's orbit, which is a fair approximation of Jupiter's orbit - Pluto dances around Neptune.
-
The dV meter ... or better said, the lack of it in stock. I can't find a rational reason for not having it besides adding artificial difficulty to the game disguised as a incentive to experimentation. Really, the same game devs that make manouver nodes that give dV count and burn times ( so they actually made the game do half of the math needed ) refuse to make a dV meter ...
Meh, I think they just realize how tricky it is to have an in-all-cases-correct delta-v readout (consider the number of glitches that can happen with the mod ones, despite the fact that they're (undoubtedly) far better than anything that will ever appear in stock), and don't really want to have to deal with it.
Never attribute to malice that which can adequately be explained by laziness, I guess?
-
Uh, the current demo (well, as of the last time I installed it) is "v1.0.0.813 Demo" - that's not 0.18.3. It's some early version of 1.0. I recall that it's missing a lot of the 1.0.x features/fixes and also has a microscopic tech tree...
-
Don't get me wrong; I'm not criticizing your efforts to write something that looks aesthetically pleasing; I've seen to many 3.1415E17's on this forum (instead of 3.1415×1017) to complain about that; just trying to make what you write even more awesome.
I take a bit of exception to that; you can paste 3.1415E17 into C-derived languages* as a floating point literal, whereas 3.1415×1017 is definitely incompatible with just about anything outside of vBulletin. The E notation isn't as stylish, but it's more useful.
If you write it as 3.1415e17, it's not only compatible with C-derived languages, but also Windows Vista/7's calculator (and possibly others too). You can throw in a + there (3.1415e+17) and make the visual gap bigger if so desired (I do think it looks better that way, and it's compatible with gcalctool that way) and retain all the above compatibility.
* - I've only ever really worked with C (and the vast majority of C things work in C++), perl, java, and C#/mono, but I'd expect most of the rest of the C-styled languages to support these notations. Also I've noticed that all three formats work with LibreOffice Calc..
-
Something like "P.S.: Jeb, I ate all the Snacks ~Bob", right?
Not sure about the mk3 monstrosity, but the Cupola definitely has a note like that.
-
a mining drill... maybe theres ore in the vab, who knows
...now I have to try that to see if it works heh.
-
Overcast in T.O. region, so no dice.
I had my old 40D ready with a 300mm (480 after crop factor; it's a cheapy Sigma, but it gets the job done) lens for it too...
-
This is my "Tower of Power" unit, used for supplying fuel and power for permanent installations on atmospheric bodies. The tank and thuds are just landing gear, removed via stack separator, then picked up and disposed of (KIS).
...is it just me or does that look like a virus?
-
.....or just mount the decouplers high on the booster, and let the air resistance catch 'em and fling 'em away for you?
-
hopefully KSPedia will fix that.
Agreed! Not going to board the #hypetrain on that though, hope leads to disappointment, which leads to anger, which leads to the dark side, I've been told
Also - it has an issue where sometimes it doesn't register the click. I'd initially assumed it wasn't a thing until Awaras pointed it out.
Yes. Dead useful, stupidly obscure, doesn't work in map view despite the widgets looking the same.Actually it does work on the map view. It sometimes doesn't work (possibly due to the navball bug, possibly due to lack of control - I haven't tested to isolate what causes it), but there are conditions where it definitely DOES work.
-
Here's what I want in a save system:
1) Autosave every X minutes, where X can be set by the user, or disabled entirely.
I've been considering scribbling up a simple external utility to do this. My own games I've scribbled up generally have a save backup system much like that, although I use my weird binary timestamp instead of something entirely human-readable (it's human readable to me though, heh).
Binary time:
$ date;datestr -h
Wed Sep 23 17:58:38 EDT 2015
2015-09-23_bfc
it's 0xBFC of 0xFFF right now. That's a lot shorter than '17:58:38' (3 chars vs 6-8)
Good point. That does make more sense.It's also ISO standard 8601 (and is self-consistent with the time, which generally puts the slowest-changing/longest timespan number first). Also works rather well with command line utilities (doubly so with things like bash shell globbing). del blah_2014-* (delete everything from last year; cmd.exe), tar cvfz monthly.tar.gz blah_2015-??-01* (the data saved on the first of every month; /bin/{ba,}sh), etcetc.
-
Yeah, it's a well hidden feature. It works from Map View as well (although there's some restrictions).
However.. this sort of thread pops up from time to time.. We talked about it in the BTSM thread, and there's been some talk in General as well.
So basically .. this gets 'discovered' from time to time, due to it's hidden nature and KSP's kinda poor documentation. Hooray for poor documentation!
-
I much prefer the current Lab system to the one we used to have. Automatic science generation while warping is much less fiddly and overall more fun than a tiny % bonus to each individual science transmission. Also it allows more freedom in spaceship design when the Lab doesn't have to be carted along to every landing to maximize science.
I made heavy use of the lab before 1.x - you don't have to bring it down with the landing craft. It's perfectly workable to leave it in orbit and rendezvous with it later.
Of course I rarely used the %-transmit-boost stuff, I just used it to reset the one-shot experiments and took the results home at the end of a biome sweep. I try to avoid transmitting things that aren't 100% transmittable unless there's duplicates or such (ex, having two goo pods for balance results in a duplicate result that I'd transmit).
Now in 1.x, I don't do biome sweeps anymore at all, as the science lab pretty much finishes the whole science tree for you. My last big save had a Duna lab that must have yielded something like 30,000 science (well, whatever tiers 6-9 cost + 6500 or so science) and it had only gone through a handful of the science bits that I'd recovered from the Duna subsystem.
Also I'd like to say that the science lab sci/day bit doesn't seem to be sensitive to the Kerbin/Earth locale settings. Tsk, tsk.
-
Yup, thats true. But a burned out Sepatron weighs only 0.0125t and you only need one of them per Booster.
Other designs need two or four of them placed left and right on the Booster.
Some People manage to do it with one the top of the Booster or just above the radial decoupler which would either give spin the Boosters bottom inside or the burn the center Stack.
Er, the dry mass of the sepratron is only half the story - you aren't launching with 'em empty. Plus, they are most likely adding some drag too.
Anyhow, I try to avoid using them if at all possible. You can get away with not using 'em pretty easily in a vacuum obviously, but you can also often get away without 'em by mounting the booster low on the decoupler (or sliding it down with the linear tool). That way, the impulse from the decoupler pushes the nose of the booster out more than the tail, and the new-aero lifting-body effect catches the side of the booster and flings it away essentially for free. This is of course easiest with user-built liquid fuel boosters, as they tend to be bottom heavy anyhow.
That's also one of the (many) design flaws of the Kerbal X rocket - the decouplers are mounted very low.
Also, the Energia way is a good one: Have a few sepatrons on your slanted 2,5m-1,25m adapter or the nose cone, facing retrograde. This will push the boosters in the 'retrograde and out' direction.
If I do use seps, that's usually what I do..
-
No offence but didn't I already say this a week ago in post #3?
You said, "as far as I know", which doesn't really tell us anything about testing or presence or absence of mods etc, so, no.
I've tested a pure stock install, and and now a pure stock + Asteroid Day install (I checked out about 70 rescue contracts, to match my prior 'heavily modded' sample set in both new cases).
-
I've followed up with my testing - installing Asteroid Day on the stock install (which had proper-seeming distribution prior to Asteroid Day) definitely causes it to change to all-female.
Anyhow, my best-guess programmer-gut-feeling is that Asteroid Day is causing some bias to occur somehow (either that or clobbering a value).
-
Anyhow, it sounds to me that while isolated cases of Kerbelle Space Program could occur, the sort of endemic instancing we're seeing here makes it seem statistically improbable. Especially the aforementioned 70:0 number.
I love me some rescue missions. Why upgrade the Astronaut Complex past the second tier and pay for kerbals when missions appear that pay YOU to receive a kerbal, which also bypasses the max kerbal limit
I've since played a stock game a bit (as in pure stock, no mods at all) and I'm getting males and females on rescue missions. Next, I'm going to install Asteroid Day and see what happens.
(I stand by my theory that it's a cyclical bias of some kind)
-
Yeah, but the under the hood rebuilding should add something tangible.
I'd reserve judgement on that too until we see it. I've followed some other games through U5 updates and they had kinda mixed results. The dev blog about the changes to heating sound.. computationally expensive, and changes like that could wipe out any speed improvements.
Hope for the best, but expect the worst. That way, all of your surprises will be pleasant ones~
-
Q: What will 64 bit do to the game?
A: [We all know that answer.
] No physical changes. You won't notice much [except I assume performance on large ships] for non-modded games. Modded installs will notice they can mod a lot more64-bit won't help performance one tiny bit. It'll just let you add tons of texture-heavy mods. Even a thousand part ship isn't using up much in the way of memory...
Most of the purported advantages of 64-bit are generally overwhelmed by the increased data load (especially with 'modern' languages, which tend to be nested webs of virtual pointers, which are all now going to be twice as long), and the rest of the 'advantages' are actually just the 'advantage' that a programmer can enable optimizations for specific features without having to worry that a 486 doesn't have SSE support (which can also be done by specifying a later-generation CPU as a minimum).
Most of this 64-bit rah-rah comes from two sources:
1. The marketing departments at AMD and Intel, for what I assume are obvious reasons.
2. Old timers (or maybe a kinda..genetic memory) recall the 286-386 (or 68000-68020) era, when jumping from 16-bit systems resulted in huge improvements in performance. However, most of those improvements were because the 286 (and 68000) had a 16-bit data bus, and the 386 (68020) had a 32-bit data bus, and many data objects were 32 bits in size (multi-word instructions, far pointers, floating point values, etc), and also as the newer generation processors had much shorter execution times on common instructions. When the Pentium was released, it had a 64-bit data path (save for some of the special chips, like the Overdrive units that go into 486 boards), and CPUs have largely had the same IPC values since the Pentium Pro, so any step from a 32-bit to 64-bit environment will be a fairly subtle change as the data paths aren't going to get better, and nor are execution times.
All of that being said, I am looking forward to not having to sheepdog the damn memory counter for KSP in the task manager constantly. Hopefully they'll nail some of the memory leaks too; that'll give me even more playtime.
-
LOL! Well not much more to say other than give a nod of respect to you, Renegrade. I do enjoy these types of debates (or else I wouldn't have gotten into IT in the first place) and it's good to meet someone else in the industry on the forums.
Likewise! Although I'd say it's been especially interesting due to the fact that we're from somewhat different backgrounds (Academia vs Corporate, Desktop vs Back End, etc). Always interesting to see those differences. Like the concept of the coddled god-babies or having OS X machines around, etc. I'd not normally think about such things as they don't come up much/at all in my end of things.
-
in the game I'm making (should hit the appstores within the next few weeks) - we've devised a somewhat intricate "biased random" color selection system -- this was done because "actual random" simply proved to feel "not random enough", and gave us no options to fine tune each level's difficulty (it biases both ways, mind you)
I generally use a Knuthian shuffle for any of my random game-development-ness, you can effortlessly stack the deck with those, and guarantee short term distributions.
but much like there are families of 5 children all of the same gender, a localized truly random sample group has a large tendency to appear biased - especially given our human disposition to see patterns, even when they're not thereWell, in my last few stock-ish games, I've rescued about 70 Kerbals. 70 of the Kerbals were female, and 0 were male. The odds of that happening are 8.47e-22. That's like three games, no boys aside from Bob, Bill, and Jeb.
I'm not sure if Asteroid Day has something to do with it or not (I usually do have that installed, I like the big fixed panels); but it strikes me as rather unlikely that I'd be getting a 70:0 ratio (that number is really durned close to being Avogadro's number inverted, geez).
As a counter example, this simple throwaway code:
#!/usr/bin/perl
$m=$f=0;
for($i=0;$i<25;$i++) {
if( int(rand(2)) )
{ print "Male\n"; $m++;}
else
{ print "Female\n"; $f++;}
}
print "$m/$f males/females\n";when run 20 times, resulted in roughly equal distribution. Only once did it favor one gender, and that was a 5/20 split (with the longest run being only 7 females), not a 0/70 split. And that isn't even cautious use, a really poor quality system rand() could really mess that code up.
I suspect that Squad's code looks something like this:
Name_and_Therefore_Career = MakeAStringFromANumber(rand());
Gender = rand()&1;
You can end up with some nasty bias that way. Throw into the mix that contracts are being randomly generated, probably from the same pseudo-random-number-generator state, and you could very well end up with a situation where a given type of contract could only have a given type of gender because of some bias in the PRNG.
Of course, C# might have a rand() call that ties in with any hardware RNGs, which might allow it to ditch any evil bias it normally has in software mode (also it may vary per underlying OS or OS version etc, with some versions having less than stellar properties).
Maybe I'll throw together a pure stock game to see if it still happens..
(Interesting tidbit: I used to hire kerbals with low stupidity to run my labs as scientists (a bit of RP there, there's no real benefit it seems), but after kerbals had careers, I'd noticed that scientists offered for sale were generally always stupid :/ )
-
Re-reading your previous post about the monthly patch cycle and firewalls and such, I'm not sure whether you're arguing that Windows is insecure and we should all move to Linux, or if it doesn't matter because of firewalls.
In a word: yes (or say.. 'both'). The presence of firewalls (especially at a personal level, where the LAN is enormously more secure) negates much of the need. However, switching platforms would get rid of the issue 99% of the time (only kernel patches need reboots). Having/doing both is even better. Defense in depth!
(when 7 is retired and I finally switch over to a Linux desktop at home, I'm going to have both then universally. Right now, just my home servers are Linux-based)
My position is simply that zero day patches are released out of band for a reason (they're more urgent) so we mirror that level of urgency. I'd rather suffer a reboot than get compromised.Given those two and only those two options, I'd pick the same way. I'd want a third option though. A reboot could involve data loss, and there's no guarantee that the patch didn't cause more problems than it solved (MS15-097 for example; I hope nothing I use is impacted by this one..sigh)
By "Enterprise" I mean that, for example, licensing is handled by a server, like KMS or Flex_LM.I don't think I need a server to tell me that GPL or modern BSD or CC or Apache licenses are all currently valid and will remain so forever.
Anyhow, I've found that a lot of these "Enterprise" solutions end up happening kinda like this: You get an "enterprise" class AV, and it takes just as many man hours to handle as "non-enterprise" software, as the damn thing breaks down, refuses connection to the master server(s), and you have to dispatch technicians to work on every workstation to install some last-second hacked-together patch from the so-called 'vendor' (I'm not specifically referring to Symantec *cough*). Thankfully that was a big "SEP" there, although it was rather amusing when the technician tried to install it on my Debian workstation of the time.
By the way, Apple is terrible at considering Enterprise level needs, but we support them anyway because end-users want it and/or need it, and Macs cost us three times as much (in technician time) to support.I always suspected that would be the case heh.
This is totally the difference between corporate IT and higher-education IT. At a university, the IT department has WAY less weight to throw around. Faculty members are like gods (that, or babies that you have to coddle). It's maddening, but you definitely see an adjustment period for technicians we hire that are not used to this environment. And sometimes end-users have to interface with external constituents that can force them to buy the prevailing industry standard. We have one department that just had to lay down $17,000 PER YEAR for Adobe products even though technicallyalternatives exist, because they have to send those files to another company.Again, here's a difference between corporate and higher-education. Mac OS X is not only permitted, but it's rampant. Yes, we do have to haul users onto a new OS that has a different interface when the vendor drops support for old ones, and for some of them it's dragging them kicking and screaming. We avoided upgrading anyone to Windows 8 because of this consideration. Office 2007 (not an OS obviously) was probably the worst upgrade that I can remember because of the ribbon interface.
Okay, you definitely live in a terrifying world. :S
If I ever get a job to directly work for an academic institution, I think I'll pass. :S I've worked indirectly for such organizations before (their IT departments were customers of ours, I went to school in the long-ago, etc), but I've never been exposed to the internals.
I had a brief thought after reading the above that I might actually qualify as one of those coddled baby-gods..but then I realized that in all of my programmer roles, I also performed my own IT duties heh. Most of the places simply offered up a beige box and a DHCP lease and the rest was up to me (if I declined the XP-running-IE6 corporate special heh).
-
Multithreaded applications have been the norm for a long time, and even back when the user generally only had a single core, it was worth it, because most threads spend a majority of their time waiting for things to happen (data read from a disk, input from a keyboard, etc), the CPU can get on with other things while a thread is waiting.
Actually, mostly because most programmers can't wrap their little minds around asynchronous design. select() has a timeout, y'all!
...and it's not like blocking on input is going to shut down the whole OS. Just a single process (and most processes don't actually have anything to do when waiting on input or data anyhow). Well, assuming you aren't under OS/2 and ignoring input events or something.
Thank goodness it's been a long time since we had to deal with that kind of nonsense.I wouldn't sound so relieved, it's just getting replaced by a whole different set of nonsense.
-
What bothers ME about the stock fairings is that it seems to have some rather angrily fixed snap-to behavior. The regular VAB controls (ex shift) don't seem to help with that either...
Well, that and the bugs (things that are 'inside' which are not, the engines not firing if they're "contained", weird heating behavior, etc). I'm assuming for the sake of this thread that the bugs will eventually be fixed (not holding my breath though~).
Anyhow, the concept is a good one, but the implementation is falling short.
] No physical changes. You won't notice much [except I assume performance on large ships] for non-modded games. Modded installs will notice they can mod a lot more
What are you doing until 1.1?
in KSP1 Discussion
Posted
What am I doing while waiting for 1.1/1.0.5?
Waiting for 7 Days to Die Alpha 13~
I still do that when new releases come in. I own both versions (Steam and Squad Store), but the Squad Store tends to be a little slow on release day (although it's been better in the 1.0 era than pre-1.0), so I usually just branch off from the Steam version (which, as it happens, is on sale right now) for the first few days. As sal_vager says, there's no DRM on it (yay!), plus it loads all assets from a relative path, so it's highly compatible with that sort of installation.
Are you starting it from the KSP.exe (I've heard that the launcher doesn't work so well these days, never used it to be honest)? Are the permissions okay?