eightiesboi
-
Posts
478 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by eightiesboi
-
-
On 6/11/2022 at 8:44 PM, FireFaced said:
Could support for NF Spacecraft pods be added? Some of them (notably the Mk1-L 'Nereld', Mk3 'Tethys', and Mk3B 'Pandora") have segments that are exposed to heat during reentry, and visually appear to be ablators, but there is no ablator module. This causes explosion on reentry, which is less than ideal. I would contribute the patch myself but I can't for the life of me find documentation on what modules to use.
Visuals aside, I don't see anything in the description that there is an integrated heatshield or that ablative material is used on any of those command pods / landers. There is no ablator resource included in the configs for those vehicles, which suggests that that Nertea (the mod author for NF) didn't intend for these pods to have integrated heatshields.
It's your game, of course, and you can do whatever you want with it!
In that spirit, if you want to add ablative shielding to the NF pods, you might want to either look at how DRE added it (check out the DeadlyReentry.cfg and look at the line for "@PART[mk1pod|mk1podNew|mk1pod_v2]:FOR[DeadlyReentry]" for an example), or you could look at what Squad does on their pods (an example can be found in the KV1Pod.cfg, and either add an MM patch [the best practices method] or copy/paste the ModuleAblator and Resource blocks right into your command pod of choice [not generally a good idea]).
Remember to backup any files you start playing around with!
-
@DeliriumTriggerraises some great points (and extra kudos for being respectful, clear, and comprehensive). I am a bit opposite from DT (hope you don't mind the abbreviation) in that I always install RealChutes in every career playthrough. However, I also go into the config files outside the game and change the presets there, as well as a couple of actions to make my life a bit easier. What this says to me, is that although I have a workaround, the fact that I do this every time means that the default configuration doesn't work well for me (emphasis on "for me"; YMMV). I agree that the User Experience could be made better in RC2, assuming that it is technically feasible and that @stupid_chrisso chooses.
This is a great mod that has made my game qualitatively better. I appreciate all of the work SC has done and generously shared with the community. And I also think that DT has made some great suggestions worthy of consideration.
-
3 hours ago, Zulkonit said:
Will near future construction be updated to 1.12 soon?
Hi @Zulkonit! Welcome to the Forums!
Are you having specific problems with NF Construction? There are many people (myself included) that use the various Near Future mods in their games without problem. If you aren't having any problems, then don't worry about the version number. It's like the song says, "Age is just a number, and so are KSP versions" (or something like that!).
If you haven't tried using any of the NF mods, it's usually a good idea to read some of the forum posts. At minimum, the Original Post and at least a few pages back from current. That will tell you if anyone has been reporting significant problems. In this case, on the previous page, on March 4th @Grem helpfully reported that all of the mods are currently working with KSP 1.12.3.
If you are trying to install using CKAN and having issues, note that you can override the version in CKAN.
And, if you have already installed an NF mod and you are having problems, we need information to help you. Follow the instructions in this post.
Again, welcome!
-
I am going to add my thanks to @zer0Kerbalfor reviving another languishing mod. Between ZK and @linuxgurugamer, the number of mods that have been updated and maintained long after their authors have taken a break from the community is inspiring (and let's not forget the number of original mods ZK and LGG have authored).
Not only that, but the cooperation and coordination between the two of them is much appreciated. I can't speak for anyone else, but I find myself constantly revisiting old mods, comparing them to new ones, and feeling quite fortunate that I have different feature sets to choose from. I can Play My Way (tm), and that's not a bad thing.
Just waiting for ZK to release his take on Office 365 for KSP.
-
Hi @Artyom,
I see you've been around the forums for about a year, so a belated "welcome!"
My apologies if you have already seen this, but in order for someone to really be able to help you, we need information. Check out this post here, which explains everything.
-
Hey ZK,
I am getting this in my logs:
Spoiler[ERR 16:24:52.448] ExperienceTrait: Cannot add effect 'ELSurveySkill' as it does not exist.
[ERR 16:24:52.448] ExperienceTrait: Cannot add effect 'ELConstructionSkill' as it does not exist.
[ERR 16:24:52.449] ExperienceTrait: Cannot add effect 'ELConstructionSkill' as it does not exist.
[ERR 16:24:52.449] ExperienceTrait: Cannot add effect 'ELSurveySkill' as it does not exist.
[ERR 16:24:52.450] ExperienceTrait: Cannot add effect 'ELConstructionSkill' as it does not exist.
[ERR 16:24:52.451] ExperienceTrait: Cannot add effect 'ELConstructionSkill' as it does not exist.
[ERR 16:24:52.451] ExperienceTrait: Cannot add effect 'ELConstructionSkill' as it does not exist.
[ERR 16:24:52.451] ExperienceTrait: Cannot add effect 'ELSurveySkill' as it does not exist.
And then I found this on the forums:
SpoilerWhat do you think? What did I screw up... again?
Logs here: https://1drv.ms/u/s!AoyHZiRU1jT-z5MCm0GZJg5PFxNW5g?e=fpOlNj
-
Spoiler
I was fast asleep, dreaming of Duna, and the giant worms that produce the spice. One swallowed me whole, and I felt a huge weight on my chest, crushing the life out of me. With my last breath, I gasped, "desert power" and startled awake. "That's nice," said my cat, who was sitting on my chest, "but you failed to take into account the altitude of the decoupling event. Also, I'm hungry."
As @darthgentlyand others have mentioned, I was sloppy in my little experiment. I performed it again this morning, making two changes: first, I flew to 66km and made sure I had an AP close to 200km and a PE below 20km (specifically, 198 and 14). Then I quicksaved the game. I then ran multiple tests, decoupling each 1000m (starting at 67,000) up to 74km, checking the SR recovery process each time. And, each time I ran the test, the lifter was successfully recovered.
And so, the "oddity" I noted was due to failure to control for a variable on my part. My cats are ashamed of me, and they've stated it will take many bribes of treats to ever publish in their journal again.
Everything else I said, however, matches. If you want to use SR to recover a vessel, you must make sure that the PE for the vessel to be recovered is below the point at which KSP deletes it (just under 25km on Kerbin in stock solar system).
One other thing:
On 3/7/2022 at 9:30 AM, linuxgurugamer said:You do need to stay with the initial vessel until the lifter body gets recovered or destroyed by the game, though.
I tried one other little experiment. After getting the payload in stable orbit, but before the lifter was recovered, I switched back to the Space Center, then went to the Tracking Station. I watched the lifter make several orbits, going all the way down to 14km and back up to 198km. Then I switched back to the payload. If the lifter was below the 25km line and thus deleted by KSP, SR *did* process the vessel correctly. So it would seem that you don't have to stay with the vessel after a decoupling event; if you leave Flight, it will be immune from deletion while it proceeds on rails, but when you return to Flight, it correctly gets deleted and SR does work.
@linuxgurugamerand @magico13make great code. But I think we all know that.
-
Just now, linuxgurugamer said:
Really?
As long as my cats count as peer reviewers.
-
Just now, DeadJohn said:
That's an interesting observation.
You were on a 200/20km orbit when you decoupled below 70km. The lifter was still in physics range while in atmosphere. Drag would have cause the lifter's orbit to decay and reduce Ap to something less than 200km. Maybe that was just enough to reduce reentry speed below your Stage Recovery heat settings?
200/20 sounds like too high an orbit for SR to recover with default settings, but all of my recent KSP has been with the JNSQ planet pack so I'm not sure about stock.
Well, to be fair to by rigidly controlled and fully scientific experiment, my AP was rarely at 200km at the time of decoupling. I was mostly testing for PE, not AP, so the AP varied from a low of 84 to a high of 180 (after decoupling, I targeted the lifter and noted the AP/PE after it left physics range). 200 was the final AP for the payload. However, AP didn't seem to matter at all. The only difference I experienced (again, in my peer-reviewed and journal-ready) experiment was as reported: decoupling events below 70km resulted in success, above resulted in failure with orbital speeds reported in the dialog.
I am *not* suggesting that anything is wrong with SR, nor that my observations should be taken without a ton of salt. The only thing I *did* do (without being sarcastic) is run the test multiple times, so I am relatively sure that what I observed, on my rig with my modified install, was an accurate representation of how SR works (again though--on my rig with my modded install).
-
On 3/7/2022 at 7:58 AM, eightiesboi said:
Hey @linuxgurugamer!
I have a question regarding expectations. I am not reporting a bug. A lifter body with an active probe core and sufficient parachutes (per SR in the VAB) is decoupled with an AP of 200,000m and a PE of 50,000m. There is still fuel in the tanks at the time of recovery, although probably not enough to recover completely without the use of the attached chutes. What should I expect to see when the payload gets out of physics range of the lifter?
- An attempted powered recovery? (likely unsuccessful, as insufficient fuel remains)
- An attempted unpowered recovery? (likely successful, as sufficient parachutes exist)
- Nothing? (No ground intersect, so once out of range, it remains on rails)
- Something else?
Ladies and gentlemen, the results of my experiment:
AP/PE (km) Decouple below 70km? Result 200/50 Y #3 200/50 N #3 200/20 Y #1 (pass) 200/20 N #1(?) (fail) Parameters of experiment: Lifter with probe core, engine, fuel, and parachutes was decoupled from payload either above or below 70km, as noted above. @DeadJohnwas 100% correct; if the lifter's PE was below 25km, when KSP deleted it as it passed through 25km, Stage Recovery processed it. If the lifter's PE was above 50km, it stayed on rails regardless of the parameters of its "orbit".
One oddity: when I decoupled the lifter from the payload below 70km, SR recovered the lifter without problem and indicated a propulsive recovery. However, when decoupled above 70km, SR did process the lifter when it was deleted from the game but invariably noted it was destroyed due to excessive speed, as shown here:NB: This was later determined to be due to difference in altitude during the decoupling event.The only difference between successful recovery and failure that I was able to note was that in each incidence where the lifter was decoupled below 70km, recovery was successful. Likewise, in each incidence where decoupling occurred above 70km recovery failed. In my totally inexpert opinion, I would like to note that the velocity indicated (2276 m/s) looks like the orbital velocity at the time the lifter was decoupled. I would speculate that once you've crossed the border from "flying high" to "in space low", the velocity that SR uses to decide if the recovery was successful changes.However, I may be *totally* wrong about this. NB: I was.@linuxgurugamer, I hope you find my little experiment interesting. If nothing else, it seems to show that if one wants to use Stage Recovery, one must make certain that any craft to be recovered has a PE (on Kerbin, at least) below 25km. It also may help with successful recovery if the decouple event occurs before crossing the border between flying high and in space low.
-
I apologize in advance for not responding directly to the OP. However, this thread has been sleeping for over a year and a half and has turned into a discussion of the merits of Tweakscale instead of being about the mod. Please note that I hold both modders and moderators in high regard and that absolutely nothing that I am about to say is meant to be a disrespect to either of those groups. Without modders who continue to create and maintain the dazzling array of mods available, KSP would not be the fantastic game that it is. And without moderators to keep the forum well-organized, we might have long descended into toxic anarchy.
On 3/6/2022 at 11:20 AM, adsii1970 said:The current modder who has taken up Tweakscale has added things to the mod that I find too obtrusive for me. They have a strong dislike and are very unhappy with how ModuleManager works and is trying to convince everyone to switch to their version of ModuleManager. So, every time you fire up KSP with their updated Tweakscale loaded, you get this:
First, I am familiar with @Lisias and with Tweakscale (both the mod and the forum post). I haven't seen Lisias state a "strong dislike" or being "very unhappy" with ModuleManager, other than discussing some of the things that MM does or does not do well. I've also not seen Lisias try to convince anyone, much less "everyone" to switch to any version of MM other than the official one. And it is certainly not true--at least for me--that Tweakscale displays the aforementioned message on loading (in fact, I have never seen that message in my own, moderately modded install). Unless you have evidence to the contrary, everything stated here is unsupported allegation at best, demonstrably false at worst.
On 3/6/2022 at 11:20 AM, adsii1970 said:But it certainly is better than being forced to use another version of ModuleManager when the one I am accustomed to, with all of the updates and patches and occasional quirks, has worked so well.
To my knowledge, I have not been forced to use another version of MM. The only version I have loaded, per my log, is the official 4.2.1 version. Therefore, unless you have evidence otherwise, this statement is false.
[snip]
-
2 minutes ago, linuxgurugamer said:
At what point do you decouple? On the way up to 200km? Do you stay with the initial vessel until the lifter body gets down to 50km?
I really don't know, would be interested to hear the results. You do need to stay with the initial vessel until the lifter body gets recovered or destroyed by the game, though. On the assumption it's on the way up, I'm not sure what would happen.
I will try it and report back. My inclination was to decouple just before transition at 70km, but I could try something else if you'd like me to do so. I am going to predict that "#3 - Nothing happens, because there's no ground intersect and the vessel is on rails" will be the winner. I'm not willing to bet money on it though!
I'm doing my taxes ATM, so I won't get to play around with this until tonight. But I'll post my results this evening. Thank you!
-
Hey @linuxgurugamer!
I have a question regarding expectations. I am not reporting a bug. A lifter body with an active probe core and sufficient parachutes (per SR in the VAB) is decoupled with an AP of 200,000m and a PE of 50,000m. There is still fuel in the tanks at the time of recovery, although probably not enough to recover completely without the use of the attached chutes. What should I expect to see when the payload gets out of physics range of the lifter?
- An attempted powered recovery? (likely unsuccessful, as insufficient fuel remains)
- An attempted unpowered recovery? (likely successful, as sufficient parachutes exist)
- Nothing? (No ground intersect, so once out of range, it remains on rails)
- Something else?
Follow-up question: does SR continue to process for vessels that have been unloaded from prior launches? That is, if I have a lifter that's drifting on rails from a launch of a different (not the current) vessel, will SR process that vessel or is it effectively a ghost ship? If the latter, can I call it and its brethren "The Flying Kutchmen"?
Thank you so much for the work you do!
PS - I know that FMRS exists and I've benefitted from it many many many times, but I am only curious about SR in this scenario.
-
31 minutes ago, Starwaster said:
Found it.
I commented out the entire section referenced below. I probably commented rather than outright remove because I wasn't sure I wasn't totally screwing something up, but the impact was such that I stopped ever thinking about it for four years until you reminded me.
So the effect apparently wasn't exactly catastrophic.
First, I am definitely not a coder, but I don't see why that little snippet of code exists. It does seem like the likely culprit. I don't have the tools installed to compile the code right now, but maybe I will download them this weekend, comment out that section, and then see if it kills my problem without causing any new ones.
Thanks, Starwaster.
-
3 minutes ago, Starwaster said:
So I started up KSP and loaded up a craft because it's been long enough that I really don't remember what SmartRCS does (other than the post of mine you quoted)
Apparently I don't have that problem anymore and I don't remember what I did to eliminate it. I'm using a custom MJ2 branch because I didn't like certain changes that were made and also to test out certain ideas that I had been thinking of submitting but never did.
Anyway, I suspect that I hacked on SmartRCS to prevent it from making changes to my RCS at all (I probably just literally am not allowing it to touch my RCS at all)
I'm still looking to see where in the code I did that.
If you find it and you don't mind sharing, that would be fantastic!
-
Just want to share this with the community. As presented, the top node is impassible with CLS. That makes sense, as the real Gemini, IIRC, had parachutes in the top part of the capsule; thus, it would have indeed been impassable. However, since this one doesn't have main and/or drogue chutes in its snout, I decided my head canon allows a departure from reality. If you want to slap a clamp-o-tron jr (or similarly sized) docking port on the top node, and you want your Kerbals to be able to crawl on through without an EVA, then I recommend the following change to the MM_ConnectedLivingSpace.cfg file in the "GameData\JFJohnny5\MM_Patches" directory:
Spoiler@PART[K2Pod*]:NEEDS[ConnectedLivingSpace]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
MODULE
{
name = ModuleConnectedLivingSpace
passable = true
impassablenodes = bottom //Changed by eightiesboi from impassablenodes = top , bottom
}
}
You can also make this a separate MM patch without touching the original config, of course, but then (AFAIK) you need to add ":FINAL" or ":AFTER[JFJOHNNY5]". (If I am wrong about that, please someone correct me.)
As always, thanks to the Maintainer of Many Mods, LGG, for making KSP even better.
-
10 hours ago, tremonthedgehog said:
ok fair but it make the part invalid, unusable, and unseeable. Also module manger is up to date pls help me
edit: could you please maybe provide a version that works? Thanks so much if you do
Hi @tremonthedgehog! I see you've been around the forums for only a relatively short time. There are *a lot* of people here that are willing to help you, and the community is pretty amazing overall. But if you're having problems, you need to make it possible for others to help you find and fix them. You've actually made a good start by specifically mentioning the behavior you are seeing (i.e., you are unable to find a part). But to figure out what's going on, we need logs. Follow this link:
and then upload your logs to a hosting service (like dropbox, onedrive, or google drive). Post the link to the log, not the log itself. And don't just take a snippet of the log, as that doesn't help as much as you might think.
There really are only four categories of possible reasons for what's happening in your game:
- A bug in the mod
- A bug in KSP
- Another mod is actually causing the issue (for example, by moving items in the tech tree)
- User error (looking for the item in the wrong place, failing to install dependencies, etc)
In my experience, #4 is the most likely reason, followed by #3. While some mods *do* have bugs, big ones (like major parts missing in popular mods) are usually reported and verified pretty quickly after a mod update. As far as I know, you are the only person that is experiencing this, which makes #3 and #4 even more likely, especially because I saw that you've posted that parts from other mods are also not showing up in your game. But if you post a link to your logs, it's *very* likely that someone knowledgeable will try to help......
However, one thing to always keep in mind. Mod authors owe us, the KSP community, nothing. They don't have to share their labor with us, they don't have to fix things we think are wrong, and they don't have to respond to us on the forums. Most of the mod devs here do all those things, but they don't *have* to. When you post in a forum making claims about a mod without any proof, you aren't really helping. So, my advice is, again, follow the link I included, post a link to your logs, and don't forget to thank Nertea and any other mod author you come across for helping make KSP the fantastic game it is.
-
Hi @linuxgurugamer and everyone else!
I wanted to share this. I use both the Aviation Lights mod and Crew Light. I like having all my lights have the motion detector functionality, but the option wasn't in the PAW for the new Aviation Lights part. So, I changed ModuleMotionDetector.cfg in Crew Light to add:
Spoiler// Trying to add motion detector to aviation lights
@PART[*]:HAS[@MODULE[ModuleNavLight],!MODULE[ModuleMotionDetector],!MODULE[ModuleStatusLight],~CrewCapacity[]]:FOR[CrewLight]
{
MODULE
{
name = ModuleMotionDetector
motionDetectorEnabled = false
range = 5
timer = 15
}
}It seems to work just fine, although I haven't tested it much. Just wanted to share this in case it helps anyone.
LGG, thanks for keeping so many mods going!
-
@Snark I don't know if it helps at all, but logs here: https://1drv.ms/u/s!AoyHZiRU1jT-z5F1TM6AWgE2L5oynw?e=4uejTG
I just started the game up and let it run for a few minutes with a couple of scene changes. Obviously, I am running more than a few mods but my logs are pretty clean. I can also set up a test run if it helps. The one thing I can't do is code, so I am useless for that, but let me know if there's anything else I can do to help. Thank you!
-
On 2/26/2022 at 2:04 PM, Snark said:
Hi all,
I'm pleased to announce the release of PlanetInfoPlus 1.3.1.
This one has no new user-facing features in normal gameplay for most users, but it does add two new things:
-
French localization. Merci beaucoup à @vinix for generously supplying this!
- Ability to dump planetary "max elevation" data to a file. As has been discussed in the preceding page or so of posts on this thread. Thanks to @flart for the suggestion.
You can access the data-dump function via the Alt+F12 debug console. Open the console, and issue this command:
/pip dump
This will cause the mod to write a file, PlanetInfoPlusDump.cfg, into whatever folder the mod's installed in. Here's what it looks like, for example, when I run it with the New Horizons mod installed:
// PlanetInfoPlusDump.cfg
// This file is auto-generated and will be overwritten. Do not hand-edit.
//
// Highest points of KSP celestial bodies, as calculated by PlanetInfoPlus
//
// 32 bodies present in fileMAX_ELEVATION
{
name = Aptur
elevation = 16077.4941974379
latitude = -1.05196726682755
longitude = 86.3388418018286
}MAX_ELEVATION
{
name = Arin
elevation = 7545.89933093963
latitude = 3.5926123289759
longitude = 176.067793502226
}MAX_ELEVATION
{
name = Astid
elevation = 13843.6335833912
latitude = -36.554022912912
longitude = -122.343702276544
}MAX_ELEVATION
{
name = Atell
elevation = 13856.4955536686
latitude = -62.5780546023758
longitude = 107.578001002621
}MAX_ELEVATION
{
name = Bop
elevation = 21757.6602041329
latitude = 23.8825053620375
longitude = -64.5673345251739
}MAX_ELEVATION
{
name = Derso
elevation = 12492.4224267485
latitude = 13.5047697568921
longitude = 112.067186912557
}MAX_ELEVATION
{
name = Dres
elevation = 5670.309878378
latitude = -84.979263109466
longitude = 42.6098668846923
}MAX_ELEVATION
{
name = Duna
elevation = 8268.86505027115
latitude = 20.8982062395276
longitude = -106.800427436916
}MAX_ELEVATION
{
name = Eeloo
elevation = 3868.35930906259
latitude = 24.3404188921954
longitude = 27.9523093799084
}MAX_ELEVATION
{
name = Eli
elevation = 13352.3008717702
latitude = 8.4883565134239
longitude = -36.8129762037255
}MAX_ELEVATION
{
name = Ernus
elevation = 8110.06572621933
latitude = 1.93351103215481
longitude = 179.472684756063
}MAX_ELEVATION
{
name = Etal
elevation = 35040.8385682161
latitude = -57.9940060654945
longitude = 76.8788715879396
}MAX_ELEVATION
{
name = Ete
elevation = 3023.49038124084
latitude = 5.46760631472165E-05
longitude = -180
}MAX_ELEVATION
{
name = Eve
elevation = 7541.24574347341
latitude = -24.994949011724
longitude = -158.474660874084
}MAX_ELEVATION
{
name = Gilly
elevation = 6400.98153515043
latitude = -29.2433253127642
longitude = -123.889593756272
}MAX_ELEVATION
{
name = Ike
elevation = 12738.3322681647
latitude = 25.2566390113354
longitude = 178.289946187111
}MAX_ELEVATION
{
name = Kerbin
elevation = 6768.59174087178
latitude = 61.5966960705499
longitude = 46.3594821624808
}MAX_ELEVATION
{
name = Lave
elevation = 34063.952459989
latitude = 0.0879033232651164
longitude = 99.9419648613264
}MAX_ELEVATION
{
name = Laythe
elevation = 6073.54642105289
latitude = -17.5781255290504
longitude = 172.56725421008
}MAX_ELEVATION
{
name = Leouch
elevation = 9897.27287654518
latitude = 57.0951898867443
longitude = -122.947581896224
}MAX_ELEVATION
{
name = Levy
elevation = 15166.6626653135
latitude = 5.49855456737566
longitude = -124.036799787317
}MAX_ELEVATION
{
name = Minmus
elevation = 5724.60000000001
latitude = -62.9394721912
longitude = 74.7718127609952
}MAX_ELEVATION
{
name = Moho
elevation = 6828.21774258424
latitude = 54.5650702355627
longitude = 149.573085050297
}MAX_ELEVATION
{
name = Mun
elevation = 7064.47305365134
latitude = -82.5122293995637
longitude = -152.401805994757
}MAX_ELEVATION
{
name = Nolas
elevation = 8667.53222448012
latitude = -12.2291845203345
longitude = 174.734317083903
}MAX_ELEVATION
{
name = Oree
elevation = 11186.0880610264
latitude = -32.0918226115234
longitude = -123.142705328924
}MAX_ELEVATION
{
name = Pol
elevation = 4891.2810274427
latitude = -62.814479485114
longitude = 164.565391732729
}MAX_ELEVATION
{
name = Serran
elevation = 7966.47304189322
latitude = 0.639364853575464
longitude = 120.702936408624
}MAX_ELEVATION
{
name = Tidus
elevation = 8314.40630682523
latitude = 45.7361829270588
longitude = 17.6990998353796
}MAX_ELEVATION
{
name = Titanus
elevation = 7888.37537673255
latitude = -4.41674733113386
longitude = -62.7562990416902
}MAX_ELEVATION
{
name = Tylo
elevation = 12904.6663088199
latitude = -28.8813181357037
longitude = -171.998200075779
}MAX_ELEVATION
{
name = Vall
elevation = 7994.06984259601
latitude = 25.8542849534857
longitude = -33.9000964671635
}Note that executing this command will force the mod to go ahead and (expensively) calculate the max elevation point of every single body in the system that isn't already pre-calculated. So, depending on how fast your machine is and what percentage of bodies have already been pre-calculated by the time you run the command, it might lock up the game for up to several seconds. (On my machine, fully calculating the entire New Horizons system with 32 solid planets takes around 10 seconds total, for example.) So, if you use that command, give it a few seconds and don't think your game is crashing.
Enjoy!
Hey @Snark!
First, thank you.
Second, what does it look like when it calculates max elevation? Every 2-4 minutes, I get this in my log:
Spoiler[PlanetInfoPlus] Read cache timestamp: 637815173177486543
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Bop: 21757.6602041329 m at lat=23.8825053620375, lon=-64.5673345251739
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Dres: 5670.309878378 m at lat=-84.979263109466, lon=42.6098668846923
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Duna: 8268.86505027115 m at lat=20.8982062395276, lon=-106.800427436916
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Eeloo: 3868.35930906259 m at lat=24.3404188921954, lon=27.9523093799084
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Eve: 7541.24574347341 m at lat=-24.994949011724, lon=-158.474660874084
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Gilly: 6400.98153515043 m at lat=-29.2433253127642, lon=-123.889593756272
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Ike: 12738.3322681647 m at lat=25.2566390113354, lon=178.289946187111
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Kerbin: 6768.59174087178 m at lat=61.5966960705499, lon=46.3594821624808
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Laythe: 6073.54642105289 m at lat=-17.5781255290504, lon=172.56725421008
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Minmus: 5724.60000000001 m at lat=-62.9394721912, lon=74.7718127609952
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Moho: 6828.21774258424 m at lat=54.5650702355627, lon=149.573085050297
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Mun: 7064.47305365134 m at lat=-82.5122293995637, lon=-152.401805994757
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Pol: 4891.2810274427 m at lat=-62.814479485114, lon=164.565391732729
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Tylo: 12904.6663088199 m at lat=-28.8813181357037, lon=-171.998200075779
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)[PlanetInfoPlus] Read max elevation of Vall: 7994.06984259601 m at lat=25.8542849534857, lon=-33.9000964671635
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)
I've noticed some minor stuttering when this is happening (I am literally playing as I type this). I am *not* trying to force recalculation or do anything other than play. If this is normal, then let me know and I will disregard. If not, I will provide a clean log and also try rolling back to 1.3 to see if there's any difference.
Thanks!
-
French localization. Merci beaucoup à @vinix for generously supplying this!
-
4 minutes ago, ColdJ said:
Just to be clear, are you saying that if you set the thrust limiter to allowing no thrust whatsoever (using the slider, not the rcs actuation toggle)That mechjeb can change the slider and bring it back up?
Also what happens if you only have RSC that point forward and backwards, it can push and pull and yaw on a flat plane but you would need the reaction wheels to roll?
No, that's not what I am saying. If I set the thrust to zero or individually disable the RCS in the PAW, then Mechjeb doesn't change it. However, means I also can't use them when I need to use the RCS without turning them all back on individually (in the case of disabling them) or touch the thrust slider for at least one thruster in a symmetry group.
As far as having RCS that only point forward and backwards, yes, Mechjeb will enable them and use them for rotation control, but pitch and yaw only though (obviously, roll is not a factor). So that doesn't help me and takes away the main thing I use RCS for, fine translation control.
My problem is exactly what sarbian said:
On 2/25/2022 at 12:25 PM, sarbian said:There is no need to diagnose anything. SmartRCS disable rotation or translation by changing the RCS config. It does not save the original config and so it can not restore it when switched off. Saving the conf is not trivial, but far from impossible. The main issue is people willing to code it. I am not among those people.
I guess one fix for me would be if I could disable the SmartRCS module itself, but I don't see a way to do that in the config files that I can touch. I am fine disabling rotation on RCS through an MM patch myself. I mean, that's what I already have done, but Mechjeb wants it to be on.
One also possible fix might be (if I understood what sarbian said) to set the default so that SmartRCS (when set to disable rotation) defaults to toggling rotation off, instead of defaults to toggling it back on. I don't know. In the end, Mechjeb is very useful and still worth it even if keeps turning my RCS rotation back on.
-
1 minute ago, ColdJ said:
Just an outside the box thought for a sec. Build using single direction RCS units. You can either leave ones for roll completely off or otherwise set them to zero thrust limited when you don't want them used. As they are individual they don't need to use the method that mechjeb seems to be overiding. The modern KSP variants mean you can also use ones with only 2 nozelles for forward and backward so as to reduce parts.
That's a good idea, but it doesn't work. The single direction RCS has the same toggles and suffers from the same issue. Here's another video that shows what I am talking about, and I apologize for getting your name wrong (I called you ColdP instead of ColdJ!). Notice that in this case, I was yawing, not pitching or rolling. Any rotation seems to reactivate the disabled settings.
https://1drv.ms/u/s!AoyHZiRU1jT-z5F036PL2GuwB1B3Uw?e=A6Cq4P
-
4 minutes ago, darthgently said:
I never find that I need to roll quickly in space, so rarely use RCS for rolls and rely on reaction wheels for that. Most cases I see are that RCS is mostly only necessary for pitch, yaw, and translations. I think you may have too much control authority for the roll so the MJ PID is overshooting. You can adjust the PID values iirc (I haven't used MJ in awhile since getting more up to speed in kOS) but it would probably be easier to disable the roll actuation toggles in the part pop-up window on your thrusters. But if your reaction wheels aren't enough to roll, and the RCS is too much, then adjusting down the overall thrust limiter of your thrusters in the part pop-up window could help; especially if the roll thrusters are separate linear thrusters, then it would be a no-brainer
Hi! I appreciate your response, but I think you may have misunderstood my issue. I am not trying to use RCS for rotation. I am trying *not* to use RCS for rotation. RCS rotation (roll/pitch/yaw) is disabled (by me, intentionally), both in the actuator settings and in the Mechjeb settings. However, Mechjeb appears to be rapidly toggling it on and off, and then leaving it on.
-
7 minutes ago, Starwaster said:
I think the solution was not to use smart rotation.... Honestly I don't remember what I do about it for myself. I'll look into it
For what it's worth, here's a short video clip so what I am describing is clear. You can see on the left that SmartRCS has "Use RCS for rotation" unchecked. On the right you can see that Yaw, Pitch, and Roll are all set to "Off" on my RCS Thruster Block. When I roll the ship, everything is fine until I stop rolling (with SAS on) and the reaction wheels kick in. Then RCS toggles rapidly between on and off until the ship stops rolling, and then stays on. Same with a pitching movement.
Video clip: https://1drv.ms/v/s!AoyHZiRU1jT-z5Fwsq8fCkZdBpqGwA?e=zFmOBF
I threw the logs in the same folder, just for fun, but I captured this during a play session, not in my (clean) test environment: https://1drv.ms/u/s!AoyHZiRU1jT-z5FvLjmi4BIhDEw8eA?e=ycPw5k
I'd appreciate any suggestions anyone might have.
In that spirit, if you want to add ablative shielding to the NF pods, you might want to either look at how DRE added it (check out the DeadlyReentry.cfg and look at the line for "@PART[mk1pod|mk1podNew|mk1pod_v2]:FOR[DeadlyReentry]" for an example), or you could look at what Squad does on their pods (an example can be found in the KV1Pod.cfg, and either add an MM patch [the best practices method] or copy/paste the ModuleAblator and Resource blocks right into your command pod of choice [not generally a good idea]).
[1.7.3] Community Delta-V Map 2.7
in KSP1 Tutorials
Posted
I disagree with one thing you said:
Thanks for helping keep up KSP. I rarely comment anymore, but this was worth crawling out from my cave. :)