Sandworm
-
Posts
1,009 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Sandworm
-
-
After being away from KSP (ctd bugs) I'm starting anew. As usual, my first priority is getting KScale64 working (aka 64k). I had some issues with Kopernicus and Sigma Dimensions but figured it out. Then I noticed this.
Were not all of the easter eggs previously hard-coded? I never noticed this monument before. It was always buried. Are egg positions now scaling along with the rest of the planet? To VALE!
-
Question: Is anyone else having trouble getting kopernicus to load Kscale64 or other resized kerbins?
I've got a bare-bones install (Stock+Kopernicus+Kscale64) but it just wasn't loading. Kscale64 is mentioned in the logs.
Fixed: I installed sigma. Was Sigma Dimensions meant to be bundled with kopernicus?
-
39 minutes ago, Anth12 said:
Just curious...was it a bug related to the steam controller?
GOG takes a day or two to update. They have a system of checks that is out of Squad's hands. So if they are a version behind that is probably the reason.
-
53 minutes ago, Tricky14 said:
Is there a mod that plain removes those Squad monoliths?
Yes. As their locations are hard coded, any resized version of kerbin will bury them. I haven't seen a monolith, or any other egg, in years.
-
1 hour ago, teag2 said:
Oh, please. I'd give money to play KSP with Squad.
Yup. I used to work in film/TV and there were always lots of young people ready to do anything to work on a big production. We paid them nothing, treated them like dirt, and replaced them the moment they complained. Except the pretty ones. Those we kept around, at least until they had a falling out with someone on payroll. It was a sour culture and is why today I see red flags whenever a company asks fans for favors.
-
Just now, JJE64 said:
Actually, to agree with some of the others, I rather like the idea of creating a "malfunctions and other problems" area. It would give people a place to seek help/vent/ragequit without cluttering up the General forum and invading some folks' safe spaces. You could venture in there if you want to commiserate or try to help, but it could also serve as a DMZ for those who suffer from counter-complaint derangement syndrome. It would also give the devs a way to collect and examine in a macro scale the most obvious and pressing issues users are facing without having them scattered throughout the forum. It may not be as directly helpful as a well written and properly formatted bug report, but if they can go on there and see a trend of complaints about gripe X, it could clue them in that something is amiss for some folks. It would also possibly clean up the endless stream, of frustrated posts that seem to accompany every devnote tuesday posting.
I think it's a capital idea.
Or, like areas dedicated to suggestions and such, doing so is simply another rule to sideline "negative" remarks to a place where that can be more efficiently ignored. Such oubliettes are convenient, but not a long term solution to addressing legitimate concerns of the community. They also create the temptation to expand the limits of forbidden discussions under the guise of rules, "categorization" rather than overt censorship. Either way, the result is the same.
-
Lol 500. That's still noob territory imho.
I'd throw my hat in but sadly am nowhere near LA. But I'd also want to know the pay structure. If this is another effort to crowd-source some free QA testers, I suggest that fans stay away. Demand payment for the services you provide. And I would suggest everyone take a close look at California minimum wage laws before agreeing to do anything.
-
17 minutes ago, Matuchkin said:
1. Complaining about someone complaining about someone complaining is CHEATING!
2. There is a difference between complaining and calming others. There is nothing wrong with what OP did.
Every person here complaining about all the complaining is a person that isn't playing KSP atm. That's a message to Squad, readers researching whether to buy the game and, most importantly, the all-seeing Google spider. Posts here expressing frustration with the game, community, Squad or anything else are valid information for those deciding whether to purchase and/or recommend KSP.
-
22 hours ago, Terwin said:
1&2
Like Squad telling us that the wheel/landing leg problems are related to Unity issues that they have not been able to work around and may require waiting for a new Unity version?
How about telling us that they fixed every CTD that they could reliably reproduce. (indicating that there were some CTD bug reports they could not fix because they could not get it to happen locally)
3) Volunteer testers are not generally in a good position to determine when it is in the best interests of a company to release the next version.
Setting marketing and financial reasons aside, 50%+1 of the testers could easily get over-excited with a new, not quite finished feature, or hold out for a version that has every feature that they deem important. After all, how many people will volunteer to play-test a new version of a game that they do not already have strong feelings about?
4) Which major bugs has Squad not acknowledged? They acknowledged wheels/landing struts(Unity issue), Random CTD issues(fixed all the ones they could reproduce), Orbit decay(Bug fix that took an issue from 'small but only annoying' to 'tiny but potentially serious'). The only other issue I have seen (unable to move research window) is probably mod related(I have dozens) and not annoying enough to even work out which one is causing it.
Wheels we even knew about before the beta-test period started
I am not saying your ideas are bad, but what have you asked Squad to do that they have not already done, aside from handing over full control of the release cycle over to volunteer testers?
(4) It depends on what you call a bug. Some of the SAS silliness and inconsistencies have been around for so long they are now "features". Difficulties in placing maneuver nodes seems eternal. Gittery/random trajectories are here to stay, despite being "fixed" by multiple updates. Anyone who has played KSP for more than a couple years has grown to ignore these issues. And let's not even mention the various graphical anomalies that come and go depending on your hardware.
-
Linux here. Rock stable in 1.0.5. I often remarked that KSP's linux build was one of the most stable pieces of software I've ever seen ... more stable than some standard office applications. But now in 1.1.2 I'm getting ungraceful CDTs randomly. Sometimes after only a minute or two in the VAB. CTD is rare in space, but still happens. It got frustrating and so I've shelved the game. I only drop in here every couple days to see if there is any hope of Squad addressing the issues. I fear not. I'm not sure they know how.
-
21 hours ago, TheRag said:
I used to play this game a lot, but now, I cannot reliable play it anymore due to the CTDs in the VAB/SPH and the Orbital Decay bug, wheels, and landing gear. 1.1.2 just feels sloppy, not in the true KSP fashion or quality. It's feels like KSP is trying to grow up faster than it's supposed to and it's disfiguring it.
Frankly I probably won't be able to play until whatever is breaking the game is fix Squad-side or Unity side. Which means waiting until 1.2, when I was promised that 1.1 would a new golden era for KSP. I mean we waited for entire year for this and came in underwhelming successor to 1.0, now I have to wait another couple of months to actual get to play the game again.
I think a lot of people are dissatisfied. I still like the game, but if I can't play it, it really does help me like it all.
The point is that I am dissatisfied as a customer, I expect to least have the ability play my product that I paid for, no matter how much I used to enjoy it, nor how much I had played it.
Lol, a couple months. Really? 1.1.3 could come out in the next couple weeks/months, but I doubt it will be more than a wheels patch. There are some bugs with Unity that Squad cannot address easily with their current setup. While they may have technical access to the code that needs fixing, I doubt they have the resources to work out the specifics of a hardware or OS-dependant bug. Even if they were willing, spinning up a testing lab from scratch takes more than a few weeks. With each full release taking longer and longer, I'm looking towards Xmas for any fix.
-
Working hard and not being "incompetent" are the minimum for any business. But you can be a genius, work very hard, and still churn out junk. I would like to see squad up their game by hiring a proper QA team. That doesn't mean a handful of recent grads "playtesting" on their home machines. That means an array of hardware/OS combinations in a lab environment, a regimented and scientific approach. That means getting ahead of bug reports. A community-reported bug should be seen as a failure, a bug that wasn't detected in-house prior to release.
From the plethora of bugs, including those that have been with KSP for a year or more, I suspect a morass of technical debt is home to roost. Continuing the same scheme that built the debt mountain isn't a solution. "High fliers" need to have their wings clipped and be replaced by a strong team dedicated to code review.
-
2 minutes ago, drhay53 said:
This is surely true; I haven't done a lot of thinking about what DoD telescopes would be looking for. However, they almost certainly wouldn't be turning a UV telescope in space down towards the earth. The Earth's atmosphere heavily absorbs UV light, which is why UV astronomy cannot be done from the ground. Still, your point is correct that if you're wanting to observe in a very narrow filter and yet still get high resolution imaging, you'd need a lot more light gathering power.
Unless the target is something like a missile climbing out of that atmosphere. Against the dark UV-absorbing background of the atmosphere, an SRB plume might stick out even if 90% of it's light is absorbed.
-
51 minutes ago, drhay53 said:
I'm fairly sure from the people that I've talked to (I have many collaborators at STSci) that at least some of the DoD telescopes are of the unfolding design. That doesn't mean they're as large as JWST, and certainly wouldn't need to be as they aren't trying to detect galaxies that are 12+ billion light years away
The size of the mirror is dictated by how much light you need to see the thing you are looking for. That in turn is dictated by which frequencies are emitted by your target. Galaxies cover a relatively broad-range, but I would not be surprised if DoD sats sometimes look at a very narrow range, requiring a larger reflector to gather the needed light. Specifically, ballistic missile detectors might look for the unique UV light emitted by solid rocket boosters. That in turn could define the chemicals used and therefore the missile type, and important fact to know before reacting to an unexpected launch. A narrow frequency + very small target = big optics.
-
2 hours ago, spacegardener said:
Same here. Quite annoying. :-(
Same here. on 64bit Linux, if that matters.
-
4 hours ago, DMagic said:
@Sandworm Are you looking at the SIGINT.cfg file? That is for the old version, the 2.5m inline part. The nosecone version is in the electronics node, the new 1.25m inline version is in the miniaturization node.
As for the accuracy of the dish, I might worry about that more if someone could find actual, concrete information about any of these satellites, or even just more than one source for all of the diagrams. All we know for sure is that the design of these satellites have grown significantly over that past 50 or so years, they are enormous, there are a lot of them, and they tend to use whatever is the biggest launcher at the time. There were several classified shuttle missions that supposedly dropped these off (and used the same type of booster as the Galileo probe to get into GSO), and more recently they seem to have made up most of the Delta IV Heavy launches (along with a few KH-11 telescopes).
Given how open the NRO has been about their telescopes (they put a KH-9 on public display for one day a few years ago) it seems a little bit surprising that almost nothing has been released about the signals intelligence programs. As one of your pictures demonstrates, the basic technology behind really big satellite dishes doesn't seem to be a secret, it is used in communications and radar science satellites.
We actually do know lots about the big geostationary stuff. They use the same tech as the communications satellites. If you want to spy at a particular frequency, then you use an antenna very similar in construction to those communicating on that frequency. The spy sats for many years were simple "bent pipe" rigs, exactly the same as any other com sat (they beamed down to either remote australia/canada). Now they are encrypted, but they still just bounce the signals back down. The shape of fairings also indicates a similar packing regime.
http://www.isro.gov.in/gslv-d6/gslv-d6-gsat-6-gallery
http://www.boeing.com/space/boeing-satellite-family/#/gallery
Some of the stuff closer to earth has actually been imaged from the ground, note the asymmetry very similar to the Boeing say with the big antenna. (The lacrosse sats are interesting because only a spy agency would have any need for such an antenna so close to earth.)
https://leaksource.wordpress.com/category/nro/
As for the optical sats, I think it safe to assume that they are tubes, with a big mirror at one end, large enough to fit inside the shuttle and/or whatever fairing they launched in ... very Hubble-like.
As for the nosecone version. The cfg appears correct, but it isn't appearing anywhere on my tech tree. I'll have a look around and try to figure it out.
-
I like the dish. It is impressive ... but it took some fiddling in cfgs to see it,
"TechRequired = Unresearcheable" Deliberate?
-
11 hours ago, DMagic said:
@blu3wolf Yes, pretty much. Though I added a transmitter module to it later on, since it seemed silly to have such a big dish that couldn't transmit at all; it does use quite a bit of power.
The real thing supposedly needs a two relatively big solar arrays for power, but I have no idea how much power those would actually provide:
I love and use this mod, but with respect, that isn't what spy sat antennae look like. They stopped being symmetrical many years ago. Today, the standard config for large sats (GTO stuff) is for the large reflecting dish to sit beside the main body which holds the receiver and solar panels. The above pic, with panels separated by such a huge distance would never happen. I suspect it was drawn up for a media release and is deliberately dissimilar to any flight hardware. Why does is have a CIA label? That isn't normal. It should say NRO, the people who actually launch these things. It appears to have been drawn by some outside company/person, hence the copyright claim.
-
55 minutes ago, Alshain said:
That's not how it works. KSP uses Unity, Unity runs on 3 operating systems, KSP runs on one engine. They aren't developing 3 different versions. Unity also supports the consoles, Flying Tigers job is most likely to make it work with the console's control style for the most part and iron out other little details that come with porting a game.
There may be some exceptions in some areas but for the most part, it's one code base for all of the games versions.
Remember the linux mousewheel bug? Or the current spat of Linux crashes? See the number of OS-specific bug reports? The codebase may theoretically be the same, but all the testing/qa (the bulk of the work) involves three streams. A fourth or fifth can only delay Squad's already glacial process.
-
On 5/16/2016 at 3:22 AM, eddiew said:
I agree with @Majorjim in general - but once you reach the level of an overclocked i5, there's not a lot of point in spending more. i7 doesn't help KSP at all, nor does it really matter if you have this year's CPU or one from 4 years ago because improvements have been so incremental.
SSD for boot speed. Mechanical hard drives just don't handle heavily modded installs very well.
Vsync doesn't cause lag per se, but it will cause you to snap to divisors of your monitor's refresh rate. Example, if you have a 60Hz screen and your computer is producing 40 fps, it'll have to drop down to 30, because it isn't allowed to render a new frame every 1.5 refreshes. If you can only do 25 fps, it'll slow to 20, 19 will come down to 15, and 14 will come down to 12. This tends to exacerbate the lag caused by a machine that can't keep up and makes the fps drop seem worse than it really is.
You can help alleviate this with a higher frequency screen, or going for FreeSync or GSync, which allows the monitor to refresh whenever a new frame is ready, meaning that 25 fps really is 25 and not 20. Alternatively, you can increase your physics delta time in the game options, which will make your clock turn yellow or red more often, but will keep the actual on-screen fps higher and give you a smoother feeling, slower, game.
I disagree with spinning drives not handlings large installs. They certainly do not load as quickly, but KSP is special in that everything is stored in ram. Once there, there isn't much difference.
-
56 minutes ago, ag3nt108 said:
I don't see a problem with having a version of KSP on every platform. Port it to iPhone if you can. The more popular and larger the sales the more likely Squad will be motivated to continue developing and adding content.
I do, many problems. Squad already has difficulty enough trying to serve the three versions it has on the go today. Also, I don't want mobile game-style UI decisions appearing in KSP. Giant flashy buttons and other touchscreen adaptations would be very out of place in such an exacting game.
And imagine the state of the forums once umpteen thousand iPhone kids start complaining about this and that little mobile-specific bug. It would monopolize every conversation. Desktop users have thicker skin.
-
4 hours ago, psamathe said:
MechJeb is precise, but it only optimizes for flyby intercepts (i.e. optimizing the departure burn). TWP is the only tool I know that can also take into account a capture burn - for some transfers it does not make that much difference, but for something like Kerbin to Moho there is a big difference, as the capture burn is where most of your dV is used - you can save 1000s of dV using TWP transfer windows in this case.
Not just that, but MJ doesn't accommodate less-than-optimal planning. If you are playing with any LS mods, time is a factor. Sometimes you want that sooner window even though it requires more work. Or sometimes you just want to optimize for travel time rather than energy reqs. (I may be wrong about this, it's been at least a year since I last used MJ).
Also, it's MJ. Those who dislike it (me) really don't want it on our screens 24/7 just for launch window planning purposes.
-
(1) Career mode is all about grinding out quick contracts. Going a long way takes time. So you "win" much faster by staying near Kerbin. This is a vanilla game design error imho.
(2) We lack many of the tools necessary to travel interplanetary. There is no in-game launch window planner. There is no in-game DeltaV information. Without such things, travelling into deep space is at most trial and error, but on average suicidal.
But maybe that will change with the Transfer window planner mod is updated.
-
Skip the VR. KSP is a much better candidate for shutter glasses-style 3d rendering. All the 2d and 3rd person perspective (90% of KSP) are easily rendered in non-VR 3d.
[1.8.1-1] [PLEASE FORK ME] Kopernicus & KittopiaTech
in KSP1 Mod Releases
Posted
Ah, thanks. The KScale64 instructions don't mention the need for sigma and I didn't ever remember installing it separately. Live and learn.