swjr-swis

Having been invested with exploratory knighthood, sleep evaded me tonight. Thus I embarked on a quest, a pilgrimage, to seek out the Selfie Places of the Brotherhood. All the locations on the first scroll, attested with pictorial evidence of visitation, in the same canonical order: Castille7's Kayak River purpleivan's Wall Klapaucius' Caldera Air Rally Hotel26's Valhalla B.A.S.E. SuicidalInsanity's Dumbell Lakes purpleivan's End of the Watery Road Castille7's nighttime J.U.M.P.E.R.S. location (I could definitively match only one of the screenshots, the river one. I flew around the area for a good hour without finding anything that looked even slightly similar to the other pictures. Are there any directions missing from the river to the mountains in those pictures? Perhaps it explains why no one seems to have located this one yet.) Hotel26's Fake Victoria Falls (and True Victoria Falls as well) fulgur's Klapaucius Mountain Lake

I used to be an adventurer like you, then I took an aeroplane to the sea. So, in reminiscence of days long past, I shall attempt to regale you of far away locations, so as to gain my way into the Brotherhood of Knee I mean, explorers. In lieu of clues and a flowery description, I present my feeble attempts at poetic riddling: This destination may lack massive rocky formations and elusive victorian falls, but for the lone explorer seeking absolute silence and oneness with nature there is nigh a better location. Immerse yourself in the breathing tides of the vast ocean around you, and achieve consciousness of your insignificance. Only then can you prepare for your journey to space.

Jeb felt he was issued a challenge and marched into the hangar to ready his trusty Seaplane One (his own variation of it anyway) and see about that. Full album (including a second landing on a tiny snowy plateau much closer to the entry point): https://imgur.com/a/zEDUqrD A seaplane is a conventional enough craft, yes?

To answer both questions, this is how I would do it: TL;DW: 1) go slow, align from far. 2) lots and lots of wing area. and 3) make it a wacky design and record it, we wanna see!

Believe it or not, there are people around to whom the notion of getting into the nitty-gritty of a text file is an almost irresistible invitation. I don't have an abundance of time for it anymore, but I have on occasion created a (working!) craft file or two from scratch in Notepad++ just to test if I understood the format correctly. Assembly was my first programming language. Probably has something to do with that. Disclaimer: I'm not a fan of the changes introduced to the craft file format at some point, I think it was with the introduction of part variants. I feel it lost consistency, and readability. And yes, ironic, from an Assembly guy. I've not enjoyed craft file editing quite as much since then. A standalone editor purely for testing ideas of craft design, would see a lot of use from me, even on a mobile device. Make it a paid app if the beancounters want an RoI. But do consider it. From my own experience of using KSP on a pretty wide performance range of hardware, it's the unnecessary 'fluff' that seems to consume most of the performance: ground crew, flickering lights, Vehicles On Ice. None of that would be necessary for a standalone editor. The editor also completely lacks the need for per-frame physics calculations, which is the main performance bottleneck in flight mode. Performance-wise, I don't think a standalone editor is as unfeasible on a low-power device as people tend to think. I generally dislike having to do anything on a mobile device other than making or taking calls, but for this, I would be willing to accept a good few compromises in user interface, just to have it available practically anytime anywhere.

I've been a pure stock player for a long time now. I don't consider mods essential or required for KSP. That said, I do recognise that the sheer -and not always fully realised- potential of KSP works like a black hole for modding ideas. So. Many. Ideas. Not every idea is necessarily brought to optimal result, not all modders have the same talents, time, tools, and several other Ts probably. And of course tastes and playing styles and opinions are spread out over an enormous scale, which means people can frown, shrug, or spontaneously want babies when looking at the same mod. But frequently, I dare say most times, I find myself sitting here grinning like a toddler that just got away with two treats instead of one when observing the conception and creation of another completely obviously essential mod idea that somehow, throughout all this time, we all seem to have missed somehow. Yes yes, we were eating those chestnuts just fine without the fire, but omg why did no one think of having them roasted before? And all it took was striking a random (*) rock to another to create, get this... fire. Fire! It makes chestnuts AWESOME! I don't even know what fire is or why it makes sticks disappear but ROASTED CHESTNUTS OMG! What else can it do?! <breathes> Ahem. I know, the very irreverently implied 'randomness' of conceiving the idea and bringing it to a tangible useful result is highly debatable. There's bucketloads of talent involved. And an almost inconceivable amount of personal time and energy invested. So in conclusion: my vote is for ALL OF THE ABOVE. Modders: y'all are awesome. Like roasted chestnuts awesome. Thank you.

I've had that feeling with KSP, the base game, for a long time now. It's sort of a backdrop thing that has become part of the KSP 'experience'. I've stopped expecting any change to that. It's not even the serious bugs. Just so many little things with easy fixes that remain in the game to this day, with ancient bug or feedback reports that linger on without attention. Symmetry rotation issues that just require a reorientation of the model or texture to fix. Textures that are demonstrably upside down, or badly aligned. Clearly visible shader errors. Illogical choice of default part parameters that have been reported and community-patched ages ago and still remain in the base game. Incomplete part sets that miss crucial parts to be able to build a consistent looking stack. Then there's the game systems that were added and never fleshed out or used only in very partial manner: part upgrades and variants, G-force and pressure limits, tracking mechanics. Dare I even mention the tech tree? And 'features' that only ever caused problems and never really solved the 'issue' they were supposedly introduced for (*cough* "cannot deploy while stowed" *cough*), only to be 'fixed' by -optionally and only partially- disabling it again. Wheels and gear that apparently will just never again work as one would expect it to... as they once did. Some of these things can be user-patched by editing the files. And of course there's mods. Eventually I'll cave and decide on my 'least-objectionable' patch version and then resort to hand-edits and mods to fix it for my own games. Probably with a pure stock 1.3.1 on the side for craft sharing or challenges. That I'm still waiting to decide on what version that'll be I guess shows I still think there's a chance of a better one. I love KSP, it's at the very top of my favourite games, and I own several thousands of them. But it's disheartening getting to the point where you don't really expect it to ever be a polished game anymore. Still is for me too. Despite some glaring issues, overall it's the best compromise between performance and working features vs missing QoL stuff and new/worse bugs. For pure stock players anyway - if you want DLC or mods, you're out of luck.

Everyone going on about millimeters and pints. I just upvote for the realisum.

That's ok. "You have a week to make it happen..."

I'm formulating a theory that KSP is nothing but a crowd control experiment, whereby the public is distracted by a concept of building-block rockets to ensure they don't notice what's going on right around them. Some initial tests I've done have shown a distraction level of frankly disconcerting proportions. I have seen indications it can even extend to areas of basic life functions, with extreme examples even ending up in food going cold and bladders not being emptied at the required moments. More on this as I investigate.

It's perhaps relevant to mention here that some, maybe most, of what you see in the Unity dll code is generic stuff they bundle for any Unity-based game to use, or as it may be the case, ignore. Before anyone jumps to unfounded conclusions, just because references to achievements or in-game ads or who knows what are found, it does not mean KSP specifically is doing anything at all with that code.

I have no insider info, so just based on the filenames used, these ones are almost certainly related: Unity.Analytics.DataPrivacy.dll Unity.Analytics.StandardEvents.dll Unity.Analytics.Tracker.dll UnityEngine.CrashReportingModule.dll UnityEngine.PerformanceReportingModule.dll UnityEngine.UnityAnalyticsModule.dll Of which the crash reporting is the one I least object to, if it would allow me an acceptable method to opt in. Alongside the above, there's also a whole list of dlls in there that one can question how or why they are required for KSP, like connect, webrequest, and streaming . Probably a case of either lazy inclusions or Unity being a dingbat and forcing their inclusion through some other totally unrelated function that KSP does actually need. All these files can be found in the /KSP_x64_Data/Managed directory.

I'm no stranger to topic derailing myself, so I won't make too hard a point of it, but this thread is meant to discuss the newly added/extended version of Unity Analytics in KSP 1.8.0.

No worries. Stress has certainly gotten the better of me a few times too, it's a sneaky one. Yeah give them some time to fix whatever the engine upgrade screwed up with the drag cubes. No point making changes that will just be invalidated in the next patch or two.

Back when this was first done in this forum, with one of the 1.4.x releases, the entire list was three entries. Now we're up to eight (yours is missing data-optout-service.uca.cloud.unity3d.com). QED. Redshell also wanted to contact the following two addresses: 127.0.0.1 treasuredata.com 127.0.0.1 api.treasuredata.com

Requoting for truth.

Ok well, I don't like what that says about this, but thank you for doing the research I didn't find the time to do yet.

Well, they did move to a new Unity version, and Unity themselves have not exactly been model citizens on that respect. It may just be coded in now and there's no choice? I have not yet had the time to research the matter. So I'll still give the benefit of the doubt towards the new KSP Overlords on this one. For the record: I'm not accusing anyone, I'm venting a frustration. It just annoys me no end to see how it's been silently enforced now. Just when it starts looking like there may finally be a new version of KSP to move on to.

The game doesn't require those files, or the functions they contain, to 'work properly'. As quite strikingly illustrated by the fact that all versions from 1.4.0 (when they first decided to include/enforce analytics) to 1.7.3 work perfectly without those files, without even generating a single line of error or warning in the logs. Unless of course it's coded explicitly to fail or loop indefinitely when the call doesn't get answered. Personally I prefer not to lay my trust in code that has already proven to first call and report home and then ask me if I want to continue allowing it (and signify so by a convoluted method of registering to their website to 'let them know my preference', which the game then has to connect to every single load to check ). You sure you know all the hostnames the engine will try connecting to? How about after the next patch?

More Unity Analytics crap as part of the new engine, I notice. Connecting, crash reporting, performance reporting, tracking, 'standard events'. And the ever so ironically named 'data privacy' - yes, that is actually in the same filename as 'analytics'; got a good chuckle outta that one. Except now, unlike up to 1.7.3, we can no longer disable it entirely by deleting/renaming the DLLs - the game basically either doesn't load at all, or gets indefinitely stuck in the loading screens (thank you for that, btw, it's the first time I've been able to see all the available loading screens). So, from 1.8.0 on, this means no analytics, no game? I guess I no longer need to wait for a definitive version of KSP. 1.3.1 it is.

Yes that is true.

Hmm... a single-launch orbital delivery system to plunk 14 payloads (relay/science stations?) with reasonable accuracy onto the listed peaks... Argh noooo, I don't have time for this! . . . And yet...

You made me perk up for a moment there. Booklets, physical Kerbal merchandise, professionally 3D-printed models... hmm. Just please don't do a Ubisoft and keep pricing within realistic proportions? Yeah, you might want to research the company -under their previous name- that is tasked with KSP2; their history shows the exact opposite of this, to a rather shocking extreme. One can hope they've learned from past mistakes, but I've not seen any indications to that effect yet. Wait and see.

I build most of my (space)planes with CoM practically on CoL, at first. Just a smidge behind, and maybe two smidges above. That last one helps with making the plane tend to keep it's belly pointing down or into the reentry path when holding radial out. Keeping CoM and CoL practically on top of each other, in combination with sufficient wing surface and AoI helps making planes take to the air by themselves, a trait I value highly because of my very frequent flight testing during design (repeatability) and as a way to keep usage instructions for my designs as simple as possible (craft sharing). It is however often adjusted once I start flight testing, because a) CoL is often not accurately visualized in the stock game, especially when you use AoI on wings - which you should, b) CoL is not the same a CoP and that difference matters, c) CoD can also play a significant role in certain flight conditions which can overwhelm other forces. Generally though, it stays pretty close to where it started, and tweaks are mostly done by ensuring there is proper control authority. So tl;dr: I don't see anything inherently wrong with it, it tends to work for me and generally results in fuel-efficient and easy to fly and land spaceplanes. Carry on, I'd say.

Keep in mind that contracts of that type are already fulfilled when the orbit just barely becomes an escape trajectory. All you really need at that point is to expend a tiny puff of fuel in retrograde to close the orbit again, and you can spend the remainder of fuel to creatively lower Ap. Perhaps lowering Pe a bit to aerobrake and lower Ap 'for free'?