lipatden

Confirmed, thanks for the quick work

https://drive.google.com/file/d/1oa5bVdkxleAiYUZXjIO4_Nuojutzygc_/view?usp=sharing Zip contains complete KSP.log, and a list of installed mods. Note the last line in the log is generated when the application is closed, so it essentially sat there for 12 minutes doing nothing (except looping loading art).

When I first installed this mod, ALT-Right-click did nothing. then something changed, and I at least got to see the file after adding a few parts so I could do manual stuff because... ALT-Right-Click no longer brings up the menu. Any hints on how to troubleshoot this, or do I need to go the whole submit a log route...? Appreciate the work in this mod.

I've come up with a proposal to include configurable min and max limits for throttle in autopilot and opened a GitHub issue (feature request) including a UI mock and the logic in pseudocode. Apologies, I don't have the VS-fu to get a dev environment working, I hope this is helpful? https://github.com/MuMech/MechJeb2/issues/1472

It seems throttle limits - max and minimum - are not being applied while using autopilot. Is this correct, or am I missing something? I've built a testbed jet-powered aeroplane for small rocket engines, and set the rockets to use their own throttle (ie not linked to main). Turning the rockets on makes the plane go over the autothrottle speed (expected), so mechjeb commands zero throttle, turning off all engines (no matter if they are linked to main throttle or not). I'd like to set a minimum of 5%, so the "turn off engines" command doesn't propagate everywhere as zero thrust is commanded by the autopilot, but none of the settings in the "Utilities" window seem to have any effect. For reference, I'm using DEV release (RO/RP-1 playthrough).

Just opened an issue on GitHub: All my existing station tourist missions from Tourism Plus can't find the vessel, so tested with a brand new contract. I'm offered a contract, but immediately on accepting it immediately can't find the target vessel, showing "No vessel currently matching parameters". Note this is while I'm still in Mission control, so the vessel has not changed (no docking, renaming etc). Checked the savefile and the contract's targetVessel Guid matches the pid of the contract target vessel (after converting the pid to guid format, savefile attached in issue). Offer: After accepting:

Hello all. I use a tool to manage my mods - apparently it's taboo to mention a name? Anyhoo, about a month ago I launched it and it did its' job, updating my stuff to the newest version for more features and bugfixes. I didn't make a note of what changes happened. Unfortunately my KSP started crashing, right at the end of the ~7 minute load time for my 60-mods extended Galileo-based scenario. The log files aren't halpful as there is zero diagnostic info just before the crash entry, and I can't read crash dumps. After an hour of bisecting the enabled mods, I landed at ResearchBodies v1.9.6. Rolling back to v1.9.5 gives me a fully-functional game that actually launches. How to proceed? At least it's working for me now, the prospect of having to ditch this part of the game would have gutted me. I suggested basically the premise of this mod to Squad several years ago, as without this it's just a building game. ResearchBodies turns it into a genuine exploration game. Mod list:

Hi there Tried to recompile, but a reference to KSPUtil.dll eludes me - there is no such file in the 1.2 ZIP - not in x86 or x64. If you have Kerbal Alarm Clock (KAC) you can create a placeholder node, but since your orbit could place you anywhere around the source body actually making a node that is correct for your orbital situation is not trivial. I use KAC to create a roughly correct node, then PreciseNode to edit it to more correctly reflect TWP's suggestion (angles etc).

Yep, that makes the most sense, but at least the option to spam my alarm list would be nice +1

And we're now entering bizarro-world... 1. From KSC select the pad, choose vehicle that fails on launch 2. SAS on, launch (throttle irrelevant, first stage is SRBs) 3. Kaboom! 4. Revert to launch 5. SAS on, launch (throttle irrelevant, first stage is SRBs) 6. What a nice orbit (no failures) 7. Go to KSC, jump to step 1. Basically, any first launch directly from KSC exhibits the failure, launch without going back to KSC first is fine (haven't tested quickload). Never found this before as I'm on Hard mode so revert is not an option.

I'm getting similar problems, in two types: 2.1) Stock parts to make a small satellite (Stayputnik, FL-T100 tank) inside a 1,25m expended fairing (no side, just the cone) overheats and explodes - inside the fairing. This is with DRE. all other patrts have <200deg temps. this is somewhere not far above 5km, and it has no heat-generating parts attached, so the fairing isn't keeping this tank from DRE consideration. 2.2) Mid-launch my SA1-LFT (on top of a LV-909, below a 1,25m expanded base) simply disappears, though the Reflectron DP-10 stuck on its side is still there. Right-click does nothing, but when the stage is eventually activated the fuel is available. It blipped back into place a few seconds after stage acrtivation. First launch of that sat it then overheated (in space) after 30 seconds of the LV-909 burning, the second one didn't quite disassemble, but when I returned focus from Space Center the parts were spread out over ten meters though still considered a single craft. I'm almost certain this is part alignment issues with the patch published earlier, though I can't afford to do much testing as I'm on Hard mode and my budget is stretched as it is...

I respect your dedication. Holy mackerel that's a lot of steps! It does unfortunately break the ingame experience, and as Squad pointed out in the 0.25 notes even Return to Space Center should be in-game (as opposed to ESC). I'll track down the issue list on Github, thanks!

Hello all Is there any plan to provide for commands in the Flight Computer that survive vessel switches? I am thinking of a more advanced scenario where a vessel hibernates and wakes up once per hour to receive commands to save power, but before that happens RT would need to implement: Queued commands that are remembered between active vessel switches; and a generic "sleep" and "wake" function (turn on/off antennae) that doesn't necessarily depend on action groups (though this is how I'm doing active-vessel power management now). I often find I need to execute a mid-orbit correction while out of range, and while I can happily schedule a burn for e.g. 2 days past going out of contact range, if I have something else that needs attention in the meantime I'm done for. Any thoughts?

Good point - is in v3 Beta 3 - out later todayHold on a second. I purposefully ditch my debris once on a collision course during transfers, and follow the debris to the surface after the SOI change (which is also useful for seismographic impactor experiments I don't use, but others might) to ensure warp doesn't mess their orbits up to a non-collision or warp them through the target body. Besides the SOI alarm only appears when you transfer craft focus, random debris (and other objects) are ignored if not focused. Does this default to present behaviour?

I agree it's not very useful. My hope has been that biomes get added to other planets to make it more useful. I considered taking it out, but I figured some might like it. I might add a contract that uses it, though. On the contrary, I'm more than happy to send these guys and the spectro off to distant worlds, transmit the science back and use it to unlock the parts needed to actually build a return vehicle and send it to them post-haste

Yes you can, once in low orbit, once in high. I've also built my second station with transport in mind (e.g. launching with empty tanks as structural elements) so they can be ported to wherever there is SCIENCE to do (Mun, Minmus) once I shift some fuel there. This does of course imply you're on the regular docking port (the prototype doesn't allow fuel transfers) but this is the nature of progress.

Hi Cilph I've noticed a timer display issue (not the warp-related ones I've seen reported earlier). The countdown to an action in the list on the right of the UI window seems to be displaying incorrectly. When an event has 2m01s remaining it is shown correctly, two seconds later it displays 59s remaining instead of 1m59s. As it reaches 0s it again shows 59s remaining and the event fires off at the correct time so it is probably just not displaying the 1m component for events between 119 and 60 seconds. I'd also like to know if it is by design that I can't seem to queue a command (e.g. kill rot) if connectivity is absent. I have already sent a re-enable antenna command so it will be established, or perhaps I know I will be in range at a future date. If this is by design then that's ok, but it was unexpected - perhaps if connectivity is not established in time for the event to arrive at the designated time it can simply be discarded. I was getting frustrated that my probe's antenna kept falling off during re-entry until I figured out how to use the delay, especially the first command - retract in the future, and in the meantime accept the following timed commands. It's also a tad confusing that I can't set up a bunch of delayed commands (e.g. four minutes from now), then issue and immediate command after that (I'm done queuing, go ahead and retract), so checklists are a must. Again, if by design then fine since inserting commands into an existing list as opposed to simply appending is a coding headache, but it is a bit counter-intuitive. Now that I've got these timed commands nailed I am having such a blast getting flimsy craft safely back to kerra-firma. Thanks for all your work!

By totally taking this partial quote without context, perhaps this is a good interim measure if fully-adjustable top, bottom and side dimensions (A, B and r respectively in the diagram)?

Each device has a different optimum altitude, and the small angular view of the hires scanner lends itself to rather high orbits. They're in the config and mentioned earlier in this thread, so no, I wouldn't put them on the same satellite. A Hubble-style service mission does sound like fun, and even if the part looks oversized on a Kerbal's back with KAS it's still possible - only momentum matters in space

Wow, this just ballooned into a huge post. I guess I have a few things to say on this matter... "modular spacecraft building" is almost undoubtedly not going to include connections made of chewing gum and the discovery of struts long after you've achieved orbit and amazed you got that far without them. Unless Space Engine want players to experience failure (and in comical, blasty-awesome ways) it will never go in the direction of KSP. This game is very story-driven (nixing procedurally/randomly generated systems too) and will only become more so as character development is included. I have no need of prettiness, this is basically a 3D cartoon. I really, really like this cartoon. As for actual prettiness and SE doing graphics better than KSP... Unity was never designed for this use case - as the devs have explained they don't even use the stock surface and gravity features because they're not spherical. Orbits are basically done from scratch and they've been learning as they go. I think the result is fantastic. Sure the graphics can be better but for an alpha this is just fine, and mods already add eye-candy. I'm surprised nobody has requested features from Universe Sandbox. Frame rate is another issue entirely. There are two kinds of jitter/lag people experience and from all my testing graphics rendering quality has little impact. Modern GPUs (even the simpler ones in laptops etc) can more than easily handle the simple planetary and atmospheric renders, and as the mod community has shown there is potential for more. Squad made a choice of engine for the game based on what must have been a very different expectation and feature set than the one they have now, and I'm perfectly fine with their choice. The focus here is fun, not pretty. The first jitter case I've noticed is recalculating the surface meshes after high warp in low orbit - for up to five seconds the blocky, simplistic hills and coastlines resolve to a better fidelity. This is tolerable, and an acceptable performance/memory tradeoff since storing render and collision meshes for all objects all the time is wasteful (or even all of a given object) or even impossible given the RAM constraints. nobody complains about this but this is the only "graphics" problem I can find. The second is high part count and this is where most frustration comes from. As I mentioned something like SE is unlikely to implement bendy ships that break in physically-semi-realistic ways. Modelling bodies such as the ships we all build is a complex undertaking and still relatively unoptimised. I saw a post suggesting frame rate is inversely proportional to the exponent of part count, pretty much the worst case you can think of, but makes sense when you consider one part's motion/inertia/rotation can influence every single other part. Many other programs model this sort of thing, but without looking at Squad's source I think judgement is way too premature. Related to this is the collision mesh, and I don't see anything in SE about handling both interplanetary transfer burns, landings accurate down to the centimetre and rovers trundling along a surface that is apparently entirely sane (collision mesh is coherent and matches the scene - easier said than done). This is a heck of an achievement, and the lack of anything comparable is why Squad have had to do so much from scratch. There is room for improvement with multithreading, but multithreading is hard! From my conversations with developers of other games the Windows (and other platform) threading model is simply not deterministic enough or too expensive (in terms of resources) to be used when a realtime result is required - when you've got a frame to render on a deadline. Lots and lots of research has gone into this, and modern kernels have gotten better, but it's still a pervasive problem in the industry. I wouldn't advise Squad go down that road until feature completion, and even then they're likely to get as much benefit by optimisations such as assembler blocks and better compile-time optimisations to account for branch prediction. They're simply not there yet. A major block for the implementation or requirement of multithreaded (and therefore multicore) systems is that a single-core user will have a very different experience to a quad-core user, and if everyone gets their way on quality and framerate the minimum specs for this game will get bloated and confusing - is 2x3GHz system going to be as ok as a 4x2GHz system, and how do you get a user to determine that? Squad are doing just fine by my books, and having a Kerbal stand in one of those scenes from SE would, frankly, look silly. There are excellent flight simulators out there that do a better job because that's what their primary focus is, and mission-based space games that do that game type better, but nothing remotely like KSP in terms of fun, accessibility and the opportunity to customise and watch it blow up - or white knuckle WASDs on the dark side of a remote planet with tons of expensive hardware at stake that is uniquely mine. This isn't a space flight simulator, it's still just an addictive sci-fi cartoon. I can't put it better than this:

Most command pods have a surface altitude readout in IVA so this is accessible/visible, even if not conveniently. Perhaps a toggle of absolute vs surface altitude where altitude is presently displayed, but only once you've unlocked/installed a part?

Agreed, but not until you use the... This is the crux what I'd like to see in 0.24 or later: Real Discovery. Current SCIENCE experiments are point-in-time, and some are certainly correct such as e.g. barometer or thermometer readings, but some require a bit of time to aggregate. The seismic readings only make sense if running for a minimum time and has already been mentioned by other more prominent commentators (e.g. generating impacts while a seismic sensor is running), but something like a telescope or other observational equipment would definitely need this. Essentially, in career mode we know far too much about the other bodies in the Kerbol system. Before I've launched a thing I can view all the ridges on Pol and the surface of Moho which is right next to Kerbol, both of which are incredibly difficult from surface observations. As more is known about a body, the more is shown e.g.: surface details of remote objects are obscured until good quality observations are made, e.g. blurred surface details when no quality observation of that part of the surface existand especially non-existent surface detail as with the far side of the Mun - that would be a fantastic early achievement to engage and excite players, even without associated science reward [*] the location of adjacent biomes as soon as one is discovered/explored made even more useful with a biome overlay on map mode perhaps even the existence of moons or Eeloo/further objects? all of which would persist on the sandbox game unless the player explicitly asks for all details to be revealed Finally, real setup requirements for some experiments, e.g.: the seismic detector would be useless on shock-absorbant legs, or craft with moving parts such as the larger PV arrays or Kerbals on-boardtemperature scans in full sunlight gives a different reading from a shaded instrument etc. This little game has immense learning utility, and while the whole thing is a Little-Green-Men fantasy it has significant real-world analogies that can be used to teach and (unintentionally even) learn. All of it lends itself to gamification, and while mods will take care of a lot of this (e.g. SCANsat, FAR, DRE...) there is an opportunity for Squad to at least create a good platform for these in a consistent fashion (e.g. duration experiments) or outright lead (e.g. exploration). On a minor note, I know everyone else seems to be really keen on economy, but a cost-based economy doesn't make too much sense to me without construction delays and real value for recovery of used parts. Economy and associated bits are low on my list, but will by all means add gameplay depth.

Hmmm, I don't seem to be up-to-date on MS Common Runtime Language, thanks for the tip...

Good point, this means all mod writers would need to compile their code as both 32-bit and 64-bit versions. This is going to add complexity...

Is it a reasonable idea to limit the maximum radius of the fairing based on tech tree progression? I don't know how this would be displayed in the VAB, but adding a fairing that expands to over 2.5m while only 1.25m parts are available seems like a stretch (pun intended) and allows launching unwieldy (even if light) assemblies before the tech appears to support it.