Green Baron

Very impressive @Epox75 ! And, yes, it is sub-millimeter work to get the right distances. But it should be in an epsilon distance around the calculated distance from scope focal length, backfocus of camera and the corrector's datasheet. And a newton might need recalibration during a session from what i heard. All my elements in the queue between camera and telescope/corrector are 2" (m48) thread and t2 adapters at the end. In between is a filter drawer for 2" filters. And i got this element for fine adjustments.

You switch SCE to AUX :-) (Apollo 12) It is probably anything between nothing happens, the charge just flows off, and an rud because of multiple breeches and holes welded in the hull by the strong current. Like with aircraft, mostly nothing happens, but sometimes things go bad. Lighting is unequal to lightning, and depending on weather conditions the charge can dissipate, collect over the surface, weld it's way in the interior, destroy electronic equipment ... whatever you want.

Thanks for the forecast. Question: how risky is just rain ? Or is it more gusts or the chance of a lightning strike that they are afraid of during rocket launches ?

I'm so jealous. Every night when the sun goes down clouds condensate over the western slopes of the island. I mean, i moved here (partly) because of the sky ... unfortunately i am not independent from electricity with the telescope and can't easily flee from the cover. This is probably a stupid hint, but Newtons need a slight offset of the secondary , towards the main and away from the focuser. It is not much and if there is no problem with uneven illumination i think it can be ignored. Btw., i find the first picture really nice, besides of the coma ! @munlander1: Always raws. Jpegs are just piles of artefacts and information loss, for internet presentation only. You can make a few darks and biases with the iso setting you used and stack them into a master dark and a master bias. Inspect them. You need a stretching tool like a histogram tool because the stacked images have a high dynamic range, depending on the picture format of your stacking tool (usually fits or tiffs, the latter mostly deprecated).

Well, if you want to inform us about the stripes, ok, information received :-) I assume it's your nexton + eos400d and the screenshot is from the stacked lightframes after application of dark and bias ? Type, number and exposure time as well as settings like temperature and iso of the cam if applicable ? How many frames do you have, light, dark, bias flat ? How are single frames ? If you stretch (histogram gamma curve) a single dark or a single light frame, does it show stripes as well ? A slight readout error from the chip sums up over multiple exposures because the program cannot distinguish is from e.g. a nebula if it doesn't have a hint. cmos chips are more prone to these errors (horizontal or vertical stripes) than ccds because they are produced for single shots where these errors don't matter. If you don't see them on single darks or biases, do the stripes appear on the master dark or even the master bias as well if you stretch the histogram or just on the stacked lights ? If yes then it is something with the camera / chip, if no it might be an artefact from the stacking. Then try other settings while stacking, if you have like 10 frames or more of each light dark and bias try sigma-kappa stacking in dss because it weighs single exposures less. If it turns out to be a chip error than you will need a software like PixInsight (and a semester of intense study) to correct it.

New ideas on the causes for Enceladus' topography, including the suggestion that the polar activity might not have an internal cause: http://www.sciencedirect.com/science/article/pii/S001910351630584X

http://orbiter-forum.com/ http://orbitersimulator.com/ http://orbithangar.com/ Everything in there, have fun :-) I played a while ago, but since i don't have any suitable windows pc anymore that's over.

Fortunately there is a stable inversion layer between the sratosphere and the whether relevant storeys. For now we're safe from inhaling poop ... :-)

*rubchin* hmm, that leaves us with two possible interpretations .... :-))

f/6.5, touchdown at the threshold ...

I do not understand it but it sounds spooky :-)

Yeah, sure one must wait for mods to update, problems resulting from unupdated mods are self-inflicted. But ksp crashes just plain vanilla. On exit it is always thrown out by the kernel due to access violation, it never exits normally (linux).

An umbrella stand :-) For collimation (also with the laser pointer) turn the tube so that the focuser faces up. You could coil a bit of adhesive tape around the pointer so that it fits almost perfectly in a 1,25" opening. And i'm doing the same ritual: first the main mirror, then the secondary mirror. But i never tighten the screws of the main mirror, just so far that it can be moved by hand in the cell. Nearly all of the instructions say so because of risk of mirror deformation when temperature changes.

Qapla' ! ... and best wishes for a successful search of the null pointers and access violations ! ;-)

The Home Of The Kraken ! They enhanced colour and contrast, simply meaning that wavelengths or greyscale where mapped to colours. Typical thing in many astronomic photos. And several photos were combined to show the whole pole in an equal lighting because Jupiter's axis is only very slightly tilted (few degrees).

I don't care about languages. English is plain, straightforward and easy. Almost a formal language. But easier than C++ :-) I want a stable game ! Edit: ... but then again, it's not that important. It's just a game and i certainly had my fun with it (in some versions) !

While what you say is absolutely true, i must add that most complaints about crashes are actually plain vanilla ksp or ksp with correctly updated mods. The cases with uncorrectly or not updated mods are usually solved immediately on the forum.

Ksp ran on my notebook for ~10min without crashes. But the poor thing is a little overstressed :-) On exit the above mentioned segfault happened there as well.

Oh well, i'd be happy if 1.3 would just run, i don't mean flawlessly, just run. Of course i am aware that others do play the game just fine with a lot of mods and have no reasons for complaints. As far as i am concerned, i think that programs producing segfaults or nullpointer exceptions aren't exactly well behaved and taking a look in the support forums here there apparently hasn't been much of a change with 1.3. Facts are, and in that i can understand @KnutG: there hasn't been much new visible /playable stuff since 0.90, but i think behind the scenes much was done (multithreading e.g.). There was a huge effort with extraordinary manpower from the community a few subreleases ago just to make ksp stable because what was delivered before just wasn't playable or maintainable. KSP stays interesting as a game mainly because of the great modder community. I must admit i haven't played much since 1.0.5 because of instabilities and poor gameplay (wheels !) and also because i was a little overfed with starting rockets and setting manoeuver nodes over and again, but i was looking forward to a new game with 1.3, hoping for a fix of the wheels etc. pp. But apparently that will not take place ... Edit: what i do not want to read is something like "Unity is to blame !" or "Mono is the culprit !". The developers have chosen their tools and are responsible for working with them. I would even think that an own graphics framework and physics routines would make maintenance cheaper and the code more reliable than the use of stack of doubtable tools, but i am only a dumb user.

Thanks, ThirdOfSeven. I sadly have no hints in the logs .... So i do what i've always done: wait for the next subrelease :-)

Hi, anybody playing 1.3 on linux (preferably debian stretch no steam), unmodded or slightly moddod ? Is it running stable ? cheers gb

A software provoked halt is a single instruction. I limited cpu frequency to something below norm frequency (3200 of 3500mhz) and the halts still happen a few seconds into a flight. There is no software running except for the system processes and a terminal. This is debian 9, no other software has provoked that behaviour before. I could experiment further with limiting the cpu time or memory for the application but i doubt that is worth the while. I'd rather expect a forgotten piece of code somewhere in the stack of tools, engines and frameworks ksp uses. Maybe others come up with similar problems ....

I know about the signals. No, it is definitely KSP halting the system. Edit: cpu temp below 60° according to sensors. This is not an overheating problem. The pc has 4 years, i played a lot ksp on it (little since 1.0.5).

- A colleague of Homo erectus, ~250.000 ago in western Europe. See if we can talk. I'm sure we can - A Neandertal shaman ~125.000 ago, talk about spirits and the land. Sure i can learn something. - A hunter in the cold steppe ~25.000 ago ("The Golden Age"), have a steak together. I bring the French fries. These surely are peaceful and reasonable. If they have no time for me then maybe somebody from late mesolithic / early agriculture though i'd like to approach him/her slowly from afar ... - Hanno the navigator, clear, talk about navigation, one of my favourite hobbies. Though my Latin is just Asterix (Comic) level ... - Tomás de Torquemada. With a gun under the robe. - i think i'm better of with one of the early agriculturalists.