King Arthur
-
Posts
314 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by King Arthur
-
-
4 minutes ago, JadeOfMaar said:
CRP itself is just a bunch of configs and only adds resources to your game. It doesn't reduce Ore's availability. It doesn't change your game on its own. It doesn't subtract performance. In this case it's very safe to install and uninstall. However, it is a "foundational" mod, massively important, required by nearly every mod (Many, many mods. Prepare to lose your socks.) that uses resources other than the stock set. It's a "set and forget" thing. Once it's installed you don't have to think about it again and it's always doing its job.
CRP is very safe to install, and is very safe to uninstall as long as: You haven't settled into using heavily game-changing mods already; You've uninstalled these heavy mods; Or you're ready to abandon your playthrough.
So I wouldn't have something like, say, "I installed CRP but the new resources (when applicable as dependencies) don't show up in resource distribution" and other such "variables initialized only at new game start"-esque shortcomings I often see in other games? Asking because I sincerely am not familiar (yet) with how KSP handles this, and a lot of other games usually choke or fallback on these modified-after-the-fact things.
In any case, it's good to know that this doesn't seem to be the case for KSP and I can install CRP with minimal worry, if any. Thanks, this further opens up the range of mods I can try out now.
-
Would installing the CRP have any ramifications for an ongoing save file? I saw that the CRP messes with resource distributions in planets and asteroids, and I'm not familiar with how that system works as far as resource distributions getting changed mid-game.
A few mods I'm interested in trying out have the CRP as a dependency, and I would like to know if the CRP is safe to (un)install on the fly.
-
Also having problems with soil recyclers demanding EC during timewarps at 100x and higher, despite running Dynamic Battery Storage. I don't mind it too much since it's mostly an aesthetic problem, though right-clicking away the messages gets old fairly quickly.
I'm almost tempted to just remove EC consumptions from resource converter modules, which soil recyclers use... :V
-
2 minutes ago, Jognt said:
You don’t need to fiddle with those cfgs. Check out the white/blacklist system.
I would need to mess with the CFGs since the black/whitelist is completely separate from the actual ModuleManager patching of stock part CFGs. I could whitelist the stock Vector for example, but unless I also remove or modify the 1.25m engines CFG containing the Restock Vector I'm still not going to get the stock Vector back.
As far as I can tell, Restock would presumably still work if I were to just take out the black/whitelist system wholesale; it's only there as a RAM- and load time-saving measure. The actual stock parts replacement is done by ModuleManager CFGs, which are all centralized rather than individualized.
-
I don't think so, since my plan is to have both the stock and Restock heatshields side-by-side rather than the latter replacing the former. If that doesn't work out though, I'll make sure to replace the stock Mk1-3 too.
-
3 hours ago, Nertea said:
If you want to get technical there is a soft dependency for Restock in everything I make because they all target the porkalike style. However there is no expectation of needing it installed to have good results.
For this case, you absolutely need to use the tweak gizmos in stock. The way the stock heatshield and pods were designed tends to be as a single unit - placing them on other parts or specifically capsules that have a different bottom node layout (one that is logical rather than really, really stupid) results in visual problems. This is most visible with the 2.5m and 1.25m ones. I have obviously fixed this with Restock, but the options for this mod with many new capsules are:
- Design the bottom of each pod to be identical to the stock one (attach node protruding far out, strange bulge, inconsistently angled sides)
- Place a second special heatshield-only attach node to use with the stock heatshield
- Include a new, fixed heatshield model with adjusted nodes
- Accept that you will need to use the offset gizmo to align the heat shields with the bottom correctly
To me there's no contest - (1) means pods will all look weird at the bottom, (2) is player confusing and (3) is basically what Restock does. That leaves (4), which uses what I would consider to be a well-known player friendly solution.
I mean I can clarify that in the FAQ I guess, but there's no perfect solution. I believe I have a long Discord rant about there being no optimal solution somewhere.
Roger that, appreciate the reasoning behind it.
As a personal workaround, I'll see about taking the Restock heatshields and using them as a separate standalone mod rather than a stock-replacer for my own personal use with NFSpacecraft, since I find using the tweak gizmo for this kind of thing to be tedious and above all inconsistent.
51 minutes ago, Nertea said:Two more bugfix updates
NFLV 1.2.3
- Updated B9PartSwitch to 2.10.0
- Fixed incorrect labeling of Buzzard's Compact and Boattail variants
- Restructured how RealPlume FX is handled (Zorg)
NF Electrical 1.0.3
- Updated B9PartSwitch to 2.10.0
- Updated DynamicBatteryStorage to 2.0.6
- Made use of B9PS 2.9+ features for reactors (colours, labels)
Thanks!
-
6 hours ago, Zorg said:
Everyone is of course entitled to their own opinion of what they like but its not really fair to the say the stock version of the plume is more "true" to the SSME than ReStock
My impression of the SSME is mostly from this wonderful picture of the RS-25 SSME (courtesy Wikipedia):
The stock Vector's plume is predominantly blue (perhaps too blue as it gets farther from the nozzle, I admit), whereas I find the Restock Vector's plume is predominantly red. This is going to be a case of YMMV, since everyone is entitled to their opinions, so I just prefer the stock Vector's take on the RS-25 SSME and find it more accurate as far as I'm concerned.
I'm not raining on anyone, just to be clear. This is really just a matter of my own taste and thoughts, especially since KSP is more about just having fun rather than being 100% realistic.
1 hour ago, Foxxonius Augustus said:It is my understanding that ReStock uses a 'blacklist' and a 'whitelist' that lets you control what parts are loaded. At least as far as I know. More info can be found on this page of the ReStock wiki. Some one who knows more about how it works can probably help you if you run into trouble.
Also:
Many of the foiled parts have alternate texture variants that might be more to your liking, they even use the stock variant switch mechanic!
Restock uses a very different, more centralized file structure compared to stock and most other mods. Whereas stock and most mods organize parts by category>individual-part and keep the part's CFG and associated models and textures together, Restock centralizes assets (models and textures) and CFGs separately, and only goes as deep as organizing by categories (all the 2.5m fuel tanks' definitions are under one CFG and its assets all in one 2.5m fuel tank directory, for example), and the blacklist is similarly centralized in one file rather than individually defined per part.
I can certainly see that I can pick apart Restock given enough time and willpower, but it's a lot more tedious than just removing the directory structure for parts I don't want.
-
I gave Restock and Restock+ a trial run to see if it's something up my alley. Personally, I found it a mixed bag.
Some of the changes I really loved, namely most of the fuel tanks and some of the engines like the Twin Boar. Given that fuel tanks make up the majority of an average rocket (hah), the visual improvement really goes a long way. Clipping fixes for things like the Z-4K battery are also great to have.
On the other hand, I hated the "foiled" parts like the HECS2 probe core and toroidal fuel tanks, and I found the stock Vector (specifically the plume) to be much more true to the RS-25 SSME than the Restock version.
I also really, really, really dislike the Restock version of the Aerodynamic Nose Cone:
Left: Stock, Right: Restock. The stock nose cone and Mk3 Cockpit are flush with each other, making a beautiful and smooth aerodynamic line, but the Restock version ruins it. Yes it's minor, but I find great pleasure in these small details lining up.
Overall, I wish Restock was modular so I could easily pick and choose what I want from it. There's a lot of good and a lot of disagreeable stuff in here. I also wish Restock+ didn't have a hard dependency on Restock, because those parts (obviously) scratch an itch that stock (and even a lot of stockalike mods) doesn't.
-
On 9/9/2019 at 6:58 PM, Nertea said:
This is a thing for the Restock thread I guess, but retexturing and remodeling are not functionally different. Great care has been taken to leave colliders and gameplay untouched (at great personal stress levels to the team I might add). If you have concerns or problems with this or discover actual inconsistencies please let us know. In the past there were a lot of problems reported, but ironically these usually turned out to be problems with other mods compensating for stock inconsistencies (eg. RealChute, RealPlume, FAR caused issues in the past).
That's fairly untrue. Everything is was modernized within the last year. Again, please let me know what the specific issues are so I can address them.
So I finally bit the bullet and installed Restock/Restock+ for a trial run to see what it's like. As I found out, the restock'd-stock heatshields work perfectly with the NFSpacecraft command modules (stock heatshields otherwise have hideous clipping). While it is not my intention to sound ungrateful or anything, I would appreciate it if Restock was listed as a soft dependency if the expectation for NFSpacecraft (and other NFT mods...?) is that it's to be used with Restock.
I'll leave my thoughts on Restock/Restock+ proper (if any) for its thread, as that would be ill-suited for here. :V
-
16 minutes ago, mikegarrison said:
I'm not sure what the problem is you are worried about. Is it visual or gameplay?
Gameplay. I feel anything that delves into remodels and spec changes should be a mod separate from stock (ie: ReStock+) rather than a stock-replacer. Retextures are great, they change nothing tangible, but model and spec changes not so much.
-
10 hours ago, Foxxonius Augustus said:
I would recommend using ReStock and ReStock+, the stock heat shields don't even line up well with the stock pods.
I'm a bit hesitant on using ReStock since, from what I understand, there are subtle remodels and respecs in addition to just simple retexturing. I would prefer to leave stock parts' gameplay as untouched as possible (additions to accomodate mods notwithstanding, of course). Not to mention that there seem to be a number of significant bugfixes waiting on a 0.2.0 release anyway, judging from its Github issue tracker.
This isn't the ReStock thread though, so I digress. Appreciate the suggestion though!
Was basically looking for a 4-man command and 3-man lander modules to make a slightly sized up "Apollo"-esque mission, but I ran into a dead end as far as using NFSpacecraft since a lot of it seems to be holdovers from before re-entry heating and all the newer (well, "newer") stuff in KSP nowadays. Love the rest of NFTechnologies, but NFSpacecraft is still waiting on a bit of modernization, I guess.
-
I'm kind of confused what the intended use-case for the command modules in NFSpacecraft is supposed to be. None of the stock heat shields appear to fit nicely (especially the Mk4-1), so are these in-orbit use only unlike the stock Mk1-3?
-
I had this happen to me a couple times when I made the structural fuselage (which I thus discovered was non-physics) the root of my fake asteroid
The Structural Fuselage is not a physicsless part.
-
Hitting CTRL+Z should allow you to undo stuff. Be warned though that this is very flaky, more often than not you will likely summon the Kraken for tea.
-
The music selection in KSP really reminds me of The Sims, personally.
-
^ https://en.wikipedia.org/wiki/Lockheed_P-38_Lightning
Great minds certainly think alike.
-
There are some neat ideas here. I especially like King Arthurs piggy back plane. I'm not sure what purpose it serves but it does look cool.
Originally the piggybacked Mk2 shuttle was launched STS-style like so:
However, that launcher is expendable. I wanted to make a recoverable, reusable launcher to cut down on costs, so I made those carrier shuttles. The Mk2 shuttle itself carries a crew of 6 and has a full-size Mk2 cargo bay for carrying stuff, as well as hauling other smaller ships around via its junior docking port on its underside.
-
Given that a lot of fuel flow logic and node handling needed to be rewritten with 0.90, among other things, I doubt that any of the MJ builds for 0.90 will work properly in 0.25.
-
^ Magnificent.
-
This is a bit off topic, but it shows how silly the layout of the KSC is. Normally the hangar would have the flight line in front of it, and taxiways leading alongside the runway to either end at minimum. According to the current layout, the planes are either towed into position or the planes are literally taxiing to the end and then performing a 360 in that tiny little space. I agree, there are MANY designs that wouldn't survive that and most of them aren't even that impressive!
It's perfectly fine and normal operating procedures for smaller airports to have aircraft use the runway(s) as a taxiway, and even something as huge as the Boeing 747 can perform a 180 at the end of the runway. Granted, KSC is not a "small airport" given what its facilities are for, but yeah.
-
Choice #1 for everything.
Except when I'm "simulating" stuff, then it's revert-ahoy.
-
I'll just leave these here:
Javascript is disabled. View full album
The above has since been succeeded by a B9 SSTO design as it performed better and proved safer to fly, as follows:
Javascript is disabled. View full album
They are both reusable carrier shuttle launchers for the smaller Mk2 shuttle that's piggybacked.
------
- No appropriate nose cones
- No appropriate wings
- No appropriate landing gear
- No appropriate sized jet engines or multi adapters for existing ones
- All fuel is inline making for a massively long plane.
1. Aerodynamic Nose Cone.
2. Mk2 wings can lift the Mk3.
3. Easy enough to make your own double-sized copy of the stock landing gear.
4. Mk3->2.5m adapter into multi-couplers/engines.
5. Same goes for all other stock parts, though.
- No appropriate nose cones
-
That did not test upgrading from KJR 2.4.5 to 3.0.1 so did not attempt to reproduce the problem.
Ah, I missed that part. My bad, will go and test that (and edit this post once I get something post-worthy).
---EDIT---
Mod present: KJR 2.4.5 -> 3.0.1
Steps to reproduce:
1. Made a new blank sandbox save, KJR 2.4.5 installed.
2. Launched Kerbal X to orbit.
3. Exited, deleted KJR 2.4.5, installed KJR 3.0.1.
4. Booted up KSP after KJR 3.0.1 install, loaded save with Kerbal X in orbit.
5. Switched to Kerbal X via Tracking Station.
6. KJR did its magic.
7. Nothing out of the ordinary happened.
The end result was that, once again, KJR did not do anything bad or not intended to a pre-existing Kerbal X, in an environment where no other mods were at play.
The logs:
http://rpgmaker.net/media/content/users/6088/locker/245_output_log.txt
http://rpgmaker.net/media/content/users/6088/locker/301_output_log.txt
-
Wait, all of the reports require already-existing ships? If that's the case, why didn't anyone else mention that? That could be really important!
But KJR doesn't save anything that could be reloaded anyway... so what?! How?
This sounded easy enough to test and try reproducing, so I tried the following to see if KJR v3.0.1 would blow up a pre-existing stock Kerbal X:
1. Made a new blank sandbox save.
2. Launched a Kerbal X under pure stock, no mod (not even KJR) environment into a stable orbit.
3. Exited KSP and installed KJR.
4. Booted up KSP (with KJR installed) and loaded up the save with the Kerbal X.
5. Switched to it through the Tracking Station.
6. KJR did its magic.
7. Nothing out of the ordinary happened.
The end result was that KJR did not do anything bad or not intended to a pre-existing Kerbal X, in an environment where no other mods were at play.
The logs, even though I doubt they'll be interesting:
http://rpgmaker.net/media/content/users/6088/locker/PreKJR_output_log.txt
http://rpgmaker.net/media/content/users/6088/locker/PostKJR_output_log.txt
[1.x+] Community Resource Pack
in KSP1 Mod Releases
Posted · Edited by King Arthur
@DStaal @Starstrider42 I see, many thanks for the insight. I was aware that resource distribution was based on a seed that was initialized at new game start, I just wasn't aware how static or dynamic the systems beyond that seed were. If everything is generated on the fly based upon that seed, then I can understand there won't be any major problems. Fortunately I haven't setup any immovable ISRU-related infrastructure yet, so I don't have anything to worry on that front. Will I need to perform a rescan with my resource scanner satelites, or will they be updated without my intervention?
On a related note, is resource distribution in asteroids also generated on the fly like with planets? I understand that asteroids are handled like ordinary vessels in the save file, unlike planets which are on rails and not recorded in any way in save files. I got curious and took a look inside one of my save files, and asteroids have a "ModuleAsteroidResource" module with a saved value of "displayAbundance", so am I correct in presuming that KSP will generate resources in asteroids dynamically based on this number, changing composition depending upon currently active mods like CRP? I've captured a few asteroids in orbit around Kerbin and like 20 more tracked/untracked outside of Kerbin SOI, it would be a shame if CRP and similar mods only take effect for newly generated asteroids.